composite pattern · Choice and binary state controls
Radio Group
A labeled set of radio buttons in which no more than one option can be checked at a time.
Decisive boundary
If users may choose several independent items, use Checkboxes; if the control changes one ongoing setting, use a Switch.
Definition and intent
What is a Radio Group UI pattern?
Use the behavior, not the silhouette
A labeled set of radio buttons in which no more than one option can be checked at a time. The term is used here as a composite pattern made from multiple controls or regions that must work together. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Present a small visible set of mutually exclusive options and keep the selected option explicit. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Radio Group, the boundary is: If users may choose several independent items, use Checkboxes; if the control changes one ongoing setting, use a Switch.
Do not implement it as Checkboxes when only one option is allowed, a Switch for choosing among named alternatives, or independent Toggle Buttons without a group contract If those requirements describe the real task better, use the related pattern page or the full Choice and binary state controls comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Present a small visible set of mutually exclusive options and keep the selected option explicit.
Define opening and closing
Pointer activation, Space on a focused radio, or arrow-key movement within the group. There is no open surface; choosing another radio replaces the current checked option.
Specify access behavior
Tab enters or leaves the group; focus then moves among radios according to the radio-group keyboard model. Space checks the focused radio; arrow keys move focus and selection through the group.
Reject the near miss
Checkboxes when only one option is allowed, a Switch for choosing among named alternatives, or independent Toggle Buttons without a group contract
Behavior contract
What must survive the build
- trigger
- Pointer activation, Space on a focused radio, or arrow-key movement within the group.
- dismissal
- There is no open surface; choosing another radio replaces the current checked option.
- modality
- Inline and non-modal.
- focus
- Tab enters or leaves the group; focus then moves among radios according to the radio-group keyboard model.
- keyboard
- Space checks the focused radio; arrow keys move focus and selection through the group.
- interactive
- Each radio is a control inside one labeled radiogroup.
- persistence
- The selected option remains checked until another option or application state replaces it.
- placement
- Options remain visibly grouped under one shared question or label.
- mobile
- Keep every option and label readable and tappable without turning the group into an undisclosed custom picker.
- state
- Each radio exposes checked or unchecked state; no more than one radio in the group is checked.
- choice
- Supports one mutually exclusive choice from a visible set.
- grouping
- All radios belong to one labeled radiogroup and share one selection contract.
Failure modes
Common wrong builds
- Allowing more than one radio in the group to be checked.
- Making every radio a separate Tab stop in a custom implementation.
- Omitting the group label.
Observable checks
Verify the result
- No more than one radio is checked.
- Tab enters and leaves the group predictably.
- Arrow keys move through the options and update selection.
- Space checks the focused option.
- Every radio has a visible and accessible label.
- The radiogroup exposes one shared accessible label.
Coding-agent handoff
Implementation brief template
Pattern: Radio Group Purpose: Present a small visible set of mutually exclusive options and keep the selected option explicit. Trigger: Pointer activation, Space on a focused radio, or arrow-key movement within the group. Dismissal behavior: There is no open surface; choosing another radio replaces the current checked option. Modality: Inline and non-modal. Focus behavior: Tab enters or leaves the group; focus then moves among radios according to the radio-group keyboard model. Keyboard behavior: Space checks the focused radio; arrow keys move focus and selection through the group. Interactive content: Each radio is a control inside one labeled radiogroup. Placement: Options remain visibly grouped under one shared question or label. Mobile behavior: Keep every option and label readable and tappable without turning the group into an undisclosed custom picker. Do not implement as: Checkboxes when only one option is allowed, a Switch for choosing among named alternatives, or independent Toggle Buttons without a group contract Acceptance checks: - No more than one radio is checked. - Tab enters and leaves the group predictably. - Arrow keys move through the options and update selection. - Space checks the focused option. - Every radio has a visible and accessible label. - The radiogroup exposes one shared accessible label.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Radio Group UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Radio Group in web UI?
A labeled set of radio buttons in which no more than one option can be checked at a time. In this reference set it is a composite pattern made from multiple controls or regions that must work together.
When should I use a Radio Group?
Present a small visible set of mutually exclusive options and keep the selected option explicit. The decisive boundary to confirm is this: If users may choose several independent items, use Checkboxes; if the control changes one ongoing setting, use a Switch.
What keyboard and focus behavior does a Radio Group need?
Space checks the focused radio; arrow keys move focus and selection through the group. Tab enters or leaves the group; focus then moves among radios according to the radio-group keyboard model. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Radio Group behave on mobile?
Keep every option and label readable and tappable without turning the group into an undisclosed custom picker. Its modality is a separate requirement: Inline and non-modal.
How do I verify a Radio Group implementation?
Start with observable checks: No more than one radio is checked. Tab enters and leaves the group predictably. Arrow keys move through the options and update selection. Then verify the remaining checks and compare the result with the linked source guidance.