Is Your Search Bar Locking People Out? A Plain-English Guide to Accessible Site Search and Autocomplete

For a lot of visitors, the search box is the website. They land on your homepage, ignore the menu, type what they want, and expect to be taken straight to it. On a large store or a content-heavy site, search often drives more conversions than any navigation menu. And shoppers who use search tend to buy: they already know what they want.

So it is worth asking an uncomfortable question. If your search bar is the front door for a big slice of your visitors, what happens to the ones who cannot use it?

For people who navigate with a keyboard instead of a mouse, or who rely on a screen reader to read the page aloud, a poorly built search box is not a minor inconvenience. It can be a dead end. And the part that breaks most often is the feature designed to make search easier: the predictive dropdown that suggests results as you type, usually called autocomplete or “typeahead.”

The good news is that you do not need to read a line of code to tell whether your search is accessible. You need ten minutes, your keyboard, and a free screen reader. This guide explains what tends to go wrong, how to test it yourself, and how to describe the problem clearly to whoever maintains your site.

Why search is a make-or-break feature for accessibility

Think about who relies on search the most. People who find scanning a busy page exhausting. People with low vision who would rather type three words than hunt through a cluttered menu at high zoom. People using a screen reader, for whom “just glance at the navigation” is not an option, because there is nothing to glance at — every menu item has to be read aloud, one at a time.

For these visitors, a working search box can be the single fastest way through your site. Which is exactly why a broken one hurts so much. When search fails for someone using assistive technology, they do not see an error message. They simply cannot find what they came for, and they leave. You never hear about it, and you never see it in your analytics as anything other than a bounce.

There is a legal dimension too. Under the Americans with Disabilities Act (ADA) in the US and the European Accessibility Act (EAA) in the EU, business websites are expected to be usable by people with disabilities, with WCAG 2.1/2.2 Level AA as the practical benchmark. Site search is not exempt. An autocomplete widget that a screen reader cannot operate is the kind of barrier that shows up in accessibility complaints and demand letters. But honestly, the business case is simpler than the legal one: if search is where people buy, you cannot afford to lock anyone out of it.

The four ways search bars commonly fail

Most search accessibility problems fall into one of four buckets. None of them require you to understand the underlying code to recognize.

1. The search box has no real label

Every input on your site is supposed to have a label that assistive technology can read, so a screen reader can announce “search, edit text” when the user lands on it. Many search boxes skip this. They rely on the little magnifying-glass icon, or on placeholder text like “Search products…” that vanishes the moment you start typing.

To a sighted user, the magnifying glass is obvious. To a screen reader user, an unlabeled box is just “edit text” with no hint of what it does. And placeholder text is not a reliable substitute for a label — it disappears, it often fails contrast requirements, and screen readers treat it inconsistently. The fix is a proper, persistent label (it can be visually hidden if you do not want it cluttering the design), so the field always announces itself as the search box.

2. The predictive dropdown cannot be used with a keyboard

This is the big one. As you type, a list of suggestions appears below the box — products, articles, categories. With a mouse, you point and click. But a keyboard user expects to press the Down arrow to move into that list, use the arrows to move through suggestions, press Enter to choose one, and press Escape to dismiss the list.

When autocomplete is built quickly, those keystrokes often do nothing. The suggestions are clickable but not reachable by keyboard. So a keyboard user sees tempting suggestions appear and has no way to select them — they have to ignore the list entirely and submit their raw text, which sometimes lands on a worse result. Worst case, focus gets trapped or thrown to the top of the page when the list opens, and the person loses their place completely.

3. The suggestions are silent to screen readers

Here is the subtle one. A screen reader user types “wint” into the box. Visually, six suggestions appear: winter coats, winter boots, and so on. But the screen reader says nothing. There is no announcement that suggestions are available, no announcement of how many, and no way to know the list is even there.

Accessible autocomplete needs to speak. When suggestions appear, the user should hear something like “six suggestions available.” As they arrow through, each suggestion should be read aloud and identified as the current one. When they reach the bottom or the list updates, that should be conveyed too. This is done with specific roles and “live” announcements behind the scenes — but from your side, the test is simply: does the screen reader tell me the suggestions exist, or do I type into a silent void?

