Aria-practices: Enhance Tabs Design Pattern to Provide Guidance on Panel Focusability

[mcking65]

Add a note to the keyboard subsection of the
Tabs Design Pattern
that provides guidance regarding when it is advisable to make the tabpanel focusable, e.g.:

1. The panel does not contain any focusable elements.
2. Focusable elements are not near the top of the content.
3. The panel content is scrollable.

[ahuth]

We're trying to wrap our heads around why the tabpanel should be focusable when there are no focusable elements within it. Can anyone shed light on why that would be? Not sure of the accessibility benefits of focusing a non-interactive tab panel.

Thanks!

[accdc]

Hi,
This was added to account for cases where a tab panel may not include any focusable interactive elements, or if a large amount of textual content appears at the beginning of the tabpanel and the first focusable active element is at the end, such as a license agreement form where the Agree button is at the very end.

If the tabpanel is not focusable, then sighted keyboard-only users will not be able to tab to the tabpanel content and read it from the beginning on down, but will instead jump to Agree and entirely skip all of the main content. This is also helpful for screen reader users who may wish to move directly from the focused expanded Tab and be placed at the beginning of the newly rendered Tabpanel content, instead of jumping passed it or moved to the end of it unexpectedly.

[ahuth]

That makes perfect sense. Thank you @accdc!

[mcking65]

Adding to carousel project because carousels are another pattern where having focusable tabpanels can be useful. In particular, some carousels enable left/right arrow keys to work as hotkeys for the prev/next buttons, and in these cases, the panel would need to be focused when the arrow keys are pressed.