Radio button

Overview

Radios are for mutually exclusive picks where every option is worth seeing at a glance — payout schedule, payment method, plan tier. Use them when the set has 3 to 5 options. With 2, a switch reads cleaner; with 6 or more, a select keeps the form short. Radios always belong to a group, never on their own.

Anatomy

Four parts inside the row, plus the group wrapper that holds them together. The whole row — mark, title, help text — is the click target; clicking the title selects the option just like clicking the ring.

States

Five visible states, each rendered checked and unchecked. Held still here for review — the real component handles transitions natively.

Layout

Vertical is the default; the eye scans down one column and lands on the answer. Horizontal works only when every label is one or two words and the group is part of a wider row of fields.

With help text

Use help text to disambiguate options the title can't carry on its own — a delivery window, a constraint, a price. Keep it to one line. If the help text needs two lines, the option is too complex for a radio; reach for a radio card or split the question.

Error

The error tone applies to the whole group — every ring goes red, and a single helper message sits below the last option. Don't paint untouched required groups red preemptively; only after the user submits without a choice.

Behavior

• 01The whole row is the click target. Clicking the title or the help text selects the option, just like clicking the ring. The hover halo widens to cover the row, not just the mark.
• 02A radio can't be unchecked by clicking it. That's the difference from a checkbox — selecting another option deselects the current one. Provide a “None” option if the user needs to opt out.
• 03Default is the safe pick. Pre-select the option most users will keep — “Next business day” for payouts, the lower-risk shipping option, the more conservative permission. Never pre-select something destructive or surprising.
• 04Order options consistently. When there's a natural progression (low → high, soonest → latest, free → expensive), order by it. Otherwise lead with the default and follow with frequency.
• 05Don't hide the group behind progressive disclosure. Radios are for choices the user is making now. If the choice shouldn't be visible until a precondition is met, show it when the precondition is met — don't lurk it behind a “More options” toggle.

Radio vs. checkbox vs. select vs. switch

Picking the right control matters more than picking the right styling. The four are not interchangeable.

Accessibility

• Use native inputs. <input type="radio"> with a shared nameon every option in the group. The browser handles arrow-key nav, focus, and form submission for free; don't reach for a custom implementation.
• Group with <fieldset> + <legend> so screen readers announce the question before the options. Alternative for non-form contexts: role="radiogroup" + aria-labelledby.
• Labels associate explicitly. Wrap each input in its <label> or use an id + htmlFor pair so clicking the title selects the option.
• Keyboard: ↑ / ↓ move and select. Tab leaves the group. Don't override — the native pattern is what users expect.
• Focus ring is keyboard-only. :focus-visibleshows the ring; mouse clicks don't. Never replace the ring with a colour change inside the radio.
• Error messages link to the group, not each option. Use aria-describedby on the fieldset pointing at the helper text, and announce the message via aria-live="polite" when it appears.
• Touch targets: the entire row is clickable. The 20 px mark is the visual; the row gives the user a 44 px+ tap target.

Code

The component composes from RadioGroup + Radio primitives in @flatpay-dk/ui. The group renders the fieldset/legend; each radio is a single option with title and optional help.

import { RadioGroup, Radio } from "@flatpay-dk/ui";

// Default group with a pre-selected option
const [schedule, setSchedule] = useState("next");

<RadioGroup
  legend="Payout schedule"
  description="When the daily settlement should land in your bank."
  value={schedule}
  onValueChange={setSchedule}
>
  <Radio
    value="same"
    title="Same day"
    help="Available before 18:00 CET on weekdays."
  />
  <Radio
    value="next"
    title="Next business day"
    help="The default. Lands by 09:00 the morning after."
  />
  <Radio
    value="weekly"
    title="Weekly"
    help="Bundled into one transfer every Monday morning."
  />
</RadioGroup>

// Disabled option
<Radio
  value="instant"
  title="Instant"
  help="Coming soon for European accounts."
  disabled
/>

// Error state — applies to the whole group
<RadioGroup
  legend="Pickup or delivery"
  value={method}
  onValueChange={setMethod}
  error="Choose pickup or delivery to continue."
>
  <Radio value="pickup" title="Pickup" />
  <Radio value="delivery" title="Delivery" />
</RadioGroup>

Best practices

Small habits that keep radios scannable and predictable across forms.

Props

RadioGroup

Radio

Related