Sometimes suggestions are styled to look interactive — they highlight on hover, they have an arrow — but they are not built as real, operable controls. They cannot be focused, they have no accessible name, and they do not respond to Enter. Related failures include suggestions that rely on color alone to show which one is highlighted (invisible to colorblind users and anyone in grayscale), and “no results” states that show nothing at all to a screen reader, leaving the user unsure whether the search even ran.

The trap of “we have a search feature, so we’re fine”

A common reason these problems persist is that, on the surface, everything looks great. The owner types a query, the dropdown animates in, the results are relevant, and they conclude search is working beautifully. It is working — for a mouse user with good vision.

The failures only appear when you change how you interact with the page. They are invisible from the driver’s seat and obvious the moment you put the mouse down or close your eyes and listen. That is why the rest of this guide is about testing the way affected users actually experience your site, rather than the way you normally do.

It is also worth knowing that a lot of site search is powered by third-party tools — a Shopify search app, a hosted search service, a plugin on WordPress. That can be good news: switching to or configuring an accessibility-minded search provider is often easier than rebuilding your own. But it does not let you off the hook. The barrier is on your site, so it is your responsibility, and “the plugin does that” is not a defense. The move is to test what your visitors actually get, then ask your provider for their accessibility documentation and push them to fix what is broken.

A ten-minute test you can run yourself

You do not need tools or training to get a strong sense of whether your search is accessible. Block out ten minutes and run these checks on your live site:

  1. The keyboard-only pass. Hands off the mouse. Press Tab until you reach the search box. Type a few letters of a common query. When suggestions appear, press the Down arrow. Can you move into the list and through the suggestions? Press Enter on one — does it take you to that result? Press Escape — does the list close? If any of these do nothing, you have found a real barrier.

  2. The focus test. After the suggestion list opens and closes, press Tab again. Make sure focus stays somewhere sensible near the search box, rather than jumping to the top of the page or vanishing. Losing your place is a classic autocomplete bug.

  3. The screen reader test. Turn on VoiceOver (Mac: Command + F5) or NVDA (Windows, free download). Move to the search box and confirm it announces itself as a search field. Type a query and listen: does the screen reader tell you that suggestions are available and how many? As you arrow through, does it read each one? If you hear silence while the screen fills with suggestions, that is the silent-dropdown failure.

  4. The grayscale squint. Set your display to grayscale (or just squint hard) and confirm you can tell which suggestion is currently highlighted without relying on color. The “active” suggestion should be distinguishable by more than a faint color change.

  5. The no-results check. Search for gibberish like “qzxqzx.” Make sure the page clearly states there are no results, in real text that a screen reader will read — not just an empty, silent dropdown.

If any step fails, you now have a precise, plain-English description of the problem. You do not have to diagnose the code — you just have to be able to say “keyboard users can’t select a suggestion” or “the screen reader says nothing when suggestions appear.” That sentence is exactly what your developer, theme support team, or search-app vendor needs to act.

How to get it fixed without writing code

Once you have found a problem, your job is to hand it off clearly. A few tips that make a real difference:

  • Describe the behavior, not a guess at the cause. “When I press Down arrow in the search suggestions, nothing happens” is far more useful than “I think the ARIA is wrong.”
  • Name the assistive technology and steps. “Using NVDA on Chrome, typing in the search box produces no announcement that suggestions exist” gives a developer something they can reproduce.
  • Ask vendors for their conformance documentation. If your search runs on a third-party app, request its accessibility statement or VPAT, and ask specifically how the autocomplete handles keyboard and screen reader users.
  • Prioritize the keyboard and announcement fixes. A labeled search box, an arrow-key-navigable suggestion list, and spoken announcements of suggestions cover the large majority of real-world failures.

The bottom line

Search is not a secondary feature you can afford to get wrong. For many visitors — and especially for people who use a keyboard or a screen reader — it is the fastest and sometimes the only practical way through your site. The four failures here, missing labels, keyboard-inoperable suggestions, silent updates, and fake-interactive suggestions, are common, but they are well understood and entirely fixable. Most come down to labeling the box in text, making the suggestion list work with arrow keys, announcing changes out loud, and showing state with more than color.

And you do not need to be technical to find any of this. Ten minutes with your keyboard, a free screen reader, and a grayscale squint will tell you most of what you need to know — and give you the exact words to get it fixed.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.