Accessibility, Continuous Integration, Non-functional Requirements

Accessibility and Continuous Integration

There are some great tools out there already to test if your page conforms to accessibility standards – HTML_CodeSniffer is one of the best I’ve seen – but I can’t run this as part of my automated CI process.

There are some tools that allow you to submit a URL, such as the WAVE tool on the WebAIM site, but if you’re developing a site on an intranet, or you’re working with confidential data, this isn’t useful either.

From the W3C WAI Tools list, I discovered AccessLint, which audits your code using javascript from Google’s Accessibility Developer Tools. This posting is a quick recipe for how to run this against a web page from the command line using Windows.

  1. Download PhantomJS, extract to somewhere on your hard drive, and add the binary’s path to your environment variables.
    • Grab Phantom JS from here.
    • I extracted the zip file to C:\PhantomJS_2.0.0 so the actual PhantomJS.exe sits in C:\PhantomJS_2.0.0\bin. I created an environment variable called PHANTOM_JS, and then added “%PHANTOM_JS\bin” to the end of my PATH.
  2. Download the installer for Ruby and run it.
  3. Download the Access Lint code.
    • Grab the Access Lint code from here. Pull using Git, or download the zip – either way works.
    • I have the code in C:\Access_Lint so I can see the access_lint ruby file in C:\Access_Lint\bin.
  4. Install the rubygem.
    • Open a command prompt, browse to where the access_lint ruby file is saved (as above, I have it in C:\Access_Lint\bin), and enter:
gem install access_lint

And we’re ready to go!

Now you can open a command prompt, and enter a command like:

access_lint audit http://w3.org

The audit output will render to the command prompt window as JSON.

You can now check the accessibility of a web page on your integration server as part of a CI process.

Criticisms

The process isn’t perfect.

  • To test each page, you’d have to audit it individually – it would be better if we could crawl the site. (We could work around this by running a batch of audit commands, specifying each page to be audited in a separate line).
  • The JSON output has some odd artefacts – it uses “=>” instead of “:”, and the first and last lines in the file are console logs. (We could work around this by doing some simple post processing on the output).
  • JSON isn’t particularly readable. (We could work around this by using the JSON as a data source, and using another tool to render results in a more readable format)
  • And most significantly, if this tool doesn’t report failures, it doesn’t mean your page is accessible. (No real workarounds beyond manually checking the page.)

But this is the starting point on a journey. Accessibility can sometimes be an afterthought. It should be a natural part of development and process, and part of a team’s definition of done.