Site search and autocomplete

In short

People who know what they are looking for don’t wander through the menu; they type the word in their head into the search field. Autocomplete completes that word as they type and takes them by a short path to the right result.

This pattern has four parts: where the field goes, the suggestion list, tolerance for typos, and the screen that appears when there are no results. All four must work with the keyboard and screen reader. I describe them in order; in the middle of the page there is an example to try yourself.

Where the search field should go and how big it should be

On the home page, search shouldn’t be a link but a field you can type into. Jakob Nielsen wrote this in 2001 in “Search: Visible and Simple”. When he replaced the link with a field on his own site, useit.com, search use rose by 91 percent.

According to Nielsen, the field belongs at the top of the page, usually in the right-hand corner. He adds that the left works almost as well. That is where visitors expect the field. Put it elsewhere and they have to look for it first.

Nielsen doesn’t give an exact number of characters. The field should be wide enough for a typical query. If it is too narrow, the start of a long query slides out of view to the left, and the field becomes harder to use.

On phones, the real problem is the space where the list opens. Baymard shows that sticky headers, chat bubbles and app banners leave no room for the suggestion list. In one example only 2 suggestions were visible, and those half hidden; the user typed her whole query herself. The rest of the store page is described in the e-commerce UX guide.

Suggestions: query suggestions and product suggestions

According to Baymard’s 2022 benchmark, 80 percent of e-commerce sites have autocomplete. At the first benchmark in 2014 it was 72 percent. But only 19 percent get everything right.

There are two kinds of suggestions. A query suggestion completes what was typed: someone who types “sweat” is offered “sweater” and lands on the results page. A product suggestion shows a product or category directly and opens that page when clicked.

In her NN/g article, Kate Moran recommends using rich suggestions, that is, links to products and categories, sparingly. On phones, only plain text suggestions should appear. A search scoped to a category, such as “sweater in Women”, should stand apart from the query. Baymard agrees. Italics, a different colour or an indent all work; in the tests no variant beat the others.

How many suggestions

Baymard’s limit is at most 10 suggestions on desktop and 4 to 8 on phones. In the tests, too many suggestions led to choice paralysis: users ignored the suggestions or took a very long time to read them. The list should open at its own height and have no scrollbar of its own.

Moran’s rule is simpler: every query you suggest should really return good results. A suggestion with no results leads users into a dead end with your own suggestion. In the NN/g test, suggestions appeared 136 times, and in 31 cases, or 23 percent, users chose one of them.

Keep the list plain and easy to tap

Baymard recommends reducing visual noise on desktop. Lots of white space, dividers, alternating row colours and extra content overshadow the actual suggestions. Trending searches are one example. Dimming the page background while the list is open reduces distraction from ads and carousels.

On phones, Baymard asks for a large enough font and tap area and spacing between rows. Small type and dense rows lead to mis-taps. Instead of all capitals, suggestions should appear in normal case. How big a tap area should be is described in the touch target pattern.

Which part should be bold

Here two sources say different things. Baymard recommends highlighting not the typed part but the completed part. Moran distinguishes two cases. If the suggestions only append something to what was typed, highlight the completed part. If the typed word also appears in the middle of the suggestion, highlight the typed part.

In the example below, “sweater” also appears in the middle of product names such as “Turtleneck sweater”. So I applied Moran’s second rule and made the matching part bold. That way you see at a glance where in the product name the word sits.

Tolerance for typos, accents and plurals

In an English-language store, think about how people type before you think about typos. Someone typing fast on a phone writes “cafe” instead of “Café” and “sweaters” when the product is called “sweater”. If search doesn’t count these as the same word, it reports “no results” even though the product is in stock.

Upper and lower case depend on the language too. According to MDN, toLocaleLowerCase() converts according to the rules of the given language; the documentation shows this with the Turkish “İ”, which keeps an extra dot under the English rule. For search this means: decide which language you convert by.

Accents can be handled with Unicode normalisation. MDN describes how normalize("NFD") splits a character such as “ñ” into “n” plus a combining tilde. Drop the combining mark, and “é” becomes “e”.

So the example has two steps. First I lower-case the query and the product name under the English rule and turn accented letters into plain ones. If that doesn’t match, I also drop a final “s” from the query. That way “cafe” finds the “Café mug” and “sweaters” finds every “sweater”.

Real typos need more. According to Baymard, some users have only heard a product name and don’t know how it is spelled. So search must tolerate phonetic misspellings too. It also has to know different and regional names for the same product. According to Baymard, 56 percent of sites don’t meet users’ search needs well enough.

