Your Product Filters Might Be Locking Out Shoppers: A Plain-English Guide to Accessible Faceted Search

If your online store has more than a handful of products, you almost certainly have filters: checkboxes for size and color, a price slider, a “Sort by: Price, low to high” dropdown, maybe a sidebar of categories that narrows the results as a shopper clicks. This is called faceted search, and it is one of the most useful features on any catalog. It is also one of the most common places where accessibility quietly breaks.

The reason is simple. Filters are interactive, they change the page after the shopper acts, and they are usually added by a theme or a third-party app rather than hand-built. Each of those three facts creates a way for the experience to fall apart for someone using a keyboard or a screen reader. And because filters work perfectly well when you test them with a mouse, the problems are easy to miss until a frustrated customer — or a demand letter — points them out.

You do not need to be a developer to understand what is going wrong or to check your own store. This guide explains, in plain English, the four ways product filters commonly fail, how to spot each one in a few minutes, and what to ask for when you want them fixed.

Why filters matter more than most store features

Think about what a filter actually does for a shopper. Someone who can only wear a size 12 shoe, who has a $50 budget, or who only buys vegan products is relying on your filters to avoid scrolling through hundreds of items they cannot use. For a person with low vision, a motor disability, or a cognitive disability, that scrolling is not just tedious — it can be exhausting or impossible. Filters are the tool that makes a large catalog usable at all.

So when filters do not work with a keyboard or a screen reader, you are not just removing a convenience. You are taking away the one feature that lets some shoppers find what they came for. They do not see a slightly clunky page; they hit a wall and leave. That is both a lost sale and, under laws like the Americans with Disabilities Act (ADA) in the US and the European Accessibility Act (EAA) across the EU, a genuine legal exposure. E-commerce filtering shows up regularly in accessibility complaints precisely because it sits between the shopper and the products.

The good news: the failures are predictable. Once you know the four patterns, you can find them on your own store quickly.

Failure 1: Filters you cannot reach or operate with a keyboard

Many shoppers never touch a mouse. People with motor disabilities, people using switch devices, and most screen reader users navigate entirely with the Tab key (to move between controls), Enter or Space (to activate them), and the arrow keys (to move within a group). If your filters were built as plain clickable <div> elements with a mouse handler bolted on — which is extremely common in custom themes and page-builder apps — they simply do not respond to the keyboard at all.

The classic offenders are custom dropdowns (“Sort by” menus that are not real <select> elements), price sliders that only respond to dragging, and color or size swatches that look like buttons but are not. A sighted mouse user clicks them and they work. A keyboard user presses Tab and the focus indicator skips straight over them, or lands on them but Enter does nothing.

How to check it yourself: Go to a category page in your store. Put your mouse away. Press Tab repeatedly and watch where the highlight (the focus outline) goes. Can you reach every filter checkbox, the sort dropdown, and the price control? When you get to one, can you turn it on with Space or Enter? Can you change the sort order using only the keyboard? If the highlight skips your filters, or if pressing Enter does nothing, keyboard users are locked out.

What to ask for: “Make every filter and the sort control operable with the keyboard.” A real <select> element, real <input type="checkbox"> checkboxes, and standard form controls get this for free. If a designer insists on a custom-styled control, it needs proper keyboard support added — that is a specific, reasonable request to make of your developer or app vendor.

Failure 2: The shopper has no idea the page changed

Modern filters usually update the product list instantly, without reloading the whole page. A sighted shopper sees the grid refresh and the result count tick down from “248 items” to “31 items.” It feels fast and smooth.

A screen reader user, though, may have no idea anything happened. Their software reads what is under focus; it does not automatically announce that content elsewhere on the page silently changed. So they tick “Size: Medium,” nothing is announced, and they are left wondering whether the filter worked, whether the page is broken, or whether there are simply no results. Often they re-click, get confused, and abandon the visit.

The fix is a small, invisible piece of code called a live region — a part of the page that politely announces updates, such as “31 products found,” whenever the results change. It is invisible to sighted users and costs nothing in design, but it is the difference between a usable filter and a silent one.

