use UI

Tabs

Also called tab bar, tabbed interface, tab panel, tabbed navigation

A set of labelled panels occupying the same area, where selecting a label reveals its panel and hides the others.

Example

Use the arrow keys once a tab has focus, then press Tab — focus moves into the panel, not to the next tab. That single behaviour is what most hand-built tab bars get wrong.

Overview

Three deployments this week, all green. Average build time is 84 seconds.

These three panels hold different information. In a real product each would have its own URL, so a section can be linked to and survives a reload.

When to use it

  • The content splits into related but genuinely separate sections — Overview, Activity, Settings.
  • The user needs one section at a time and switching is occasional rather than constant.
  • There are two to six sections with short, predictable labels.
  • Each section is substantial enough to deserve its own space; tabs over three lines of text each is overhead.

When not to

  • The user needs to compare what is in two panels. Anything hidden cannot be compared, and they will switch back and forth trying.
  • The sections are steps in a sequence. That is a stepper — tabs imply you may visit them in any order.
  • There are more than about six, or the labels are long. Scrolling or wrapping tabs stop reading as one row and start reading as noise.
  • The content is short enough to stack. Two paragraphs behind two tabs is worse than four paragraphs on a page.
  • The panels are the same content shown differently. That is a segmented control.

Trade-offs

  • Reduces a long page to something scannable without losing anything.
  • Labels act as a table of contents for the section.
  • Deeply familiar — nobody needs to learn how tabs work.
  • Hidden content is under-discovered; people genuinely miss whole sections.
  • Panels beyond the first are invisible to in-page search (Ctrl+F), which surprises users.
  • Needs URL support to be linkable, and that is often skipped.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • Arrow keys move between tabs; Home and End jump to the first and last.
  • Only the selected tab is in the tab order — Tab from the tab list moves into the panel, not to the next tab. This is the part hand-rolled versions almost always get wrong.
  • With manual activation, arrows move focus and Enter or Space selects. With automatic activation, moving focus selects immediately — fine for cheap panels, bad if switching triggers a fetch.
Roles and state
  • The container is `role="tablist"`, each label is a `tab`, each panel is a `tabpanel`.
  • Each tab needs `aria-selected` and `aria-controls`; each panel needs `aria-labelledby` pointing back at its tab.
  • Give the panel `tabindex="0"` so keyboard users can scroll it even when it holds no focusable content.
Focus
Selecting a tab does not move focus into the panel — focus stays on the tab so the user can keep arrowing. The relationship is carried by `aria-controls`, not by moving the cursor.

In the wild

  • GitHub Repository tabs — Code, Issues, Pull requests — are distinct sections, each with its own URL.
  • Stripe Dashboard Customer detail tabs separate payments, subscriptions and events, which are rarely needed at once.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.