behavior variant · Selection and suggestions
Autocomplete
A suggestion behavior that filters or completes values as a user types, commonly implemented as an editable combobox.
Decisive boundary
Specify whether suggestions are advisory or whether the final value must come from the list.
Definition and intent
What is a Autocomplete UI pattern?
Use the behavior, not the silhouette
A suggestion behavior that filters or completes values as a user types, commonly implemented as an editable combobox. The term is used here as a behavior variant that normally modifies another control rather than defining a complete component by itself. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Reduce typing and help users discover matching values as they enter text. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Autocomplete, the boundary is: Specify whether suggestions are advisory or whether the final value must come from the list.
Do not implement it as Treating Autocomplete as a complete semantic contract without defining its Combobox behavior. If those requirements describe the real task better, use the related pattern page or the full Selection and suggestions comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Reduce typing and help users discover matching values as they enter text.
Define opening and closing
Typing, focus, or a configured character threshold. Accepting a suggestion, Escape, focus change, or an empty result set.
Specify access behavior
Usually remains on the input while suggestion focus is represented programmatically. Text editing remains native; arrows explore; Enter accepts; Escape closes.
Reject the near miss
Treating Autocomplete as a complete semantic contract without defining its Combobox behavior.
Behavior contract
What must survive the build
- trigger
- Typing, focus, or a configured character threshold.
- dismissal
- Accepting a suggestion, Escape, focus change, or an empty result set.
- modality
- Non-modal.
- focus
- Usually remains on the input while suggestion focus is represented programmatically.
- keyboard
- Text editing remains native; arrows explore; Enter accepts; Escape closes.
- interactive
- Users type and may accept a suggested completion; free-form values depend on policy.
- persistence
- The accepted or typed value remains.
- placement
- Suggestion popup is associated with the input.
- mobile
- Avoid covering the input with the virtual keyboard or popup.
Failure modes
Common wrong builds
- Automatically replacing typed text without consent.
- Hiding whether free-form values are accepted.
- Announcing every keystroke noisily.
Observable checks
Verify the result
- Suggestions update predictably.
- Typed text is not lost.
- Keyboard users can inspect and accept suggestions.
- No-result state is clear.
- Free-form value policy is explicit.
Coding-agent handoff
Implementation brief template
Pattern: Autocomplete Purpose: Reduce typing and help users discover matching values as they enter text. Trigger: Typing, focus, or a configured character threshold. Dismissal behavior: Accepting a suggestion, Escape, focus change, or an empty result set. Modality: Non-modal. Focus behavior: Usually remains on the input while suggestion focus is represented programmatically. Keyboard behavior: Text editing remains native; arrows explore; Enter accepts; Escape closes. Interactive content: Users type and may accept a suggested completion; free-form values depend on policy. Placement: Suggestion popup is associated with the input. Mobile behavior: Avoid covering the input with the virtual keyboard or popup. Do not implement as: Treating Autocomplete as a complete semantic contract without defining its Combobox behavior. Acceptance checks: - Suggestions update predictably. - Typed text is not lost. - Keyboard users can inspect and accept suggestions. - No-result state is clear. - Free-form value policy is explicit.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Autocomplete UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Autocomplete in web UI?
A suggestion behavior that filters or completes values as a user types, commonly implemented as an editable combobox. In this reference set it is a behavior variant that normally modifies another control rather than defining a complete component by itself.
When should I use a Autocomplete?
Reduce typing and help users discover matching values as they enter text. The decisive boundary to confirm is this: Specify whether suggestions are advisory or whether the final value must come from the list.
What keyboard and focus behavior does a Autocomplete need?
Text editing remains native; arrows explore; Enter accepts; Escape closes. Usually remains on the input while suggestion focus is represented programmatically. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Autocomplete behave on mobile?
Avoid covering the input with the virtual keyboard or popup. Its modality is a separate requirement: Non-modal.
How do I verify a Autocomplete implementation?
Start with observable checks: Suggestions update predictably. Typed text is not lost. Keyboard users can inspect and accept suggestions. Then verify the remaining checks and compare the result with the linked source guidance.