At least one in five people has some kind of impairment, so it’s important to have them in mind when developing software.
Recent figures from the US Census Bureau show that 13.4% of the US population has some sort of disability, and 75% of those adults go online daily.
Globally, the WHO estimates 1.3 billion people experience significant disabilities, about 16% of the world’s population, or one in six of us.
From a business perspective, that’s a billion+ users you’re either including or shutting out. And in 2026, the legal stakes are higher than they’ve ever been: the European Accessibility Act became law across all 27 EU member states on June 28, 2025, and accessibility-related lawsuits against US sites continue to pile up.
So whether you’re approaching this because it’s the right thing to do, because your legal team is sweating, or because you want a wider customer base — this guide walks you through it.
What you’ll find below:
- A curated list of accessibility testing tools that are actually maintained in 2026 (with three I’ve retired since the last update)
- A framework for what to automate vs what to keep manual pulled from five testers I’ve interviewed on the Test Guild Automation Podcast, including a senior accessibility analyst at Salesforce, a quality engineering manager at EasyJet, and a Cypress Ambassador
- The compliance landscape (EAA, ADA, AODA, Section 508) and what testers need to know
The short version: automation catches 20–40% of accessibility issues. The other 60–80% needs humans. WCAG 2.2 AA is the new global benchmark. And the tooling that matters in 2026 is mostly built on axe-core plus screen readers plus paid disabled testers.
Here’s the long version.
Are you ready to automate accessibility testing?
Most articles jump straight to tools.
That’s wrong.
Before you fire up your favorite accessibility scanner, you need to answer a harder question one that Crystal Preston-Watson an Accessibility, Quality Engineer and Researcher, has asked every team that’s come to her wanting to automate.
“There’s a vast difference between wanting to automate and being ready and able to automate accessibility testing. Teams tend to focus on technical readiness, but with accessibility, two significant considerations must be addressed before a framework is selected or code written.” — Crystal Preston-Watson, Test Guild Automation Episode 515
Crystal’s two questions, in plain English:
- Does your team have real experience with accessibility? Not Googled-it experience. Real experience. Can your testers read a WCAG 2.2 success criterion and know how to test against it? Have they ever used VoiceOver, NVDA, or JAWS? Or did your company “fall backward into” accessibility — usually after a customer complaint or a lawsuit threat — and now leadership wants automation as a shortcut to skip the learning curve?
If it’s the second one, you don’t have time to ramp up while also automating. You need to ramp up first.
- Do you have capacity and support outside the testing team? This is Crystal’s hardest line:
“If the company accessibility initiative boils down to testing, it’s a failed initiative — and no automation will make up for that.”
Accessibility has to live in design, in code review, in product requirements, in QA, and in real-user testing. If the only person caring about it is one tester running axe in CI, you’ve already lost.
Read those two questions and feel a little uncomfortable?
Good , that’s the right reaction 🙂 Read on.
Try Our Free WCAG Compliance Scanner
What automation actually catches: the 20–40% rule
This is the single most important fact about accessibility automation, and most listicles bury it:
Automated accessibility testing catches between 20% and 40% of accessibility issues. The other 60–80% requires manual testing, real users, or both.
This number isn’t mine. It comes up independently from two of the testers I trust most on this that I’ve interviewed in the past on my podcast or online events:
- Crystal Preston-Watson: “Most accessibility experts agree that between 20% and 40% of accessibility issues are found with automation testing.” — Episode 515
- Marie Cruz (Senior Developer Advocate at Grafana Labs): “Most of these tools, they only catch between 20% to 40% of issues. Just because your automated tests are passing, this doesn’t mean your website is accessible at all.” – Applitools Front-End Test Fest
So if a vendor tells you their tool will make your site “fully accessible” with zero manual effort, close the tab. The right question isn’t “can I automate this?” — it’s “which 20–40% am I going to automate, and how do I cover the other 60–80%?”
That’s what the next section answers.
Where to automate vs where to keep manual
This is based on what multiple experts have told me over the years:
| Test layer | Automate? | What it’s good for | Recommended tools |
|---|---|---|---|
| Unit tests | Yes — best ROI |
Component behavior, focus APIs, ARIA states | axe-core, jest-axe, sa11y |
| Integration tests | Yes |
Real-browser document/page rules, color contrast | axe-core + Playwright / Cypress / Selenium |
| UI / E2E tests | Sparingly |
Multi-page workflows and form flows only | axe-core inside your existing E2E framework |
| Subjective judgment | No — manual only |
Is alt text meaningful? Does heading order make sense? | Human review |
| Assistive technology | No — manual only |
Screen reader, switch device, voice control flows | VoiceOver, NVDA, JAWS, TalkBack, Guidepup |
| Real-user testing | No — paid UAT |
Actual usability for actual disabled users | Hire and pay disabled testers |
A few things worth highlighting:
UI/E2E tests are the trap. If your E2E suite is already flaky on functional tests, sprinkling axe checks across it just adds noise. Put your accessibility automation deeper in the stack — unit and integration — where the failures are deterministic.
The bottom two layers can’t be skipped. This is where most accessibility programs quietly fail. They ship axe in CI, declare victory, and never put a screen reader user in front of the product. Crystal again:
“Testing with people with disabilities is necessary to understand how your application performs in the real world. Make sure that it’s paid. People’s time is worth money.”
Don’t ask disabled testers to work for free.
Pay them.
Their time finds the bugs your automation never will.
The European Accessibility Act and global compliance for testers in 2026
If you’re a tester working on any product touching the EU, the legal landscape changed on June 28, 2025. The European Accessibility Act is now national law across all 27 EU member states. The deadline for removing inaccessible products from the EU market is June 28, 2030.
Laveena Ramchandani, a Quality Engineering Manager at EasyJet [VERIFY title is current], walked through this in detail on TGA Episode 545:
“The reason I’m giving this talk is not because we want to wait for any legislation to come in place to act for accessibility, but to be aware of what this is about and how we can act before it comes into place. Why are we waiting for a law to come in place to be worried about things?” — Laveena Ramchandani, EasyJet
The major frameworks every tester should have on their radar in 2026:
| Region | Law | What it requires | Status in 2026 |
|---|---|---|---|
| EU (27 states) | European Accessibility Act (EAA) | WCAG 2.2 Level AA for digital products and services | Enforced June 28, 2025. Removal deadline: June 28, 2030 |
| United States | ADA Title III + Section 508 | WCAG 2.x for federal/contractor sites; ADA “places of public accommodation” online | Active. Lawsuits common |
| United States | VPAT | Accessibility documentation for procurement | Required by most US federal/enterprise buyers |
| Canada | Accessible Canada Act + AODA (Ontario) | WCAG 2.0 AA for federally regulated and Ontario orgs | Active |
| United Kingdom | UK Equality Act 2010 | “Reasonable adjustments” for digital services | Active |
I first heard about AODA from Pragati Sharma, who has a Test Guild course on Cypress and Accessibility Testing. She summed it up like this:
AODA Compliance refers to adhering to the Accessibility for Ontarians with Disabilities Act. This mandates that organizations in Ontario, Canada, ensure their environments and services are accessible to individuals with disabilities , including web accessibility. The standards are similar to the WCAG guidelines.
The lawsuits aren’t theoretical
Somya Gupta, a quality expert speaking at Automation Guild 2025, walked through documented cases that should be on every product owner’s whiteboard:
- Netflix (2014) — federal court ordered Netflix to caption its full streaming library. Settled with the National Association of the Deaf with a reported figure around $755,000 in legal fees. [VERIFY exact figure]
- Expedia — ADA lawsuit alleging the website and mobile apps were inaccessible to visually impaired users. Settled, with Expedia agreeing to bring the platform up to WCAG 2.2. [VERIFY year]
- TikTok (2022) — sued by an advocacy group for failing to provide adequate accessibility features for users with hearing impairments.
- eBay (2023) — group of visually impaired users filed suit alleging the site was not fully accessible.
- Cedric Bishop v. Amazon (2018) — a visually impaired customer sued Amazon for inaccessibility.
Somya’s headline state: “82% of the top 500 e-commerce websites have faced legal action regarding their websites lacking accessibility features” needs verification against a primary source before you cite it in a stakeholder pitch. [
What the big brands are doing right
Worth flipping the pessimism. The same companies sued for inaccessibility a decade ago are now setting the standard:
- Apple — VoiceOver and Braille display support across the entire OS
- Microsoft — Xbox Adaptive Controller, accessibility-first design across Windows
- Netflix — full-library closed captioning post-2014 settlement
- Instagram — automatic alt text and image descriptions
- BBC iPlayer — screen-reader-friendly redesign
If you’re trying to convince a stakeholder that accessibility is a competitive advantage, that list is a better deck slide than any compliance threat.
5 Accessibility Testing Myths, Debunked
This section is built on Marie Drake’s misconception teardown.
Each myth is something I hear from teams every week.
Myth 1: “Accessibility testing is too expensive and time-consuming”
Only if you do it at the end. Marie said:
“It’s similar with other development and testing activities — but it’s not expensive if we embed it right in the beginning. Think about accessibility as added revenue instead. The more users we can include, the more revenue.”
Late-stage accessibility fixes mean retrofitting your entire UI. Early-stage accessibility means adding alt text and proper heading order while you’re already writing the markup. The cost difference is roughly 10x same as fixing any bug late vs early.
Myth 2: “Accessibility testing is the tester’s responsibility”
No. It’s everyone’s. Marie cites Regine Gilbert’s Inclusive Design for a Digital World:
“It takes a whole village to make an accessible product.”
Designers handle color contrast and layout. Developers handle semantic HTML and ARIA. Product owners write accessibility acceptance criteria. Gowtham Byregowda at ING Australia put this most concretely on a panel I hosted a few years ago for Applitools:
“We have made accessibility one of the Definition of Done for the user story.”
That’s the org structure that actually works. One sentence in your DoD does more than ten enterprise-tool licenses.
Myth 3: “If our automated accessibility tests pass, we’re accessible”
No. Again according to Marie:
“Just because your automated tests are passing, this doesn’t mean your website is accessible at all.”
Automation passing tells you the easy issues are fixed. It tells you nothing about whether someone using NVDA can actually complete a checkout flow.
Myth 4: “Accessibility testing is too hard to learn”
It’s learnable. Marie’s beginner advice is the best one I’ve heard:
“Start with the basics. Just play around with your keyboard and don’t use your mouse for a day. See how much like issues you can identify.”
That’s it. That’s the entry point.
Myth 5: “We’re WCAG-compliant, so we’re accessible”
Not necessarily. Marie:
“Different people who have different disabilities will always use your product differently. WCAG is a guideline. Use it in conjunction with actual user research and inviting real users to do accessibility testing.”
WCAG 2.2 AA is a floor, not a ceiling. You can ship a site that passes axe with zero violations and still be unusable on a screen reader.
Free Course Accessibility Testing Using Cypress
Top Accessibility Testing Tool List
I’ve organized this list by how you’d actually use them. From free tools you can run on your own keyboard this afternoon, up through enterprise platforms that scan on every build. I’ve also retired three tools that were on the previous version of this guide because they’re no longer maintained or recommended (Protractor, AATT, ChromeVox — see notes below).
Tier 1: Human-assisted tools (free, learn these first)
You don’t need a license for any of this.
- Your keyboard. Tab, Shift+Tab, Enter, Space, arrow keys. If you can’t reach every interactive element this way, your site has accessibility problems
- Browser zoom. Test at 200% and 400% zoom. Watch for elements stacking on top of each other.
- Screen readers (free, built into modern OSes):
+ VoiceOver — macOS and iOS (Cmd+F5 to toggle)
+ NVDA — free, Windows, the most-used screen reader globally
+ JAWS — Windows, paid, common in enterprise
+ TalkBack — built into Android - ChromeVox — Chromebook screen reader (the standalone Chrome extension is no longer maintained, but the OS-bundled version still ships).
- Color Oracle — free color blindness simulator for Windows, Mac, and Linux. Real-time view of what users with common color vision impairments see.
Tier 2: Enterprise accessibility platforms
If your team has the budget and wants a full platform, CI/CD integration, real device clouds, scheduled scans, dashboards, and a centralized way to keep accessibility from drifting between deploys, this is the tier you’re looking at. These aren’t single-page browser extensions; they’re full SaaS platforms that wrap around your existing automation.
1. BrowserStack
BrowserStack is an industry-leading test platform offering manual and automated accessibility testing. Their App Accessibility product covers testing of iOS and Android apps by running scans on app screens/workflows to identify and capture accessibility issues automatically. Enabling a code flag in your SDK config file makes integrating accessibility testing into your builds possible.
With their accessibility automation, teams can monitor DOM with every build run, triggering accessibility scans wherever any changes are detected.
What important to note is the BrowserStack is already built on WCAG principles, their test engine covers ADA, AODA, Section 508, and EN 301 549 compliance.
All test reports are saved in a central repository, which allows for a quick overview of test results and further investigation with smart issue summaries.
2. TestMu AI Accessibility Testing Suite
TestMu AI Accessibility Testing Suite is a platform that lets teams automate WCAG, ADA and Section 508 compliance checks directly within their existing Selenium and Cypress test suites. Instead of running separate accessibility scans, TestMu AI monitors the DOM during every build run and automatically triggers accessibility checks wherever changes are detected, covering 10,000 + real device and browser combinations.
What sets it apart is the full-stack approach: teams get a browser-based DevTools extension for accessibility scans, CI/CD automation for continuous compliance, scheduled scans to prevent accessibility drift between deploys, native mobile app testing for Android and iOS, and real screen reader testing with NVDA, VoiceOver, and TalkBack. An MCP Server integration also enables AI-assisted detection and fixing of accessibility issues directly inside your IDE.
All results flow into a centralized dashboard with severity-based reporting, trend analysis, and actionable fix recommendations.
Tier 3: Single-page browser extensions (run on every page)
These are the workhorses for ad-hoc accessibility checks. Free or freemium, fast, and the right tool when you want to scan one page at a time without setting up a platform.
3. axe DevTools (Deque)
The industry standard browser extension. The axe-core engine powers most other accessibility tools, both free and paid. Free version is enough for most teams; the Pro version adds intelligent guided tests and developer integrations.
4. WAVE Evaluation Tool (WebAIM)
The Wave Evaluation Tool gives you a visual overlay of accessibility issues directly on the page. It’s the easiest tool for non-technical reviewers because it shows problems in context.
5. Lighthouse (Google Chrome)
Bundled with Chrome DevTools. The Accessibility section scores your page and lists violations. Quick to run, but lighter coverage than axe.
6. Accessibility Insights for Web (Microsoft)
Accessibility Insights for Web is a powerful Chrome and Edge extension that empowers developers to identify and resolve accessibility issues efficiently:
- FastPass — quick two-step process for common, high-impact issues in under five minutes
- Assessment — comprehensive evaluation against WCAG 2.1 Level AA
Key features include automated checks against ~50 accessibility requirements, Tab Stops visualization, and step-by-step manual tests with how-to-fix guidance.
7. Web Accessibility Checker (ASP.NET)
This one was mentioned to me by Aparna Gopalakrishnan on the Test Guild Automation Podcast.
The Web Accessibility Checker is probably the easiest way to perform accessibility checks on any ASP.NET Web application. Fully customizable, supports all major international accessibility standards.
8. Color Contrast Analyzer
The Color Contrast Analyzer extension checks for text color contrast problems against WCAG 2 requirements. It evaluates the page as it appears in the browser, so it handles text over gradients and advanced CSS.
Get screenshots, test code & fix ownership in 30 seconds. Built for developers, testers, and QA engineers. Everything a tester needs to turn accessibility scans into real fixes. With comprehensive accessibility testing tools to help you build inclusive web experiences.
Tier 4: Automated CI/CD libraries (the real automation layer)
This is where accessibility testing pays off at scale.
10. axe-core
Open-source library, MIT-licensed. Powers virtually every other accessibility automation tool, free or paid. If you’re building anything in this space, you start here.
11. axe-core-maven-html (Java/JUnit/Selenium/Playwright)
axe-core-maven-html is a robust toolset designed to integrate axe accessibility testing with popular testing frameworks like JUnit, Selenium, and Playwright.
Key features:
- Selenium integration for automated web accessibility testing
- Playwright support for fast, reliable accessibility testing across browsers
- Rules designed to ensure zero false positives, quick execution, and compatibility with modern browsers
12. Axe-WebDriverJs
Axe-WebDriverJs provides JavaScript test automation engineers with a chainable axe API for Selenium’s WebDriverJS, automatically injecting it into all frames.
13. sa11y (Salesforce Automated Accessibility Testing Libraries)
sa11y offers a comprehensive suite for integrating automated accessibility testing into various testing workflows. Built on axe-core, sa11y supports Jest unit tests, WebdriverIO component/integration tests, and more.
Key features:
- Jest integration — provides a toBeAccessible() matcher
- WebdriverIO integration — assertAccessible() and assertAccessibleSync() APIs
- Flexible APIs — check DOM or HTML elements for accessibility issues
- Preset rules — Base, Extended, and Full accessibility preset rules
This is what Crystal Preston-Watson’s team at Salesforce uses internally — and they open-sourced it.
14. Pa11y
Pa11y has a bunch of tools to automate accessibility tests: a CLI, a browser-based dashboard for monitoring multiple sites simultaneously, a web service, and a CI integration. Solid pick if you want a self-hosted accessibility dashboard.
15. Guidepup (the underrated screen-reader automator)
Guidepup is a screen reader driver designed for test automation. It supports VoiceOver on macOS and NVDA on Windows. With Guidepup, you can ensure your applications are accessible by mirroring real user experiences with screen readers.
Key features:
- Full control — if a screen reader has a keyboard command, Guidepup supports it
- User experience — assert on what users actually do and hear when using screen readers
- Framework agnostic — compatible with Jest, Playwright, and runs as an independent script
This is the tool that closes the gap between “axe says we’re fine” and “an actual NVDA user can complete the task.”
Tier 5: Native platform accessibility frameworks
16. UI Automation (Microsoft)
UI Automation is Microsoft’s accessibility framework for Windows applications. Provides programmatic access to UI elements, enables assistive technology products like screen readers, and allows automated test scripts to interact with the UI.
17. Apple Accessibility APIs (iOS / macOS)
If you’re testing iOS apps, Apple’s Accessibility APIs like VoiceOver are available in your scripts. Leveraging these APIs not only makes testing easier — it has the added benefit of improving the user experience.
18. Google’s Accessibility Test Framework for Android
Accessibility Test Framework (GATF) has test logic that detects common Android accessibility issues. Integrates with Espresso via AccessibilityChecks.enable.
Tools I’m retiring from this list
Three tools that were in earlier versions of this guide are no longer recommended for 2026:
- Protractor Accessibility Plugin — Protractor itself was deprecated by the Angular team. Marcy Sutton’s original plugin was excellent for its time, but new projects should use axe-core with Playwright or Cypress instead.
- AATT (PayPal) — repository hasn’t seen meaningful activity in years.
- Accessibility Developer Tools (Google ADT) — superseded by Lighthouse and axe-core.
If your team is still using any of these, plan a migration. Most use axe-core under the hood anyway.
What are some key Metrics used in Accessibility Testing?
Key Metrics used in Accessibility Testing are quantitative measures that assess various aspects of website accessibility.
These metrics play a crucial role in evaluating the level of accessibility, tracking progress, identifying areas for improvement, and ensuring compliance with accessibility standards.
The core ones:
- Error Density — frequency of accessibility errors per page or per 1,000 elements
- WCAG Compliance Level — A, AA, or AAA conformance against WCAG 2.2 success criteria
- Unique Issues — distinct accessibility issues (so you don’t double-count the same missing alt text repeated 200 times)
- User Impact — how accessibility barriers affect users (severity-weighted)
- Keyboard Accessibility Score — ease of navigating with only keyboard
- Screen Reader Compatibility — how well the site works across NVDA, JAWS, VoiceOver, TalkBack
Test Guild Testing Expert Recommended Metrics and Guidelines
Also many experts on my Test Guild Automation podcast have mentioned their view over the years. For example here are a few metrics and guidelines mentioned in some episodes that can help you with accessibility testing:
What are the different Types of Accessibility Testing?
Different types of accessibility testing aim to ensure that web and mobile applications are easily usable by individuals with disabilities such as visual, hearing, mobility, and cognitive impairments. The process involves thorough evaluation of the product against recognized accessibility standards and laws, such as WCAG Compliance, to address any existing accessibility issues.
Various key types of accessibility testing include:
- Color Contrast Testing: This involves assessing the contrast of text against its background to meet specific standards, like the minimum contrast ratio required by WCAG for different types of text sizes.
- Text Alternatives Verification: Verifying the presence of appropriate alternative text or aria-labels for images to aid users who cannot see the visuals.
- Accessible Rich Internet Applications (ARIA) Testing: Ensuring proper application of ARIA roles and attributes on interactive elements like buttons, form controls, and live regions to enhance screen reader compatibility.
- Keyboard Accessibility Testing: Testing the functionality of navigating through a website or application solely using the keyboard, including checking keyboard shortcuts that enable users to interact with links, buttons, and form controls effectively.
By conducting these types of accessibility testing, developers and testers work towards creating a digital environment that is inclusive and free from accessibility barriers, thus ensuring better user experience for individuals with disabilities.
Accessibility Advocate Crystal Preston-Watson breaks down accessibility testing into three main categories:
- Manual Accessibility Testing: This involves testing applications manually for accessibility issues that may cause problems for users with disabilities. It includes using browser and plug-in tools like WAVE, Lighthouse, or aXe, as well as assistive technologies like screen readers and switches.
- Automation Accessibility Testing: This involves using automated tools and frameworks to test for accessibility issues. Some examples include aXe, Applitools Contrast Advisor, and Espresso (for Android).
- User/Usability Testing: This involves testing with people with disabilities to understand how the application or site performs in the real world and to find issues beyond just accessibility conformance.
Who should be involved in Accessibility Testing?
Thats easy – everyone on the team!
But seriously based on the insights provided by the experts I’ve spoken with, it’s clear that accessibility testing should involve a diverse group of people to ensure a comprehensive and inclusive approach. Here’s who should be involved in accessibility testing:
1. Quality Assurance (QA) Teams: QA professionals, play a vital role in ensuring accessibility standards are met. They are responsible for creating test plans, executing tests, and reporting issues.
2. Accessibility Specialists: Experts who have deep knowledge of accessibility guidelines and best practices, should be involved to provide guidance and support throughout the testing process.
3. Designers and User Experience (UX) Professionals: As Shweta Sharma points out, accessibility should be considered from the early stages of design. Designers and UX professionals should work closely with accessibility specialists to create inclusive designs that meet accessibility standards.
4. Developers: Developers play a crucial role in implementing accessible code and fixing identified issues. They should be knowledgeable about accessibility guidelines and work closely with QA and accessibility specialists.
5. Product Managers: Product managers are responsible for ensuring that accessibility is prioritized and included in the product roadmap. They should work with the team to balance accessibility requirements with other product goals.
6. Users with Disabilities: As emphasized by Crystal Preston-Watson involving users with disabilities in the testing process is essential. They can provide valuable insights and feedback on the real-world usability of the website or application.
7. Stakeholders: All experts mentioned the importance of educating stakeholders about the importance of accessibility. Stakeholders, such as business owners and executives, should be involved in the process to ensure that accessibility is given the necessary resources and priority.
8. Legal and Compliance Teams: Given the legal implications of accessibility, it’s important to involve legal and compliance teams to ensure that the website or application meets all relevant regulations and standards.
Accessibility testing should involve a collaborative effort from QA teams, accessibility specialists, designers, developers, product managers, users with disabilities, stakeholders, and legal and compliance teams. By involving this diverse group of people, organizations can ensure that their digital products are accessible, inclusive, and compliant with relevant standards and regulations.
Your Top Accessibility Testing Tools
Accessibility testing is an essential part of creating an effective, accessible website. While you automate accessibility testing with tools, you save time and money, as well as improve testing accuracy and reliability.
Do not let a lack of resources stand in your way any longer. Let me know if I missed one of your favorite accessibility test automation tools, and I will add it to the list.