NEW: AI Readiness Starts with an Accessible Website
Read the studyAutomated Accessibility Testing Tools: What They Catch and What They Miss
Automated accessibility testing tools reliably catch code-level barriers across every page of a site, but they cannot evaluate the criteria that depend on human judgment. Below, you'll learn what automation reliably detects, what it structurally can't, how free scanners, developer tools, and platforms compare, and what to ask before you buy.
Author: Jeff Curtis, Sr. Content Manager
Published: 09/14/2026
)
Every automated accessibility testing tool will find issues on your site. The harder question is what they don’t find.
That answer varies more than you’d expect. Independent testing found that tools scanning the same pages returned dramatically different results, with some reporting nothing at the Web Content Accessibility Guidelines (WCAG) levels most closely tied to legal risk.
The first thing to understand is that tools differ widely in what they catch. The second is that all of them stop at the same place: no scanner can evaluate whether your site actually works for someone using it. Below, we’ll cover what automation reliably catches, what it structurally cannot, how the different categories compare, and what actually to evaluate when you choose one.
What is Automated Accessibility Testing?
Automated accessibility testing is software that crawls a website’s code and content to detect barriers that violate accessibility standards, such as WCAG 2.2 Level AA, without requiring a human to review each page.
The tool loads your pages, evaluates the rendered code against a ruleset, and returns a report of what failed and where. Some tools stop there. Others apply fixes, monitor for new issues, or integrate into your build pipeline so problems surface before they reach production.
What Automated Accessibility Testing Detects
Automated accessibility testing reliably detects code-level, machine-checkable issues, which together account for a large share of the accessibility barriers on a typical site.
Specifically, automated tools catch:
Missing or empty alt attributes. An image without alt text gives screen readers nothing to announce, leaving users unable to understand or interact with it.
Color contrast ratios below WCAG 2.2 Level AA thresholds. Automated tools can identify whether a page falls below the 4.5:1 color contrast ratio, which can make text unreadable for users with low vision.
Form inputs without programmatic labels. The user hears “edit text,” but has no indication of what to type.
Empty links and buttons. A control with no accessible name is announced simply as ‘link’ or ‘button’, so the user knows something is there but has no way to tell what it does before activating it.
Missing page language detection. Without a declared language, screen readers fall back to their default pronunciation rules, which can render an entire page as unintelligible phonetic noise to the listener.
Missing or out-of-order heading structure. Many screen reader users navigate by jumping between headings, so a page with skipped levels or no headings at all forces them to read through everything linearly to find what they need.
Missing table headers. Without header associations, a screen reader announces each cell as a bare value, so the user hears “482” with no indication of which row or column it belongs to.
Duplicate IDs. When two elements share an ID, assistive technology can associate the wrong label with the wrong control, leading the user to believe they are filling one field when they are actually in another.
Each of these is a real barrier, and finding them at scale is genuinely valuable. They are also the issues software can verify without judgment, which is precisely why automation handles them well.
)
What Automated Accessibility Testing Misses
Automated accessibility testing cannot evaluate issues that require human judgment. Things like whether alt text is meaningful, whether focus order is logical, whether an error message is understandable, or whether a component works well with a screen reader. Each of these issues requires a human to interact with the page rather than inspect the code.
Four examples of what pass an automated check but still block a user:
Alt text that exists but says nothing. A product photo with alt=”image1.jpg” will typically pass every automated scan since the attribute is present and non-empty. A screen reader user, on the other hand, learns nothing about the product they’re considering buying.
Focus order that is technically valid but illogical. Every element is reachable via keyboard, so the automation reports no errors. In practice, the user tabs from the site header directly into the footer, back up to the middle of the page, and then into a modal that opened three tabs ago.
Error messages that are announced but incomprehensible. A form field correctly associates its error via ARIA. But an error that reads “invalid input” is unhelpful to the user. They know something is wrong, but have no idea what.
Components with correct ARIA that behave unpredictably. A custom dropdown exposes the right roles and states. Tested with an actual screen reader, it announces options twice, traps focus, or closes without confirming the selection.
What is the Difference Between Manual and Automated Testing?
Automated accessibility testing checks code against machine-verifiable rules at scale, while manual expert testing uses trained testers and assistive technology to verify that the experience actually works for people with disabilities.
The four failures above share a trait: each involves a question software cannot ask. Does this make sense to a person? Alt text either describes the image usefully, or it doesn’t. Focus order either follows the visual flow or jumps. An error message either tells the user what to fix, or it doesn’t. None of those can be resolved by inspecting code, because the code is already valid in every case.
That’s the division of labor. Automation runs across thousands of pages consistently and catches regressions the moment they appear. Manual expert testing covers the criteria that require judgment, verifying that the experience works rather than assuming it does because the code validates.
That distinction has direct consequences under the Americans with Disabilities Act (ADA). A significant share of WCAG success criteria cannot be evaluated by software, which means automated testing alone does not establish conformance.
The bottom line: if your accessibility program is entirely automated, the criteria it skips are invisible to you, which drastically increases your legal risk.
The Three Types of Automated Accessibility Testing Tools
Automated accessibility tools fall into three categories: free scanners that report issues on a page, developer workflow tools that test accessibility inside the build pipeline, and digital accessibility platforms that combine continuous automated testing with expert testing and fixes.
Free Scanners
Free scanners check a single page on demand and return a list of detected issues. They are the fastest way to find out whether you have a problem, and they do not monitor, fix, or cover judgment-dependent criteria. Common options include:
WAVE(opens in a new tab) (Web Accessibility Evaluation Tool)
Deque(opens in a new tab), Siteimprove(opens in a new tab), and accessiBe(opens in a new tab) each offer a free tier.
Developer Workflow Tools
Developer workflow tools run accessibility tests in your build pipeline, catching issues before they reach production and failing builds when new violations are detected. They fit teams with engineering capacity to act on findings immediately. Tools in this category include:
Digital Accessibility Platforms
Platforms combine continuous automated scanning across your site with fixes and, in most cases, manual expert testing. They fit organizations that need coverage maintained over time rather than a point-in-time report. This category includes:
How the Categories Compare
One thing worth distinguishing. Fix model distinguishes between tools that report issues, tools that suggest code fixes for your team to apply, and tools that apply fixes themselves, either at the source or at render time for each visitor session.
How to Evaluate an Automated Accessibility Testing Tool
The decisive criteria for an automated accessibility tool are detection depth, whether it fixes issues or only reports them, whether it monitors continuously or scans on demand, and whether it pairs automation with expert testing.
Five questions worth asking any vendor:
How deep is detection? Every tool claims WCAG coverage and ADA compliance, but it’s worth asking how deep that detection goes. A lower issue count, for example, can mean a cleaner site or a weaker scanner, and you can’t tell from the report alone.
Does it fix, or only report? A report is a list of work, meaning someone still has to do the work. It’s worth asking who.
Does it monitor continuously or scan on demand? Every content update, template change, and third-party script can introduce new barriers between scans. It’s worth asking how often monitoring occurs and how the platform keeps you accessible between audits.
Does it include expert testing? If not, the judgment-dependent criteria go uncovered, regardless of how good the automation is. This can also increase your legal risk.
What happens after an issue is found? This is where tools diverge most, and where evaluations usually stop too early.
)
Covering What Automation Misses: Where AudioEye Fits
The tools on this page differ in how much they can detect, but none of them can tell you whether your site works for the person using it. That limit isn't a gap in the current generation of scanners. It's structural, and no amount of improvement to automated rules will close it, because the questions that remain concern meaning and experience rather than code.
Which is why the choice was never really scanner versus scanner. Automation makes accessibility tractable at scale, catching regressions within hours instead of at the next audit. Expert testing makes it real, verifying with assistive technology that the experience holds together. Alone, the first gives you speed with blind spots, and the second gives you accuracy that goes stale on delivery. You need both, connected, so what the experts find informs what the automation watches for.
That’s the approach AudioEye is built around. AudioEye pairs continuous monitoring with Automatic Fixes, so issues are resolved rather than added to a backlog. For criteria that automation can’t detect, Expert Audits are performed by certified accessibility testers, including people with disabilities who regularly use assistive technology.
Independent testing by Adience, commissioned by AudioEye and conducted independently, found that AudioEye's automated detection surfaced 89–253% more WCAG issues than the other tools evaluated. AudioEye was also the only tool to detect valid issues across all six test sites at WCAG Levels A, AA, and AAA.
Detection is where it starts, not where it ends. A free scan will tell you what automation can see on your site. What you do with the rest is the real decision.
Frequently Asked Questions
Share Article
)
)
)