UX Patterns Guide
UI + UX Navigation And Wayfinding standard

Tabs

Group sibling panels behind labeled tabs, keep one active at a time, and make the active section and panel relationship explicit.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users switch between sibling panels frequently.
  • Only one section needs to be visible at a time.

Avoid when

  • The destinations are unrelated pages.
  • Users need to compare all sections at once.
  • The content must be read in sequence.
  • There are too many labels to fit without wrapping, truncation, or horizontal scrolling.

Problem it prevents

Users need to switch between peer sections without leaving the current page context.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Tabs in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The content areas are peers under the same parent task.

Pattern promise

Group sibling panels behind labeled tabs, keep one active at a time, and make the active section and panel relationship explicit.

Required state

Default active tab and visible panel.

Recovery path

Changing URL pages while presenting the control as local tabs.

Access contract

Expose the active tab and associated panel.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Tab labels are short, active tab is obvious, focused tab is distinguishable, and panel content is visually attached to the selected tab.
  • The current panel has a heading and stateful controls while inactive panels stay hidden from the visual surface.
  • Users switch between sibling sections without leaving page context or losing panel-local notes.
  • Keyboard users can move focus with arrows, activate with Enter or Space, and then reach the selected panel.
Weak implementation

Vague, hidden, hard to recover from

  • Tabs wrap unpredictably or look like unrelated buttons.
  • Low-contrast active tab that users cannot distinguish from focused or inactive tabs.
  • Using tabs as primary navigation to unrelated pages.
  • Hiding required workflow steps or comparison-critical content in mutually exclusive panels.
UI guidance
  • Render a tablist with short tab labels, selected tab styling, visible keyboard focus, and a single associated tabpanel that is visually connected to the active tab.
  • Show enough panel identity, heading, and preserved state for users to understand what changed when a tab is activated.
UX guidance
  • Help users switch between sibling sections in the same page context without changing routes or losing local work.
  • Avoid tabs when users must compare panels, read panels sequentially, or complete required workflow steps.
Implementation contract

What the implementation must handle

States

  • Default active tab and visible panel.
  • Inactive tab states that remain readable and selectable.
  • Focused tab that may differ from the selected tab during manual activation.
  • Panel state after a tab is selected.

Interaction

  • Changing tabs updates the visible panel without losing the surrounding page context.
  • The active tab is programmatically exposed with its controlled panel.
  • Keyboard users can move between tabs and reach panel content.
  • When activation is manual, arrow keys move focus and Enter or Space activates the focused tab.

Accessibility

  • Expose the active tab and associated panel.
  • Keep focus order predictable between tab list and panel.
  • Use aria-controls and aria-labelledby so each tab and panel relationship is explicit.
  • Arrow keys move focus between tabs when using ARIA tabs.

Review

  • Are these sections truly peers in the same task context?
  • Would users miss, forget, or need to compare content hidden in another panel?
Evidence trail

Source-backed claims behind this guidance

WAI-ARIA APG Tabs Pattern

W3C Web Accessibility Initiative - checked

APG documents tablist, tab, tabpanel, aria-controls, aria-selected, arrow-key movement, and manual activation.

GOV.UK Design System Tabs

GOV.UK Design System - checked

GOV.UK supports tabs for related content shown one section at a time and warns against page navigation, sequential reading, and cross-panel comparison.

Carbon Design System Tabs

IBM Carbon Design System - checked

Carbon distinguishes line, contained, and vertical tabs, connects selected tabs to panels, and warns not to use vertical tabs as replacement navigation.

Full agent/debug reference

Problem Context

  • The content areas are peers under the same parent task.
  • Users benefit from quick switching without page navigation.
  • Only one section should be visible at a time and hidden sections are not required for sequential reading.

Selection Rules

  • Choose tabs for sibling sections at the same hierarchy level that share one surrounding page context.
  • Keep tab labels short, stable, and content-specific so users can predict the panel before opening it.
  • Use segmented controls when the choice changes a local mode or presentation rather than revealing a content panel.
  • Use pagination when users are moving through one ordered collection split into pages.
  • Use page navigation, headings, or a table of contents when users need to read content in order or compare sections side by side.

Required States

  • Default active tab and visible panel.
  • Inactive tab states that remain readable and selectable.
  • Focused tab that may differ from the selected tab during manual activation.
  • Panel state after a tab is selected.
  • Hidden panel state that is not exposed as current content.
  • Overflow or small-screen state when labels no longer fit.

Interaction Contract

  • Changing tabs updates the visible panel without losing the surrounding page context.
  • The active tab is programmatically exposed with its controlled panel.
  • Keyboard users can move between tabs and reach panel content.
  • When activation is manual, arrow keys move focus and Enter or Space activates the focused tab.
  • Panel-local inputs, scroll, or draft content are preserved or intentionally reset with clear feedback.

Implementation Checklist

  • Use tablist, tab, and tabpanel semantics or equivalent native structure.
  • Expose selected state and panel ownership.
  • Keep panel content mounted or restore state intentionally.
  • Do not overload tabs with unrelated navigation.
  • Decide whether activation is automatic or manual based on panel latency.
  • Provide a responsive fallback when tab labels wrap or overflow.

Common Generated-UI Mistakes

  • Using tabs as a primary site navigation system.
  • Hiding required form steps in tabs without completion state.
  • Using ambiguous tab labels that force users to inspect every panel.
  • Putting content that users must compare into mutually hidden panels.

Critique Questions

  • Are these sections truly peers in the same task context?
  • Would users miss, forget, or need to compare content hidden in another panel?
Accessibility
  • Expose the active tab and associated panel.
  • Keep focus order predictable between tab list and panel.
  • Use aria-controls and aria-labelledby so each tab and panel relationship is explicit.
Keyboard Behavior
  • Arrow keys move focus between tabs when using ARIA tabs.
  • Enter or Space activates a focused tab when activation is manual.
  • Tab moves from the active tab area to the current panel content.
  • Do not make all hidden panel controls reachable in the page tab order.
Variants
  • Horizontal tabs
  • Vertical tabs
  • Icon and label tabs

Verification

Source trail checked:

Saved items