# Select menu or radio buttons?

[Website version](https://patterns.alexanderclaes.com/patterns/select-or-radios/)

Updated 30 October 2026

Show manageable choices as radios. Try narrowing a long list before using a select.

## Sources take different approaches

GOV.UK recommends asking questions that reduce the options before using a select. USWDS suggests a combo box for more than 15 choices, but also warns of assistive-technology usability concerns with its own component and suggests considering a select instead. This guide follows GOV.UK’s design approach rather than an option-count cutoff, while preserving the USWDS component warning.

**Preferred source:** [GOV.UK · Select](https://design-system.service.gov.uk/components/select/). Prefer GOV.UK for the form-control decision: make manageable choices visible and try narrowing a long list before using a select. Its last-resort advice is scoped to public-facing services, not a WCAG ban. If a select or autocomplete remains appropriate, test it with users and supported assistive technology; preserve component-specific warnings.

Compare: [USWDS · Combo box](https://designsystem.digital.gov/components/combo-box/). [How we choose sources](https://patterns.alexanderclaes.com/about/#sources).

## Recommendation

Follow GOV.UK: prefer radio buttons for a manageable set of choices. Before using a select for a long list, try asking a question that narrows the options. In public-facing services, treat selects as a last resort rather than choosing one simply to save space.

## Problem

The user needs to choose one option.

## Use radio buttons when

- There are a few meaningful choices and users need to see their differences.
- Each option needs a short explanation, such as delivery speed and price.

## Use a select or autocomplete when

- A long list that would overwhelm the page: first consider whether another question can narrow it to fewer meaningful choices.
- A long list that remains necessary may need a select or a carefully tested autocomplete. Do not choose a combo box solely because the list has more than 15 options; USWDS reports assistive-technology issues with its own component and suggests considering a select instead.

## What if the list is long?

We follow GOV.UK’s advice to simplify the choice before choosing a control. Its last-resort guidance for selects applies to public-facing services; it is design guidance, not a WCAG prohibition on selects.

- Try a useful narrowing question when it genuinely reduces the choices. Do not add questions that users cannot answer or that merely make the flow longer; this is our task-based qualification.
- If a long list is still necessary, a select or autocomplete may be appropriate after checking how users find and choose an option. A select is not automatically the right answer because space is tight.
- USWDS suggests combo boxes for more than 15 choices, but also documents assistive-technology usability concerns with its component and suggests considering a select instead. We do not adopt 15 as a universal cutoff or treat that warning as applying to every autocomplete.

## Example

[View the example on the website](https://patterns.alexanderclaes.com/patterns/select-or-radios/#example).

## Implementation

1. First check whether the question can offer fewer meaningful options. Use radios when the resulting choices are manageable. If a long list remains necessary, assess a select or autocomplete with users; preserve the qualifications and accessibility warnings for the component you choose.
2. Use native radio inputs with the same name for each group, inside a fieldset with a short legend.
3. Give each option a clickable label. Associate separate hints with aria-describedby, and give a select its own visible label.
4. Avoid preselecting an unanswered question when it could bias the answer. Preserve existing choices; settings may have a sensible default.
5. If “None” or “No preference” is valid, include it: users cannot clear a selected radio by clicking it again.
6. For an unanswered select, start with an empty-value prompt option. Use required when an answer is mandatory.

## Tradeoffs

Radio buttons use more room but make alternatives visible. Selects are compact and familiar but hide choices until opened. There is no universal option-count cutoff.

## Verification

Can users understand and compare the choices without opening and closing a menu repeatedly?

## References

- [GOV.UK · Radios](https://design-system.service.gov.uk/components/radios/)
- [GOV.UK · Select](https://design-system.service.gov.uk/components/select/)
- [W3C WAI · Grouping controls](https://www.w3.org/WAI/tutorials/forms/grouping/)
- [HTML Standard · The select element](https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element)
- [USWDS · Combo box](https://designsystem.digital.gov/components/combo-box/)

## Related patterns

- [When should a form show errors?](https://patterns.alexanderclaes.com/patterns/validation-timing.md)
- [Toggle or checkbox?](https://patterns.alexanderclaes.com/patterns/toggles-or-checkboxes.md)