Selectable cards are not announced with screen reader

[nicolethoen]

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.

[jessiehuff]

This is definitely an issue and also exists similarly for Tile with this issue. I'm not so sure on the role=listbox though 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]

@jessiehuff since listbox was 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 gridcells and put them in a grid, but I think that's less optimal than listbox. 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]

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]

@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]

Makes sense, @nicolethoen. Thanks for the update!