Tab Component Accessibility

Tab component accessibility ensures tabbed interfaces work for keyboard users and screen readers through proper ARIA roles, keyboard navigation patterns, and focus management. Accessible tabs enable users to navigate between content panels efficiently.

What Is Tab Component Accessibility

Tab components organize content into panels where only one panel is visible at a time. A row of tabs provides access to each panel. Users select a tab to view its associated content, switching between panels without page navigation.

The ARIA tab pattern uses specific roles: tablist for the tab container, tab for each tab button, and tabpanel for each content panel. Relationships between tabs and panels use aria-controls and aria-labelledby. aria-selected indicates the currently active tab.

WCAG requirements include keyboard operability (2.1.1), focus visible (2.4.7), and proper name/role/state exposure (4.1.2). The tab pattern has specific keyboard navigation expectations that differ from simple button navigation.

How Tab Component Accessibility Works

The tablist container uses role=“tablist” and optionally aria-label to name the tab group. Each tab uses role=“tab” with aria-selected=“true” on the active tab and aria-selected=“false” on inactive tabs. aria-controls references the associated panel’s ID.

Tab panels use role=“tabpanel” with aria-labelledby referencing their associated tab. Only the active panel is visible; inactive panels use hidden attribute or CSS hiding methods that remove them from the accessibility tree.

Keyboard navigation follows the roving tabindex pattern:

• Tab key: Enters the tablist, landing on the selected tab
• Arrow keys: Move between tabs (left/right for horizontal, up/down for vertical)
• Tab key again: Exits the tablist, moving to the next focusable element (often the panel content)
• Enter/Space: May select the tab (depending on selection behavior)

Two selection models exist:

1. Selection follows focus: Arrow keys both move focus and change the selected tab
2. Manual selection: Arrow keys move focus; Enter/Space changes selection

Selection-follows-focus provides a simpler experience but shows panels immediately on arrow navigation. Manual selection requires explicit activation but allows users to preview tabs without changing displayed content.

Key Considerations

• Use correct ARIA roles: tablist, tab, tabpanel
• Indicate selected state with aria-selected
• Associate tabs and panels with aria-controls and aria-labelledby
• Implement arrow key navigation between tabs
• Use roving tabindex so Tab moves out of the tablist, not between tabs
• Hide inactive panels from assistive technologies
• Choose a selection model (automatic or manual) and implement consistently

Common Questions

Should selection follow focus in tab components?

Selection-follows-focus is the more common pattern and often provides a better experience. Users immediately see content as they arrow between tabs. This provides direct feedback about tab contents.

Manual selection suits tabs where changing selection has significant cost (network requests, complex rendering). Users can preview tabs before committing to load content. The choice depends on implementation context; design systems should document their chosen pattern.

How should Tab panels handle focus?

When the active panel changes, focus typically remains on the tab. Users then Tab from the tablist into the panel content. Alternatively, focus can move into the panel automatically.

If panels contain interactive content that users likely want to access immediately, moving focus into the panel on selection saves a Tab keypress. If panels often contain non-interactive content, keeping focus on tabs allows quick comparison between panels.

What about vertical versus horizontal tabs?

Vertical tabs arranged in a column use Up/Down arrows instead of Left/Right. The tablist should include aria-orientation=“vertical” to communicate orientation to screen readers.

Horizontal tabs (the default) use Left/Right arrows and do not require explicit orientation. Some implementations support both arrow pairs regardless of visual orientation for flexibility.

Summary

Tab component accessibility uses the ARIA tab pattern with tablist, tab, and tabpanel roles. Arrow key navigation moves between tabs using roving tabindex. aria-selected communicates the active tab, while inactive panels hide from assistive technologies. Consistent implementation of these patterns ensures tabbed interfaces work for all users.