What a Free Accessibility Scan Cannot See

We built a free scanner and we are the first to tell you where it stops. Automated checks can fully verify only a minority of WCAG's requirements, and that is not a weakness in ours. Every scanner has the same ceiling, including the expensive ones, because most of the standard asks whether meaning arrived and no machine has an opinion about that.

What Our Scan Actually Runs

Vagueness is easy here, so here are the numbers. The scan drives a real browser across up to 10 pages and runs all 90 supported automated rules in the installed engine. Of those, 63 are WCAG-mapped and 27 are additional best-practice checks, which the report keeps separate. The WCAG-mapped checks touch 20 of the 55 Level A and AA success criteria, leaving 35 untouched by the scan entirely, and touching one is not the same as clearing it. It looks at one state of each page, at one screen width, after the page has loaded and settled.

That last sentence is the important one, and it is the honest line between free and paid. The scan never signs in, never submits a form, never opens a dialog, never triggers an error, never waits for a session to expire and never narrows the window. So account pages, checkout past the first step, every closed menu, every modal, every form in its error state and everything at a phone-sized width are outside what it has seen, rather than things it checked and approved.

What a Machine Can Genuinely Prove

Machines are very good at facts that sit in your code. An image with no alt attribute. Text measured at 2.8 to 1 where the rule wants 4.5 to 1. A page with no declared language. An ARIA attribute pointing at an element ID that does not exist. All of those are real failures, all of them are worth fixing, and a scanner finds them in seconds and never gets tired.

What It Cannot Detect

• Whether alt text is accurate. The text alt="image" passes every automated check ever written and fails every human being who relies on it.
• Whether a form field has a real label. A field labeled only by a placeholder passes the label check and breaks a different rule entirely, which is the next section, because it is the clearest example on this page.
• Whether keyboard focus gets trapped in your cookie banner. The scanner never presses the Tab key.
• Whether checkout can be completed on screen reader audio alone. That takes an actual screen reader user actually buying something.
• Whether your error messages help. Invalid input is valid HTML and useless English.
• Whether the page makes sense read aloud from top to bottom with none of the layout to explain it.

One Broken Field, Traced From the Spec to the Report

Take the commonest form failure on the web, an email field whose only labeling is gray placeholder text that vanishes the moment somebody types. Our scan passes it. So does axe DevTools, so does Lighthouse, and every one of them is behaving correctly. Here is the whole chain, because it is the clearest illustration of the gap this post is about. Once you have seen it, you stop reading a clean report as an all-clear.

It starts in the specification that tells browsers how to work out what a control is called. That spec sets an order to try. A label written into the ARIA attributes wins, then a real label element, then the tooltip text, and if none of those exist, the placeholder. So a field with nothing but a placeholder genuinely has an accessible name, and the name is whatever the placeholder says. The browser is right, the accessibility tree is right, and the field satisfies the naming rule outright.

The engine underneath our scan implements that order faithfully, which means its label rule reports a pass. A second rule in the same engine would flag a field labeled only by a placeholder. It is switched off in every WCAG-filtered run, ours included, because the vendor tags it as best practice rather than as a conformance check. So the one rule that would catch this never executes. That is a choice about which rules count as conformance rules, not an oversight.

What the field actually breaks is a different rule, 3.3.2 Labels or Instructions, because a label that disappears while you are using the control is not presented to everybody. W3C draws that distinction itself, in as many words. Content can pass the naming rule on an accessible name and still fail this one, when the label reaches assistive technology and not everybody else. And that criterion has no automated test rule anywhere in the published set. Nothing exists for a scanner to run.

The last link is the one that catches careful teams. A person testing by ear does not catch it either, because the screen reader announces the placeholder and the field sounds fine. Nobody hears silence. You find it by typing into the box and noticing that the only thing telling you what the box was for has just gone.

How to Read Any Scan Report Honestly

Three habits, and they apply to our report as much as anybody's. First, nothing found means nothing found in the machine-checkable part of the standard, on the pages and the state it looked at. It never means your site is accessible. Even a pass has limits the standards body writes down. On most published test rules, a pass is formally recorded as meaning the criterion needs further testing rather than that it is satisfied.

Second, watch for count inflation. One missing alt attribute on a reused template component is one defect in your code and dozens of findings in the report. In WebAIM's 2026 survey of a million home pages, low contrast text averaged 34 separate instances on a single page, and nearly all of those trace back to one decision about a color. A report saying 400 errors may be describing a dozen real problems.

Third, expect false positives, and expect the number to move depending on what anyone is counting. Tool vendors quote much higher coverage figures than ours, and they are counting defect instances while we are counting criteria. Both numbers are true about different denominators, and the denominator is the part the marketing leaves out. Our scanners versus humans page breaks all 432 of WCAG's techniques and documented failures down by what machines can and cannot verify.