Tabs

This page contains the inaccessible version of the component including the description of issues, additional considerations, and also the more accessible version of the component for comparison.

(future video slot)

Inaccessible Version

Inaccessible tabs

Edit on Codesandbox

Issues

Expand each issue to see the user impact.

The tab list and tab panel are not next to each other.

Both list and panel should be next to each other - both visually and in DOM. With screen magnification software or large zoom, it may be impossible to detect tab panel switching.

Tabs are focusable but not interactive.

Although it is possible to tab through tabs, it is not possible to activate the tab by a keyboard.

Tab panels are hidden only visually.

Inactive tab panels are still accessible by keyboard and their content is discoverable. This can confuse visual users and destroys the purpose of tabs for screen reader users in the first place.

Missing ARIA attributes.

Tabs are a custom JavaScript widget, there is no native HTML element to use for that. Therefore, a couple of attributes need to be added:

• role="tablist" - a wrapper for the list of tabs
• role="tab" - a tab control also providing a label for the connected tabpanel
• role="tabpanel" - a wrapper for the tab panel content
• aria-labelledby on the tablist to provide an accessible name
• aria-selected on the tab to indicate selected tabs
• aria-controls on the tab to connect tab with tabpanel
• tabindex on the tab to control the tab sequence of tabs
• aria-labelledby on the tabpanel to provide an accessible name

Missing keyboard support.

To make the component accessible and convenient to use for keyboard users, the following key support should be added:

• The Tab key - tabbing into the tablist should focus the selected tab, and tabbing again should leave the tablist.
• The Left arrow and Right arrow keys - moving focus between tabs is done by arrows, not the Tab key.
• The Home key moves the focus to the first tab.
• The End key moves the focus to the last tab.

Note: Focusing the tab automatically activates it.

Wrong "Google" link location.

The Google link leads to apple.com, however, it should be leading to google.com.

The contrast of the currently selected tab is too low.

The color used to highlight the active tab against the inactive tabs is barely visible with low contrast.

Color is used alone to style links in the text.

Color alone is not a sufficient way to distinguish links from normal text. Low-vision or color-blind users would miss that completely, except for when the color contrast is very high.

max-height is used on the tab panel.

The tab panel limits the height of the content inside even without using a vertical scrollbar. On smaller resolutions (or with more content), users would lose a part of the content.

Considerations

The usage of certain techniques depends on the circumstances. Expand each consideration to learn more.

Consider changing the tab switch from hover to click event.

Hovering over something should not ideally cause a change in context, but there are exceptions. Tabs are usually switched either by activation or by selecting them by arrows.

Consider making the tabpanel focusable.

If there are no focusable elements in panels, users might miss the content in the panel. In such situations, it is recommended to put the tabindex="0" to the tabpanel.

Consider using links or buttons as tabs.

Depending on the circumstances, tabs can also be developed as buttons or links (anchors). This should depend on the content importance and amount.

More Accessible Version

More accessible tabs

Edit on Codesandbox