Skip to content
wcagc
←Back to blog
WCAGoverlayscannerEAA

The best WCAG scanner that isn't an overlay

A WCAG scanner finds issues in your code; an overlay hides them. Here's the difference, why overlays draw lawsuits, and what to look for.

P

Pavel Charkasau

If you want the best WCAG scanner that isn't an overlay, the short version is this: choose a tool that reads your source and reports the specific issues it finds, and avoid any widget that promises to "fix" accessibility with one line of JavaScript. Those are two different products wearing similar marketing. A WCAG scanner tests your pages against the Web Content Accessibility Guidelines and hands you a list of problems to correct in the code. An accessibility overlay injects a script that repaints the page in the browser and claims to make it compliant on its own. The first gives you real, fixable information you own. The second has drawn a wave of lawsuits and a $1 million order from the US Federal Trade Commission for over-promising (FTC). This guide covers the difference, what an honest scanner should and shouldn't claim, the features that actually matter, and why no scanner alone confirms conformance.

What is a WCAG scanner, and how is it different from an overlay?

A WCAG scanner is a testing tool. It loads your pages, checks the rendered HTML, CSS, and ARIA against WCAG success criteria, and returns a report: this image has no alt text, this control has no accessible name, this text fails contrast. The output is a to-do list for your developers. Nothing about your live site changes until someone fixes the underlying code.

An overlay is the opposite in intent. It is a third-party script you paste into your site that runs in every visitor's browser and tries to patch problems on the fly, while adding a toolbar for font size and contrast. The pitch is that one line of code buys compliance. That pitch is the problem. Accessibility lives in your source code, not in a layer painted over it after the page loads. A scanner tells you what to fix and leaves the fix in your hands. An overlay tries to do the fixing itself, at runtime, without touching your code, and that is exactly where it falls down.

So when the search is for a "WCAG scanner, not an overlay", the distinction is not cosmetic. One is a measurement tool. The other is an automated patch that the accessibility community, and now a federal regulator, has judged not to work as sold.

Why do accessibility overlays draw lawsuits?

Because they do not fix the underlying barriers, and courts and regulators have noticed. Three facts are worth knowing.

First, the accessibility profession has said plainly that overlays do not work. The Overlay Fact Sheet, signed by more than 800 accessibility practitioners, researchers, and advocates, states that overlays "are not an effective means of ensuring accessibility." Signatories include contributors to the WCAG, ARIA, and HTML specifications. This is not a vendor squabble; it is a broad professional consensus.

Second, overlays attract legal claims rather than deflecting them. In UsableNet's tracking, roughly 25% of the 2024 US digital accessibility lawsuits, over 1,000 cases, were filed against sites that had an accessibility widget installed (Accessibility.Works, on UsableNet data). The widget did not prevent the suit; in many complaints it was named as a barrier.

Third, the FTC acted. In its final order approved on 22 April 2025, the FTC required the overlay vendor accessiBe to pay $1 million and barred it from claiming its automated product can make any website WCAG- or ADA-compliant unless it has evidence to support the claim (FTC). The agency found the "compliant" representations false, misleading, or unsubstantiated. If a marketing promise earns a regulator's $1 million order, it is not a compliance strategy.

What can an automated WCAG scanner actually catch?

Less than the whole picture, and an honest scanner says so. Automated testing is good at the machine-checkable criteria: missing alt attributes, empty links and buttons, form fields with no label, low colour contrast, missing page language, some ARIA misuse. It is fast, repeatable, and worth running on every deploy.

But it cannot judge meaning. Whether alt text is accurate, whether the reading and focus order make sense, whether a keyboard user can actually complete a checkout, whether an error message is understandable, all of that needs a person. Deque's analysis of more than 2,000 audits found automation identified about 57% of issues by volume, while estimates based on the share of success criteria a scanner can even evaluate put the figure closer to 30% (Deque). The W3C is just as direct: evaluation tools "can not determine accessibility, they can only assist in doing so," and human judgment is required to know whether a site meets the standard (W3C WAI).

