Accessible Code Quality
Every project that is more than a few lines long should implement automated testing to ensure code quality. This is especially true when it comes to the accessibility features. When a developer adds accessibility features to code, another developer may want to change that code months later and, in doing so, may accidentally remove those accessibility features.
In order to prevent this from happening in Enable, we have implemented the following automated testing frameworks inside of Enable:
Before testing anything else, it is important that the HTML of the project you are working on is valid. If a developer produces invalid HTML, a browser's accessibility API may not have the right information for screen readers and other assistive technology to work with the page correctly.
Enable uses v.Nu to check the HTML of all the pages within Enable. It does this by:
- Generating all the HTML of all the PHP pages on the site.
- Parsing the group A pages with v.Nu, using one call to v.Nu (since each call to the v.Nu command line tool would be a separate call to Java, which is expensive).
- Parsing the group B pages with v.Nu (each page requires a separate call to v.Nu, and thus Java).
Note that v.Nu requires Java in order to run. If this is a concern on your project, you may want to try using this Node based HTML validator instead (I have not used this yet, so your mileage may vary).
Using Axe-core and Pa11y CI for Accessibility Linting
Enable uses both Deque Labs' @axe-core/cli as well as Pa11y CI to do accessibility linting. Why two? Both are very good tools, but they don't test for the same things, and as Craig Abbott states in this excellent article that compares axe-core and pa11y, it's hard to compare the two. So why not just use both?
Both tools go through all the Enable pages to check to see if colour contrast is right, alt attributes are set, ARIA is marked up correctly, and so on. As axe-core explicitly states after execution, automated testing can only catch from 20% to 50% of accessibility issues. Is there any way to improve upon that?
Unit testing is the final tool in your automated testing toolkit that you should use in your project to ensure any accessibility feature you have just implemented stays within the project. For example, if you create a custom accessible listbox dropdown, you want to make sure that when keyboard users tab into the component and use the arrow keys that they can change the selected listbox value.
Enable currently uses Jest with Puppeteer to do unit tests. Usually, each test involves:
- Loading a page that contains component examples
- Querying the DOM on the page to make sure the components in question are coded correctly.
- Querying the current CSS style in the components to make sure it captures the visual requirements (and/or screen reader contents, when using visually-hidden CSS generated content)
- If needed, simulate a keyboard user manipulating the components to ensure the user-experience works correctly.
- After the component is manipulated, go through steps 2-5 again, if necessary.
Before we start
Our unit testing examples use ES6 modules. In order to support ES6 Modules in Jest, you need to do the following commands inside your project:npm install @babel/preset-env npm install --save-dev @babel/plugin-transform-modules-commonjs
You should also put the following lines in your
A Simple Example
Let's look at a simple example that just involves just steps 1 through 3. If you look at the page for Exposing Style Information To Screen Readers, we use
visually-hidden CSS generated content on the
mark tags. We want to
ensure that a new developer that contributes code to Enable never removes this CSS by accident, so we create a jest
exposing-style-info-to-screen-readers.test.js, to ensure we can test that this CSS is in these
example. Let's walk through this file to show how it works.
Code Walkthrough of the Above Example
Below is the HTML of the above example. Use the dropdown to highlight each of the individual steps that makes the example accessible.
If you want to do some further reading, we recommend Writing Automated Tests for Accessibility by Marcie Sutton and Web Accessibility Testing by Kfir Zuberi are great places to start (it's where we started).