UX Patterns Guide
UI + UX Selection And Choice standard

Select

Use a native select with a persistent label, optional hint, visible closed value, an empty option only for no selection, and validation that does not auto-submit on change.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The user chooses one option from a moderate known list.
  • The selected value matters more than seeing every option constantly.

Avoid when

  • The option set is short and comparison matters.
  • Users need to select many values.
  • The list is long enough that users need search, filtering, or autocomplete.

Problem it prevents

Users need to choose one value from a known list that is too long or secondary to keep fully expanded on the page.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Select in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The option set is known, finite, and moderately sized.

Pattern promise

Use a native select with a persistent label, optional hint, visible closed value, an empty option only for no selection, and validation that does not auto-submit on change.

Required state

Closed state with empty option or current selected value.

Recovery path

Inaccessible custom dropdowns.

Access contract

Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Persistent label, hint text, visible selected value, readable options, and clear required validation state.
  • Native select is used when custom presentation is not necessary.
  • Users can open, scan, choose one value, and review the selected value after close.
  • Very long lists use search or autocomplete instead of forcing scrolling.
Weak implementation

Vague, hidden, hard to recover from

  • Placeholder as the only label.
  • Custom dropdown that looks polished but hides focus and selected state.
  • Hiding two obvious critical choices in a dropdown.
  • Option labels are ambiguous or duplicated without context.
UI guidance
  • Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
  • Prefer native select unless custom listbox behavior is truly needed and fully accessible.
UX guidance
  • Help users choose one value from a moderate known list without showing every option permanently.
  • Do not hide short critical choices just to save space, and do not auto-submit while users navigate options.
Implementation contract

What the implementation must handle

States

  • Closed state with empty option or current selected value.
  • Open native option menu or equivalent listbox state.
  • Selected option state after the menu closes.
  • Required validation error state when no valid option is chosen.

Interaction

  • The selected value remains visible after the menu closes.
  • Opening the control reveals the finite options without accepting arbitrary free text.
  • Changing selection updates local state without automatically submitting the form.
  • A required empty option is not treated as a completed answer.

Accessibility

  • Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
  • Keep labels persistent.
  • Associate hints and errors through platform-supported descriptions.
  • Native select follows platform-specific keyboard behavior.

Review

  • Is collapsing this choice worth the extra interaction cost?
  • Would a visible radio group or searchable autocomplete make this list easier to complete?
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Select component

Government Digital Service - checked

GOV.UK select guidance supports native labels, hints, errors, selected values, long-list caution, and no preselected answers for questions.

U.S. Web Design System Select component

U.S. Web Design System - checked

USWDS select guidance supports sparing use for about seven to 15 options, persistent labels, no auto-submit, and radio/combo-box alternatives.

WAI-ARIA APG Listbox Pattern

W3C Web Accessibility Initiative - checked

APG listbox guidance documents keyboard, labeling, and selected-state requirements for custom listbox-style select alternatives.

Full agent/debug reference

Problem Context

  • The option set is known, finite, and moderately sized.
  • A compact control is justified because visible comparison of every option is less important than saving space.

Selection Rules

  • Choose select sparingly for a single choice from a moderate known list when space or task priority justifies collapsing options.
  • Prefer radio groups for fewer visible choices when comparison or consequence matters.
  • Use autocomplete or combo box behavior when the list is very long, searchable, or hard to scan manually.
  • Do not submit or navigate automatically when the selected option changes.

Required States

  • Closed state with empty option or current selected value.
  • Open native option menu or equivalent listbox state.
  • Selected option state after the menu closes.
  • Required validation error state when no valid option is chosen.

Interaction Contract

  • The selected value remains visible after the menu closes.
  • Opening the control reveals the finite options without accepting arbitrary free text.
  • Changing selection updates local state without automatically submitting the form.
  • A required empty option is not treated as a completed answer.

Implementation Checklist

  • Use native select when platform behavior satisfies the design.
  • Label the control clearly and keep the label visible after a value is selected.
  • Include an empty option only for the no-selection state and validate it as incomplete when required.
  • Provide hint or error text through descriptive associations when needed.
  • Avoid custom selects unless keyboard, focus, selected state, dismissal, and assistive behavior match the native control.

Common Generated-UI Mistakes

  • Custom select with no keyboard support or hidden selected state.
  • Using select to hide two or three obvious choices that should be compared.
  • Placeholder-only labels that disappear after selection.
  • Auto-submitting the form as soon as a user arrows through options.

Critique Questions

  • Is collapsing this choice worth the extra interaction cost?
  • Would a visible radio group or searchable autocomplete make this list easier to complete?
Accessibility
  • Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
  • Keep labels persistent.
  • Associate hints and errors through platform-supported descriptions.
Keyboard Behavior
  • Native select follows platform-specific keyboard behavior.
  • Custom selects must support opening, navigation, selection, and dismissal by keyboard.
  • Do not trigger submission while users are navigating options.
Variants
  • Native select
  • Custom listbox select
  • Grouped select
  • Select with hint and error

Verification

Source trail checked:

Saved items