Screen Reader Bug Examples for Accessibility Tickets
Good screen reader tickets describe what the user hears, what task is affected, and what a developer can inspect. “Does not work with screen reader” is not enough.
Useful evidence to capture
- Assistive technology and browser, for example “NVDA 2024.4 with Firefox”.
- The exact phrase announced, or that nothing useful was announced.
- Current focus location before and after the interaction.
- Relevant selector, component name, or visible label.
- The user task affected: checkout, login, filter products, submit a form, close a modal.
Examples
Icon button has no accessible name
Ticket title: [High] Cart: remove item button is announced only as “button” User impact: Screen reader users cannot tell whether the control removes an item, changes quantity, or opens details. Evidence: NVDA announces “button” for the trash icon in each cart row. The button has no visible text, aria-label, or labelled relationship. Likely WCAG references to verify: - 4.1.2 Name, Role, Value - 2.4.6 Headings and Labels
Status change is not announced
Ticket title: [Medium] Product filters: result count update is not announced User impact: After selecting a filter, screen reader users do not know whether the product list changed or how many results remain. Evidence: VoiceOver focus stays on the checkbox. The visual count changes from “42 products” to “8 products”, but no live region or focus change communicates the update. Likely WCAG references to verify: - 4.1.3 Status Messages
Dialog opens without context
Ticket title: [High] Newsletter modal opens but focus remains behind it User impact: Keyboard and screen reader users may navigate the background page while a modal visually covers the content. Evidence: After activating “Subscribe”, focus remains on the page behind the modal. The dialog lacks an accessible name and focus is not contained. Likely WCAG references to verify: - 2.4.3 Focus Order - 2.1.2 No Keyboard Trap - 4.1.2 Name, Role, Value