WCAG Score - TBD
Provided by the component
The Segmented Control component provides the following accessibility foundations out of the box:
Semantic grouping
- The segmented control exposes itself as a group of related controls, ensuring assistive technologies understand that the segments belong to a single decision set.
- Group semantics are applied at the container level to communicate the relationship between segments.
Accessible control elements
- Each segment is rendered as an interactive control using platform-native accessibility primitives.
- Segments are exposed to screen readers as buttons, ensuring consistent and predictable interaction patterns.
Selection state communication
- The component programmatically exposes the selected / not selected state of each control button.
- Screen readers announce selection changes when users interact with a segment.
Support for selection modes
- In single-selection mode, the component ensures that only one segment is exposed as selected at a time.
- In multiple-selection mode, each segment exposes its independent selected state.
Accessibility labels
- The component provides an accessibility label prop at the segmented control level, allowing teams to describe the purpose of the control as a whole.
- For icon-only segments, the component provides an accessibility label prop at the segment level to ensure icons are announced with meaningful descriptions.
Focus handling for assistive technologies
- Each control button is focusable via screen readers.
- Focus order follows the visual order of the segments (left to right).
Implementation considerations
Developers must do the following in the implementation to be considered fully accessible:
Provide a meaningful group label
- Always supply a concise and descriptive accessibility label for the segmented control container.
- This label should describe the purpose of the control, not the currently selected value.
Example:
“Choose view type”, “Filter appointments”, “Select display mode”
A missing or vague group label significantly reduces usability for screen reader users.
Provide labels for icon-only segments
- Any segment that uses icons without visible text must include an accessibility label describing the option.
- Do not rely on the icon alone to convey meaning to assistive technologies.
Example:
“Calendar view”, “List view”
Ensure clarity for text-based segments
- For segments that include visible text labels, ensure the text is:
- Clear
- Concise
- Descriptive of the resulting view or context
- This visible label is typically what screen readers will announce.
Announce content changes triggered by selection
- If selecting a segment causes significant content changes (e.g. filtering a list, switching views), ensure the updated content is perceivable by screen reader users.
- When appropriate, apply accessibility announcements or live region equivalents on the updated content area so users are informed that content has changed.
This responsibility sits outside the segmented control itself, but is essential for the end-to-end accessible experience.
Focus management beyond the component
- While the segmented control ensures each segment is accessible, teams may need to manage focus in certain flows:
- When the segmented control appears inside a modal or bottom sheet
- When switching segments causes content to appear or disappear
In such cases, consider programmatically moving focus to the most relevant new content or logical next element.
Platform-specific considerations
- Keyboard navigation patterns (e.g. arrow key navigation, roving tabindex) are not applicable in mobile contexts and are therefore not implemented.
- Interaction relies on touch and screen reader gestures, aligned with VoiceOver and TalkBack conventions.
