Accessibility Field Guide

Tabs

A practical Accessibility Field Guide page for checking tabbed interfaces, selected state, tab panels, keyboard behavior, focus, and when tabs are the right pattern.

Photo: Person taking white paper from folder via Pexels — https://www.pexels.com/photo/person-taking-white-paper-from-folder-4792287/

View full screen Download image

Tabs let people switch between related panels of content without leaving the page.

That can be useful when the sections are peers and the user only needs one section at a time.

It can also create confusion when tabs are used as decoration, hidden navigation, or a way to compress unrelated content into a smaller space.

A useful tab interface needs clear tab labels, one understandable selected state, predictable keyboard behavior, and a real relationship between each tab and its panel.

The goal is not to make every group of options into tabs.

The goal is to use tabs when the pattern helps the task, and to make the selected panel clear to people using a keyboard, screen reader, or magnification.

The common project moment

A screen has several related views.

Maybe the user can switch between Summary, Details, History, and Notes. Maybe a settings page has tabs for Profile, Security, Notifications, and Billing. Maybe a dashboard uses tabs to swap between charts or filters.

In the design file, tabs look clean:

one row of labels;
one active tab;
a line, color, or background showing the selected tab;
one visible panel underneath;
less vertical scrolling than showing every section at once.

But the implementation may not match the visual promise:

the tabs are links when they do not navigate anywhere;
every tab is just a clickable div;
the selected tab is shown only by color;
aria-selected is missing or does not update;
the tab and panel are not programmatically connected;
keyboard focus lands in an unexpected place;
arrow keys, Tab, Enter, and Space do not behave consistently;
content changes visually, but assistive technology does not get a clear state or relationship.

That is where tabs become harder than they look.

The visual design says, "this panel belongs to this selected tab."

The code needs to expose the same relationship.

Start by asking whether the sections are peers

Tabs work best when the sections are parallel choices at the same level.

They are usually a poor fit when the content is a sequence, a wizard, a long article outline, or unrelated navigation.

Before building tabs, ask:

Are these sections truly alternatives at the same level?
Does the user usually need only one panel at a time?
Would normal headings make the content easier to scan?
Would links to separate pages or routes be clearer?
Does the selected tab change content in place, or does it navigate somewhere new?

If the user needs to read all sections in order, tabs may hide too much.

If each item goes to a different page or route, links may be the clearer pattern.

Name the tabs clearly

Each tab label should describe the panel it opens.

Short labels are helpful, but vague labels create guesswork.

Labels like Overview, Details, Settings, or History can work when the surrounding page provides enough context.

Labels like Option 1, More, Info, or View usually need more specificity.

The accessible name should match the visible label unless there is a strong reason to add context.

That matters for speech input and for people who build a mental map of the interface from what they hear.

Expose the selected state

A tab interface needs a clear selected tab.

The selected state should be visible, but it should not rely only on color.

It also needs to be exposed programmatically.

For ARIA tabs, that usually means the active tab has aria-selected="true", inactive tabs have aria-selected="false", and the active tab is connected to its tabpanel.

Do not let the visual state and ARIA state drift apart.

If the user switches tabs, the selected state, visible panel, and hidden panels need to update together.

Connect each tab to its panel

A tab should not be a label floating above unrelated content.

The tab and panel need a real relationship.

In a typical ARIA tabs pattern:

the group of tabs has a tablist role;
each tab has a tab role;
each content panel has a tabpanel role;
the selected tab points to the active panel;
the panel is labeled by the tab that controls it.

That does not mean every implementation needs to be complex.

It means the pattern needs to communicate which tab controls which content.

If a simpler heading and content structure would be clearer, use that instead.

Keep keyboard behavior predictable

Tabs are one of the places where keyboard expectations matter.

A keyboard user should be able to reach the tab interface, identify the selected tab, move between tabs, and get to the active panel without getting lost.

For a typical tabs pattern:

