Autocomplete Patterns: Search Suggestions and Fields That Fill Themselves

What kinds of autocomplete exist?

Search autocomplete shows suggestions below the field while the user types. It can complete the query, suggest a category, or go straight to a product. Form autocomplete is different: the page does not control it, the browser does. It proposes data such as name, address, or card number.

The two problems are different, but they share one question: does the user save time or lose attention? A suggestion that does not help is noise; a field filled in wrongly is an error.

Why does this matter for a junior designer?

Because autocomplete appears on almost every product, and almost nobody reviews it. According to Baymard (2022), search autocomplete appears on 80% of the e-commerce sites it studied, but only 19% get all the implementation details right. That gap is an improvement opportunity that does not need a big redesign.

Form autocomplete also saves users from typing by hand data the browser already knows. If a field is properly identified as the postal code, the user does not have to type it, which avoids typing errors.

How do you design search autocomplete?

1. Limit the number of suggestions. Baymard says not to exceed 10 on desktop, and aims for 4 to 8 on mobile.
2. Highlight what is missing, not what you already typed. The useful part is the predictive portion. If all the text is bold, the user cannot see what the suggestion offers.
3. Distinguish suggestion types. A query (“sofa bed”) and a scope (“in Furniture”) should look different. Baymard found no single style beat the others: italics, a different text color, or indentation all gave enough of a cue.
4. Do not crowd the list with extra content. Baymard advises limiting additional elements, such as product suggestions or trending searches, which can overpower the query suggestions.
5. Test with real queries. Autocomplete that looks good with two words can produce confusing suggestions for rare terms.

For how to show change while the response loads, the article on loading states explains how to keep the list from flickering.

How do you use the autocomplete attribute well in forms?

MDN describes the attribute and its values in detail. A few practical rules:

• Use the right token for each field. given-name for the first name, family-name for the last name, email for email, and tel for phone. The W3C lists tokens such as username, nickname, or bday.
• Respect the token order. MDN gives an order: section identifier first, then shipping or billing, then detail tokens, and webauthn last.
• Do not mix street-address with the lines. street-address does not include the city, postal code, or country, and address-line1 to address-line3 should only be used if street-address is not present.
• Use payment tokens where they apply. cc-number for the card number, cc-exp for the expiry date (MM/YY or MM/YYYY), and cc-csc for the security code.
• Use off only when needed. MDN recommends reserving it for cases such as a CAPTCHA or a one-time token field, not applying it across the whole form.

For validating these fields, the article on form validation timing explains when to show an error.

What does WCAG 1.3.5 require?

Criterion 1.3.5, Identify Input Purpose, is level AA. It asks that the purpose of each field collecting user data can be determined in code, when the field serves a purpose on the criterion’s list and assistive technology can express it. It does not apply to fields asking for data about another person.

This lets the browser and assistive technology recognize what each field asks for and present or fill it appropriately. Without the attribute, they would have to guess.

When should you NOT use autocomplete?

• In one-time fields. A CAPTCHA or a verification code should not fill itself; MDN gives these cases as examples of legitimate use of autocomplete="off".
• In fields that do not ask for user data. WCAG 1.3.5 does not apply, and autofilling personal data has no purpose there.
• As a substitute for a correct autocomplete attribute. Visible suggestions do not replace the attribute, which is still the foundation of everything else.

If you want to use AI to generate suggestions, the article on AI autocomplete covers the risks of suggestions that are invented.

Example

Illustrative example: a shipping form in an online store has three problems.

• Problem: the “address” field asks for street, number, and floor in one line, with no attributes. The browser cannot fill it, and the user types it by hand.
• Fix: the address is split into lines with street-address and postal-code, and the city field uses address-level2.
• Problem 2: the search field shows 25 suggestions on mobile, with the typed text in bold.
• Fix: the list is limited to 6 suggestions, and the missing part is highlighted.

The result does not change the visual design; the goal is a faster shipping step and fewer address errors. It is a good example of how autocomplete improves checkout without touching the aesthetics.

Common mistakes

• Using autocomplete="off" to block autocomplete, without knowing browsers may ignore it on login fields.
• Mixing street-address with address-line values in the same form.
• Ordering the attribute’s tokens wrongly.
• Highlighting the text already typed instead of the suggestion.
• Showing suggestion lists longer than the user can read.
• Showing the same long list on mobile as on desktop, when Baymard aims for 4 to 8 suggestions.

Sources

• Baymard Institute, Autocomplete Design
• MDN, autocomplete (HTML attribute)
• W3C, Understanding SC 1.3.5: Identify Input Purpose