← Back to Blog Home

Four Free Tools for Automated Accessibility Testing of Web Apps

Developer Tools
by: Ross Patterson

Article summary

Designing and developing for web accessibility has become a requirement of modern computing. Depending on the content and complexity of your project requirements, it can also be a very difficult pursuit.

Two colleagues of mine have already written excellent articles exploring the need for and design of accessible web sites: Designing Accessible Software – Breaking Down WCAG 2.0 and Easy Design & Front-End Practices for Improving Accessibility.

According to the experts at Deque Systems, somewhere between 20% and 50% of accessibility issues can be automatically tested. In this post, I will show you four free tools you can use to add automated accessibility testing to your development process.

aXe Browser Extensions

The easiest (but least flexible) method for accessibility testing is to use an aXe browser extension. These extensions are published for both Chrome and Firefox by the fine folks at Deque Systems. Once installed, simply open the page you want to test in the browser, open the extension in the browser developer tools, and click “Analyze.”

aXe will then scan the page for violations of accessibility standards (WCAG 2.0 and Section 508). As you can see below, the tool will report any violations it finds and include the raw HTML in violation, the standard(s) violated, the number of times those violations occurred, and any suggestions for how to fix them.

Accessibility testing with the aXe Chrome extension
Accessibility testing with the aXe Chrome extension.

The aXe browser extensions are great for one-off accessibility testing, but it would be difficult to integrate them into an automated testing suite. Let’s take a look at some other options for doing just that.

Other aXe Interfaces

It turns out that the aXe browser extensions are really just useful interfaces built on top of the aXe-core package. aXe-core provides all the necessary components to parse raw HTML and evaluate its validity against a set of compliance rules.

This separation allows for the building of other interfaces on top of aXe-core. And the aXe-cli and aXe-webdriver packages do exactly this in order to provide aXe accessibility testing into development environments.

aXe-webdriverjs

Another interface for aXe-core is the aXe-webdriverjs package, which provides a Promise-based API for the Selenium WebDriver. As a result, it is more configurable and grants fine-grained control over how the document is tested.

First, let’s install it:


yarn add axe-webdriverjs

Now we can instantiate and run an AxeBuilder inside of our Mocha test suite and inspect the results for violations.


const AxeBuilder = require('axe-webdriverjs');
const WebDriver = require('selenium-webdriver');
const assert = require("chai").assert;

describe("aXe test", function() {
  this.timeout(10000);
  let driver;

  beforeEach(function(done) {
    driver = new WebDriver.Builder()
      .forBrowser('chrome')
      .build();

    driver.manage().timeouts().setScriptTimeout(500);

    driver
      .get('https://www.google.com')
      .then(function () {
        done();
      });
  });

  afterEach(function () {
		driver.quit();
  });

  it('should find some violations and some passes', function (done) {
    AxeBuilder(driver)
      .analyze(function (results) {
        assert.lengthOf(results.violations, 2);
        assert.lengthOf(results.passes, 19);
        done();
      });
  });
});

The results JSON object contains all of the same data as the aXe browser extension reported, but now you will need to parse the JSON to reveal it. There is a lot of power and flexibility with this WebDriver-based testing approach, but it will also require the most investment.

aXe-cli

The aXe-cli package provides a fairly simple wrapper around aXe-core. Let’s quickly install it and try it out.


yarn add axe-cli

Once installed, it is easy to run an accessibility test against a web page.


./node_modules/.bin/axe www.google.com

Accessibility testing with aXe-cli.
Accessibility testing with aXe-cli.

As with the browser extension, aXe-cli reports any violations it encounters, along with suggestions to fix and a link to more detailed information. One thing I’ve found I don’t like about aXe-cli is that it exits with a 0 status even if violations are found, and that does not appear to be configurable at this time. Consequently, this makes it more difficult to incorporate as part of an automated testing process.

Pa11y

So far, the only tools I’ve talked about have been created by the team at Deque Systems. There is another great option out there, and it happens to be the one I currently use in my projects. Pa11y is a very simple but configurable CLI for automating your accessibility testing. It uses PhantomJS under the hood to load the test page and inspect the DOM for accessibility issues.

Both Pa11y itself and the way it uses PhantomJS are adequately configurable. And importantly, you can tell Pa11y to exit with a non-zero status based on the number and types of violations it finds, opening the door for an automated accessibility test suite as part of your CI build. In fact, there is a Pa11y add-on called pa11y-ci that makes that an easy thing to do.

Conclusion

Accessibility testing is hard. And while no piece of software can evaluate your site for 100% compliance, there are several tools freely available that can get you almost halfway there. I highly encourage you to add one of these tools to your software development process to give you early insight into any accessibility issues you may have.

Related Posts