Reviewed October 16, 2026

Making Shopify collection filters and sorting accessible to everyone

Filters and sorting decide what shoppers find, and they are often mouse only, unlabeled, or silent about results. How to make collection controls operable and understandable.

Controls that decide what shoppers can buy

Collection filters are not decoration. They decide which products a shopper ever sees, so a filter panel that only works with a mouse quietly decides that keyboard and screen reader shoppers get the unfiltered store, all of it, in whatever order it arrived. Sorting carries the same weight for price and relevance decisions.

The common failures are consistent: filter groups that expand only on hover, checkboxes drawn as clickable colored boxes with no real input behind them, a sort menu that is a styled list pretending to be a select, and results that change with no announcement that anything happened.

Use real controls with real labels

Build filters on native checkboxes and radio buttons, styled as needed, each with a visible label tied to its input. Native controls bring keyboard behavior, focus, and screen reader announcement for free, which is engineering your theme does not have to reinvent and cannot easily match with clickable divs.

Sort should be a genuine select element or a properly built menu button with the current choice exposed. Every control group needs a heading or label a screen reader can announce, so a shopper arriving at the filters understands the territory before touching anything. Count of results belongs near the controls, in text, not only as a visual grid change.

Announce what changed

When filters apply, the product grid updates, and that change must be communicated: a polite live announcement of how many products now match is the pattern that works, without yanking focus away from the control the shopper just used. Focus theft after every checkbox is the fastest way to make filtering unusable even when every control is technically operable.

On mobile, the filter drawer needs the same discipline as any dialog: focus moves in, stays manageable, and returns to the filter button on close, and the applied filters must be visible as removable tags with labels that say what they remove. A tag that only says x is a riddle, not a control.

Test the flow the way shoppers run it

Test with keyboard alone: reach the filters, toggle several, remove one, change the sort, and reach the first product, counting how many steps each action costs. Then run it with a screen reader and listen for whether state changes, result counts, and applied filters are announced in words you would understand with your eyes closed.

Finally, test an empty result. Filters that combine to zero products should say so clearly, offer a one action reset, and never leave a shopper staring at a blank region wondering if the store broke. The empty state is part of the control system, and it is where inaccessible implementations quietly give up.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: How to screen reader test a Shopify product page in 30 minutes, Making returns information accessible on a Shopify store, and How to test your Shopify store with only a keyboard in 15 minutes.

Frequently asked questions

Are clickable div filters really an accessibility problem?

Yes, because divs do not receive keyboard focus, do not announce state to screen readers, and do not behave predictably with assistive technology. They can be rebuilt with extensive scripting to imitate real controls, but native checkboxes and radios already are real controls. Imitation costs more and delivers less.

How should a screen reader announce filter results?

With a brief, polite status message such as the number of products shown, triggered when results update, without moving the shopper’s focus. Moving focus on every change destroys the filtering flow. Announcing nothing leaves the shopper guessing whether anything happened. The middle path is the standard pattern for a reason.

Does the sort dropdown need to be a native select?

A native select is the simplest fully accessible answer and works everywhere. A custom control can be valid if it implements the full keyboard and announcement pattern of a real menu or listbox, which most theme implementations do not. When in doubt, native wins on reliability and maintenance.

What makes mobile filter drawers fail accessibility checks?

Focus that never enters the drawer or escapes behind it, close controls without labels, applied filters that cannot be reviewed or removed by keyboard, and drawers that break at high zoom. Test the drawer at 200 percent zoom with a keyboard or switch device, not just with a thumb on a new phone.