Accessibility
The segmented control is a labelled radio group — it follows the WAI-ARIA Radio Group pattern and meets WCAG 2.1 AA. Because it’s built from a native <fieldset> and same-name <input type="radio"> segments, the browser provides the grouping, the single-select constraint, roving keyboard navigation, and the selected-state announcement — so the one active choice is clear whether the user sees it, hears it, or tabs to it.
For designers
Section titled “For designers”- Every segment state — rested, hover, selected, disabled, focus — must keep accessible contrast in both the neutral and contrast schemes. Source: WCAG 1.4.3 Contrast (Minimum).
- Never signal the selected segment with colour alone — pair the contained fill with the emphasised label weight so the state reads without relying on hue. Source: WCAG 1.4.1 Use of Color.
- The focus ring must stay visible, meet contrast on every supported surface, and stay clearly distinguishable from both the hover and selected states. Source: WCAG 2.4.7 Focus Visible.
- Use semantic colour tokens (e.g.
foreground/neutral/default) rather than fixed values, so the control adapts correctly across brands and surfaces.
For developers
Section titled “For developers”The segmented control is a native radio group: a <fieldset> wrapping same-name <input type="radio"> segments. Grouping, single-select, roving arrow-key navigation, and the selected-state announcement all come from the platform, so there are no ARIA roles to add and no JavaScript to wire — it satisfies the Radio Group pattern without re-implementing it. Don’t override the native keyboard behaviour, and never rebuild segments from <div> or <button> elements. As the consumer you own the integration contract: supply a meaningful group label and a name unique to the page, start the control with exactly one segment selected, and never suppress the focus ring. Each element’s role, name, and state are in the Labelling elements section below.
Keyboard interaction
Section titled “Keyboard interaction”| Key | Action |
|---|---|
| Tab / Shift + Tab | Move focus into and out of the control, onto the selected segment |
| ← / → / ↑ / ↓ | Move focus and selection between segments |
| Space | Select the focused segment |
The whole segment is the tap target — keep each at least 44 px for comfortable touch use, comfortably clearing the WCAG AA minimum. Source: WCAG 2.5.8 Target Size (Minimum).
Focus order
Section titled “Focus order”The control is a single stop in the tab sequence: focus lands on the selected segment, and the arrow keys then rove between segments within it. The keys that drive this are in the Keyboard interaction table above.
- Focused segment
Source: WCAG 2.4.3 Focus Order.
Labelling elements
Section titled “Labelling elements”Give every element the role, name, and state assistive technology needs.
Segmented control
The native <fieldset> groups the segments and exposes them as a single radio group; its <legend> is the group’s accessible name. Keep the legend sr-only and fill it with a meaningful group name, since a visible legend would break the flex track.
Segment
Each <label> wraps a native <input type="radio">, and the radios share one name so the browser enforces single-select. The label text is the accessible name; for an icon-only segment, supply it with a visually-hidden sr-only span. Selected state is announced from the native checked attribute, and a disabled segment — or a disabled <fieldset> — conveys the disabled state programmatically.
Icon
A leading or icon-only glyph is decorative: mark it aria-hidden="true" so it isn’t announced, and let the label — visible or sr-only — carry the accessible name.
Source: WCAG 4.1.2 Name, Role, Value.