Accessible Radio Buttons

Accessible radio buttons enable users to select one option from a group using keyboard, mouse, or assistive technology. Proper radio button accessibility requires attention to group structure, keyboard navigation patterns, and screen reader announcements.

What Are Accessible Radio Buttons

Radio buttons present mutually exclusive options where selecting one deselects others in the same group. Native HTML radio inputs with matching name attributes automatically form groups with correct keyboard behavior and screen reader support.

Radio button accessibility extends beyond individual buttons to include group labeling, keyboard navigation within the group, and clear communication of which option is selected. Users must understand the options, navigate between them, and confirm their selection.

WCAG requirements include keyboard operability (2.1.1), focus visibility (2.4.7), proper labels (1.3.1), and name/role/state communication (4.1.2). Native radio buttons satisfy these requirements. Custom implementations must recreate this functionality.

How Accessible Radio Buttons Work

Native radio buttons with matching name attributes form a group automatically. The browser manages focus within the group: Tab enters and exits the group, while arrow keys move between options. Only one radio in a group appears in the tab order, with arrows accessing others.

Group labeling uses the fieldset and legend elements. The fieldset wraps all radios in the group. The legend provides the group label, announced by screen readers when users enter the group. This context helps users understand what the options represent.

Screen readers announce radio buttons with their label, role, and selection state: “Small, radio button, 1 of 3, not selected.” When selected, the announcement changes to “selected.” This communication helps users understand their position and current selection.

Custom styled radio buttons typically use the same CSS-hiding approach as custom checkboxes. The native input remains functional but invisible. CSS styles adjacent elements as the visible radio indicator. This preserves native keyboard and screen reader behavior.

Pure ARIA implementations use role=“radiogroup” on the container and role=“radio” on each option. aria-checked indicates selection state. tabindex manages focus, with only the selected radio (or first radio if none selected) having tabindex=“0”.

Key Considerations

• Use native input type=“radio” with matching name attributes for groups
• Wrap groups in fieldset with legend for accessible group labeling
• Ensure arrow keys move between options within a group
• Provide visible focus indication on the focused option
• Communicate selection state both visually and programmatically
• Do not require Tab between each radio; use standard arrow key navigation
• Test that screen readers announce group name, option label, and position

Common Questions

How should radio button groups be labeled?

The fieldset and legend pattern provides group labeling that screen readers announce. When users focus a radio within the fieldset, the legend provides context for what the options represent.

Alternatively, aria-labelledby on a radiogroup can reference visible heading text. This approach works when the visual design does not accommodate a legend element. Either way, the group needs a programmatically associated name.

What keyboard navigation should radio groups support?

Standard radio group navigation uses Tab to enter and exit the group, and arrow keys to move between options. Up/Left arrows move to the previous option. Down/Right arrows move to the next option.

Selection behavior varies by implementation. Some radios select on focus (arrow to an option selects it). Others require Space or Enter to confirm selection. Native behavior selects on arrow navigation, which is the expected pattern.

How do required radio groups work?

A required radio group means users must select one option. The required attribute on one radio in the group (typically the first) triggers native validation. The fieldset should also convey requirement through legend text or aria-required on the radiogroup.

Error messaging for unselected required groups should clearly indicate that a selection is needed. The error connects to the group rather than an individual radio.

Summary

Accessible radio buttons provide single-selection from multiple options through proper group structure using fieldset and legend, keyboard navigation with arrow keys within groups, and clear communication of selection state. Native radio buttons provide these behaviors automatically when properly grouped.