Skip to content

Tabs

Tabs organize content into separate views where only one view is visible at a time.

Ready to use

Design Develop Accessibility

The Tabs component lets users switch between different views or sections of content within the same page, without navigating away. It organises related information in a compact, accessible way — improving content discoverability and reducing cognitive load. Tabs work best when content is related but needs to be divided into smaller, manageable sections such as product details, settings, or data panels.

Anatomy

Section titled “Anatomy”
  1. Tabs container
  2. Tab item
  3. Active indicator
  4. Panel

When to use it

Section titled “When to use it”

Use Tabs when:

  • You need to organise related content into separate sections within the same context.
  • Users should be able to switch between different views without leaving the page.
  • The pattern improves the clarity of complex or lengthy interfaces.

Avoid Tabs when:

  • The sections aren’t closely related, or users need to compare content side by side.
  • There are too many tabs — navigation becomes overwhelming.

Properties

Section titled “Properties”

Scheme

Neutral or Contrast. The container picks up the scheme tokens so the tab item colours flip when the surrounding surface is dark — no per-tab overrides needed.

Variant

Two visual variants: Default (no fill behind active tab) and Filled (contrast fill on the active tab). Default suits most cases — reserve the filled variant for specific scenarios where the fill is needed (for example EV Tools like the Charging Time Calculator).

State

Rested, Hover, Active, and Disabled. The active state is reinforced with a bolder weight and a coloured border, so the cue isn’t carried by colour alone.

EV accent

A special border colour for the active tab when the Tabs sit inside an EV-tools surface. Use only for EV Tools — not as a general accent.

Platform considerations

Section titled “Platform considerations”

Desktop

Tabs sit in a single row at the top of the panel. Keep labels short enough to fit on one line so the comparison reads at a glance.

Tablet

Same row layout. Make sure the tab row doesn’t overflow horizontally — if labels grow, consider shorter wording or a different navigation pattern.

Mobile

Tabs can scroll horizontally when there’s no room for the full set. Keep each label short so the visible portion still names the section.

Best practices

Section titled “Best practices”

Use ARIA semantics so keyboard, focus, and assistive-tech behaviour come for free.

Do

Keep tab labels short, clear, and descriptive; ensure exactly one tab is selected at a time; provide visible focus indicators for keyboard users; use proper heading hierarchy within panels; pair an active visual with bold text or an underline so the cue isn’t colour-only; use the default no-fill variant in most cases and reserve the filled variant for EV Tools.

Don't

Don’t mimic tab behaviour with <div> elements that lack ARIA roles, don’t allow multiple tabs to be selected at once, don’t remove inactive panels from the DOM (use hidden instead so accessibility holds), don’t auto-shift focus to the panel on tab switch (keep focus on the tab), don’t rely on colour alone to indicate the active tab, don’t let labels wrap or truncate, and don’t use tabs for unrelated or excessively long content (split it into separate pages).

Content guidelines

Section titled “Content guidelines”

Tab labels should name the section they reveal, in one or two words (“Overview”, “Specifications”, “Reviews”). Keep wording parallel across the row (all nouns or all verbs) so the comparison reads coherently, use sentence case, and avoid trailing punctuation. Each panel’s first heading should match or echo the tab label so screen-reader users find their bearings when focus moves into the content.