Bug - Tabs - Tabs do not behave as expected for keyboard users (accessibility)

[kdoberst]

Describe the problem When navigating the tab list via keyboard, unexpected items have focus and standard expected keyboard keys are not functional.

See: https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/ For the W3C standards on how the tab widget is expected to function when navigating via the keyboard.

How do you reproduce the problem? Any PF tab list and keyboard will due. See https://www.patternfly.org/v4/components/tabs

Expected behavior Summarizing from: https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/

When I use the keyboard tab key and select the tab list, I shall be able to use the arrow keys (up/down for vertical tabs and right/left for horizontal tabs) to move between (aka select) different tabs.

When I click on the keyboard tab key again, I expect to have the tab panel (aka the tab content) to be selected.

Current behavior When I use the keyboard tab key and select the tab list, the arrow keys are non-functional.

When I currently have the tab list selected and I click on the keyboard tab key, I am unexpectantly brought to the next tab instead of the content.

Is this issue blocking you? Technically you can get to the content, but only in non-standard and unexpected ways. Beyond being unexpected and having to somehow know how the tabs work, navigating via the keyboard as currently implemented is time-consuming and confusing vs the standard approach. I would consider this a major accessibility issue.

What is your environment?

• OS: [e.g. iOS]: Any (I tested using a macbook pro using OS 11.7.1)
• Browser [e.g. chrome, safari]: Any (I tested using chrome 108.0.5359.124 )

What is your product and what release date are you targeting? OCM

Any other information?

I'm an expert in mediating accessibility issues, and I fixed numerous tab sets in my day. Please feel free to contact me via the Internal Red Hat slack if you have questions or need assistance.

[kdoberst]

@nicolethoen I noticed that this bug has been marked as "needs info" is there anything I can help with?

[nicolethoen]

Hi @kdoberst! thank you for opening the issue. We have a group on the PF team which focuses on accessibility and so we are planning to add this issue to the agenda when we all meet next to make sure that we triage it correctly. If any questions come from that meeting, we will be sure to reach out!

[nicolethoen]

Okay @kdoberst, I've had a chance to process this proposal to the a11y folks on the PF team.

I think, for the most basic use case of tabs, this interaction pattern would absolutely be ideal. My concern is the fact that the Tabs component in PatternFly is encompassing many more complex use cases.

Consider the following examples which would require significant interaction overhaul to use arrow keys to move through tabs:

• Horizontal overflow where there is a dropdown menu on one of the tabs.
• Tabs with subtabs where there are two levels of tabs, one directly below the other
• Dynamic tabs - which creates a scenario were all the tabs may not be on the page on page load, and adds intractable close buttons to the tabs
• With help action - which creates help icons which display more information on focus
• with help and close actions - which puts two interactable elements on each tab

It doesn't rule out the possibility of using arrow keys to move between tabs, but it does significantly complicate the implementation and focus management. Does the existence of these features, which make our tabs behave a bit more like browser tabs than, a typical tabs panel, provide more context for our decision to implement it the way we have for now?

I just want to be sure that we are not nesting interactable elements or mixing patterns for moving between interactable elements in any of these cases and further complicating user interactions.

@thatblindgeye @jessiehuff @srambach

[kdoberst]

It would be really nice to have at least basic tabs that meet standards and user expectations.

[nicolethoen]

@kmcfaul I wonder if we could wire up an example or a codesandbox to use the keyboard handler functions with the Tabs component so that arrow keys can move focus in our basic tab examples

[kmcfaul]

The helper functions (or the whole helper component) should cover the arrow key behavior with some setup for references, while the tab handling might take a bit of extra handling. I think it should be possible overall.