Cards: Implement keyboard focus and navigation

[imageck]

Is your feature request related to a problem? Please describe

A group of cards is not accessible out of the box. To enable keyboard interaction and navigation, manual implementation is necessary.

Describe the solution you'd like

Implement a wrapper component, Cards (CardGroup is inflexible in terms of layout). When focus is moved into it, arrow keys are enabled for navigation between each individual card. Interactive elements (buttons and links) are tabbable as per usual.

CardTitle and CardSubtitle could be used for accessible name and description.

Describe alternatives you've considered

No response

Additional context

See https://www.w3.org/WAI/ARIA/apg/patterns/feed/

[jquense]

Cards aren't a general "feed" component so that pattern i don't think is appropriate for any and all cards. Cards are simply presentation wrappers around sections and content, they aren't semantically one thing that would require keyboard navigation. AFAIK simple tab order and using headers is fine here, SR's can access all the information they need

[imageck]

Right. They are not. That was just an example of how keyboard navigation might be implemented.

The web was also a simple place at first. It didn't require much, only rendered blocks of text and acted as the mediator for resource representation. Years later, we have complex layouts and representation techniques.

A simple tab order is fine when there is at most two interactive elements in a card. Tabbing through a long list of cards is bound to get tedious. Arrow navigation would allow for quick switching between cards.

Keyboard navigation has nothing to do with what SR are capable of and how they operate. I'm an abled person and I predominantly use my keyboard to code, or to browse the web, or to do anything. I don't think I'm unique in that aspect. Accessibility is not only about screen reader support.

[imageck]

For additional styling, I found this article: https://inclusive-components.design/cards/

[jquense]

I don't disagree with anything your saying, my point is more that picking a specific keyboard navigation style would be limiting Card use-cases in a way that doesn't make sense for a general UI library like this. Absolutely it might make sense to use keyboard navigation for your app cards but that's something that you would need to implement on top of RB. We couldn't add that without breaking a ton of people using cards to build more complex or semantic components