UX Patterns Guide
Back to compare picker

Inaccessible custom select vs Select vs Autocomplete vs Multi-select

Flag inaccessible custom select when a visual dropdown lacks keyboard opening, option navigation, selected state, focus return, accessible value, or submitted form value.

Inaccessible custom select live exampleSelect live exampleAutocomplete live exampleMulti-select live example
Learn the decision

Match the interaction to the person's task

Flag inaccessible custom select when a visual dropdown lacks keyboard opening, option navigation, selected state, focus return, accessible value, or submitted form value.

Inaccessible custom select

Use it when: Use this anti-pattern entry to audit custom dropdowns, styled select replacements, portal menus, command-palette-like selectors, and generated UIs that imitate native controls.

Make this state clear: Closed state with persistent label, current value, and collapsed state.

Observe the result: Screen reader users hear the label, current value, expanded state, available options, and selected value.

Study the full pattern →

Select

Use it when: The user chooses one option from a moderate known list.

Make this state clear: Closed state with empty option or current selected value.

Observe the result: Users can open, scan, choose one value, and review the selected value after close.

Study the full pattern →

Autocomplete

Use it when: The list is long but values are known.

Make this state clear: Empty input state.

Observe the result: Typing filters suggestions while preserving the exact typed value.

Study the full pattern →

Multi-select

Use it when: Users choose many values from a long predefined list.

Make this state clear: Open filtered option list state.

Observe the result: Selection limits and duplicates are handled before submit.

Study the full pattern →

Practice the judgment: Imagine this situation: A fake select updates visual text but submits an empty value. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Inaccessible custom selectSelectAutocompleteMulti-select
UI or UX UI + UX - Broken custom widget anti-patternUI + UX - Single-choice dropdown controlUI + UX - Input widget with suggestion behaviorUI + UX - Multi-value picker widget
UI guidance Replace fake select markup with a native select unless a custom listbox, combobox, or multi-select contract is truly required and fully implemented.Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.Expose clear visual states for expanded, focused, highlighted, and selected options.Render a filter input, open option list, selected-value chips, remove controls, checked option states, clear-all control, and validation state.
UX guidance Let every user complete the same choice with pointer, keyboard, touch, voice, and assistive technology instead of making styling work for only one input method.Help the person reach a clear task outcome.Preserve typed input and make selection reversible before submission.Help users choose multiple values from a large, compact, or dynamic option set.
Good UI A native select keeps its persistent label, selected value, required validation, and platform keyboard behavior.Persistent label, hint text, visible selected value, readable options, and clear required validation state.Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.Selected values are shown as removable chips or checked rows with clear labels.
Bad UI The selected visual label changes but the submitted form value remains empty.Placeholder as the only label.Placeholder-only label that disappears after typing.Selected values hidden inside a closed dropdown.
Good UX Screen reader users hear the label, current value, expanded state, available options, and selected value.Users can open, scan, choose one value, and review the selected value after close.Typing filters suggestions while preserving the exact typed value.Selection limits and duplicates are handled before submit.
Bad UX Focus lost on close or trapped in a portal.Hiding two obvious critical choices in a dropdown.Automatically forcing the first suggestion into the field.Removing a value is impossible by keyboard.
Best fit Use this anti-pattern entry to audit custom dropdowns, styled select replacements, portal menus, command-palette-like selectors, and generated UIs that imitate native controls.The user chooses one option from a moderate known list.The list is long but values are known.Users choose many values from a long predefined list.
Avoid when The custom component fully implements the appropriate listbox, combobox, or multi-select contract and has been tested with keyboard and assistive technology.The option set is short and comparison matters.The task is open-ended query exploration.The set is short and independent choices should stay visible.
Required state Closed state with persistent label, current value, and collapsed state.Closed state with empty option or current selected value.Empty input state.Open filtered option list state.
Accessibility burden Expose name, role, value, expanded state, popup relationship, active option, and selected option state when implementing custom choice widgets.Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.Expose combobox expanded state, active descendant, and option labels.Expose selected state for options and labels for remove controls.
Common misuse Closing the menu before keyboard or assistive technology users can inspect options.Using select to hide two or three obvious choices that should be compared.Using autocomplete where users expect broad search results.Hiding selected values inside a closed menu.

Inaccessible custom select

