Making Store Search and Autocomplete Accessible
Search suggestions appear fast, change constantly, and are easy to break for keyboard and screen reader users. A pattern for autocomplete that announces, navigates, and dismisses properly.
Search is the front door for shoppers who know what they want, and the suggestion list is where that door sticks. Results update as each letter is typed, focus behaviour varies by implementation, and a screen reader user can be left typing into a box whose suggestions they never hear about.
Autocomplete is a solved pattern when it is built as one. This guide covers the announcement, keyboard, and dismissal behaviour a store search box needs, and how to test it with real queries.
Announce that suggestions exist and how many
When suggestions appear, a screen reader user needs to know: that a list opened, roughly how many results it holds, and how to reach it. A polite live region announcing the result count, with instructions to use the arrow keys, covers all three without interrupting typing.
As the query changes, the announcement should update without chattering on every keystroke. Debounced announcements tied to the settled result set keep the user informed without turning each character into a speech event.
Make the list fully keyboard operable
Arrow keys should move through suggestions, Enter should choose, Escape should close the list and return the user to their typed text intact. Tab should move on to the next control, not trap the shopper inside a suggestion list they did not ask to enter.
The active suggestion needs both a visible highlight and a programmatic state, so keyboard and screen reader users are looking at the same item sighted users see highlighted. A mismatch between the visual highlight and the announced item is a common and confusing defect.
Handle no results and errors in text
An empty suggestion list is information, and it should be delivered as text: no matches for this term, with a route to the full search results page. A silent empty box reads as a broken search to a screen reader user.
The full results page matters as the reliable fallback. Every suggestion interaction should end somewhere usable: a product, a results page, or a clear no results message. Autocomplete that only works with a mouse fails that test.
Test search with real catalogue queries
Test with the queries shoppers actually type: misspellings, brand and product names, multi word phrases, and terms with no matches. Each type stresses a different part of the pattern, from announcement timing to the no results route.
Repeat the tests after any search app or theme update. Search is usually a third party component, and its updates change focus and announcement behaviour without any visible difference, which is exactly the class of change that slips past visual review.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Keyboard Navigation for Product Image Galleries, Accessible Size Guides and Fit Finders That Actually Help, and Accessible Checkout Error Recovery That Saves the Order.
Frequently asked questions
Should typing move focus into the suggestion list automatically?
No. Focus stays in the search box while the user types. Arrow keys move the active suggestion from there. Moving focus on each keystroke destroys the typing flow and disorients screen reader users.
How many suggestions should be announced?
Announce the count and let the user navigate the list, rather than reading every suggestion aloud. Reading the full list on each keystroke makes search unusable for the people the announcement exists to help.
What if the store search is provided by an app?
The store still owns the shopper experience. Test the app against the announcement and keyboard pattern, raise gaps with the vendor in writing, and weigh the results when the app contract renews.
Does autocomplete need to work without a mouse on mobile too?
Yes. Touch users need suggestions that are easy to tap, a close route that works, and no layout that hides the list behind the keyboard. The pattern adapts, the obligations do not shrink.