Segmented Control

Also called segmented button, toggle group, button group, view switcher

A compact set of adjacent options, exactly one of which is selected, used to switch between views or modes of the same content.

Example

Tab into the control once, then use the arrow keys — three options, one tab stop. The list below never changes; only how it is drawn does.

4 projects

analytics-api

Updated 2 hours ago

design-tokens

Updated yesterday

marketing-site

Updated 3 days ago

mobile-app

Updated last week

The group is a radiogroup, not a tablist — there are no panels here, so promising them would mislead assistive tech.

The same data is being shown a different way — list or grid, day or month, chart or table.
It filters rather than navigates: All, Active, Archived over one list.
The choice is a setting that belongs to the view, and you want it visible rather than buried in a menu.
There are two to four short options that fit on one line without wrapping.

The options lead to genuinely different content. That is tabs, and using a segmented control mislabels the relationship for assistive tech.
There are five or more options, or the labels are long. Past that point a select is more honest than a squeezed row.
More than one can be active. Segmented controls are single-choice by definition; use checkboxes or a multi-toggle group.
The options are actions rather than states. A row of buttons that do things is a toolbar, not a segmented control.

Every option is visible at once, unlike a select.
Takes very little space and sits comfortably next to a heading or search field.
The current state is unmistakable, because the selected segment is physically distinct.

Falls apart past four options or with long labels.
Cramped on narrow screens, where a select usually wins.
Frequently built as a plain row of buttons with no grouping semantics, which leaves screen reader users without the relationship.

What this pattern needs in order to work for everyone.

Keyboard: Arrow keys move between segments; the group holds a single tab stop, so Tab enters and leaves it as one unit.
Selection normally follows focus, since switching a view is cheap and reversible.
Never make each segment its own tab stop — a four-option control should not cost four presses to pass.
Roles and state: Use `role="radiogroup"` with `role="radio"` and `aria-checked` on each segment. It communicates “one of these” precisely.
Label the group with `aria-label` or `aria-labelledby` — “View” or “Filter” — or the options are announced without any context.
Do not use `role="tablist"` unless it genuinely controls panels. The wrong role promises panels that do not exist.
Focus: The group behaves as one control: focus enters the selected segment, arrows move within, and Tab leaves. This roving-tabindex behaviour is what separates it from an ordinary row of buttons.

Apple Music — The pattern's origin — iOS segmented controls switch between views of the same library.
Google Calendar — Day / Week / Month changes how the same calendar is drawn, not what it contains.

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