A shopper looking for a waterproof jacket in a medium opens your filters, checks “Waterproof”, checks “M”, and watches the grid shuffle. That works if you can see the grid. If you are listening to a screen reader, you checked two boxes and heard nothing else. Did the page change? How many jackets are left? Are you still in the filter list or somewhere else?
That is the heart of product filter accessibility: the controls themselves are usually ordinary, but the feedback after each choice is often missing. This post covers filter checkboxes, sliders, sort menus, live updates and result counts, with checks you can run on your own category pages. The search box itself is a separate topic.
What faceted navigation asks of a shopper
Faceted filters let people narrow a catalog by several properties at once: size, color, price, brand, rating. Each choice changes the results and often the other filters too, because some sizes stop being available once a color is chosen. For a sighted mouse user, the changes are visible. For everyone else, every one of those changes needs to be either announced or easy to find.
An accessible faceted search does three things well:
- Each filter control has a clear name and state that assistive technology can read.
- When results change, people are told, without losing their place.
- People can see and undo what they have selected.
Filter groups and checkboxes
Most filters are sets of checkboxes under a heading: Size, Color, Brand. The simplest accessible version is exactly that, real checkboxes with real labels, grouped under a fieldset with a legend or a heading.
Common problems:
- Fake checkboxes. Styled spans or links that look like checkboxes but have no checked state, so a screen reader cannot say whether “Medium” is on or off.
- Links instead of controls. Some filter plugins turn each option into a link that reloads the page. That can work, but each link then needs to say whether it adds or removes the filter, and the page needs to announce the new state after reloading.
- Collapsed groups. Groups that expand and collapse need a button with aria-expanded so people know whether the group is open. A heading that only responds to a click leaves keyboard users stuck.
- Color filters. Swatches need the color name in text. A circle of teal tells a screen reader nothing.
- Counts beside options. “Medium (12)” is helpful. Make sure the count is read with the label rather than as a separate stray number.
Small checkboxes packed into a sidebar also cause trouble on touch screens. WCAG 2.5.8 sets a minimum for target size, explained in our post on touch target size. Making the whole label clickable, not just the box, is usually the easiest fix.
Price sliders and range inputs
Price sliders are the most fragile filter on most stores. A typical slider has two handles, a minimum and a maximum, and many of them only respond to dragging.
A usable one:
- Lets each handle be focused with Tab and moved with the arrow keys.
- Gives each handle a name, such as “Minimum price” and “Maximum price”.
- Announces the current value as it changes, in a readable form like “40 dollars” rather than a raw number with no unit.
Since version 2.2, WCAG includes a criterion (2.5.7) saying that a drag should never be the only way to set a value; a tap or click alternative has to exist. The cleanest way to meet that and help keyboard users at the same time is to show two labeled number fields beside or instead of the slider. Many shoppers prefer typing a budget anyway.
Live updates versus an Apply button
There are two common patterns, and both can work.
| Question | Instant update | Apply button |
|---|---|---|
| How it feels | Fast; results change on each click | Shopper picks several filters, then applies |
| What it needs | A status message after each change; focus must stay on the control | A clearly named button; focus moves to results or a heading after applying |
| What usually goes wrong | Silent changes, focus jumping to the top, the filter list re-rendered so focus is lost | Button hidden at the bottom of a long list, no feedback after applying |
With instant updates, the worst failure is when the whole filter panel is rebuilt after each choice. Focus falls back to the start of the page, and a keyboard user has to tab all the way back to where they were. If your filters do this, fix it first, since it undoes every other piece of product filter accessibility work.
Announcing the result count
After each change, a short message such as “18 products found” should be announced by screen readers without moving focus. That is what WCAG 4.1.3 Status Messages describes. Technically this usually means a container marked as a live region or status, updated with the new count.
Keep the message short. “Showing 1 to 18 of 18 results for Waterproof, Medium, sorted by popularity” read after every click wears people out. The count is what matters; the active filters can be shown separately.
And handle zero. “No products match these filters” with a button to clear the last choice is far better than an empty grid.
Showing and clearing active filters
A row of active filter “chips” above the results helps everyone see what is applied. Each chip should be a button with a clear name like “Remove filter: Medium”, not just an X icon. Include a “Clear all filters” button. When a chip is removed, move focus to a sensible place, such as the next chip or the results heading, rather than letting it vanish with the removed button.
Sort menus
A sort control is usually a dropdown: Popularity, Newest, Price low to high. A native select element with a visible label (“Sort by”) is the most dependable choice. Problems start when a theme replaces it with a custom dropdown that opens on hover, or one that changes the page as soon as an option is highlighted with the arrow keys. The second kind catches out a lot of stores: a keyboard user arrows down to look at the choices and the page reloads under them. Either apply the sort on selection with Enter, or add a button.
Filters on mobile
On phones, filters usually move into a drawer behind a “Filter” button. Check that the button says whether the drawer is open, that focus moves into the drawer when it opens, that it has a heading and a named close button, and that closing it returns focus to the “Filter” button. If the drawer has its own Apply button, keep it visible without scrolling through every option.
Testing product filter accessibility on your category pages
- With the keyboard only, open a category page, apply two filters, change the sort, remove one filter and clear all.
- Repeat with a screen reader and note every time you are not told what happened.
- Try the price filter without dragging.
- Open the filters on a phone and repeat the first step.
Filters are hard to judge with a scanner, since the problems are about behavior after a click. A manual pass catches them; our screen reader testing service describes how we approach that. If you run WooCommerce, our list of common WooCommerce accessibility issues covers the store-specific pieces around filters, while our end-to-end store accessibility guide follows a shopper from the menu to the order email. For everything else, start at our website accessibility hub.
Frequently asked questions
Should product filters update results instantly or use an Apply button?
Both can be accessible. Instant updates are convenient but need a status message so screen reader users know the results changed, and they must not move focus. An Apply button is simpler to get right and suits stores with many filters, because the shopper chooses when the page changes. Pick one pattern and use it everywhere.
Are price range sliders accessible?
A slider can be accessible if each handle can be moved with the arrow keys, has a name such as minimum price, and announces its current value. Many sliders only work by dragging. The safest approach is to pair the slider with two labeled number fields, so people can type a minimum and maximum instead.
How should a store announce the number of filtered results?
Use a short status message such as 24 products found that is announced without moving keyboard focus. Place the same count visibly near the top of the results. If no products match, say so in words and offer a way to clear the last filter or all filters.
Do filters on mobile need separate testing?
Yes. On phones, filters often move into a drawer or full-screen panel with its own open and close buttons. That panel needs a heading, a named close button, focus that moves into it on opening and back out on closing, and controls large enough to tap without hitting their neighbors.
Filter plugins vary a lot, and fixing them often means a mix of settings, template changes and small scripts. When WooCommerce category pages need that kind of repair, the approach we take, including how each change is recorded, is set out under accessible WooCommerce store fixes.
Next in this series: Chat Widget Accessibility: Live Chat That Works for All
