We sell audits and give scans away, so read this knowing that. What follows is the honest split, because sending somebody to buy an audit they do not need is a bad way to run a business.
| Free scan | Full audit | |
|---|---|---|
| Checks | 90 supported rules: 63 WCAG-mapped and 27 best-practice | All 55 WCAG 2.2 A and AA rules, reviewed by a person |
| Coverage | 10 pages, one desktop width, public URLs only | Your key templates and journeys, at desktop widths |
| Who tests | A browser, automatically | A scanner, an expert, and a blind screen-reader user |
| Finds | Missing attributes, contrast, ARIA validity, page language | The above, plus everything needing judgment |
| Answers "do we meet AA?" | No | For the pages in scope, yes |
| Evidence | The failing elements, plus what it could not decide | Screenshots, dated, per finding |
| Time | Minutes | From 5 business days |
| Cost | Free | From $499 |
That last column covers two tiers rather than one, and the pricing page is where they separate: how many pages, how long, how many screen reader pairings run, and what gets written down against each of the 55 rules. Both include the expert pass and the blind screen-reader session. Both are evaluated at desktop widths, which is a limit buying an audit does not remove, and our mobile guide sets out what that leaves unchecked.
What the Scan Genuinely Finds
Real failures affecting real people, and finding them cheaply is worth doing. Missing alt attributes, unlabelled form fields, insufficient contrast, invalid ARIA, empty links and buttons, missing page language. Fix those and your site is measurably better than it was this morning.
It runs your pages in a real browser rather than parsing source, so it sees what actually rendered, including everything added by JavaScript after load. Two limits go with that. It only looks at public URLs, because the guard in front of it rejects private addresses, non-standard ports and anything behind credentials, so your staging environment is out of reach. And it renders every page at one desktop width, 1366 pixels, while conformance asks every responsive variation of a page to pass on its own.
Under the hood, the scan runs all 90 supported automated rules in the installed engine: 63 WCAG-mapped checks and 27 additional best-practice checks that the report labels separately. The WCAG-mapped checks touch 20 of the 55 criteria at Level A and AA. That sounds like a fair slice of the standard and it is not, because touching is not settling. On the naming criterion the rules check that a name exists, never that it is right. On labels and instructions it runs a single rule about a duplicate-label edge case and nothing about whether an instruction exists anywhere. The accurate sentence is that the scan can raise a flag against 20 criteria and can clear almost none of them.
One more piece of honesty about the engine. The 27 additional best-practice checks can find real problems, but the report does not present them as WCAG failures. That distinction, along with each tool choosing a different rule set, is why two scanners can run over the same page and produce different reports.
What It Structurally Cannot Find
Start with our own count of the standard, since it is the number this whole page turns on. W3C's technique library holds 432 entries, made up of 342 techniques and 90 documented failures. We graded 356 of them, and the rest serve only rules an audit does not test. Of the 356, 10 are fully machine-detectable, which is 2.8%. Another 228 are partly detectable, meaning a tool can find a candidate and a person has to decide. And 118 need a human from start to finish. That split is our measurement rather than W3C's, which publishes no figure of the kind. It runs far below the coverage numbers quoted around the web, and it makes the point better.
So the scan cannot settle any of these:
- Whether your alt text is true, as opposed to present.
- Whether your link text means anything out of context.
- Whether focus order matches reading order. W3C publishes no automated rule for this at all.
- Whether an error message tells the user what to do. No rule for this one either.
- Whether your checkout can be completed by ear.
- Whether a heading marked as a heading is one.
Those six divide two ways in the report, and the difference is worth a minute. On the first two a rule genuinely runs. Something checks that an alt attribute exists, and that a link has a name, finds one, and files the element under checks passed. On the other four, nothing runs that asks the question at all. Focus order and error suggestion have no automated rule anywhere in W3C's set, and the check that would spot a pull quote styled as a heading is tagged experimental and never executes. So nothing passes, nothing fails, and no line appears.
The second kind is the more dangerous one. A passing line is at least a claim you can go and argue with. An absent line looks exactly like a clean report, and that is the mechanism by which a green dashboard and a complaint coexist on the same website. Where automated testing stops takes that apart rule by rule.
Why a Passing Automated Rule Is not a Passing Criterion
This is the part worth understanding properly, because it is the difference between a report you can act on and a report you can hand a regulator.
W3C maintains a set of automated test rules for WCAG, and each one publishes what a pass actually means. On 59 of the 87 live rules, passing is recorded as "success criterion needs further testing". Only four rules in the entire set clear a criterion outright. That is the standards body's own structured metadata saying, rule by rule, that passing its automated tests is not the same as conforming.
The coverage gaps are just as stark. Of the 86 criteria in WCAG 2.2, 49 have no automated rule written against them at all, and 24 of the 55 at A and AA have none. The guideline covering seizures and physical reactions has zero coverage across every one of its criteria, which means a scanner returns clean on the one guideline whose failure is a medical event.
And where the rules are thickest they still measure the wrong thing. Name, Role, Value carries fifteen rules, more than any other criterion, and of the ten that name it, seven test whether a name exists rather than whether it describes the control. A button whose accessible name is the literal word button passes all seven. The whole chain is on 4.1.2 Name, Role, Value.
None of that is a complaint about the rules. They are precise about what they test and honest about what they leave open, which is exactly why they are quotable. It is a complaint about reading a clean automated report as an answer to a question it never claimed to answer.
Why your scanner and our auditor disagree about the same field
Take an email input whose only labelling is placeholder text. The specification that computes accessible names treats a placeholder as a valid fallback, so the field genuinely has a name and satisfies the naming criterion. Our scan reports it as a pass, correctly. What it fails is Labels or Instructions, because a label that vanishes the moment you type is not presented to everybody, and that criterion has no automated rule anywhere in the W3C set. So the scan is right, the auditor is right, and the field is still broken. That is the commonest reason two reports on one page disagree, and it is traceable from the spec to the engine to the line in the report.
A Scanner Export and an Audit Report, Field by Field
The difference that matters between the two documents is not length, or price, or how many findings each one carries. It is what a silence means in each of them.
| Scanner export | Audit report | |
|---|---|---|
| One row is | A rule outcome against an element | A finding against a criterion, on a named page |
| What produced it | A rules engine at a version, run at one width | A person, on a date, with a named browser and screen reader |
| Severity means | The engine's own impact label, assigned per check rather than per rule | What it does to somebody trying to finish the task |
| A silence means | The rule never ran, and nothing on the page distinguishes that from a clean result | A person examined that rule and raised nothing |
| The fix reads | The rule's generic description | The element on your page, and what to change about it |
| A table of all 55 | Not available, since 35 of the 55 are never touched | Set out per tier on the pricing page |
| It cannot settle | Anything turning on judgment, which is most of the standard | Pages nobody opened, or a build that shipped afterwards |
Read the silence row twice, because it carries the whole comparison. An export is a list of what an engine found. Everything it did not find is simply not in the document, and nothing on the page in front of you separates a site that is clean from a site nothing looked at. A report is a record of what somebody examined, so an empty result there is evidence rather than the absence of it.
Which is why an export cannot be handed to a procurement team, a regulator or a customer asking whether you conform. Not because it is wrong. It is accurate about everything it says. It is a different kind of document, and the question they are asking lives in the part it does not contain.
None of that is a reason to skip it. Run the scan, fix what it hands you, and let the paid work start on the harder half. It just is not the artifact that answers the question somebody is putting to you.
Which One You Need
Start with the scan, always. It is free, it takes minutes, and it tells you whether you have obvious problems. Nobody should buy an audit without running it first. The odds are good that it finds something, since WebAIM's survey of a million home pages detected WCAG failures on 95.9% of them, averaging 56 per page.
Then buy the audit if any of these are true:
- A client, regulator or contract has asked whether you meet a standard. Conformance has to be met in full at a level, with no partial credit anywhere in the normative text, so a per-rule answer is the only kind that answers the question.
- You need a VPAT or ACR for procurement, which is a per-criterion document and cannot be filled in from a scan.
- You have had a complaint.
- Your site has a transactional flow. Every page in a process has to conform for any of it to conform, and W3C's own worked example of a process is a shop checkout.
- You have fixed the scan findings and want to know what is left, which is most of it, on the standards body's own reckoning.
You probably do not need one yet if you are a small brochure site, the scan came back with plenty to fix, and nobody is asking you for evidence. Fix those first and re-scan. The audit is worth more once the obvious work is done, because more of the report is then about things only a person could have found.
One honest limit
Our scan has the same ceiling as every other automated tool, and we say so on its own page. WebAIM says the same thing about WAVE in its own documentation, that the absence of errors does not mean a page is accessible and only a human can determine that. A tool that oversells itself is precisely what our whole practice argues against, so it would be a strange place to start bending.