Component contract
What it must accomplish
Provide a compact single-choice control when showing every option is unnecessary.
DefaultFocusOpenSelectedInvalidDisabled
Usage
Choose the control by behavior
Use it when
- Options are known and mutually exclusive
- The list is moderate in length
- The current selection should remain visible
Use another pattern when
- Comparing all options matters; use radios
- The list needs search; use a combobox
- Multiple selections are allowed
Anatomy
Stable parts create a reliable contract
- 1Label
- 2Select control
- 3Selected value
- 4Disclosure indicator
- 5Option list
- 6Hint or error
Explanation
Interaction and keyboard behavior
- Native selects retain platform keyboard behavior
- Custom listboxes support Arrow keys and typeahead
- Escape closes a custom popup
Why this matters
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Cross-system baseline
Accessible behavior
- Prefer the native select when customization is not essential
- Keep a persistent label
- Associate errors and hints
- Never use a placeholder as the only label
Responsive considerations
Adapt the decision—not only the dimensions
Use the available width, preserve at least a 44-pixel target, and leave room for the disclosure indicator and long localized values.
Content considerations
Language is part of the component
- Order options predictably
- Use a real empty prompt only when no default is valid
- Keep labels parallel
Common mistakes
Patterns that weaken the experience
01
Using tiny controls for large type
02
Styling away native behavior without replacing it
03
Hiding the selected value
Comparison
What to study across systems
Native platform selects maximize familiarity; enterprise systems often use custom controls for density and richer options, increasing implementation responsibility.
Open comparison