Radio Button

A radio button chooses exactly one option from a visible, mutually exclusive set. The set has to be genuinely exhaustive, and the choice genuinely singular, or the control is the wrong one.

The property that defines it and causes most of its problems: a radio cannot be unset. Once somebody picks an option, the group always has an answer. That is correct behaviour for an exclusive choice and a trap everywhere else.

Against its neighbours

The judgement underneath the counts is whether comparison is part of the task. Five plan tiers should be visible because choosing between them is the job. Five countries need not be, because the person already knows which one they want.

The single-radio mistake

A lone radio button appears when somebody wants a binary opt-in and reaches for the wrong control. The result is a one-way door: checked, and no way back short of reloading the page.

Two correct alternatives. A checkbox, where unchecked is a real state. Or two radios — "Yes" and "No" — which forces a deliberate answer and is right when an unanswered question must not be mistaken for a no.

That second form matters in B2B, where an unticked box and an unread question are indistinguishable in an audit and a deliberate "No" is not.

Layout and order

Vertical, one per line. Horizontal rows become ambiguous as soon as label lengths vary, and they wrap unpredictably on narrow screens.

Stable order. Sorting by popularity means the option somebody chose last week has moved, which destroys the muscle memory that makes a repeated form fast.

The whole label is the target. As with checkboxes, the control itself is a small target and the label is free.

Group them properly. A fieldset with a legend is what tells assistive technology that these five controls are one question rather than five. Custom radios built from divs lose this along with keyboard behaviour — arrow keys should move within a group, and Tab should move past it.

Defaults decide outcomes

A pre-selected radio is accepted far more often than an unselected group is deliberately answered. That makes the default a decision about what most people will end up with.

Where one option is safe and right for the majority, select it. Where the answer genuinely varies — a plan, a data-retention period, anything with a cost attached — leave the group unset and require a choice. The pattern to avoid is defaulting to the option that suits the business and relying on inattention, which is the same failure as a pre-ticked consent box wearing different clothes.

In practice

A trial signup asks which plan to start on, as a dropdown with three options, defaulted to the middle one.

Most people never open it. The middle plan is chosen by inaction, and support later hears from customers who did not realise there was a cheaper option that fitted them, and from others who needed the top tier and discovered the limit after two weeks of work.

Changing it to three radios with the differences visible, and no default, changes the numbers in both directions: more people pick the cheap plan, and more pick the expensive one. Fewer end up on the wrong one, which shows up a quarter later as a lower rate of plan changes and fewer limit-related tickets.

The control was doing exactly what it was designed to do. It was hiding a comparison that was the whole point of the question.

Where teams get it wrong

• A single radio. A choice that cannot be undone.
• Radios where several answers are valid. The set was not exclusive.
• Horizontal layout. Labels and controls stop pairing clearly.
• Reordering by popularity. Muscle memory destroyed on a form people repeat.
• A self-serving default. Inattention harvested rather than a question answered.
• Divs instead of a fieldset. Five controls that assistive technology cannot tell are one question.