That is the honest frame for any scanner, including ours. It finds the machine-detectable issues and helps you fix them; the rest needs manual review with a keyboard and a screen reader. A tool that claims to deliver full conformance by itself is repeating the overlay mistake with different words.

What should the best WCAG scanner (that isn't an overlay) do?

Judge a scanner by what it reports and what it refuses to promise, not by how few lines of code it takes to install. A few things separate a useful code-first scanner from a repackaged overlay:

  • It reports issues; it does not "auto-fix" your live site. The output is a list mapped to WCAG success criteria, with the element, the location, and what to change. Your team fixes it in the source, where the fix is permanent and visible to every assistive technology.
  • It is honest about coverage. It tells you which criteria it can test automatically and which need manual review, instead of implying a green score equals conformance.
  • It maps to the standard you are held to. For the EU, that is EN 301 549, which incorporates WCAG 2.1 Level AA for the web. A scan that ties findings to specific clauses is far more useful than a generic score.
  • It supports the paperwork. Under the EAA, service providers must publish an accessibility statement that documents their level of conformance, known limitations, and a contact for feedback. EN 301 549 Annex C is the natural template for recording each requirement as met, partially met, or not met. A scanner that helps you draft that statement from real results does something an overlay never can.
  • It runs continuously. Accessibility regresses every time you ship. A scanner you can re-run on each release, and use with our WCAG checklist for the manual criteria, keeps you honest over time.

Notice what is missing from that list: a widget, a toolbar, and any promise of instant compliance. That absence is the point.

Does a scanner make my site EAA compliant?

No single tool does, and you should be wary of one that says otherwise. A scanner measures your site against WCAG 2.1 AA, which is the web bar EN 301 549 sets and the EAA relies on for its presumption of conformity (EUR-Lex, Directive (EU) 2019/882). Fixing what the scanner finds is real progress. But full EAA conformance also needs the manual testing a scanner cannot do, and the documentation the law requires, including an accessibility statement. Our statement generator turns your findings into an honest draft rather than a guess.

The reliable route is unglamorous and it works: scan to find the machine-detectable issues, fix them in code, review the rest by hand, and document where you stand. That is the honest alternative to a one-line overlay, and it is what a scanner is for.

Frequently asked questions

Is an accessibility overlay a WCAG scanner?

No. An overlay is a runtime script that tries to alter your page in the browser and adds a user toolbar. A WCAG scanner is a testing tool that reports issues in your code for your team to fix. They serve opposite purposes, and the accessibility profession, through the Overlay Fact Sheet, rejects overlays as a compliance method.

Can a scanner find every WCAG issue?

No. Automated tools catch roughly 30 to 57% of issues, depending on how you count (Deque). The rest, including reading order, keyboard flows, and whether alt text is accurate, needs manual review by a person. The W3C says the same: tools assist, they do not determine accessibility.

Why did the FTC fine an overlay company?

The FTC found that accessiBe misrepresented that its automated product could make any website WCAG-compliant, and in April 2025 it approved a final order requiring $1 million and barring unsubstantiated compliance claims (FTC).

Will a scanner make my site EAA compliant on its own?

No. It measures your site against WCAG 2.1 AA, which is most of the web-facing work, but EAA conformance also needs manual testing and documentation such as an accessibility statement. A scanner supports that work; it does not replace it.

Is a code-first scanner better than an overlay for lawsuit risk?

Fixing issues in your source removes the barrier itself, which is what claims are about. Overlays leave the underlying issues in place, and in 2024 about a quarter of US lawsuits targeted sites that had one installed (Accessibility.Works, on UsableNet data). No tool eliminates legal risk, but real fixes address the cause.

Scan your site, then fix the code

If you want a scanner that reports issues instead of hiding them, start with a measurement. Run a free scan to surface the machine-detectable problems on your key pages, mapped to WCAG. Fix them in your source, work through the manual checks a scanner cannot judge, and you will have a real baseline and the evidence to write an honest accessibility statement, without a widget in sight.

Pavel Charkasau, founder, wcagc.com. Last updated 3 July 2026.

Sources