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.

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.

Accessibility Bug Report Template

When to use this template

Copy-and-paste template

Quality checks before you paste the ticket

Related resources