Test · Core
Check acceptance criteria and accessibility
Before anything goes to users, check it does what the stories promised and that disabled people can use it. Accessibility is a legal duty for many services, and fixing problems late costs far more.
About 1-3 daysChanges yearlyLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Design and user experienceDelivery and execution
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- For each story, go through its acceptance criteria one by one in a test environment. Mark each as passed or failed, and raise a bug for each failure.
- Ask your tester or engineers to run an automated accessibility checker. Automated tools only catch part of the problems, so this is a starting point.
- Do a basic manual check yourself: use the feature with only a keyboard, zoom the page to 200%, and check text is readable and every button says what it does.
- Ask someone to try it with a screen reader, such as VoiceOver on a Mac or iPhone, or NVDA on Windows.
- Agree with the team which problems must be fixed before release and which can wait. Write down any that wait, with a date.
- Before release, record the result: what was tested, what passed and what is still known to be wrong.
Intermediate (1 to 4 years)
- Test every story against its acceptance criteria and log failures as bugs.
- Run automated accessibility checks plus manual checks: keyboard only, zoom and screen reader.
- Triage issues with the team into 'must fix before release' and 'known issues'.
- Record the test outcome and update the accessibility statement if you have one.
Experienced (5+ years)
- Verify all acceptance criteria, and log and triage failures.
- Check WCAG 2.2 AA with automated and manual testing, including assistive technology.
- Get release-blocking issues fixed, and record known issues with dates.
- Update the accessibility statement where one is required.
Who can do this
Owner: Product manager
Can be delegated to
- QA / Tester: Test each story against its criteria and run accessibility checks
- Frontend Engineer or Tech Lead or Backend Engineer: Add automated accessibility tests and fix issues found
- User Researcher: Test with disabled users and people who use assistive technology
- Content Designer: Check headings, labels, link text and error messages are clear
Reviewed by: QA / Tester, Tech Lead
Tool examples
- Jira
- Link each bug to the story it came from, and use a label such as 'accessibility' so you can report on those issues separately.
- Azure DevOps
- Use Test Plans to record a pass or fail against each acceptance criterion.
- GitHub
- Ask engineers to run an automated accessibility check on every pull request, so problems are caught before they merge.
- Confluence
- Keep a test summary page per release: what was tested, results and known issues.
- Claude
- Paste your acceptance criteria and ask which ones are hard to test as written and how to reword them.
Definition of done
- Every acceptance criterion tested and marked passed or failed
- Automated and manual accessibility checks done, including a screen reader
- Release-blocking issues fixed
- Known issues written down with a plan to fix them
Common pitfalls
- Relying only on automated accessibility tools
- Leaving accessibility until the end of the project
- Testing only the happy path
If you lead the team
What good looks like: Work is checked against its acceptance criteria and accessibility standards before users see it.
Ask your PM
- Who checks acceptance criteria, and when?
- How do we test with assistive technology?
Warning signs
- Accessibility issues are found by users.
- 'Done' means different things to different people.