Autocomplete automatically completes typed user input with matching results from a larger data set. Autosuggest breaks beyond the input provided to suggest alternative, relevant answers.
- Autocomplete (not built)
- Button Group (not built)
- Checkbox Group
- Date Picker (not built)
- Empty State
- Filter Menu
- Global Notification
- Guidance Block
- Hero Card
- Icon Button
- Infinite Scroll (not built)
- Inline Notification
- Likert Scale Legacy
- Loading Placeholder
- Loading Skeleton (not built)
- Loading Spinner
- Pagination (not built)
- Progress Bar (not built)
- Progress Stepper
- Radio Group
- Rich Text Editor
- Search Field (not built)
- Slider (not built)
- Split Button
- Tile Grid
- Toast Notification
- Search and autocomplete are separated into distinct components, because search may be used in a way that doesn't show autocompleted results.
- Unlike a Select (single- or multi-) that lets you select options from an options menu, the Autocomplete component has other behavior beyond choosing an option as the value for a setting, such as linking to other content.
You might use the guidance around autocompletion in other UI or components, such as using good defaults in Select. You might also use the Autocomplete component to present autocomplete options in a dropdown container for Search Field.
Using Autocomplete, a user can start writing a partial query and available results are surfaced, which they can select. This works well when the user has some idea of what might be available.
Autocomplete is forgiving, letting people make mistakes such as spelling errors and still predict the content they want.
- Dropdown container: the bit that drops down from a Search Field to show Autocomplete options.
- Autocomplete options or items: the options menu that lets you choose options.
- Each option/item may be presented as plain text or with rich media, such as images.
- Limit the number of options: Show 10 or fewer suggested items at a time (and no scroll bar) so the options don’t become overwhelming.
- Design for the loading state:
- If autocomplete options are likely to take longer than 1 second to show for the majority of users, display a loading indicator. For example, you might display a loading spinner in place of the search icon in a Search Field or one loading spinner in the whole Dropdown container. See loading guidelines.
- Test performance: To maintain performance and responsive interaction, you may consider if “debouncing” is necessary for rapidly changing search queries, avoiding search results appearing and reappearing rapidly or blocking the page and preventing the user from typing.
- Highlight matching text: Clearly identify matching and non-matching text. For example, with 3 suggested items starting with the same text that the user searched for, you might presented the additional, non-matching text in a stronger font weight.
- Keep results clean: Avoid providing too much information or metadata in the suggested items to reduce cognitive load for the user choosing an item.
- Categorization: Consider if it's helpful to chunk results into categories with subheadings.
- Good defaults: Where possible, show good defaults on focus, even before the user has typed anything.
- Keyboard navigation: Ensure the results list can be navigated with a keyboard and test this regularly.
- Show autocomplete options after conditions:
- For a limited dataset you might update autocomplete options with new matching results on every key stroke the user types.
- For large datasets you might delay updating options until there's at least some number of characters (usually 3). If so, ensure results of only 1 or 2 characters long can be shown.
- Fuzzy search: a user can write some text and a partial match returns results. Consider whether the text needs to be in order, what effect spaces have, and the effect of capitalization on the match. For example, a forgiving search input that lets you type “design” to match the result “Marketing Design” may be ideal for users that aren't sure what exactly it will be called here.
- Smart capitalization matching: consider appropriate capitalization matching for the data available. For example, when people type a search query using lowercase letters, you might return all, case-insensitive results and when they type a search query containing capital letters, you might return only case-sensitive results matching their capitalization.
Use short and clear keywords in autocomplete options. This helps people understand the content associated with the keyword. You might, for example, use linked page titles as keywords rather than page descriptions.
Similar to traditional “autocomplete,” “autosuggest” breaks beyond the input provided to suggest alternative, relevant answers. It might even suggest results from multiple data sets.
- When tabbing forward or backward through the page, let the autocomplete text input take keyboard focus with the tab key
- Let people navigate through the list of autocomplete options using the up and down arrow keys
- Let people select the option that has focus using the Enter key
Let people using screen readers know when new options are presented while typing. This requires testing to avoid excessively noisy announcements.
If the Autocomplete component causes a change to content on the page, use ARIA live regions to inform screen reader users of what's changed.
- Use Autocomplete when the user has some idea of the content available and some related terms they might use to search
- Avoid Autocomplete when the user has no concept of the search space and what's available. You might instead use navigation options or surface top content.