Repository navigation
Selectable cards are not announced with screen reader #6798
Description
Currently, there is nothing about selectable cards that indicates to screen readers that they are selectable or interactable.
Selectable cards likely need an aria role=option and need to be placed in a parent container with an aria role=listbox
If multiple cards are selectable, then the parents container with the listbox role should also have aria-multiselectable=true and aria-activedescendant set up to contain the id of the card which currently has focus.
The parent will also need an aria-label if the list of cards does not have a title, or can reference a visual title using aria-labelledby.
When a card is selected, the card should use the aria-selected=true
this fix needs to be applied to the card/Selectable and selected example, the card/Legacy selectable and selected example, the Card view demo, the Tabs/modal tabs demo, Primary-detail card view demo.
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
jessiehuff commentedon Jan 18, 2022
This is definitely an issue and also exists similarly for Tile with this issue. I'm not so sure on the
role=listboxthough since typically I've seen this role used in dropdown-like components. The other potential issue with using that role is that we would need to add all of the other typical role expectations like implementing up/down arrow keys instead of Tab. It's an interesting idea and worth a discussion, but I'm not positive on the approach.wise-king-sullyman commentedon Mar 16, 2022
@jessiehuff since
listboxwas the solution landed on in the Tile issue should that standard be followed here?If not the only other approach I can think of would be to maybe make the cards
gridcellsand put them in agrid, but I think that's less optimal thanlistbox. If you have other suggestions though I'm all ears, my research so far hasn't led me to any.Edit: I'm going to go ahead and throw a PR up using
listbox, more than open to further discussion on the PR though.jgiardino commentedon Mar 24, 2022
Just curious if anyone looked at a solution like the one Carbon has? When I look at the implementation for Carbon, they use native html radio buttons and checkboxes to handle the keyboard interaction and semantics. They also use custom visual indicators that are visually similar to native html radio buttons and checkboxes to provide more of an affordance that these are single- or multi-select, which is also really nice for sighted users (but I realize that's a separate issue).
The carbon solution is also similar to how we've implemented the switch component:
https://www.patternfly.org/v4/components/switch/html
What's nice about using native html elements is that it handles a lot of things that we otherwise need to handle ourselves, which could raise the risk of it not being as accessible but also makes it harder to maintain. A similar sentiment is stated in this description on MDN: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/listbox_role
nicolethoen commentedon Mar 24, 2022
@jgiardino I was discussing this with @wise-king-sullyman this morning.
I think the HTML markup for Cards and Tiles came long before the 'selectable' variants. So we'd likely need to re-evaluate the structure of the component and that'd be considered a breaking change. I will make a note to consider this more semantic approach when we get a change to make breaking changes.
jgiardino commentedon Mar 24, 2022
Makes sense, @nicolethoen. Thanks for the update!