All Topics
Test Automation for Accessibility
Using an A11y Testing API

Using an Accessibility Test API

Even though you should write your own accessibility tests, you might not want to be in the business of writing accessibility testing rules. Libraries like axe-core (opens in a new tab) and WAVE (opens in a new tab) (among others) were written for this purpose by accessibility companies and organizations that deal with accessibility compliance every single day. They bake their findings and knowledge of accessibility from the real world into their APIs so developers and test engineers don’t have to write those rules.

For example, axe-core and WAVE have rules for color contrast and a ton of ARIA stuff including what’s “accessibility supported”. The teams keep close track of WCAG and ARIA along with support in various ATs, and they update their rules accordingly. They are also part of the W3C’s ACT Rules Group (opens in a new tab) for standardizing automated accessibility tests.

Writing (and maintaining) those rules typically wouldn’t be a great use of time for most teams. So you should consider using an accessibility test API (if you haven’t already)!

Axe in Automated Tests

The axe-core library (opens in a new tab) has become popular because it has solid results and it’s free and open source. You can integrate it into unit tests, although its page-level rules for contrast in particular could be quite slow. You might want to limit it to integration or end-to-end testing where you can run the API on a larger section of DOM for performance reasons.

Also consider how you’ll digest the results. Teams with increasing accessibility maturity (and budgets) have robust solutions where developer results get piped to other environments, like web-based dashboards and the like. But most developers could get results from an automated test result that they can discern on their own on the command line.

There are different flavors of Axe that could be useful:

There are also other testing products that could be more comprehensive for your team. It is important in a larger organization to test with the same ruleset and technology as much as possible, which we’ll discuss in the next section.

Find something that works for you!

An accessibility test API can help you with:

  • HTML nesting and structuring issues
  • Label/name computation
  • Incorrect ARIA usage
  • Color contrast
  • Data table markup
  • Viewport/zooming problems

...and much more. These are very helpful rules as they can help catch accessibility issues within your automated test suite.