UX Patterns Guide
UI + UX Selection And Choice standard

Radio group

Show a labeled group of native radio inputs with visible options, clickable labels, optional hints, one selected value at a time, and group-level validation when required.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users must choose exactly one option.
  • There are roughly two to seven meaningful options that benefit from visible comparison.

Avoid when

  • Users can choose multiple options.
  • The option list is long, searchable, or too low priority to keep expanded.

Problem it prevents

Users need to make one mutually exclusive choice from a short set while seeing every available option before deciding.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Radio group in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The option set is short, stable, and mutually exclusive.

Pattern promise

Show a labeled group of native radio inputs with visible options, clickable labels, optional hints, one selected value at a time, and group-level validation when required.

Required state

No selection state for required unanswered groups.

Recovery path

Custom buttons without radio semantics or keyboard behavior.

Access contract

Use a programmatic group label through fieldset/legend or an accessible radiogroup name.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Visible native radio options with a clear legend, selected state, focus state, and helper text.
  • Vertical spacing supports comparison and touch selection without making options feel unrelated.
  • Exactly one option is selected at a time and labels are clickable.
  • Required errors apply to the whole group and do not erase a user's existing selection.
Weak implementation

Vague, hidden, hard to recover from

  • Custom circles that do not show focus or selected state clearly.
  • Radio options laid out like unrelated buttons with no group label.
  • Using radios for choices where multiple selections are allowed.
  • Defaulting to a consequential choice without user intent.
UI guidance
  • Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation.
  • Keep short mutually exclusive choices visible instead of collapsing them into a dropdown.
UX guidance
  • Help users compare the available options and choose exactly one without opening an extra control.
  • Avoid biased defaults and do not hide critical short choices inside a collapsed dropdown.
Implementation contract

What the implementation must handle

States

  • No selection state for required unanswered groups.
  • Exactly one selected option state.
  • Focused radio option state.
  • Group-level validation error when a required choice is missing.

Interaction

  • Only one option in the named group can be selected at a time.
  • The fieldset legend explains the decision being made.
  • Selection, focus, and required error state remain visible and programmatically exposed.

Accessibility

  • Use a programmatic group label through fieldset/legend or an accessible radiogroup name.
  • Expose checked, focused, disabled, and required error states.
  • Associate each label with its radio input so the label is a reliable click target.
  • Tab enters and leaves the radio group predictably.

Review

  • Is this one mutually exclusive decision with a short enough list to show?
  • Would hiding these options in a collapsed control make comparison or error recovery worse?
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Radios component

Government Digital Service - checked

GOV.UK radios guidance supports one option from a list, fieldset/legend grouping, no careless preselection, and group-level errors.

WAI-ARIA APG Radio Group Pattern

W3C Web Accessibility Initiative - checked

APG radio group guidance documents keyboard behavior, roles, checked state, labels, and descriptions for custom implementations.

Full agent/debug reference

Problem Context

  • The option set is short, stable, and mutually exclusive.
  • Seeing every choice helps users compare plans, answer a question, or avoid missing a consequential option.

Selection Rules

  • Choose radio groups when the user must choose one option from a short visible set.
  • Make the group question explicit with a legend and keep each option label directly clickable.
  • Avoid pre-selecting a consequential option unless there is strong evidence that a default is safe and expected.
  • Use select only when the option list is longer, familiar, or secondary enough to collapse.

Required States

  • No selection state for required unanswered groups.
  • Exactly one selected option state.
  • Focused radio option state.
  • Group-level validation error when a required choice is missing.

Interaction Contract

  • Only one option in the named group can be selected at a time.
  • The fieldset legend explains the decision being made.
  • Selection, focus, and required error state remain visible and programmatically exposed.

Implementation Checklist

  • Use native radio inputs where possible before reaching for a custom radiogroup implementation.
  • Group related options with a fieldset and legend or an equivalent accessible name.
  • Keep option labels concise, distinct, and large enough to select through the label text.
  • List options vertically when comparison or touch selection matters.
  • Show required errors at the group level without clearing a user's existing choice.

Common Generated-UI Mistakes

  • Using radios for independent choices where several answers can be true.
  • Hiding a short critical set inside a select just to save vertical space.
  • Omitting the group legend so users hear options without the question.
  • Pre-selecting a paid, destructive, or biased option without clear evidence.

Critique Questions

  • Is this one mutually exclusive decision with a short enough list to show?
  • Would hiding these options in a collapsed control make comparison or error recovery worse?
Accessibility
  • Use a programmatic group label through fieldset/legend or an accessible radiogroup name.
  • Expose checked, focused, disabled, and required error states.
  • Associate each label with its radio input so the label is a reliable click target.
Keyboard Behavior
  • Tab enters and leaves the radio group predictably.
  • Arrow keys move between options in native or APG-compatible radio groups.
  • Space selects the focused radio option when it is not already selected.
Variants
  • Vertical radios
  • Tile radios
  • Inline yes/no radios
  • Radios with conditional reveal

Verification

Source trail checked:

Saved items