Skip to content

Radio

A radio allows users to select exactly one option from a set.

Ready to use

DesignDevelopAccessibility

Radio buttons allow users to select exactly one option from a list of at least two mutually exclusive choices. Selecting one option automatically deselects the previously selected one. The component is fully responsive and intentionally designed to be used across all viewports.

Anatomy

Section titled “Anatomy”
  1. Radio button
  2. Label

When to use it

Section titled “When to use it”

Use radio buttons when:

  • The user must select exactly one option from a small list of mutually exclusive choices (typically 2–5).
  • All available options should be visible at a glance for quick comparison.
  • You want to provide a clear “recommended” or “current” state by pre-selecting a default.

Avoid radio buttons when:

  • The user needs to select multiple items — use checkboxes.
  • The list contains more than 5–6 options — use a dropdown to save space.
  • The action is a binary on/off that takes effect immediately without a submit button — use a toggle switch.

Properties

Section titled “Properties”

State

Default, Hover, Selected, Disabled, Disabled-Selected, and Focus. Selected fills the control; disabled mutes it but stays visible; focus shows a 2 px outline around the entire item.

Size

Two sizes — Small (typography-body-7) for dense forms, Large (typography-body-6) for primary selections or hero comparisons. Both keep the same control size; only the label typography changes.

Label

The visible label sits next to the control and is fully clickable, which keeps the touch target generous. Always associate the label with the input so screen-reader users hear the choice as they navigate.

Platform considerations

Section titled “Platform considerations”

Desktop

Vertical stacking keeps the comparison readable. Keyboard arrow keys move focus logically between options inside the group.

Tablet

Same vertical stack. Touch and pointer both work because the entire label area is clickable.

Mobile

Stick with the vertical stack and pick the large size for primary choices so the touch target stays comfortable.

Best practices

Section titled “Best practices”

Lean on native semantics so keyboard, focus, and assistive-tech behaviour come for free.

Do

Use radio buttons when the user must select exactly one option, wrap groups in a <fieldset> with a <legend>, pre-select a sensible default when one exists, associate a visible label with every radio, provide clear visual feedback for selected, unselected, and disabled states, and ensure arrow-key navigation moves focus logically between options.

Don't

Don’t reach for radio buttons when the user can select multiple options (use checkboxes), don’t reach for them when the list contains more than 5–6 options (use a dropdown), don’t reach for them for instant on/off actions (use a toggle), don’t recreate the control with <div> or <span> without ARIA roles, don’t rely on colour alone for the selected state, and don’t remove the browser focus outline unless you replace it with an accessible equivalent.

Content guidelines

Section titled “Content guidelines”

Write each label so it stands on its own — users shouldn’t have to read the legend to understand a choice. Keep the wording parallel across the group (“Petrol”, “Hybrid”, “Electric” rather than “Petrol car”, “Hybrid”, “Fully electric vehicles”), use sentence case, and skip trailing punctuation. The group’s legend should pose a clear question or name the dimension the choices vary along.