Better Tabs Overflow

[NicholasBoll]

🚀 Feature Proposal

Better keyboard and screenreader consistency and support in our Tabs overflow solution.

Motivation

Currently, our Tabs overflow into a separate menu when there isn't enough room to render all the tabs. This separate menu is a button that is not associated with the role=tablist. This means the user must open the button in order to see additional tabs. Since this button is not associated with the tablist, keyboard users can use the arrow keys to access the visible tabs, but not to open the menu. Screen reader users will "see" only visible tabs exist and will "see" a "More Tabs" button.

For example, let's say there is 8 tabs. Here's the experience for different modality users if all tabs are visibly rendered:

• Mouse: User can see and click any tabs
• Keyboard: All tabs can be accessed via the arrow keys. Enter key will activate the tab.
• Screen reader: Screen reader will announce "tablist, 1 of 8 tabs, {tab name}...". Arrow keys will "focus" each tab, announcing the name. Enter key will activate

If only 5 tabs are visibly rendered (keep in mind a screen reader user might have a smaller screen size as physical pixels rendered is less important)

• Mouse: User can see 5 tabs. The "More Tabs" button is rendered next to the tabs. Clicking the button will show the additional 3 tabs, and clicking a menu item will activate the tab.
• Keyboard: User can see 5 tabs and arrow through the list of 5 tabs (focus wraps with arrow keys). The user cannot use the arrow key to activate the "More Tabs" menu. The user must use the tab key to focus the "More Tabs". A space/enter key will open the menu. From there, the arrow keys can be used to focus the menu item and space/enter will activate the tab and the menu will close.
• Screen reader: Screen reader will announce "tablist, 1 of 5 tabs, {tab name}...". To a screen reader user, they will think only 5 tabs exist. Normally hitting the "tab" key will move to the tabpanel, but instead will land on a "More Tabs" menu button. When they activate this, they will get something like "menu More Tabs, 1 of 3 items, {tab name}". The arrow keys will work as normal. Also screen readers come with additional modes that may not use focus order or JS-based key events. The "More Tabs" is discoverable, but there's some confusion why all tabs where not in the tablist. If the screen reader user cannot see the physical pixels, there's no concept of "not enough room to render" and the truncation of the tablist seems arbitrary.

This PoC changes the interaction a bit to make the experience of a keyboard user and a screen reader user more consistent with if overflow wasn't happening: https://835t8.csb.app/. To these users, the experience is the same whether all tabs are rendered or an overflow exists. A screen reader user who cannot see the screen won't know or care that the tabs are being overflowed into a menu, because the menu is actually part of the tablist where each menu item is actually a role=tab. To a screen reader user, the tablist announces "1 of 8 tabs".