Accessibility Bug Report Examples

These examples show the difference between a vague accessibility note and a ticket a developer can reproduce, fix, and retest.

Each example keeps the legal language calm, names the affected user task, preserves useful evidence, and ends with acceptance criteria. Adapt the wording to your own issue tracker, audit report, or remediation backlog.

Quick format

# [Severity] Flow: short user-facing problem

User impact:
Who is affected, and what task becomes harder or impossible?

Evidence:
- Page or component:
- Tool, assistive technology, or tester note:
- Selector, announcement, keyboard path, or raw finding:

Likely WCAG references to verify:
- ...

Acceptance criteria:
- The issue can no longer be reproduced.
- The affected task can be completed with the relevant keyboard or assistive technology path.
- Labels, roles, states, errors, and status messages are programmatically available where relevant.

Example: axe finding with missing button name

Weak note:
button-name issue on checkout.

Better ticket:
[High] Checkout: payment method buttons have no accessible names

User impact:
Screen reader users hear repeated unnamed buttons and cannot determine which payment method they are selecting.

Evidence:
- Source: axe DevTools rule button-name
- Component: checkout payment method list
- Selector: .payment-method-card button.icon-only
- NVDA/Firefox check: each control is announced as "button"

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 2.4.6 Headings and Labels

Acceptance criteria:
- Each payment method control exposes a unique accessible name.
- The selected payment method state is programmatically available.
- The payment step can be completed with keyboard and NVDA.

Example: screen reader status message

Weak note:
Filter changes are not accessible.

Better ticket:
[Medium] Product listing: updated result count is not announced after applying filters

User impact:
Screen reader users do not know whether the selected filter changed the product list or how many results remain.

Evidence:
- Flow: category product filters
- Assistive technology: VoiceOver with Safari
- Observed behavior: visual count changes from "42 products" to "8 products"; focus stays on the checkbox and no status update is announced

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

Acceptance criteria:
- Filter changes expose the updated result count through status semantics or an equivalent announcement.
- Focus is not moved unexpectedly for passive result updates.
- The visible result count and programmatic announcement match.

Example: keyboard and modal focus

Weak note:
Modal focus broken.

Better ticket:
[High] Newsletter modal opens while keyboard focus remains behind the dialog

User impact:
Keyboard and screen reader users can navigate background content while the modal visually blocks the page, making the active task confusing and unreliable.

Evidence:
- Flow: newsletter sign-up modal
- Source: manual keyboard test
- Steps: activate "Subscribe"; press Tab repeatedly; focus continues through page links behind the modal

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

Acceptance criteria:
- Focus moves into the dialog when it opens.
- Focus remains within the dialog until it is closed.
- Closing the dialog returns focus to the Subscribe control.
- The dialog exposes a useful accessible name.

Example: Shopware BFSG backlog item

Backlog ticket:
[Critical] Shopware checkout: payment validation error is visible but not announced

User impact:
Blind shoppers may not know why checkout submission failed and may be unable to complete a purchase.

Evidence:
- Flow: checkout payment step
- Component: payment plugin / checkout template
- Observed behavior: error appears visually after submit; focus remains on the submit button; no field relationship or live/status announcement communicates the failure

Likely WCAG references to verify:
- 3.3.1 Error Identification
- 3.3.3 Error Suggestion
- 4.1.3 Status Messages

Acceptance criteria:
- The invalid payment state is announced after submission fails.
- Field-level errors are associated with the affected controls.
- The shopper can identify and recover from the error with keyboard and screen reader.

Before publishing a ticket

Replace generic words like "accessibility issue" with the exact flow and task.
Keep the scanner rule or WCAG reference, but do not make it the whole ticket.
Write the impact in user language before implementation details.
Add a retest path that matches the original evidence.
Avoid legal panic wording unless a qualified legal review requires it.