Accessibility Bug Report Template
A useful accessibility bug report is not a scanner dump. It explains the affected task, the assistive technology context, what happened, and what must be true after the fix.
Draft from a real bug shape
Open a checkout button-name example in the generator with the affected component, NVDA behavior, evidence, retest steps, and acceptance criteria already filled in.
When to use this template
Use it for keyboard, screen reader, WCAG, and automated-tool findings that need to become developer tickets in Jira, GitLab, Linear, or a client remediation backlog.
- Good fit: reproducible bugs in checkout, forms, navigation, modals, product filters, account flows, or reusable components.
- Bad fit: vague audit notes like “site is not accessible” without an affected page, user task, or evidence.
Copy-and-paste template
# [Severity] Area: short issue title ## Summary for client / product owner Plain-language impact. Name the affected user group and business/customer task without exaggerating legal risk. ## Developer ticket **Area / flow:** **Assistive technology context:** Keyboard only / VoiceOver / NVDA / JAWS / TalkBack / not tested **Finding source:** Manual test / axe / Lighthouse / WAVE / audit note / user feedback **Suggested severity:** Critical / High / Medium / Low / Needs triage **User impact:** Blocks task completion / causes confusion / slows users down / minor annoyance ### Expected behavior What should happen for keyboard or screen reader users? ### Actual behavior What happens instead? Include what the user hears, sees, or cannot reach. ### Reproduction steps 1. Open ... 2. Navigate with keyboard or screen reader ... 3. Activate ... 4. Observe ... ### Evidence / raw finding - Selector / component: - Tool rule or tester note: - Screenshot/video note, if available: ### Likely WCAG references to verify - ... ### Acceptance criteria - The issue can no longer be reproduced. - Keyboard and/or screen reader users can complete the affected task. - Relevant labels, roles, states, errors, and status messages are exposed programmatically. ### Fix direction Concrete implementation hints, not vague “make accessible”. ### Test after fix How to confirm the issue is resolved, including the assistive technology or keyboard path to retest.
Quality checks before you paste the ticket
- The title names the flow and problem, not only the WCAG number.
- The reproduction steps can be followed by someone who did not run the original audit.
- The ticket includes evidence, but does not depend on the scanner output alone.
- Acceptance criteria describe observable behavior after the fix.
Related resources
- Use the accessibility ticket generator
- Accessibility bug report examples with generator links
- Turn audit report excerpts into accessibility tickets
- WCAG issue ticket template
- Screen reader bug examples
- Keyboard accessibility ticket examples
- Turn axe findings into Jira tickets
- Prioritize accessibility backlog tickets
- TYPO3 accessibility finding to developer ticket
- Shopware checkout BFSG ticket example