Tabs

Tabs organize content into multiple panels, only one of which is visible at a time, allowing keyboard users to move between tabs with arrow keys and select content with Enter or Space.

Demo

Click any tab label to display its associated content panel. With keyboard focus on the tab list, use the Left and Right arrow keys to move between tabs. Press Tab to move focus into the active panel and interact with its content. Observe how only the active panel is exposed to keyboard navigation.

What to Observe

• The tab list is announced as a group, and each tab announces its label and selected state when it receives focus.
• Arrow keys move focus within the tab list; Tab moves focus out of the tab list into the active panel's content.
• Only the active panel is visible and reachable by keyboard — content in inactive panels is hidden from both view and focus order.
• The selected tab is visually distinct from inactive tabs and communicates its state programmatically, not just through color or position.
• Each tab is associated with its panel through matching id and aria attributes, which assistive technology uses to confirm the relationship.

Anatomy

[Anatomy image placeholder — will be added when assets are available]

1. Tab list: A container with role="tablist" that groups all tab buttons and establishes the keyboard navigation context.
2. Tab button: Each tab has role="tab", an aria-selected attribute reflecting its state, and an aria-controls attribute pointing to its associated panel.
3. Tab panel: A container with role="tabpanel" holding the content for one tab; it has an aria-labelledby attribute pointing back to its controlling tab.
4. Active indicator: A visual treatment — typically an underline or background change — that distinguishes the selected tab from inactive ones.
5. Hidden panels: Inactive panels are removed from the visual layout and hidden from the accessibility tree using the hidden attribute or equivalent.

Accessibility Behavior

• The tab list container must have role="tablist", and each tab button must have role="tab".
• The active tab must have aria-selected="true"; all inactive tabs must have aria-selected="false".
• Arrow keys must move focus between tabs within the tab list; Tab must move focus into the active panel rather than to the next tab.
• Each tab panel must have role="tabpanel" and be labeled by its corresponding tab through aria-labelledby.
• Inactive panels must be hidden from both the visual layout and the accessibility tree so their content is not reachable by keyboard or screen reader.
• The selected tab must be visually distinguishable through more than color alone — shape, weight, or underline must also signal selection.

Common Mistakes

• Using plain <div> elements with click handlers instead of proper role attributes, which makes the tabs invisible to screen readers.
• Implementing Tab key navigation between tabs instead of arrow keys, breaking the expected interaction pattern for keyboard users.
• Forgetting to hide inactive panels from the accessibility tree, causing screen reader users to find and read content from panels that appear closed.
• Only using color to indicate the selected tab, making the active state ambiguous for users with color vision deficiencies.
• Not associating each panel with its tab through ARIA attributes, so the programmatic relationship between control and content is lost.

Why This Matters

Tabs are one of the most common patterns for organizing dense content in dashboards, product pages, and settings screens. When implemented without proper roles and keyboard behavior, a screen reader user encounters a set of unlabeled buttons with no indication that they control content panels, and a keyboard user cannot navigate between them predictably. The ARIA tabs pattern is well-documented and widely supported — using it correctly ensures that users relying on assistive technology get the same efficient, structured access to content that sighted mouse users experience.

Accessibility Validation

This component is validated against internal accessibility criteria aligned with WCAG standards, using our internally developed system, Resonance Specs.

To learn more, please contact us.

Code

Reference Implementation

• Back to Home
• GitHub Code