Implementing accessible card components

  • 17/09/2026
  • volcanic

The card is one of the most common components in a UI (user interface). A card groups the information about a single item or topic. You use cards when a page shows several items at once.

For example:

  • A list of blog posts
  • A list of products in an online store
  • A list of hotels in a travel app

A card usually summarises a longer page. The full information lives on its own page.

Making the whole card into a link is common, and it is good practice: it gives people a much larger area to click or tap. But the way you build that link can create accessibility problems.

Three implementations follow. Use the third one.

Implementation 1: repeated links

The first option links several elements inside the card instead of one. This was common years ago. It is rarer today.

The problem: several pieces of text link to the same destination.

A product card built this way contains:

  • A link with the product name as its text. For example, “Aurora 2 wireless over-ear headphones”.
  • An image with alternative text. For example, “Aurora 2 wireless over-ear headphones, Slate”.
  • A button with a call to action. For example, “Add to cart”, or “Add Aurora 2 wireless over-ear headphones to cart” as text for screen readers only.

This looks fine to many people:

  • Several elements are linked, so the clickable area is large
  • The image has alternative text
  • The button has a full accessible name

With a screen reader it is a different experience. You hear almost the same link name three times for every card in the list.

Implementation 2: one link around the whole card

One link instead of three sounds like a clear improvement. It brings its own problems:

  • Semantic elements inside the link, such as a heading, make screen reader navigation confusing.
  • It can fail WCAG (Web Content Accessibility Guidelines) success criteria on information and relationships, and on labelling.
  • It cannot contain interactive elements such as buttons. Text styled to look like a button is not a fix. It makes accessibility worse.

A variant of this approach puts the link outside the card and uses CSS (Cascading Style Sheets) to stretch it over the card. Avoid this one too. The position of the link in the DOM (Document Object Model) does not match where it appears on screen, so the reading order and the visual order disagree. In most cases, the link also has no accessible name.

Implementation 3: the stretched link pattern

This is the current industry standard. You keep the semantics of the card, and use CSS to grow the clickable area:

  • Build the card with semantic HTML, and link one element only, such as the title.
  • Use CSS to stretch that link over the whole card. Nothing moves, and nothing is duplicated.

Four rules do it:

  1. Set position: relative on the card wrapper.
  2. Add a pseudo-element (::before or ::after) to the link.
  3. Set position: absolute on the pseudo-element.
  4. Set inset: 0 so it fills the card.

You can still add a button to the card, because the button sits outside the link. Watch out for one thing: a button on every card brings back the repetition from Implementation 1. Give each button a short, specific accessible name, then test the list with a screen reader.

Conclusion

Many tools still ship the older patterns instead of the stretched link. The technical problem is already solved. Two things are left to do:

  • Know that the pattern exists.
  • Check which pattern the tools you use produce.