Automated accessibility testing is a fast and repeatable way to spot some accessibility issues. These tools can be integrated into development and deployment workflows.

Automated accessibility testing is essential but only finds between 30 – 50% of accessibility problems. The limitations of automated accessibility testing page explains why manual testing is always required.

Use a variety of automated testing tools to capture as many accessibility issues as possible.

Test web apps using tools and extensions for that browser and test in multiple browsers where possible.

You need to use at least two accessibility testing extensions because each one will highlight slightly different accessibility problems.

The UK Government Digital Service (GDS) published an accessibility tool audit . The Design System recommends:

Most of these tools will highlight the WCAG or best practice accessibility problems on the page and tell you how to fix the issue.

Some of the tools will walk you through extra manual testing (like Accessibility Insights for Web), while others will conduct only a full automated test.

Browser tools can only check what is rendered on a web page when you run the test. To check multiple pages, dialogs or other temporary elements, trigger them before re-running the test.

Tools called 'linters' analyse source code for a range of potential bugs. Some linters check for accessibility problems or have additional rulesets you can use.

Linters detect issues very early and can prevent certain accessibility problems from ever being implemented.

The UI Kit uses the ESLint accessibility plugin eslint-plugin-jsx-a11y . Equivalent ESLint plugins are available for Vue and Angular.

Integration testing is where parts of software are combined and tested together.

This is often done as part of a Continuous Integration and Continuous Delivery (CI/CD) workflow.

End-to-end testing is where the entire app is tested from a user's perspective.

Selenium and Cypress are common tools for end-to-end testing. Both tools have axe-core wrappers: axe-selenium and cypress-axe , respectively.

Well configured end-to-end tests should also test multiple pages, dialogs and other temporary elements.

axe-core can test pages on your app in the same way other unit or integration tests would.

Axe-core is used by the browser-based extensions axe DevTools and Accessibility Insights for Web .

Pa11y runs accessibility tests via the command line or Node.js for automating testing.

It uses axe-core as well as HTML CodeSniffer to look for potential accessibility issues.

Pa11y CI is a CI-centric accessibility test runner, built using Pa11y.

Tools such as SonarQube , which provide code-quality assurance of your source code, also have a number of accessibility rules in SonarHTML.

SonarQube recommends using this alongside other linting such as ESLint.

Read more about how to scan accessibility issues with SonarQube .