What an accessibility checker can and cannot prove

An accessibility checker can prove a negative. This button had no name on 14 September. This contrast ratio sat under 4.5:1. That later scan still failed the same rule.

It cannot prove a positive: that every person can complete every task. Overlay ads spent a decade selling the positive. That is the category error.

An accessibility checker is software that loads a live page and flags Web Content Accessibility Guidelines (WCAG) failures a machine can detect. It is a snapshot of testable issues, not a certificate that the site meets the ADA, the European Accessibility Act, or WCAG 2.2 A/AA.

I tested this the way the product actually runs: load a URL in Playwright, run axe-core, read the rule IDs. The report is useful because it is narrow. Selectors. A date. The minute someone treats that PDF as “the site is accessible,” the evidence turns into theater.

What a checker can prove

On the pages it actually crawled, on the date it ran, with the engine it names (Complience.app uses axe-core inside Playwright), a checker can show:

• Rule IDs that failed, with severity, a selector, and often an HTML snippet
• Category scores for accessibility, cookies, and headers when those scans run together
• Whether the same rule still fails on a later scheduled run

That is useful evidence for a developer or an agency retainer. It is not a courtroom-ready proof that every user can complete every task.

The WebAIM Million is the public version of this job. In February 2026, WAVE-style automation found detectable WCAG 2 failures on 95.9% of the top 1,000,000 home pages. That number is what a checker is good at: machine-visible failures at scale. WebAIM’s own caveat is the part generic “ADA checker” pages bury. Because only automatically detectable failures were counted, full WCAG 2 A/AA conformance was “certainly lower than 4.1%.”

In practice, a clean automated score is rare. A clean automated score is still not a pass.

What it cannot prove

Automated tools miss meaning, order, and real assistive-technology use. They cannot swear that alt text is accurate, that a custom widget is usable, or that a checkout works with a screen reader. They also cannot scan pages behind a login unless you give the worker those credentials. Complience.app’s public checker does not.

They cannot prove legal compliance. WCAG is a technical standard. ADA and EAA obligations depend on facts, jurisdiction, and how a person with a disability actually uses the site.

The W3C’s Understanding Conformance page is the source most product pages never link. Conformance is about the content as a whole. Automated checking is a method, not a verdict. If a vendor’s H1 says “make any website compliant,” they are selling a claim the standard itself refuses.

Low-contrast text still shows up on 83.9% of those million home pages. A checker will flag many of those. It will not tell you whether the remaining contrast is readable for the person who has to use the site.

How to use a report without overclaiming

Send the PDF as “issues found on this crawl,” not “this site is compliant.” Pair it with a keyboard pass on the money paths. If you need a monitor rather than a one-off, schedule the same check and watch for score drops.

Seyfarth counted 3,117 federal website accessibility lawsuits in 2025 (ADA Title III report). A high automated score does not appear in that count as a defense. A dated list of what you found and fixed can at least show you were looking.

What actually works is boring language. URL. Date. Engine. Failed rule IDs. Next steps. Save the word “compliant” for counsel.

For a live URL, run a free accessibility check. For the money-page method, see the website accessibility checker. If the query was ADA, use the ADA compliance checker instead of this article.

Security headers and the policy text are separate slices of the same report. See what security headers a scan can see and what a privacy policy check can prove.