Autocomplete and Typeahead
Suggestions as the user types, which turns recall into recognition when it is fast enough.
Definition
Autocomplete offers matching options in response to partial input. It reduces typing, prevents errors and teaches the vocabulary the system understands. It is also one of the most commonly mis-implemented accessible widgets.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- The value comes from a large known set.
- Typing the full value is slow or error-prone.
- Users may not know the exact vocabulary.
- The set of valid values is large and readers usually know roughly what they want to type.
Common mistakes
- Suggestions that arrive too late to be useful.
- Incomplete ARIA implementation.
- Overwriting typed text.
- No path for values outside the list.
Requirements
- Respond within about 200ms, or the suggestions arrive after the user has moved on.
- Debounce input, typically 150 to 300ms, and cancel in-flight requests when a newer one starts.
- Full keyboard support: arrow keys to move, Enter to select, Escape to dismiss, Tab to leave.
- Never steal the typed text. Inline completion that overwrites what the user typed causes errors.
- Announce the number of suggestions to assistive technology through a live region.
- Allow free text where the value may not be in the list, and be explicit about which mode the field is in.
Suggestions that help rather than interfere
Do
- Mark which part of the suggestion matched the typing.
- Keep the typed text in the field while arrowing through suggestions.
- Announce the number of suggestions through a live region.
- Allow free text where a value outside the list is legitimate.
Do not
- Autoselect the first suggestion, so Enter submits something the reader never chose.
- Fire a request on every keystroke without debouncing.
- Cover the field with the suggestion list on small screens.
- Reorder suggestions while the reader is reaching for one.
Where suggestions come from
Most fields blend several sources. Mixing them without marking which is which is why suggestion lists feel arbitrary.
| Source | Offers | Fails when |
|---|---|---|
| Recent input from this reader | What they typed before, ranked first | The list is stale, or private on a shared device. |
| Popular across everyone | The vocabulary the system understands | The reader is doing something nobody else does. |
| Direct matches from the catalogue | The item itself, skipping the results page | Matches are truncated so two similar items look identical. |
| Spelling correction | The intended word, marked as a correction | It corrects a deliberate term, such as a product code. |
| Category or scope jumps | A narrower place to search | They dominate the list and bury the actual matches. |
The markup contract
<label for="city">City</label>
<input
id="city"
role="combobox"
aria-expanded="true"
aria-controls="city-list"
aria-activedescendant="city-opt-2"
aria-autocomplete="list"
autocomplete="off"
/>
<ul id="city-list" role="listbox">
<li id="city-opt-1" role="option" aria-selected="false">Bristol</li>
<li id="city-opt-2" role="option" aria-selected="true">Brighton</li>
</ul>
<div aria-live="polite" class="visually-hidden">2 suggestions available</div>The attributes are the pattern. aria-activedescendant moves the virtual cursor while real focus stays in the input, which is what keeps the typed text editable throughout.
In practice
- i.
Address lookup
CheckoutA single lookup field replacing five address inputs removes format errors entirely and speeds up the most abandonment-prone part of checkout.
- ii.
Enter, and the wrong city
AutoselectionA field that highlighted the first suggestion by default meant a reader pressing Enter to submit the form chose a city they had not read. Nothing should be selected until the reader moves to it.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Select
ComponentA closed set of options, revealed on demand and chosen by picking.
Key difference
A select offers a closed list the reader picks from. Autocomplete accepts typing and narrows as it goes. The list length decides: a select stops working once scanning it costs more than typing.
Use Autocomplete and Typeahead when
- The set is long: cities, products, users, tags.
- The reader usually knows roughly what they want to type.
- Free text, or a new value, may be a legitimate answer.
Use Select when
- The whole set is short enough to scan, roughly under twenty.
- The reader may not know the options by name.
- Every valid answer is in the list.
Local chart
PAT·003 · Region III · Grid F1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
W3C, ARIA Authoring Practices Guide
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Principles behind this
The reasoning this solution is an application of.
- Recognition Over RecallHEUR·006 · Heuristic
- Doherty ThresholdLAW·006 · Law
- Postel's LawLAW·012 · Law
Often used with
These usually appear in the same screen or the same decision.
- DropdownCMP·019 · Component
- Text InputCMP·003 · Component
- Input ValidationPAT·007 · Pattern
- SearchPAT·002 · Pattern
Alternative approach
A different answer to the same problem, with a different cost.
- FilteringPAT·004 · Pattern
Typing narrows faster when the vocabulary is known. Filters narrow better when it is not.
Check your work
Review passes that test whether this was done properly.
- Form UX ChecklistCHK·001 · Checklist