Topics

Accessible Implementation Patterns for Card Components

  • column

Card components are commonly used in article listings. Their appearance is simple, but once accessibility is taken into account, they present surprisingly deep design challenges.

A typical card consists of, from top to bottom:

  • Image
  • Article title
  • Article summary
  • Details link

Let's consider implementation patterns for a vertically stacked layout.

Key Design Considerations

1. Visual Order and HTML Structure

Screen readers generally read content in the order it appears in the HTML. Success Criterion 1.3.2 (Meaningful Sequence, Level A) in WCAG 2.0 is based on the principle that the visual order should match the HTML order.

However, changing the order with CSS does not automatically violate WCAG. As long as the content remains understandable even when the visual and HTML orders differ, there is no issue. It is important to make this judgment based on the context.

2. Handling Images

Images on article cards are often decorative. Since the article title typically conveys the content sufficiently, there is generally little need to have the image description read aloud.

When treating an image as decorative, alt="" alone is sufficient.

<img src="thumbnail.jpg" alt="">

3. Labels for Detail Links

Generic text such as "View details" should be avoided for the following reasons.

Visual issues

Without the surrounding context, it is impossible to tell where the link goes.

Screen reader issues

When links are listed using the links list feature, every one reads "View details," so users cannot tell them apart.

Voice recognition issues

When multiple identical texts exist, users must select by number, which makes operation cumbersome.

Ideally, link text should make the purpose clear on its own, such as "View details of [item name]". However, this section covers how to implement the design as-is, with the "View details" text unchanged.

4. Clickable Areas on Cards

To improve UX, teams often want the entire card to be clickable. There are several ways to implement this, and each has different accessibility implications.

5. Should Cards Use article or div?

The choice depends on the nature of the content.

<article>Suitable when:

  • Each card's content works as a standalone piece of content

<div>Acceptable when:

  • The cards function merely as a group of links
  • The cards have no inherent semantic independence of their own

For typical blog post listings or product listing cards, <article>a section element with an article-level structure is appropriate. However, when multiple <article>section elements are used, consider screen reader landmark navigation and identify each article using aria-labelledby or aria-label (WCAG 2.4.6, Level AA).

When using aria-labelledby, make sure each ID is unique.

Visual order and HTML structure

Pattern 1: Match visual order to HTML order

<article class="article-card" aria-labelledby="article-title">
  <img src="thumbnail.jpg" alt="">
  <h3 id="article-title"><a href="#" class="card-link">記事タイトル</a></h3>
  <p>記事の概要...</p>
  <a href="#" class="card-detail-link">
	  <span class="visually-hidden">記事タイトル:</span>詳細を見る
  </a>
</article>

Because the order of the HTML markup matches the visual order exactly, the approach is simple and intuitive.

Note: It is generally recommended that the first element of <article>the structure be a heading, but this is not an absolute requirement. If matching the visual order takes priority, this pattern is acceptable.

Additional note:

Voice recognition software (such as Dragon or Voice Control) operates based on the text displayed on screen. By using visually-hidden (sr-only), visible text is preserved, allowing users to operate elements via voice recognition. Below are implementation examples of acceptable and unacceptable patterns for link label handling.

<!-- 以下は可視テキストがアクセシブルな名前に含まれているのでOK -->
<a href="#" id="link-text" class="card-detail-link" aria-labelledby="link-text article-title">
  詳細を見る
</a>
<a href="#" aria-label="詳細を見る:記事タイトル">
  詳細を見る
</a>
<!-- 以下は可視テキストがアクセシブルな名前に含まれていないのでNG -->
<a href="#" class="card-detail-link" aria-labelledby="article-title">
  詳細を見る
</a>
<a href="#" class="card-detail-link" aria-label="記事タイトル">
  詳細を見る
</a>

Pattern 2: Adjusting visual order with CSS order

<article class="article-card" aria-labelledby="article-title">
  <h3 id="article-title"><a href="#">記事タイトル</a></h3>
  <p>記事の概要...</p>
  <a href="#" class="card-detail-link">
	  <span class="visually-hidden">記事タイトル:</span>詳細を見る
  </a>
  <img src="thumbnail.jpg" alt="">
</article>
.article-card {
  display: flex;
  flex-direction: column;
}

.article-card img {
  order: -1;
}

Because the first element is a heading, <article>this structure is semantically more appropriate.

For decorative images (alt=""), there is no impact on the reading order, since the images are skipped.

Caution:

  • When an image is meaningful and has an alt attribute specified, this structure is not suitable because the visual order and reading order will differ.
  • Keyboard Tab order follows the HTML order, so if a card contains multiple focusable elements, make sure the focus sequence does not break the logical flow.

When you want the entire card to be clickable

Pattern 3: Make the entire card clickable with a pseudo-element

With this approach, the pseudo-element of the title link covers the entire card, and the "View details" text is <span>kept purely as a visual decoration.

Even if "View details" is <a>left as-is with tabindex="-1" or aria-hidden="true", it would still add noise to screen reader link lists and element navigation modes, so I believe it's better to <span>make it decorative.

<article class="article-card" aria-labelledby="article-title">
  <img src="thumbnail.jpg" alt="">
  <h3 id="article-title"><a href="#" class="card-link">記事タイトル</a></h3>
  <p>記事の概要...</p>
  <span class="card-detail-link">詳細を見る</span>
</article>
.article-card {
  position: relative;
}

.card-link::after {
  content: '';
  position: absolute;
  inset: 0;
  z-index: 1;
}

.card-link:focus-visible {
  outline: none;
}

.card-link:focus-visible::after {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

/* カード内に複数のリンクがある場合の例 */
.article-card a:not(.card-link) {
  position: relative;
  z-index: 2;
}

Advantages:

  • Preserves semantic structure
  • Screen readers read it naturally
  • Multiple links can be placed within the card (e.g., category, tags, author links)

Disadvantages:

  • Requires managing z-index (though once set, it causes no problems)

Pattern 4: Wrap the entire card in <a>

With this approach, the entire card becomes a single link, so "View details" naturally becomes <span>

<article class="article-card" aria-labelledby="article-title">
  <a href="#" class="card-link">
    <img src="thumbnail.jpg" alt="">
    <h3 id="article-title">記事タイトル</h3>
    <p>記事の概要...</p>
    <span class="card-detail-link">詳細を見る</span>
  </a>
</article>

Advantages:

  • Simple implementation
  • Easy CSS adjustments

Disadvantages:

  • Depending on the screen reader, all of the text may be read out as one continuous string (with VoiceOver in particular, it reads as "Article title Article summary... View details, link").
  • Multiple links cannot be placed within the card.

Sample of each pattern

Summary

There are multiple approaches to implementing accessible card-style components. The important point is that there is no single "correct" implementation pattern; the optimal solution varies depending on the situation.

When implementing, it is important to keep the following in mind.

  1. Choose an implementation that works well for the people who actually use it
  2. Consider the meaning of images, the purpose of the card, and the overall structure of the site
  3. Prioritize practical, maintainable implementations

About the author

Starting out in DTP and moving into the web, he now handles markup, frontend, direction, and accessibility alike. A "master of all trades" who has been versatile since Liberogic's early days and is now a walking encyclopedia of the company. Lately he has been hooked on exploring efficiency through prompts, asking, "Can't we rely more on AI for accessibility work?" Both his skills and his thinking are still evolving.

Ayumu Futamata

IAAP Certified Web Accessibility Specialist (WAS) / Markup Engineer / Frontend Engineer / Web Director

View this staff member's articles

Case Studies