There’s a continuum in accessibility testing:
At “Point A” there are no tests at all. No manual process, no automated test suite… nothing.
Then over at “Point B” is an application that’s got just the right amount of tests and process to validate the right things at the right time.
Let’s explore how you can get to point “B” no matter where you’re starting from.
As I’ve shared before, the very first step I take towards accessibility testing is to hit the Tab key.
Does your interactive application behave the way you expect? If the answer is no, you’ve got more to uncover. But you’ve now inched closer to our goal state and all you needed was a keyboard!
There are several testing tools that are must-haves on the journey.
Central to a number of accessibility tools is axe-core, a library I worked on at one point in my career (more on that some other time).
It powers the Axe Accessibility Linter for VSCode, which can catch issues in your code before you push them.
There are also browser extensions powered by Axe that allow you to test all or part of any web page. I like the browser extension because you don’t have to be a developer to use it— anyone technical or curious enough to use a program like Excel is going to be able to run these tests.
If you’re building a web application with a JavaScript library like React or Vue, consider adding Storybook to your project. This allows you to render your components in isolation from the rest of the app. You can render a button, a menu that uses those buttons, a page that includes that menu, and everything in between. Each Storybook Component Story you create can also be passed props to put it into a specific state. This is really nice for testing interactions with components like modals that might require a series of clicks to expose in the deployed app. Storybook also offers an Accessibility Add-on that checks for issues using (you guessed it) axe-core.
With some manual accessibility testing in place, let’s jump ahead to the halfway between point A and point B.
This is where the testing process gets more code heavy.
We’ll start with the introduction of unit testing. With this approach, you’ll want to make sure that the smallest individual parts of your code perform as expected.
To show how small a unit can be, the popular testing tool Jest provides an example in their docs that tests that two plus two is four.
But what does that have to do with accessibility?
Jest can be used to test the DOM with the help of Testing Library and its additional framework-specific libraries. We use React Testing Library in the Testing Accessibility workshops but many libraries and tools are supported. This means we can not only ensure that components are rendered, but that they include proper ARIA attributes or accessibility-focused functionality we could check for in a browser.
Speaking of browsers, Cypress is a powerful tool that runs integration & end-to-end tests in a real browser instance. These types of tests are focused on making sure our different components play nicely together.
Cypress lets us mimic the way a user would click, type, and otherwise flow through our application at a higher level. Using Cypress, we can assert that many accessibility requirements function as we expect. There’s also a “Component Testing” flavor of Cypress that can be used similarly to Jest and Testing Library but with the same API as the full-featured Cypress. You’ll get hands-on experience with both in the Automated Testing workshop.
Our last step to reach the target is to introduce Continuous Integration (CI) into the mix. This is where we set up our automated test suites to run every time code is pushed. If a test doesn’t pass, the code isn’t pushed and we don’t deploy an inaccessible application to production. There are several different options for setting up CI but we use GitHub Actions in the Testing Accessibility workshops.
With robust functional tests and CI in place, you can potentially move from “no testing at all” over to a fully tested application. You now have some pointers on how to set your team up for accessibility success!
Of course, there’s a lot of nuance and practice that I’ve glossed over for now that you can explore deeper in the Testing Accessibility workshops. But there’s plenty of reading you can do from here.
Remember that accessibility isn’t just making sure that your markup includes the proper elements and attributes and roles. It’s more than having tests that pass, too. (”Testing the right thing” is a whole topic on its own!)
Throughout the software development lifecycle, you have to make sure to ask yourself “What impact does this have on people with disabilities?” Continuously challenge your biases while testing both your assumptions and your code.
