What it must accomplish
Help people find a value in a large option set without scanning every choice.
Usage
Choose the control by behavior
- The option set is too large for a select
- Search terms or known values can narrow results
- Free text, suggestions, or both are explicitly supported
- Only a few options exist
- The user must compare every option
- Filtering cannot produce understandable results
Anatomy
Stable parts create a reliable contract
- 1Label
- 2Text input
- 3Popup trigger
- 4Listbox
- 5Options and selected state
- 6Loading, empty, and error feedback
Interaction and keyboard behavior
- Typing filters options
- Arrow keys move through suggestions
- Enter accepts the focused option
- Escape closes the popup without losing typed text
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Accessible behavior
- Expose combobox expansion and controls relationships
- Keep DOM focus and active option state synchronized
- Announce result count and loading changes
- Distinguish free entry from required selection
Responsive considerations
Adapt the decision—not only the dimensions
Keep the popup aligned to the field when space permits; on small screens a full-width picker may better preserve results and software-keyboard space.
Content considerations
Language is part of the component
- Use recognizable option labels
- Explain accepted free text
- Make no-results recovery specific
Patterns that weaken the experience
Building a custom autocomplete without complete keyboard behavior
Clearing input on no results
Showing duplicate labels with no differentiator
Comparison
What to study across systems
Fluent, Carbon, and Spectrum offer strong implementation references; public-service systems help clarify when simpler radios or autocomplete patterns reduce ambiguity.
Open comparison