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. 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. How we choose 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
Both options stay visible for comparison. This demo does not place an order.
Implementation
- 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.
- Use native radio inputs with the same name for each group, inside a fieldset with a short legend.
- Give each option a clickable label. Associate separate hints with aria-describedby, and give a select its own visible label.
- Avoid preselecting an unanswered question when it could bias the answer. Preserve existing choices; settings may have a sensible default.
- If “None” or “No preference” is valid, include it: users cannot clear a selected radio by clicking it again.
- 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?