Autocomplete search suggestions are one of the most common small enhancements on the modern web. Start typing in a search bar, and a dropdown of matching results, products, articles, pages, appears beneath it before you have even finished your query. We tested this exact interaction across 60 different site search bars, spanning ecommerce, media, documentation, and SaaS products, typing a partial query and checking whether a screen reader announced the resulting suggestions. On 44 of the 60, it did not. The dropdown appeared perfectly, visually, every time. A screen reader user typing the same query heard nothing but their own keystrokes.
This is one of the more quietly damaging accessibility gaps on the web, precisely because it fails invisibly rather than obviously. A completely broken search bar, one that does not work at all, gets noticed and fixed quickly, because it is broken for everyone. A search bar with autocomplete that simply never announces its own suggestions looks, sounds, and behaves completely normally to a screen reader user right up until the moment they realize sighted users are seeing something appear on screen that they cannot access at all, a gap that is far more likely to go unreported because nothing about the interaction feels obviously broken from the screen reader user's side. They typed, they got no suggestions, they assumed there were none.
Context for This Pattern: The correct accessible implementation for this interaction is the ARIA combobox pattern with a properly associated
aria-liveregion oraria-activedescendantwiring, documented directly in the W3C's ARIA Authoring Practices Guide, and it exists specifically because a visual-only suggestion dropdown provides zero information to assistive technology by default.
Why "It Uses ARIA" Is Not the Same as "It Works"
Roughly a third of the failing sites in this test did include some ARIA attributes on the search component, role="combobox" or aria-expanded present in the markup, which is exactly the trap that makes this failure pattern so persistent. Adding an ARIA role or attribute changes nothing on its own if the surrounding wiring is incomplete. The combobox pattern requires the input to be correctly associated with the listbox of suggestions via aria-controls, the currently highlighted suggestion tracked via aria-activedescendant as a user arrows through the list, and in some implementations a live region announcing the result count as it updates. A search bar with role="combobox" on the input but none of that supporting wiring looks, to an automated scanner doing a shallow attribute check, like it might be accessible. It is not, and only a real screen reader test catches the difference, which is exactly why this pattern survives so many teams' existing QA process.
The Sixteen That Got It Right
The sixteen search bars that passed shared a specific, consistent implementation: a live region, usually visually hidden but present in the DOM, that announced something like "4 results available" as suggestions loaded, combined with proper aria-activedescendant tracking so a screen reader user arrowing down through the list heard each suggestion announced individually as they moved through it, the same way a sighted user visually scans down the list. None of these sixteen implementations were custom or exotic. They were, in every case we reviewed, a fairly direct implementation of the W3C's published combobox pattern, which suggests the gap is not a hard technical problem, it is a pattern that has simply not propagated into common practice as consistently as the visual behavior of autocomplete itself has.
Why This Specifically Matters for Site Search
Search is disproportionately important for users navigating with assistive technology, because it is often a faster path to content than linear keyboard navigation through a full page or menu structure. A screen reader user relies on search precisely to avoid tabbing through dozens of navigation links to find one piece of content, which makes a broken autocomplete experience a bigger relative loss for that user than for a sighted user who can always fall back to scanning the page visually. The users most likely to benefit from a well-implemented autocomplete are, in a real sense, the same users this failure pattern hurts the most.
This gap is closely related to the pattern covered in our piece on the autocomplete attribute that traps screen reader users, though that piece covers the form-field autofill attribute specifically, a different mechanism from the search-suggestion combobox pattern covered here. Both share the same root cause: a feature built for its visual behavior first, with the accessible announcement layer treated as optional or skipped entirely.
What to Check on Your Own Search Bar
Turn on a screen reader, VoiceOver on Mac or NVDA on Windows, both free, and type a partial query into your own site's search bar. If suggestions appear on screen and you hear nothing announced as you type or arrow through them, you have this exact gap. The fix is the W3C's documented combobox pattern, not a custom solution, and it is a well-scoped, testable fix rather than an open-ended redesign.
If you want a free check on whether your own search implementation has this gap, our free accessibility tools can scan your site's markup, and our team is reachable at experts@wcag.world for a deeper manual test of the actual announced behavior. The W3C's combobox pattern documentation and status messages guidance cover the correct implementation directly from the source.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: store locator map accessibility.
A short written test plan also makes handoffs safer. Name the user goal, the starting focus, the success announcement, and the exact fallback when the preferred path is unavailable. Review that plan with someone who uses the interface differently from its author, then record the result alongside the release notes. This is a small habit, but it catches regressions that a green automated result cannot describe.