Accessibility
The Tabs component follows the WAI-ARIA Tabs pattern — a tablist whose tabs each reveal a panel — and meets WCAG 2.1 AA. An accessible tabs strip stays reachable and operable from the keyboard, keeps assistive technology informed of which tab is selected and which panel it controls, and gives every element an accessible name — so the current view is clear whether the user is looking at it, listening to it, or tabbing through it. The Tab Picker wears the same visual but is a radio group, and none of this page’s roles or keys apply to it.
For designers
Section titled “For designers”- All states (rested, hover, active, disabled) must maintain accessible contrast on every supported surface. Source: WCAG 1.4.3 Contrast (Minimum).
- Selection must never rely on colour alone — reinforce it with the emphasised label weight and the active border, so it survives for colour-blind users. Source: WCAG 1.4.1 Use of Color.
- Focus styles must stay visible, meet contrast requirements on every supported surface, and be clearly distinguishable from hover. Source: WCAG 2.4.7 Focus Visible.
- Use semantic colour tokens (e.g.
foreground/neutral/default) rather than fixed values, so the component adapts correctly across themes and surfaces.
For developers
Section titled “For developers”Tabs follow the WAI-ARIA Tabs pattern: a tablist of tab buttons, each revealing its own panel, with inactive panels kept in the DOM under the hidden attribute so the tab-to-panel relationship survives. The recipe uses auto-activation — moving to a tab with the arrow keys selects it and reveals its panel in one step — and keeps focus on the tab rather than shifting it into the panel.
Pick the pattern by what the component means, not how it looks: if the strip chooses a value rather than revealing a panel, it is a Tab Picker and needs a radio group instead of this one.
The per-element roles, names, and states are in the Labelling elements section below.
Keyboard interaction
Section titled “Keyboard interaction”The tablist is fully operable from the keyboard, with auto-activation. Source: WCAG 2.1.1 Keyboard.
| Key | Action |
|---|---|
| ← / → | Move to and activate the previous / next tab |
| Home / End | Move to and activate the first / last tab |
| Enter / Space | Activate the focused tab |
| Tab | Move focus out of the tablist to the next control |
Interactive targets must be large enough for comfortable touch use, comfortably clearing the WCAG AA minimum. Source: WCAG 2.5.8 Target Size (Minimum).
Focus order
Section titled “Focus order”Tab lands on the focused tab — a roving tabindex keeps only that one tab in the page tab sequence while the arrow keys rove between the others — then a further Tab leaves the tablist for the next control. The keys that drive this are in the Keyboard interaction table above.
Overview content goes here.
- Focused tab
Source: WCAG 2.4.3 Focus Order.
Labelling elements
Section titled “Labelling elements”Give every element the role, name, and state assistive technology needs.
Tab list
role="tablist" on the strip. Name it with aria-label (the recipe uses aria-label="Content tabs") or aria-labelledby, so it doesn’t announce as an unnamed group.
Tab
role="tab" on each <button>, with aria-selected kept in sync (true on the selected tab, false on the rest) and aria-controls pointing at the panel it reveals. Each tab takes its accessible name from its text content — keep labels short and self-describing.
Tab panel
role="tabpanel", named back to its tab with aria-labelledby, and hidden while inactive. Give it tabindex="0" when it holds no focusable content, so keyboard users can still reach the panel.
Source: WCAG 4.1.2 Name, Role, Value.