WCAG Score - Not scored
Provided by the component
This component provides the following foundation for accessibility compliance:
- HTML Structure: The component is responsible for rendering the <button> HTML tags for each segment.
- role="group" on the SegmentedControl container: The component is designed to apply this role to its root element.
- Conditional ARIA attributes based on type:
- For type="single", the component's internal logic applies role="radio" and toggles aria-checked="true/false" on the individual buttons.
- For multi-selection, the component's internal logic applies aria-pressed="true/false" to the individual buttons.
- Prop for aria-label on the SegmentedControl: The component provides the prop to allow a label to be passed in.
- Prop for aria-label on icon-only items: The component provides the prop to allow a label to be passed for individual icon-only segments.
- Basic keyboard interaction handling (inherent from <button>): Tab focus, Space/Enter activation for buttons are largely inherent but might be supplemented by the component for group navigation if needed.
Implementation considerations
Developers must do the following in the implementation to be considered fully accessible:
- Provide Meaningful aria-label Values
- For the SegmentedControl: Supply a concise and descriptive aria-label for the entire segmented control (e.g., <SegmentedControl aria-label="Choose display mode">). This tells screen reader users the overall purpose of the group of buttons. A vague or missing label here significantly harms accessibility.
- For Icon-Only Segments: For any segment that relies solely on an icon, the developer provides an aria-label that clearly describes the icon's function (e.g., <Segment icon={<GridIcon />} aria-label="Grid View">). Without this, screen reader users will not know what the icon represents.
- Ensure Visible Text Labels (When Not Icon-Only): If a segment is not icon-only, the developer must ensure it has clear and concise visual text that describes its purpose. This text is typically what the screen reader will announce by default.
- Manage State Changes and Live Regions (If Dynamic Content Changes) If selecting a segment triggers significant changes in other parts of the page (e.g., filtering a list, changing the displayed content), the developer should consider using ARIA live regions (aria-live="polite") on the changing content area. This informs screen readers that new content has appeared and should be announced. While not directly on the SegmentedControl, it's a critical part of the user flow initiated by the control.
- Handle Focus Management Beyond the Component's Scope: While the component ensures buttons are focusable, the developer might need to manage focus in specific scenarios:
- Initial Focus: If the segmented control is part of a larger form or interactive area, the developer should consider where the initial focus lands when the page loads or when a dialog opens.
- Focus After Action: If selecting a segment causes a new section to appear or an old section to disappear, the developer might need to programmatically move focus to the relevant new content or a logical next element.
- Implement Robust Keyboard Interaction Logic: While the native <button> element provides basic Tab/Space/Enter interaction, for radio group-like behavior (role="radio"), the developer should ensure:
- Arrow Key Navigation: When a segment has role="radio", users expect to navigate between options using arrow keys (left/right or up/down). The developer's implementation logic needs to handle this. When a radio button is selected, the focus should typically jump to the newly selected radio button using arrow keys.
- Only One Tab Stop: For a radio group, only the currently selected radio button should be in the tab order. Other radio buttons in the group should be navigable via arrow keys. The developer needs to manage tabindex accordingly (e.g., tabindex="0" for the selected radio, tabindex="-1" for others, with arrow key logic to shift tabindex="0").