Accessible Product Filters: Facets That Keyboard and Screen Reader Shoppers Can Actually Use
2026-10-18
Filtering is where large catalogs become usable, and it is where accessible shoppers most often hit a wall. The sidebar looks like a form but behaves like a pile of clickable text. Checkboxes that are not checkboxes, counts that never speak, selections that vanish on reload: each failure is small in the code and total in effect, because a shopper who cannot filter a 400 product category cannot shop it at all.
The encouraging fact is that filtering accessibility is a solved design problem. The patterns are documented, the components exist, and the failures persist mostly because faceted navigation is built by search vendors and accepted without an accessibility pass. This guide names what to demand.
Use real checkboxes, not styled divs
The foundational rule: every facet option is a native checkbox or radio input with a visible label. Native inputs bring keyboard focus, spacebar toggling, and state announcement for free. A div with a click handler brings none of those, and bolting ARIA onto it afterward recreates the native behavior badly, at ten times the effort.
Labels must be the clickable target and must say what the shopper gets: the facet value and, where space allows, the count. A checkbox labeled only by a color swatch or an icon is a guessing game for screen reader users, who hear a list of identical unnamed controls.
Announce the result count, do not just change it
When a filter applies, the sighted shopper sees the grid shrink. The screen reader shopper needs the equivalent: an aria-live polite region that announces the new count, such as 42 products, after the update settles. Without it, applying a filter feels like nothing happened, and shoppers either repeat the action or abandon the category.
Avoid the full reload pattern where the page refreshes and focus returns to the top. The shopper then has to navigate back through the entire sidebar to apply a second filter, an effort tax that compounds per facet. In place updates with focus kept on the control just used are the standard the patterns describe.
Applied filters must be reviewable and removable
A row of applied filter chips, each a real button named by the filter it removes, lets every shopper audit what is narrowing their results. Screen reader users in particular can lose track of selections made across a long sidebar; the chips are their summary. A clear all control completes the pattern.
Chips also prevent the mystery empty result. When filters combine to zero products, the page should say so in words, name the filters in force, and offer the removal path inline. A silent empty grid reads as a broken store to every shopper and as a dead end to a screen reader user who cannot see that anything changed.
Counts, disabled options, and honesty
Facet counts that include unavailable combinations confuse everyone and mislead screen reader users who cannot skim. When selecting one facet makes another value impossible, either update its count to zero and disable it with the reason reachable, or keep counts dynamic throughout. Static counts computed for the unfiltered catalog are the common vendor default and the common failure.
Test the whole flow with a keyboard alone and then with a screen reader: apply two filters from different groups, remove one from the chips, clear all, and confirm a zero result state announces itself. Fifteen minutes of that testing finds what automated scans of the sidebar never will.
Related reading
These earlier guides go deeper on connected questions: The Forgotten Page: Making Order Confirmation and Tracking Accessible, Accessible Guest Checkout: Forms That Do Not Punish Shoppers for Skipping the Account, and Accessible Shipping Options in the Cart: Radio Groups Done Right.
Frequently asked questions
What is the most common accessibility failure in product filters?
Facets built as clickable divs instead of native checkboxes. They exclude keyboard and screen reader shoppers entirely while looking identical to a real form.
How should screen reader users learn a filter worked?
An aria-live polite announcement of the new result count after the grid updates, with focus left on the control the shopper just used.
Why do applied filter chips matter for accessibility?
They summarize selections made across a long sidebar as named, removable buttons, so shoppers who cannot skim visually can still audit and change their filters.
Should facet counts update as filters are applied?
Yes. Static counts from the unfiltered catalog mislead shoppers about combinations that no longer exist. Dynamic counts, or clearly disabled zero options, keep the sidebar honest.