Tabs

Tabs trade a set of separate pages for one page that changes what it shows. That trade only pays off when every panel is a peer of the others, equally worth reaching, because a tab strip presents all its options as if they cost the same click.

Anatomy of tabs

The list of triggers sits above the content it controls, and only one trigger is ever marked active at a time. The active indicator has to be visible enough to answer "where am I" at a glance, because the panel underneath changes completely and gives no other clue.

Here it is working. Click through the labels and watch the indicator and the panel move together.

Variants

Segmented. Triggers sit inside a rounded, filled track, and the active one gets its own background. Reads as a single control, which suits a small, fixed set like a view switcher.

Underline. A thin line marks the active trigger against a plain background. Reads lighter and suits a strip that sits above a large content area, like a settings page.

With counts. A small number beside a label, for panels whose size is worth knowing before you open them, like "Comments (12)".

States

Focus and active look similar enough to blur together if the ring is too subtle. Arrowing across a tab strip moves focus one trigger at a time without changing the active panel in some implementations, so the two states need to read as clearly different things.

How tabs behave

Only one panel renders at a time. The others unmount or stay hidden, which is what makes tabs fast to switch and unsuitable for content someone needs to compare side by side.

Selecting a tab is immediate. No confirm step, no separate button. Clicking or arrowing to a trigger and pressing Enter shows that panel right away.

The strip doesn't reorder itself. Tabs stay in the same position every time the page loads, even if usage data says one panel gets clicked more than the others. A jumping tab order breaks the spatial memory tabs are meant to build.

Content below the strip can change height. Unless every panel is padded to match the tallest one, switching tabs shifts whatever sits below them on the page. Reserve a minimum height if that shift is disruptive.

Tabs accessibility

Keyboard

The rest

• Follow the WAI-ARIA tabs pattern. role="tablist" on the strip, role="tab" on each trigger with aria-selected, and role="tabpanel" on the content, connected with matching aria-controls and aria-labelledby.
• Only the active tab sits in the normal tab order. The rest are reachable by arrow keys once focus enters the strip, following the same single-tab-stop pattern as a radio group.
• Give the tablist an accessible name with aria-label, so a screen reader user knows what the group of tabs is for before hearing the individual labels.
• Contrast. The active indicator needs 3:1 against the background it sits on (WCAG 1.4.11), the same bar as any other non-text UI indicator.
• Target size. 24 by 24 CSS pixels minimum at Level AA (WCAG 2.5.8), which usually means padding a short label rather than shrinking the strip to fit its text.

What tabs should say

Labels are short nouns. "Reviews", not "See what people are saying". A tab strip is meant to be read in one glance across its full width.

Keep every label roughly the same length. One long label beside four short ones breaks the strip's rhythm and makes the odd one out look separate from the group.

Order by what people need first. Overview before Specs before Reviews, not alphabetical. The default tab should be the one most visits actually want.

Common tabs mistakes

The one that causes real support tickets is a required field sitting on a tab nobody opened, so the form fails to submit with no visible reason why.

1. A required field hidden on an unselected tab. The validation error has nothing to attach to on screen. Either validate before allowing a tab switch away from an incomplete panel, or route the person back to the tab that holds the problem.

2. Tabs used for a linear, step-by-step flow. Checkout steps aren't peers, they're a sequence, and a tab strip implies any of them can be opened in any order. That's a stepper's job, not this component's.

3. More tabs than fit in one row. A wrapped or horizontally scrolling strip past 7 or so items costs more attention than it saves. Group the overflow under a select or move it to a side navigation.

4. No URL sync for content worth sharing. A reader who copies the page's link and sends it lands back on the first tab, not the one they meant to show.

5. An active state that's only a colour change. Someone with low vision or colour blindness needs a second signal, like an underline or a filled background, not text colour alone.

6. Reordering tabs based on usage. Moving "Reviews" ahead of "Specs" because it gets clicked more breaks the spatial memory a returning visitor built on the last ten visits.

How to build tabs

<div role="tablist" aria-label="Product details">
  <button role="tab" id="tab-overview" aria-selected="true" aria-controls="panel-overview">
    Overview
  </button>
  <button role="tab" id="tab-specs" aria-selected="false" aria-controls="panel-specs" tabindex="-1">
    Specs
  </button>
  <button role="tab" id="tab-reviews" aria-selected="false" aria-controls="panel-reviews" tabindex="-1">
    Reviews
  </button>
</div>

<div role="tabpanel" id="panel-overview" aria-labelledby="tab-overview">
  <!-- Overview content -->
</div>
<div role="tabpanel" id="panel-specs" aria-labelledby="tab-specs" hidden>
  <!-- Specs content -->
</div>
<div role="tabpanel" id="panel-reviews" aria-labelledby="tab-reviews" hidden>
  <!-- Reviews content -->
</div>

Arrow keys move focus between triggers and update aria-selected and tabindex, so only the active trigger sits in the page's normal tab order. Panels toggle hidden to match, and each one is labelled by the trigger that opens it rather than repeating the label as a heading.

Edge cases

A panel with no content yet. Show a real empty state inside the panel rather than leaving it blank, so switching to it doesn't read like a bug.

Deep linking to one tab. Read the active tab from a query parameter or route segment on load, and write it back on every switch, so a shared link and the browser back button both land on the right panel.

A label too long for its space. Truncate with an ellipsis and keep the full label available on focus or hover, never shortened so far it stops being distinct from its neighbours.

Nested tabs. Two tab strips stacked, one controlling the other's panels, is rare and usually a sign the content needs a different structure, like a sidebar plus tabs, rather than tabs inside tabs.

Tabs in real products

Stripe's dashboard uses an underline tab strip across the top of a settings page, with the URL synced to each tab so a support link can point straight at "Webhooks" instead of "Settings".

GitHub's repository page uses tabs for Code, Issues, Pull requests and more, each one a real page with its own URL rather than a client-side panel swap, so every tab is bookmarkable and indexable on its own.

Linear's issue view uses a segmented control to switch between "Activity" and "History" on the same issue, a small, fixed set where the contained pill style reads as one control rather than a page section.