Radio

Provides single user input from a selection of options.

Default

Default Radio Example

Radio disabled

Disabled Radio Example

Radio required

Required Radio Example

Radio headless

Use the RadioGroup component without RadioGroup.Item.

Radio standalone

Standalone unlabelled radio input for use in custom UI.

  • Option 1
  • Best Practices

    When to use

    • A single choice from 2–6 mutually exclusive options where seeing every option matters (deploy regions, plan tiers, billing cycle).
    • Past 6 options, switch to Select or Combobox so the list doesn’t dominate the form.
    • For binary on/off, use Toggle. For richer per-option content (icon, description, badge), use Choicebox.

    Behavior

    • Pre-select the safest default so the field reads as configured, never as required-but-empty. Skip the default only when the choice has real consequences and you want a deliberate pick.
    • Required state goes on the RadioGroup, not on individual options. Required-against-a-single-radio is meaningless.
    • Arrow keys move selection within the group and skip disabled options. Tab moves to the next field, not the next radio.

    Content

    • Group label is a Title Case noun like Deployment Region or Billing Cycle. Render it via <legend> or a sibling label tied with aria-labelledby.
    • Option labels are parallel: same part of speech, same length range, same register. Monthly / Yearly, not Monthly / Pay yearly.
    • Disabled options need a Tooltip naming why (Available on Pro and Enterprise). A greyed-out radio with no reason reads as broken.

    Accessibility

    • Wrap related radios in <fieldset> + <legend> so screen readers announce the group name before each option.
    • The standalone unlabeled radio (custom UI) needs an aria-label describing the choice. Never ship a radio with no accessible name.
    • Don’t replace the native focus ring with a CSS hack that drops outline-offset; keyboard users lose track of which option is focused.