UI or UX
UI + UX - Broken custom widget anti-pattern
UI guidance
Replace fake select markup with a native select unless a custom listbox, combobox, or multi-select contract is truly required and fully implemented.
UX guidance
Let every user complete the same choice with pointer, keyboard, touch, voice, and assistive technology instead of making styling work for only one input method.
Good UI
A native select keeps its persistent label, selected value, required validation, and platform keyboard behavior.
Bad UI
The selected visual label changes but the submitted form value remains empty.
Good UX
Screen reader users hear the label, current value, expanded state, available options, and selected value.
Bad UX
Focus lost on close or trapped in a portal.
Best fit
Use this anti-pattern entry to audit custom dropdowns, styled select replacements, portal menus, command-palette-like selectors, and generated UIs that imitate native controls.
Avoid when
The custom component fully implements the appropriate listbox, combobox, or multi-select contract and has been tested with keyboard and assistive technology.
Required state
Closed state with persistent label, current value, and collapsed state.
Accessibility burden
Expose name, role, value, expanded state, popup relationship, active option, and selected option state when implementing custom choice widgets.
Common misuse
Closing the menu before keyboard or assistive technology users can inspect options.

Select

UI or UX
UI + UX - Single-choice dropdown control
UI guidance
Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance
Help the person reach a clear task outcome.
Good UI
Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI
Placeholder as the only label.
Good UX
Users can open, scan, choose one value, and review the selected value after close.
Bad UX
Hiding two obvious critical choices in a dropdown.
Best fit
The user chooses one option from a moderate known list.
Avoid when
The option set is short and comparison matters.
Required state
Closed state with empty option or current selected value.
Accessibility burden
Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse
Using select to hide two or three obvious choices that should be compared.

Autocomplete

UI or UX
UI + UX - Input widget with suggestion behavior
UI guidance
Expose clear visual states for expanded, focused, highlighted, and selected options.
UX guidance
Preserve typed input and make selection reversible before submission.
Good UI
Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI
Placeholder-only label that disappears after typing.
Good UX
Typing filters suggestions while preserving the exact typed value.
Bad UX
Automatically forcing the first suggestion into the field.
Best fit
The list is long but values are known.
Avoid when
The task is open-ended query exploration.
Required state
Empty input state.
Accessibility burden
Expose combobox expanded state, active descendant, and option labels.
Common misuse
Using autocomplete where users expect broad search results.

Multi-select

UI or UX
UI + UX - Multi-value picker widget
UI guidance
Render a filter input, open option list, selected-value chips, remove controls, checked option states, clear-all control, and validation state.
UX guidance
Help users choose multiple values from a large, compact, or dynamic option set.
Good UI
Selected values are shown as removable chips or checked rows with clear labels.
Bad UI
Selected values hidden inside a closed dropdown.
Good UX
Selection limits and duplicates are handled before submit.
Bad UX
Removing a value is impossible by keyboard.
Best fit
Users choose many values from a long predefined list.
Avoid when
The set is short and independent choices should stay visible.
Required state
Open filtered option list state.
Accessibility burden
Expose selected state for options and labels for remove controls.
Common misuse
Hiding selected values inside a closed menu.
Decision rules
  • Flag inaccessible custom select when a visual dropdown lacks keyboard opening, option navigation, selected state, focus return, accessible value, or submitted form value.
  • Use native select when the user chooses one value from a finite known list and the platform control satisfies labeling, validation, keyboard, and mobile behavior.
  • Use a custom listbox-style select only when native select cannot meet a documented requirement and the component exposes label, current value, expanded state, active option, and selected option.
  • Use autocomplete when users need to type, filter, or complete a long known list while preserving typed input and suggestion selection rules.
  • Use multi-select when users can choose more than one value and need visible selected chips, removal, clear-all, filtering, and multi-value submission.
  • Use radio group instead of any dropdown when the list is short and visible comparison or consequence review matters.
  • Do not auto-submit or navigate while users arrow through select options or custom listbox options.
  • Do not ship a custom dropdown until pointer, keyboard, touch, screen reader, form validation, reset, and server-submission behavior all agree on the selected value.
Inspect live examples
Inaccessible custom selectSelectAutocompleteMulti-select
Failure modes
  • A fake select updates visual text but submits an empty value.
  • Keyboard users cannot open the options or recover focus after closing.
  • Screen readers hear a generic clickable element instead of a named choice control.
  • A custom dropdown is reused for autocomplete without typed filtering semantics.
  • A single-select popup is used for multiple choices but closes after every selection and hides selected values.
  • Options are clipped by overflow or portals and cannot be reached at zoom or mobile widths.

Saved items