Accessibility Ticket Acceptance Criteria Examples

A good accessibility ticket does not end with "fix WCAG issue". It tells QA and developers what must be true when the user task works again.

Use these examples when an audit note, scanner finding, or screen reader observation already explains the problem but the ticket still needs a concrete retest path.

What acceptance criteria should prove

The affected user task works: the shopper can pay, the user can recover from the error, or the reader can understand the update.
The original evidence is retested: same flow, state, viewport, browser, scanner rule, or assistive technology path.
The fix is observable: labels, roles, states, focus order, status messages, contrast, or table relationships can be checked.
The ticket is not overbroad: one component defect can cover repeated instances, but not unrelated flows with different impact.

Reusable acceptance criteria pattern

Acceptance criteria:
- The affected user task can be completed with [keyboard / screen reader / scanner retest context].
- The original finding can no longer be reproduced in [page, flow, component, or state].
- The relevant name, role, state, relationship, focus order, status message, or visual state is available programmatically where applicable.
- The likely WCAG references listed in the ticket have been verified against the implemented behavior.
- Any repeated instances from the same component are fixed or explicitly listed as follow-up work.

Paste your finding into the generator when you want these criteria drafted from the raw issue text.

Examples by issue type

Keyboard focus and modal dialog

Acceptance criteria:
- Opening the dialog moves focus to the first useful control or the dialog heading.
- Tab and Shift+Tab stay inside the open dialog until it is closed.
- Escape or the visible close control closes the dialog.
- Closing the dialog returns focus to the control that opened it.
- The dialog exposes a useful accessible name.

Form validation and recovery

Acceptance criteria:
- Submitting invalid data identifies each field with an error.
- Each error message is programmatically associated with the affected field.
- Error text explains how to recover, not only that the value is invalid.
- Keyboard and screen reader users can find the first error without losing their current task context.
- The form can be corrected and submitted successfully without relying on color alone.

Screen reader status update

Acceptance criteria:
- The visual update and the programmatic status message communicate the same result.
- The update is announced without moving focus when no immediate action is required.
- The announcement is not repeated unnecessarily after unrelated focus changes.
- The affected flow is retested with the assistive technology named in the evidence.

ARIA reference or accessible name issue

Acceptance criteria:
- Every ARIA id reference points to an existing unique element.
- The computed accessible name or description matches the visible purpose of the control.
- Native HTML relationships are used where they express the relationship more reliably than ARIA.
- Browser accessibility inspection confirms the expected name, role, state, and value.

Contrast or visual state issue

Acceptance criteria:
- Text and meaningful UI states meet the relevant contrast requirement in default, hover, focus, error, and disabled states.
- The state is not communicated by color alone.
- The focus indicator remains visible against adjacent backgrounds and is not covered by sticky UI.

Acceptance criteria to avoid

"Make accessible": too broad to retest.
"Pass WCAG": too vague unless the exact criterion and behavior are named.
"Scanner shows zero issues": useful evidence, but not enough for keyboard and screen reader behavior.
"Looks better": replace with measurable contrast, focus visibility, or state clarity.
"Works with screen reader": name the expected announcement or navigation path.

Paste-ready input for the generator

Raw finding:
[Paste scanner output, audit row, or tester note.]

Page or flow:
[Name the page, checkout step, modal state, form, or component.]

Retest context:
[Keyboard only, VoiceOver/Safari, NVDA/Firefox, axe rule, Lighthouse audit, or manual QA.]

Acceptance criteria needed:
Draft criteria that prove the user task works, preserve the original evidence, and avoid generic "make accessible" wording.