Axon 911 Frontend DocsAxon 911 Frontend Docs
Axon 911 Frontend Docs
    Loading navigation…
U
User
Switch to light mode
  1. Components
  2. Tabs
  3. Accessibility

Tabs

Accessibility

Tabs from @prepared911/ui/tabs implements the WAI-ARIA Tabs pattern. Trigger-to-panel association, orientation, roving focus, and keyboard behavior are built in; your job is to name the tab list and to keep focus behavior inside panels sensible.
What the component handles
  • Role assignment. TabsList → tablist, TabsTrigger → tab with aria-selected and aria-controls, TabsContent → tabpanel with aria-labelledby.
  • Orientation. aria-orientation on the tab list reflects horizontal or vertical layout and drives arrow-key direction.
  • Focus flow. Focus moves into the active trigger, then Tab moves into the focused panel.
  • Activation model. Default automatic activation on arrow keys; activation={TabsActivation.Manual} keeps arrows on focus until Enter or Space.
  • Scrollable tab lists. With listOverflow={TabsListOverflow.Scroll}, arrow-key roving focus is unchanged. When focus moves to a tab outside the visible scrollport, the list scrolls that tab into view (scrollIntoView). Scroll padding and clip margin reserve space so focus rings stay visible at the edges of the scrollport (WCAG 2.4.11).
  • Fill and panel scroll. With fill on panel Tabs, the root grows in a flex parent and each TabsContent panel scrolls inside itself.
What you must provide
  • Tab list label. On TabsList, set label (LocalizedMessage, rendered as aria-label) or aria-labelledby. The panel-mode Tabs root has no role; the accessible name belongs on the tablist, not on a wrapper div.
  • Descriptive trigger text. Keep triggers concrete ("General", "Privacy"), not generic ("More"). Icon-only triggers need aria-label.
  • Panel content that doesn't trap. If a panel holds complex interactive content (forms, editors), ensure its own focus management doesn't conflict with the tab pattern.
Testing
Locate tabs only through roles and names:
  • getByRole("tablist", { name: "…" })
  • getByRole("tab", { name: "…" })
  • getByRole("tabpanel", { name: "…" }) (the panel name comes from the tab that labels it)
Do not wrap Tabs, TabsList, or TabsContent in extra elements just to attach data-test-id or to query structure. Do not disable testing-library/no-node-access to reach into a design-system tab; if a part is not findable by role, treat that as a design-system defect.
Keyboard behavior
KeyAction
TabMoves focus into the active trigger, then into the panel.
Arrow Left / RightMoves between triggers in horizontal layouts.
Arrow Up / DownMoves between triggers in vertical layouts.
Enter / SpaceActivates the focused trigger (manual mode selects).
Home / EndJumps to the first / last trigger.
Semantics and roles
ElementRoleKey attributes
TabsListtablistaria-orientation, accessible name
TabsTriggertabaria-selected, aria-controls
TabsContenttabpanelaria-labelledby
Provide a tab list label:
Screen reader announcements
Typical sequence when navigating:
  1. Focus enters the trigger list → "Account settings, tab list".
  2. First trigger → "General, tab, selected, 1 of 2".
  3. Arrow right → "Privacy, tab, 2 of 2".
  4. Enter → "Privacy, tab, selected, 2 of 2"; panel content updates.
Focus management
  • Focus stays on the active trigger after activation; Tab moves into the panel.
  • When a panel contains interactive elements, Tab reaches them directly from the trigger.
  • Respect focus restoration when tabs are controlled by external state (e.g., query parameters).
  • On a scrollable tab list (TabsListOverflow.Scroll), roving focus does not trap inside the scrollport: Home, End, and arrow keys still move among all tabs, and the list scrolls to keep the focused tab visible.
Known caveats
  • Lazy panels. If panels mount lazily, ensure the panel's content is rendered before screen readers try to read it. A momentarily empty tabpanel can confuse assistive tech.
  • Destructive actions inside panels. Confirm in a Dialog; never rely on a tab change to "cancel" a destructive flow.
Related accessibility pages
  • Tabs Accessibility: keyboard behavior for non-navigational tab strips.
  • Tabs Accessibility: link-based navigation tab semantics.
Previous
Tabs / API and Development
Next
Task / Usage
On this page
What the component handles
What you must provide
Testing
Keyboard behavior
Semantics and roles
Screen reader announcements
Focus management
Known caveats
Related accessibility pages