Automated Accessibility Testing

Automated Accessibility Testing

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.

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:

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:

Back to blog