Accessibility Testing Tools for Developers: Catch Issues Before Your Users Do

Web accessibility is not optional. Over 1 billion people worldwide have some form of disability. In the US, the ADA applies to websites, and lawsuits over inaccessible websites have increased dramatically — over 4,000 federal ADA web accessibility lawsuits were filed in 2024. Beyond legal risk, inaccessible websites exclude customers and users.

The good news: many accessibility issues are detectable with automated tools, and the remaining issues can be caught with systematic manual testing. The bad news: most development teams do not test for accessibility at all, or they run a Lighthouse audit once and call it done.

Here is a practical guide to the tools and workflows that make accessibility testing part of your development process, not an afterthought.

What Automated Tools Can and Cannot Catch

This is the most important thing to understand about accessibility testing: automated tools can detect approximately 30-50% of accessibility issues. The rest require human judgment.

What Automated Tools Catch Well

What Requires Human Testing

Automated Testing Tools

axe by Deque

axe is the industry standard accessibility testing engine. It powers many other tools and can be used as a browser extension, CLI, or library integrated into your test suite.

axe DevTools (Browser Extension)

Install the axe DevTools extension for Chrome or Firefox. Open DevTools, navigate to the axe tab, and scan the current page. The results show each issue with its WCAG rule, severity, affected element, and remediation guidance.

Strengths:

axe-core (Library)

axe-core is the open-source JavaScript library that powers axe DevTools. Integrate it into your automated test suite: 


// With Playwright
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

test('should pass accessibility checks', async ({ page }) => {
  await page.goto('https://example.com');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});


// With Cypress
import 'cypress-axe';

it('should pass accessibility checks', () => {
  cy.visit('/');
  cy.injectAxe();
  cy.checkA11y();
});

Strengths:

Best Practice: Run axe-core in your end-to-end tests on every page and every interactive state (modals open, dropdowns expanded, form errors displayed).

Lighthouse Accessibility Audit

Lighthouse includes an accessibility audit powered by axe-core. It is less comprehensive than running axe directly (fewer rules), but convenient because it runs alongside performance, SEO, and best practices audits.

When to use: Quick checks and CI integration where you want a single tool for multiple audits.

When not to use: As your only accessibility testing — the rule set is too limited.

WAVE

WAVE (Web Accessibility Evaluation Tool) by WebAIM provides a visual overlay showing accessibility issues directly on your page. Elements with issues are highlighted with icons indicating the type and severity.

Strengths:

Limitations:

Best For: Visual review during development and explaining accessibility issues to designers and product managers.

Pa11y

Pa11y is an open-source accessibility testing tool focused on CI integration and automated monitoring. It can test individual pages or crawl entire sites.

Pa11y CLI: 


pa11y https://example.com

Pa11y CI: 


# .pa11yci.json
{
  "defaults": {
    "standard": "WCAG2AA"
  },
  "urls": [
    "https://example.com/",
    "https://example.com/about",
    "https://example.com/contact"
  ]
}

pa11y-ci

Pa11y Dashboard: A web dashboard that monitors accessibility over time.

Strengths:

Limitations:

Best For: CI enforcement and site-wide accessibility monitoring.

Manual Testing Tools

Screen Readers

Testing with a screen reader is the most important manual accessibility test. If a screen reader user cannot navigate your site, no amount of automated testing will catch the problem.

VoiceOver (macOS/iOS): Built into every Mac and iPhone. Press Cmd+F5 to enable on Mac.

NVDA (Windows): Free, open-source screen reader. Download from nvaccess.org.

JAWS (Windows): The most widely used screen reader professionally. Expensive ($90/year) but important for comprehensive testing.

TalkBack (Android): Built into Android devices.

Basic Screen Reader Testing Checklist

  1. Can you navigate the page using only headings (H key in NVDA/VoiceOver)?
  2. Are all images described with meaningful alt text?
  3. Can you complete all forms using only the keyboard?
  4. Are form errors announced when they appear?
  5. Do modals trap focus correctly and announce their content?
  6. Are dynamic content updates (AJAX, live regions) announced?
  7. Is the reading order logical?

Keyboard Testing

Navigate your entire site using only the keyboard:

What to check:

Color Contrast Checkers

WebAIM Contrast Checker (https://webaim.org/resources/contrastchecker/): Enter foreground and background colors to check WCAG contrast ratios.

Stark (Figma plugin): Check contrast during design, not just development.

Chrome DevTools: Inspect an element, click the color swatch in the Styles panel — DevTools shows the contrast ratio and WCAG compliance level.

WCAG requirements:

CI/CD Integration Strategy

Level 1: Basic (Every Team Should Do This)

Add axe-core to your end-to-end tests. Fail builds on critical and serious violations. 


// playwright.config.js — add to existing e2e tests
test('homepage accessibility', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Level 2: Comprehensive

Add Pa11y CI to test all pages, not just those covered by e2e tests. Run on staging before production deployment.

Level 3: Continuous Monitoring

Use a monitoring service that tracks accessibility compliance over time and alerts on regressions. Options include Siteimprove, Level Access, and self-hosted Pa11y Dashboard.

WCAG Compliance Levels

WCAG 2.1 Level A: Minimum accessibility. Addresses the most severe barriers. 30 success criteria.

WCAG 2.1 Level AA: The target for most websites and the basis of most legal requirements. 50 success criteria (includes Level A).

WCAG 2.1 Level AAA: Highest accessibility. 78 success criteria. Difficult to achieve for all content types. Not typically a legal requirement.

WCAG 2.2: Released in 2023, adds criteria for focus appearance, dragging movements, and accessible authentication. Increasingly the standard for new projects.

Target Level AA for your projects. It covers the issues that matter most for real users and satisfies most legal requirements.

Recommendations

Every developer: Install the axe DevTools browser extension and check it during development. This takes 10 seconds and catches the most common issues.

Every project: Integrate axe-core into your e2e test suite. Fail CI on critical violations. This prevents accessibility regressions from shipping.

Teams serious about accessibility: Add keyboard testing and screen reader testing to your QA process. Automated tools catch formatting issues; manual testing catches usability issues.

Organizations with legal requirements: Combine automated testing (axe + Pa11y) with periodic manual audits (screen reader testing, keyboard testing, assistive technology testing). Consider a professional accessibility audit annually.

The most impactful step is the simplest one: run axe on every page before you ship. It takes minutes to set up, costs nothing, and catches the issues that affect the most users. Everything else builds on that foundation.