Standard approach to automated accessibility testing
Context and Problem Statement
The services we design need to be accessible and meet WCAG 2.1 level AA as a minimum, preferably meeting WCAG 2.1 level AAA where possible. Alongside human auditing, we want a consistent approach to automated accessibility testing, so which tool should we choose?
We should provide tooling around the edges that:
- creates a GitHub Action to test as part of the CI/CD process,
- providers Rake/Thor task(s) to run the tests locally.
Decision Drivers
- It’s a legal requirement to ensure that the websites and mobile applications we produce are accessible. This is done by showing compliance to the ‘AA’ standard of the WCAG 2.1 guidelines.
Considered Options
Decision Outcome
Chosen option: “Pa11y” because:
- it is a tool that we have already used as part of a GitHub workflow,
- we can run it twice to measure AA and AAA compliance,
- it runs HTML_CodeSniffer, aXe or both as “test runners”
More Information
GOV.UK Service Manual:
- Making your service accessible: an introduction
- Understanding WCAG 2.1
- Getting an accessibility audit
- Testing for accessibility
Potential Auditors: