Screen Reader Status Message Ticket Example
Dynamic updates often look obvious on screen but stay silent for screen reader users. A useful ticket names the updated state, the trigger, and the announcement that must be retested.
Open this status-message finding in the generator
Developer-ready ticket
# [Medium] Product filters: result count update is not announced ## Summary for client / product owner Screen reader users can change product filters without hearing whether the results changed. This makes it harder to confirm that a selected filter worked before continuing through the product list. ## Developer ticket **Area / flow:** Product listing filters **Assistive technology context:** VoiceOver with Safari **Finding source:** Manual screen reader test **Suggested severity:** Medium **User impact:** Slows users down ### Expected behavior After a user changes a filter, the updated result count is announced or made available as a status message without moving focus away from the active control. ### Actual behavior The visual result count changes from "42 products" to "8 products", but VoiceOver does not announce the update. Focus remains on the selected checkbox, so the user has to manually search the page to confirm what changed. ### Reproduction steps 1. Open the product listing page. 2. Start VoiceOver with Safari. 3. Move to the filters and select "In stock". 4. Keep focus on the checkbox. 5. Observe that the product count changes visually but no status update is announced. ### Evidence / raw finding - Component: product filters - Trigger: selecting the "In stock" filter - Visual update: result count changes from "42 products" to "8 products" - Observed with VoiceOver/Safari: no announcement after the filter state changes ### Likely WCAG references to verify - 4.1.3 Status Messages - 4.1.2 Name, Role, Value ### Acceptance criteria - Changing a filter communicates the updated result count to screen reader users without requiring focus to move to the count. - The announcement is concise, for example "8 products". - The selected filter state remains programmatically available. - Retest passes with VoiceOver/Safari and one keyboard-only pass. ### Fix direction Use a status-message pattern for the count update, such as an appropriately scoped live region. Avoid moving focus after every filter change unless the wider interaction pattern intentionally submits the filters and navigates to a new result view.
When to use this pattern
- Filter result counts: product, search, event, or table results change after a checkbox, chip, or select control is used.
- Cart updates: quantity, subtotal, shipping, or discount messages change without a page reload.
- Form feedback: saved, submitted, loading, or validation states appear outside the current focus location.
- Async loading: autocomplete, pagination, infinite scroll, or tab panel content changes after a user action.
Evidence to capture
- The control or action that triggers the update.
- The exact visible text before and after the update.
- The assistive technology and browser used for the retest.
- Whether focus moves, stays put, or lands somewhere unexpected.
- Whether the update is essential to completing the task or only confirms progress.