Accessibility is core to our mission, but it's easy to let it slip in moments of pressure, or to treat it as something to fix just before going live. Tools exist that can help us integrate accessibility checks into our feature tests without relying on memory or time, alerting us as soon as something goes wrong. We should use these tools where possible to make building accessible services easier.
Manual testing is still a necessary complement to automated checks, for which brief recommendations are made on minimum expectations.
One of dxw's core principles is to make everything we do accessible, and the first point of our mission statement is to:
build services that fit seamlessly into user’s lives, and that make public services usable and accessible to all [emphasis added] – especially those most in need
We take accessibility seriously in our client projects: designers, developers, and members of other disciplines within a sprinting team strive to consider accessibility within every iteration, and we conduct accessibility audits as standard.
However, in the pressure of an busy sprint, especially when deadlines are looming, it's easy to forget to check for accessibility issues. We tend also to hold off on more holistic accessibility audits until nearing the end of a statement of work, or when a service is about to go live.
We should work by the adage that accessibility should never be an afterthought.
We SHOULD integrate automated accessibility checks into feature tests using axe-core where possible. axe is one of the most popular accessibility testing suites available, with widespread usage and good language support. We have a good level of familiarity with the axe suite within dxw, and axe DevTools, which runs on axe-core, is recommended in our own internal accessibility training. axe, including axe-core, is open source. While axe has premium products (we subscribe to axe DevTools Pro), axe-core is free to use.
We MAY use an alternative automated accessibility testing tool in environments where axe is unavailable or another tool is better suited.
We MUST continue to perform manual checks as part of a holistic approach to accessibility testing. The WCAG AA standard is the minimum requirement for the types of services we work on. Automated accessibility checks don't cover 100% of the AA requirements - axe-core claims around 57% coverage - therefore manual checks are still necessary to plug the gaps. At minimum:
- we MUST do a full accessibility audit before going to public beta;
- we MAY invite people to join a sprinting team for an accessibility review before public beta;
- we SHOULD be trying to spot accessibility issues during code review.
Further guidelines on manual testing will appear in dxw's upcoming accessibility manual.
Example pull requests using cypress-axe:
Example pull requests using @axe-core/playwright:
- Add automated accessibility checks to template repositories