This content originally appeared on Scott Vinkle - Blog and was authored by Scott Vinkle
There are plenty of automated tools available to test for accessibility issues. Before we dive in, let's make one thing abundantly clear: automated testing can only reliably pick-up 30-40% of all accessibility issues.
Automated tools are not able to determine what a component is actually meant for. It can't replace a human testing an interface for accessibility and usability issues. It's advisable to always manually test with assistive technology and conduct usability test sessions with people who use and rely on assistive technology.
Automated testing tools
Here are common tools to test with. These can be installed as browser extensions and run on any site you're working on. Run often to identify "low hanging fruit" issues.
- Lighthouse by Google
- aXe by Deque
- WAVE by WebAIM
- Accessibility Insights by Microsoft
Be sure to run more than one tool as some provide more detailed and accurate feedback than others.
Usability testing
Usability testing should be conducted after development of a component, but before launching to the general public. This way feedback will be received and time will be available to correct any usability issues.
Recommended services include:
- Knowbility
- Fable
Unit testing
It is very possible to write unit tests to test your code for accessibility issues. This is another great way to catch those "easy-wins" and to prevent regressions from taking place when pushing code to production.
The most popular test framework is Deque's aXe-core library. It's incorporated into Lighthouse for Google Chrome, Sonarwhal by Microsoft's Edge team, Ember A11y Testing, and more.
For example, here's a test running the entire set of rules on a document in a page-level integration test:
var axe = require('axe-core');
describe('Some component', function() {
it('should have no accessibility violations', function(done) {
axe.run('.some-component', {}, function(error, results) {
if (error) return error;
expect(results.violations.length).toBe(0);
});
});
});
Running tests result in a JSON object being returned with everything axe-core found: arrays of passes, violations, and even a set of "incomplete" items that require manual review. You can write assertions based on the number of violations, helpful for unblocking builds locally or in Continuous Integration (CI).
Check out this example of how to use aXe with the Jasmine unit testing framework by Marcy Sutton.
CI environments
Having test run in your CI environment is another method of preventing regressions and can be viewed as a "last line of defense." These tests run automatically when a code change from a pull request is about to be merged with the master branch.
One tool you can use for this type of testing is pa11y-ci which runs accessibility tests against multiple URLs and reports issues.
Resources:
- Writing Automated Tests for Accessibility
- aXe-core
- aXe-webdriverjs
- Pa11y
- eslint-plugin-jsx-a11y
- Accessibility auditing with react-axe and eslint-plugin-jsx-a11y
- What we found when we tested tools on the world's least-accessible webpage
This content originally appeared on Scott Vinkle - Blog and was authored by Scott Vinkle
Scott Vinkle | Sciencx (2019-07-05T13:43:00+00:00) Automated Accessibility Testing. Retrieved from https://www.scien.cx/2019/07/05/automated-accessibility-testing/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.