Tab moves into and out of the tab interface;
arrow keys often move between tabs;
Enter or Space may activate a tab when activation is manual;
focus should not jump unpredictably when the selected tab changes;
hidden panel content should not stay in the tab order.

Some tabs activate automatically when focus moves. Others activate only when the user presses Enter or Space.

Either model can work, but the behavior should be intentional and tested.

If loading a panel is slow, automatic activation can feel jumpy or confusing.

Tabs and navigation links can look similar.

They are not the same pattern.

Use tabs when the user is switching panels within the same context.

Use links when the user is going to another page, route, or destination.

This distinction matters because it changes what people expect from the keyboard, browser history, page title, URL, focus, and screen reader announcement.

If selecting a tab changes the URL and loads a different page, the pattern may really be navigation.

If selecting it swaps a panel inside the current page, tabs may be appropriate.

Watch for tabs inside complex screens

Tabs often appear inside dashboards, account pages, admin screens, and design-system components.

Those screens may already have filters, tables, forms, dialogs, accordions, status messages, or loading states.

When tabs contain other interactive components, check the whole path:

Can the user reach the tab list?
Can they move to the intended tab?
Can they reach the active panel content?
Are hidden panels removed from the keyboard path?
Does focus stay predictable after loading, saving, filtering, or validation?
Does the selected tab still make sense after the content updates?

A tab pattern can be technically correct in isolation and still confusing in the real screen.

Questions teams can ask

During design

Are these sections peers, or would headings or links be clearer?
Does the user need to compare panels side by side?
Is the selected tab visible without relying only on color?
Are tab labels specific enough to understand before activation?
What should happen to focus when a tab is selected?

During development

Is this a real tabs pattern, or is it navigation styled like tabs?
Are the tab, tablist, and tabpanel relationships exposed correctly when ARIA is used?
Does the selected state update when the user changes tabs?
Are hidden panels removed from the keyboard path?
Does keyboard behavior match the pattern the component claims to use?

During QA or internal review

Can I identify the selected tab without using a mouse?
Can I move between tabs with the keyboard?
Can I get from the selected tab to the active panel content?
Does hidden panel content stay hidden from keyboard focus?
Does the interface still make sense after the panel content loads or changes?

Common trail hazards

Styling links like tabs when each item navigates to another page.
Building tabs out of clickable div or span elements without keyboard support.
Showing the selected tab only through color.
Updating the visible panel without updating aria-selected.
Leaving hidden panel controls in the keyboard path.
Moving focus into a panel unexpectedly on every arrow-key press.
Using tabs to hide content that most users need to read.
Assuming a design-system tab component works without checking the rendered screen.

Small habit

When reviewing tabs, test one switch with this sentence:

This is a tab called [label]. It is [selected or not selected]. It controls the [panel name] panel, and I can move between tabs and reach the active panel with the keyboard.

If that sentence is hard to complete, the tab pattern needs more work before ARIA can describe it accurately.

Native HTML First — for choosing simpler headings, links, or buttons before a custom tab pattern.
Button vs Link — for deciding whether the tab is actually navigation.
Accessible Names — for making tab labels clear.
Name, Role, and Value — for checking role, selected state, and panel relationships.
ARIA Is Not Duct Tape — for using ARIA to describe behavior that actually exists.
Developer Component Checklist — for a broader component handoff and review pass.
Accordions — for a related expandable-section pattern that is often confused with tabs.
Keyboard-Only Navigation — for checking the no-mouse path.
Focus Visible and Focus Order — for checking focus visibility and movement.
WAI-ARIA Authoring Practices tabs pattern — for the deeper ARIA pattern details.
Accessibility Glossary — for plain-language definitions of common accessibility terms used across this guide.

What to do next

Use this page on one tab interface before copying the pattern to more screens.

Start with the decision: tabs, links, headings, or accordions.

Then check the selected state, panel relationship, keyboard behavior, focus movement, and hidden panel content before treating ARIA as the fix.