Live example: accessible autocomplete

The field below searches a made-up store catalogue I wrote for this page. The first row is always the search for the typed word; it is in italics and gives the number of products. The rows below are product suggestions, with the category on the right.

Accessible autocomplete

Example: the list that opens for “sweat” in the search field

• Cashmere sweaterMen
• Kids sweaterKids
• Knit sweater, creamWomen
• Turtleneck sweaterMen
• Wool sweaterWomen

Because JavaScript is off, the example stays fixed. With JavaScript you can type into the field yourself.

The search field of a made-up fashion store. Type “sweater”, “cafe” or “sweaters”: accents, plurals and upper and lower case are tolerated. Navigate with the arrow keys, select with Enter, close with Esc. A typo like “sweter” shows the no-results screen.

When you move to a product with the arrow key, its name is copied into the field. Baymard recommends this, because users can then add details to the suggested term and search. Esc brings back what you typed yourself.

The no-results page

According to Baymard, nearly half of sites offer no effective way out after a search with no results. A badly built no-results page makes it easy for visitors to leave the site. It is also an empty state and follows the same principles.

Kathryn Whitenton’s three guidelines for NN/g are short: say clearly that there are no results, offer starting points to continue, and don’t mock users. Baymard adds a warning: just listing search tips isn’t enough; users rarely read such tips.

The ways out Baymard recommends:

• Broader categories for the query, ideally linking to a filtered product list.
• Simplified versions of the query with a preview of the first 3 to 5 products for each. If only one alternative returns results, it is applied automatically with a notice.
• Suggestions based on browsing history.
• Phone, live chat and links to help.
• Best sellers and popular categories.

If you type “sweter” in the example, “sweater” appears under “Did you mean:”, with popular searches next to it. Sometimes a no-results page comes not from spelling but from an active filter. The list that shows zero results with active filters is described in the filtering and sorting pattern.

Using it with the keyboard

If the suggestion list works with the mouse but not with the keyboard, it is only half done. The W3C’s ARIA Authoring Practices Guide (APG) sets these keys for the component made of a text field and a pop-up list:

Down arrow

In the field, it moves focus into the list. In the list, it goes to the next suggestion. At the last suggestion, it goes back to the field or does nothing.

Up arrow

Goes to the previous suggestion.

Enter

Accepts the selected suggestion and closes the list. If no suggestion is selected, the typed text is searched.

Escape

Closes the open list, and focus returns to the search field. If the list is closed, it can clear the field; this is optional.

Alt + Down arrow

Opens the closed list without moving focus. Optional.

Baymard also recommends on desktop navigating with the arrow keys, selecting with Enter and letting the list wrap from the end back to the start. The suggestion under the mouse pointer should get a background colour. In the example I gave the same colour to the row chosen with the keyboard. There is also a dark bar on the left of the row, because not everyone can tell apart a signal that relies on colour alone.

A detail about Esc: according to the APG, Esc closes the open list. Clearing the field when the list is already closed is optional. In the example I implemented both, so users don’t lose their input with a single key press.

Accessible combobox

The APG calls this component a combobox: an input field with an associated pop-up. The pop-up can be a list, grid, tree or dialog. For search suggestions it is almost always a list.

The APG names four kinds of autocomplete. The kind in the example is “list autocomplete with manual selection”: the suggestions are filtered by what was typed, but if the user doesn’t choose one, the value stays their typed text. For search I consider this the safest kind, because Enter always searches what was typed.

What is needed for the screen reader to announce the component correctly:

• On the search field, role="combobox" and aria-autocomplete="list".
• aria-expanded="false" when the list is closed, "true" when it is open. aria-controls points to the list.
• Focus stays in the field. The selected suggestion is announced with aria-activedescendant and carries aria-selected="true".
• The list has role="listbox", each row role="option".

My own addition: announce with a status message how many suggestions there are. In the example, the sentence “4 products match” sits in an aria-live region. So that users don’t hear an announcement with every letter, it updates shortly after typing stops. The WCAG page on status messages is covered in the WCAG guide.

My note

In audits I always test the search field the same way: I take a product name from the product list and type it without its accent or in the plural. Stores where “sweaters” returns no results aren’t rare. The fix is small but has a direct effect on revenue.

My second test is the no-results page. I deliberately type a wrong word and see what the page suggests. If I see an empty page saying “0 results”, I assume visitors leave there.

Finally I let go of the mouse and press the down arrow. If the list doesn’t react or Enter leads somewhere unexpected, I note it as a high-priority finding. For these checks on your own site you can use the UX audit checklist.