People who are familiar with my work probably know that I’m a big fan of Test Driven Development (TDD) for accessibility.
I’ve written and spoken about automated accessibility testing many times in the past 8 years, including an article on this site and another one from my time at Deque Systems. So when I get a good question about it, I feel compelled to expand on the topic!
In a tweet about TDD, I posed the question “how does this apply to accessibility?” John Costanzo (@jrock2004) replied with another great question:
I so want to do this but how do I write for tests of components I do not know I am going to build yet? Do you just mount highest component and write tests there first?
It’s true that we might find ourselves working on web sites or apps in all levels of maturity or robustness, where it can be unclear how to establish a testing strategy.
One helpful thing about accessibility testing in particular is that it needs a user-centric focus to be effective. By prioritizing tests that assert accessible outcomes on the front end, it becomes less of a concern how exactly your app is built.
In John’s question, he asked about writing tests when specific components haven’t yet been built out. Maybe you have a code prototype version of a design to prove the concept or just to get something working in the browser. But you also know the code will be broken down into sub-components as you add features, along with additional complexity.
It would indeed be too early to write effective tests for sub-components when they don’t yet exist – particularly unit tests and fine-grained feature or edge-case tests.
However, there are likely to be core user outcomes in the design that could impact accessibility: things like initial keyboard support, semantic markup, and color contrast. Having a high-level test run with an API like axe-core can be helpful as well, as it brings with it tests that you won’t have to write (think ARIA requirements, current “accessibility supported” information, and contrast algorithms).
If you begin writing tests with an end-to-end tool like Cypress that loads a page by URL or route, you can write assertions that mimic how users will interact with your application from a high level. The tests shouldn’t be affected too much by changing of business logic under the hood as you divide up the page into separate components and increase fidelity.
You could also use tools like Jest and Testing Library for your user-centric tests if you already have that infrastructure in place. These are often used for unit tests but the lines between testing types aren’t always clear if you can get the job done somehow. Cypress Component Testing could fit in there somewhere, too.
As John suggests, mounting your highest-level components and writing tests for those would give you a place to write your assertions that aren’t as likely to change. If your tests are really geared toward user outcomes that are present in the design, they should have some persistent qualities as long as the design doesn’t undergo a major change.
As you build out sub-components, you could potentially migrate your assertions to new locations with minimal changes (which components are invoked, code paths, or variable names, etc. NOT the entirety of the tests).
For automated accessibility tests using any platform or test approach–unit, integration, etc.–you’ll need to focus on programmatically-determinable aspects of user experience. This means things that a computer can assess as true or false: no nuance or human decision-making necessary.
There are plenty of accessibility requirements that don’t fall into this category so a manual testing strategy is needed as well. But you can get the satisfaction of writing automated tests for your projects from the start by focusing on user experience.
It can be exciting to get tests working for keyboard and screen reader access on interactive components. It’s also best to work out these details early on. By having test coverage for interactions that withstand refactors, you can build robustness and accessibility into your applications like a boss.
