Exploring automated accessibility testing

Published: 22 October 2026 | Author: Russ Weakley

Automated accessibility testing can help teams find accessibility issues, check how components behave, and prevent problems from being introduced during development.

This series of six articles explores how tools like axe-core and Playwright work, what they can and can't test, and how they can be used together. It starts with the basic concepts, then gradually builds towards more advanced testing techniques.

Along the way, you'll see that there's nothing magical about these tools. You can understand how they work, control what they test, and decide how to use the results.

Who this series is for

accessibility professionals who want to understand how development teams test for accessibility
developers and testers who are new to automated accessibility testing
product owners and team leads who want to know what automated accessibility testing can and can't do (article 1 is a good place to start)

You don't need any coding experience to start. Every step is explained in plain language.

1. Understanding axe-core and Playwright

Learn what axe-core and Playwright do, what they can and can't test, and how they work together. No installation or coding required.

Why this matters: These tools do different jobs. Understanding their roles helps you see how they can be used together for accessibility testing.

Start here if: You're new to automated accessibility testing and want to understand the tools before trying them. No technical knowledge needed.

2. Running axe-core in the browser console

Start using axe-core without installing any software. Run accessibility checks directly in your browser's developer console, explore the results, and learn how axe-core works behind the scenes.

Why this matters: Many people first meet axe-core through a browser extension, where everything happens behind the scenes. Running axe-core in the console is not something you'd do in day-to-day testing. It's a stepping stone. It shows you what axe-core actually does, and the results it produces, with nothing to install or set up. Everything in the later tutorials builds on this.

Start here if: You've used the axe browser extension and want to see what it's doing behind the scenes. No coding experience needed.

3. Setting up Node.js

Install Node.js and the tools you'll need for the next two tutorials.

Why this matters: These tools let you run accessibility checks from your computer's command line, rather than manually running them in the browser console.

Start here if: You understand the basics and are ready to try hands-on testing on your own computer.

4. Running axe-core from the command line

Move beyond testing one page at a time. Run axe-core from the command line, test multiple pages, save results, generate reports, and explore how accessibility failures can be used to stop automated processes.

Why this matters: Rather than manually opening pages and running checks, you can automate the process with simple commands. You also gain control over how results are saved and reported. Most importantly, tests can be set up to return a failure status when accessibility issues are found, allowing development teams to use them in automated build and release processes.

Start here if: You've already set up Node.js and the axe tools from article 3.

5. Running axe-core with a Playwright script

Take greater control of your accessibility testing by combining axe-core with Playwright. Learn how to write scripts, customise which issues cause tests to fail, generate reports, and automatically rerun tests as you make changes.

Why this matters: The command line tool fails on any violation, even a minor one, and only runs when you tell it to. By writing your own script, you can:

decide what counts as a failure
run checks automatically every time the code changes
use a failing check to stop a build or block a release.

This is much closer to how development teams use axe-core in practice.

Start here if: You've set up Node.js from article 3, and want more control over what counts as a failure and when checks run.

6. Accessibility testing with Playwright

Move beyond the issues axe-core can detect automatically. Explore six practical examples of testing accessibility behaviour with Playwright, including keyboard interactions, component states, focus management and form errors.

Why this matters: Automated accessibility scanners can only detect certain types of issues. They cannot reliably determine whether every interaction behaves as expected. Playwright allows you to write tests for specific behaviours, such as whether a dialog receives focus when opened or whether a disclosure updates its expanded state. These tests can help teams check expected accessibility behaviour and prevent regressions as their products change.

Start here if: You want to explore how Playwright can test accessibility behaviour beyond what axe-core can detect. You don't need to complete the earlier tutorials.

Remember

Automated accessibility testing is only one part of a wider accessibility testing process. These tools can help find issues and prevent regressions, but they don't replace manual testing or testing with people with disability.