Watching Filter and Sort Controls on Mobile Collection Pages

On mobile, filters hide behind buttons that do not announce state, panels that open off screen for screen readers, and sort controls that reset focus. What to watch.

On a phone, the collection page is mostly controls: a filter button, a sort dropdown, a panel that slides in from somewhere. For assistive technology users those controls decide whether the products are reachable at all, and they are usually built as custom widgets that behave almost, but not quite, like the native elements they replace.

Watch the state announcements first. A filter button that does not say whether it is expanded or collapsed, under WCAG 4.1.2, leaves a screen reader user pressing it blind. A sort that reloads the page and drops focus to the top forces the whole browse to restart after every change.

Panels that open somewhere else

Slide in filter panels are frequently placed at the end of the document in the code, whatever they look like on screen. Focus may stay on the filter button while the panel opens visually, or jump into a panel whose first element is a close button with no label. Either way the sequence makes no sense to someone navigating by sound.

The applied filters themselves often vanish. Chips showing active filters appear above the grid visually, but if they are not in the reading order near the results, and their remove buttons are labelled only with an X icon, a screen reader user cannot review or undo their own filtering.

Sort, reload, lost place

Native select elements are unfashionable and reliable: labelled, keyboard operable, understood by every assistive tool. Custom sort widgets have to rebuild all of that, and many do not. Check whether the current sort is announced, whether choosing an option moves focus predictably, and whether the result count updates as a status message.

Result counts matter more than they look. Filtering from 240 products to 6 is the key fact after applying a filter. If that count is only a visual change in the grid, a screen reader user has no confirmation the filter even worked.

A watching routine for collection pages

Once a month, on a real phone with a screen reader, run one filtering task end to end: open filters, apply two, remove one, change the sort. Write down every point where state, count, or focus was not announced. That short list is your defect backlog.

Compare against the desktop version of the same page. Stores often fix the desktop template and leave the mobile panel, which is a separate component, untouched for years.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Watching Countdown Timers and Live Sale Clocks, Watching Age Verification Prompts for Barriers That Lock People Out, and Watching Gift Card Purchase Flows for Quiet Breakage.

Frequently asked questions

What should a filter button announce?

Its name, what it controls, and whether it is expanded or collapsed. That state comes from aria-expanded on the button, and it must update when the panel opens and closes.

Are custom sort widgets worse than a native select?

Usually, unless they are built and tested carefully. A native select is labelled, keyboard operable, and understood by assistive technology by default. Custom widgets must rebuild each of those behaviours.

How should result counts be handled after filtering?

Announce the new count as a status message so screen reader users get the same confirmation sighted users get from the grid changing. Keep active filters reviewable and removable with labelled controls.

How often should mobile filters be checked?

Monthly, and after any collection template or filtering app change. Mobile filter panels are separate components and regress independently of the desktop page.