At the Canadian Digital Service (CDS), we use a variety of testing tools, including:
- Research with people with disabilities
- Automated testing tools
- Adaptive technology
- Manual testing and
- Usability testing including people with disabilities.
For automated testing, CDS uses a range of tools, including:
- accessibilityinsights.io - Open source browser extension from Microsoft.
- Axe - Open source accessibility engine.
- WAVE Toolbar - Popular free browser extension by WebAim.
- Siteimprove - Commercial tool with site-wide accessibility checking and browser extensions.
- Google Chrome - Accessibility Developer Plugin
We found that Puppeteer was easier for our devs to use then other alternatives. This also allowed use to automate certain functionality that can be difficult to test for single page apps and dynamically generated content.
aXe Core is becoming the default accessibility engine because it supports WCAG 2.1 automated test scores, has a commitment to reducing false positives and because it is open source. Deque is in partnership with Microsoft which is contributing back to this open source project through the Accessibility Insights extension. Microsoft’s accessibility extension allows more detailed walk throughs in the manual testing arena. Because it is open source, aXe has partners in government, industry and other through accessibility leaders keen on producing a robust automated accessibility engine. Google also leverages aXe in their Lighthouse tool which is available as a browser and command line tool (CLI) for automated reviews. aXe is also very easy to integrate with Puppeteer, Jira and Github.
Use the accessibility checklist created by18F (the US government's digital agency) to help you test for common accessibility problems, including:
- lack of keyboard accessibility (important because people who use screen readers, voice recognition or have situational, temporary of permanent mobility related disabilities may rely on using a keyboard to navigate websites)
- ensure that the content is written in plain language
- link text that's not descriptive (for example, 'click here' and 'read more' links)
- lack of colour contrast for text and important graphics or lack of proper controls
- non decorative images not having meaningful alt text
- Online forms not being marked up correctly, so the right control is associated with the right label
Some browsers have tools that make it easier to find accessibility problems in the Document Object Model (DOM). For example, accessibility Inspector for Mozilla Firefox and the accessibility features in Chrome DevTools. Also, you can check out the Accessibility Object Model.
For cross-browser testing, ensure your service works on the following browsers:
- Windows only: Internet Explorer 11, Microsoft Edge
- Mac/iOS only: Safari
There's a lot of information out there on accessibility. You can start some simple tests with:
- W3C Easy Checks - a few quick things to help you start to assess how accessible a web page is
- Basic screen reader commands for accessibility testing, from the Paciello Group
- WCAG report generator
You can also read some blog posts on:
- Dos and don'ts on designing for accessibility
- How the Government Digital Service did accessibility testing on GOV.UK
You may also find these guides useful: