Filter and Sort Accessibility Tickets

Filtering and sorting findings are easiest to fix when the ticket names the exact control, selected state, result update, and keyboard or screen reader path.

Use this guide for ecommerce category filters, job boards, search result facets, table sorting, product grids, map lists, and any flow where users narrow a result set before choosing an item.

Open this filter and sort finding in the generator

What to capture from the finding

Result context: product listing, search page, table, job list, map result pane, or dashboard view.
Control type: checkbox facet, radio group, range slider, sort menu, tag chip, accordion, or filter drawer.
Keyboard path: how users reach the filter, change it, apply it, clear it, and return to results.
Programmatic state: checked, selected, expanded, current sort direction, disabled options, and active filter chips.
Result update: whether the changed count, loading state, empty result, or refreshed list is announced.
Blocked decision: what users cannot find, compare, buy, book, or choose because the controls fail.

Ticket structure

Title:
[Severity] Results page: filter or sort control prevents users from narrowing results

User impact:
Explain which search, shopping, booking, or comparison task becomes blocked or unreliable.

Evidence:
- Page or result set:
- Control:
- Assistive technology or keyboard path:
- Selected state or sort state:
- Actual result:
- Expected result:
- Result-count or loading announcement:

Likely WCAG references to verify:
- 2.1.1 Keyboard, when filters or sort controls cannot be operated by keyboard.
- 2.4.3 Focus Order, when focus moves away from the filter flow unexpectedly.
- 2.4.6 Headings and Labels, when filter names or result headings are unclear.
- 3.3.2 Labels or Instructions, when range fields or grouped filters lack instructions.
- 4.1.2 Name, Role, Value, when custom controls do not expose state.
- 4.1.3 Status Messages, when result-count changes are visual-only.

Acceptance criteria:
- Every filter and sort control is reachable and operable with keyboard only.
- Group names, option names, selected states, and sort direction are programmatically exposed.
- Applying, removing, and clearing filters keeps focus in a useful location.
- Result-count, loading, and empty-result changes are announced without forcing focus away.
- Retest covers the same result set, viewport, and selected filter state named in the evidence.

Paste your filter or sort finding into the generator when you want this structure drafted from raw notes.

Example conversion: skipped facet options

Raw note:
Product listing. Size filter opens, but Tab skips the checkbox options and lands on Apply. Mouse users can select sizes.

Developer ticket:
[High] Product listing: Size filter options are skipped by keyboard navigation

User impact:
Keyboard-only shoppers cannot narrow the product list by size, so they must browse irrelevant results or abandon the task.

Evidence:
- Page: product listing
- Control: Size filter drawer
- Key path: open Size filter, then press Tab
- Actual result: focus skips the size checkboxes and moves to Apply
- Expected result: each size checkbox is reachable, named, and operable before Apply

Likely WCAG references to verify:
- 2.1.1 Keyboard
- 2.4.3 Focus Order
- 4.1.2 Name, Role, Value

Acceptance criteria:
- Size checkboxes are included in logical keyboard order.
- Each checkbox exposes its visible label and checked state.
- Space toggles the focused checkbox.
- Apply remains reachable after the options and returns focus to a useful result-list location.

Example conversion: result count is silent

Raw note:
Selecting Brand: Acme changes "48 results" to "12 results" visually. NVDA stays silent unless the tester explores the page again.

Developer ticket:
[Medium] Search results: filter updates are not announced to screen reader users

User impact:
Screen reader users do not know whether a filter was applied, how many results remain, or whether they need to wait for loading to finish.

Evidence:
- Page: search results
- Control: Brand filter checkbox
- Action: select Acme
- Actual result: result count changes visually, but no status is announced
- Expected result: users hear a concise update such as "12 results, filtered by Acme"

Likely WCAG references to verify:
- 4.1.3 Status Messages
- 1.3.1 Info and Relationships

Acceptance criteria:
- Applying or removing a filter announces the updated result count.
- Loading and empty-result states are announced once, without repeated chatter.
- The visible count and programmatic status message stay equivalent.
- Focus does not jump to the result heading unless that movement is an intentional, documented part of the flow.

Common filter and sort ticket types

Unreachable filter options: checkbox, radio, range, date, and color controls skipped by Tab.
Generic control names: sort menus exposed as "Dropdown", icon-only filter buttons exposed as "Button", or repeated "Remove" chips with no filter context.
Missing group context: screen readers announce "Small, checkbox" without "Size" or "Filter by size".
Silent result updates: changed counts, empty states, loading spinners, or refreshed lists are visual-only.
Bad focus recovery: applying or clearing a filter moves focus to the top of the page, into hidden controls, or behind a drawer.
Sort state ambiguity: current sort value or ascending/descending direction is not exposed.

Paste-ready input for the generator

Filter or sort accessibility finding:
Page or result set:
Control type:
Visible label:
Accessible name:
Selected or expanded state:
Keyboard path:
Actual result:
Expected result:
Result-count or loading announcement:
Blocked user task:
Retest notes:

Open the accessibility ticket generator and paste this structure with the audit note.