Cards screen reader behaviour when fully interactive

[aweell]

Context

The current behaviour of the cards when they behave as a full button or link is that we programatically concatenate all contents in the button or link label, although this "works" I believe there could be a better solution to solve how the content of these cards is presented to screen reader users.

Link to current card specs:
https://www.figma.com/design/tKdPOfcUALzVIh5oizFbm7/%F0%9F%94%B8-Cards-Specs?m=auto&node-id=9507-6893&t=dP1ysBZilOSJ9YvX-1

W3C design systems includes the following:

Do not wrap the contents of a card inside a singular element. This can result in the entire contents of the card being read out to screen reader users.

Reference: https://design-system.w3.org/components/cards.html#block-link-cards

An also provides a solution for cases when the card has also another link:

https://design-system.w3.org/components/cards.html#considerations-1

Vivo advanced data card

Vivo also thought about this behaviour when designing the advanced data card

I'm sure @Ro-Matos has great insights about this matter 💟

Other references

There are also another authors that already consider this as a better behaviour for interactive cards:

• Kitty Giraudel - Accessible cards
• Scott O'hara - Cards example
• Inclusive components - Cards
• ebay Mind patterns - Tile
• Fluent - Document card: The whole card is a group with an aria-label as a summary, and then each element can be reached independently.
• WAI ARIA - pattern cards

Goal

The goal is to challenge the current fully interactive cards behaviour in order to provide the best experience to screen reader users.

Additional questions

• Should be this behavior be a configuration or a default behaviour?
• If it configurable, whats the amount of content that we can consider heavy in order to reccoment avoiding programatic concatenation?
• Does what's decided in Card content grouped vs not grouped for screen readers #2147 impact how fully interactive cards behave?
• Should we update also the current list definition when interactive? I see parallelisms between both at experience level. This on the other hand goes in the opposite direction of the idea that a non interactive list should have all elements programatically concatenated.

[Ro-Matos]

Hello @aweell!
I’d like to add an observation: when a card is fully clickable, the ideal approach is to associate the interactive layer’s label (the touchable layer) with a specific element of the card — usually the Title. However, during the development of the Advanced Data Card, we faced a challenge: none of the card elements were mandatory, not even the Title.
Do you have suggestions on how we could handle this scenario?

Regarding the question:
“If it's configurable, what's the amount of content that we can consider heavy in order to recommend avoiding programmatic concatenation?”

I think that when we have more than two distinct pieces of information (e.g., title + tag + description), it already becomes too much for a single accessible label. This leads to information overload.

Regarding the other question:
“Should we update also the current list definition when interactive? I see parallelisms between both at experience level. This on the other hand goes in the opposite direction of the idea that a non-interactive list should have all elements programmatically concatenated.”

In Lists, we’ve been using concatenation in a very targeted way, usually limiting it to two pieces of information (e.g., price + value).

Finally, I’d like to know if this behavior is already being considered in the card refactoring that is currently in progress.

[aweell]

Finally, I’d like to know if this behavior is already being considered in the card refactoring that is currently in progress.

No, we kept the current behaviour, this change could be a future iteration

[aweell]

Will be solved in #2404