How to check it yourself: This one needs a screen reader, but you can do a basic version free in a few minutes. On a Mac, turn on VoiceOver (Command + F5); on Windows, use the free NVDA screen reader. Apply a filter and listen. Does the screen reader announce the new result count or that the list updated? If you hear nothing after the products change, you have a silent filter.

What to ask for: “When filtering changes the results, announce the new result count to assistive technology using a polite live region.” That sentence is enough for a competent developer to know exactly what to build.

Failure 3: Focus gets lost or thrown around

Closely related to the silent-update problem is focus management. “Focus” is the invisible cursor that marks where keyboard actions land. When a filter updates the page, focus needs to stay somewhere sensible — ideally right where the shopper was, so they can keep ticking boxes.

Two bad things commonly happen instead. Either focus is thrown back to the very top of the page after every filter click, forcing the shopper to Tab all the way down again for each selection (imagine doing that for five filters), or focus is dropped entirely so that the next Tab press starts from an unpredictable place. On mobile, a related problem is a filter panel that slides open but does not move focus into itself, leaving the keyboard or screen reader user still “stuck” on the page behind it.

How to check it yourself: Using only the keyboard, apply one filter, then immediately press Tab again. Did focus stay near the filter you just used, letting you continue, or did it jump to the top or vanish? On mobile, open the “Filter” panel and check whether you can immediately interact with the controls inside it, or whether your taps and key presses still land on the page behind.

What to ask for: “Keep keyboard focus in a logical place after filtering — don’t reset it to the top of the page — and when the mobile filter panel opens, move focus into it and trap it there until it’s closed.”

Failure 4: Filters that rely on color or shape alone

The fourth failure is about what the filters look like rather than how they behave. Color and size swatches are the worst culprits. A row of colored circles is a lovely way to show “Red, Blue, Green” — but if the only way to tell which color a swatch represents is the color itself, then a colorblind shopper, a screen reader user, or anyone whose screen is washed out in sunlight cannot use it. The same goes for a “selected” filter shown only by a subtle color change with no other indicator.

WCAG 1.4.1 (Use of Color) is explicit about this: color cannot be the only way information is conveyed. Each swatch needs a real text label (a color or size name) that is available to assistive technology, and a “selected” state needs to be shown by more than color alone — a checkmark, a border, or a text indicator.

How to check it yourself: Look at your filter swatches. Hover or tab to one — is there a visible or announced name like “Navy” or “Size 10”? Now squint, or imagine the page in grayscale: can you still tell which filters are selected? If selection is shown only by a faint color shift, it fails. You can also run a free automated scanner like WAVE (wave.webaim.org) on the page, which will flag many color-contrast and labeling problems automatically.

What to ask for: “Give every swatch a text label that screen readers can read, and show the selected state with something other than color — a checkmark or border.”

A 10-minute filter audit you can run today

You do not need tools or training to get a strong sense of whether your filters are accessible. Block out ten minutes and do this on your busiest category page:

  1. Keyboard-only pass. Hands off the mouse. Tab through the page and confirm you can reach and operate every filter, the sort menu, and the price control with Tab, Space, Enter, and arrow keys.
  2. The focus test. Apply a filter, then press Tab. Make sure focus stays somewhere sensible instead of jumping to the top or disappearing.
  3. The screen reader test. Turn on VoiceOver (Mac) or NVDA (Windows), apply a filter, and listen for an announcement of the new result count.
  4. The grayscale test. Check that selected filters and color swatches are distinguishable without relying on color, and that each swatch has a readable name.
  5. The automated scan. Run the free WAVE extension on the page to catch missing labels and contrast issues you might have eyed past.

If any step fails, you now have a precise, plain-English description of the problem to hand to whoever maintains your site or to the support team of your theme or filter app. You do not have to diagnose the code — you just have to be able to say “keyboard users can’t operate the sort menu” or “the screen reader says nothing when results change.”

The bottom line

Product filters are not a nice-to-have feature you can afford to get wrong. For a large catalog they are the front door, and for shoppers with disabilities they are often the only practical way in. The four failures — keyboard inoperability, silent updates, lost focus, and color-only information — are common, but they are also well understood and entirely fixable. Most of them come down to using real form controls, announcing changes, managing focus sensibly, and labeling things in text.

You do not need to write a line of code to find these problems. 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.