WCAG Compliance Checker: Which of the 87 Criteria a Machine Can Test
TABLE OF CONTENTS
- What does a WCAG compliance checker actually check?
- Which WCAG 2.2 criteria can an automated checker test?
- Why doesn't 60β70% coverage mean most criteria?
- Which WCAG 2.2 criteria are new, and can machines catch them?
- How do you run a real WCAG check?
- What does a WCAG conformance claim actually require?
- When do you need a formal audit or an ACR instead?
- Frequently Asked Questions
Last updated: September 14, 2026
A WCAG compliance checker tests your pages against the success criteria in the Web Content Accessibility Guidelines β but no checker tests all of them. WCAG 2.2 numbers 87 success criteria, one of which is obsolete, leaving 86 in force and 55 at Levels A and AA. In TestParty's classification, automated tools decide 9 of those 55 outright. This guide maps every one of the rest.
Key numbers: WCAG 2.2 numbers 87 success criteria; 4.1.1 Parsing is obsolete and removed, leaving 86 in force β 31 at Level A, 24 at AA, 31 at AAA (W3C). Of the 55 criteria at Levels A and AA, TestParty classifies 9 as reliably automated, 22 as partially automated, and 24 as human-judgment-only. Automated detection covers 60β70% of issue volume; the remaining 30% requires expert manual testing (TestParty data across 100+ brands). Six error types account for 96% of all detected errors on the top one million home pages, which averaged 56.1 errors each in February 2026 (WebAIM Million). The W3C published ACT Rules Format 1.1 as a Recommendation on February 5, 2026.
What does a WCAG compliance checker actually check?
It checks your content against WCAG success criteria β the numbered, individually testable requirements in the standard β at a target conformance level. WCAG 2.2 lists 87 of them; one is obsolete.
The WCAG 2.2 specification organizes those criteria under four principles (perceivable, operable, understandable, robust) and three conformance levels. Criterion 4.1.1 Parsing was declared obsolete and removed when 2.2 was published, which is why the numbered list runs to 87 while only 86 apply: 31 at Level A, 24 at Level AA, 31 at Level AAA. Level AA β 55 criteria, counting Level A β is the bar named in the DOJ's Title II web rule, EN 301 549, and virtually every procurement document.
Two consequences follow, and most checker marketing ignores both. Each criterion passes or fails outright, so there is no partial credit and no "accessibility score" anywhere in WCAG. And a criterion applies to a whole page, so a tool that samples one URL has said nothing about the other 4,000.
Which WCAG 2.2 criteria can an automated checker test?
Nine of the 55 Level A and AA criteria are reliably machine-decidable. Twenty-two are partially automated β a scanner surfaces genuine failures but a clean result proves nothing. Twenty-four require a person.
The table below is TestParty's classification of all 55, cross-referenced against the W3C's ACT rules, which tag each test rule's implementations as manual, semi-automatic, automated, or linter.
+----------------------------------------------------+----------------------------------------------------+--------------+----------------------------------------------------+
| Machine-checkability | WCAG 2.2 Level A and AA criteria | Count | What a person still has to do |
+----------------------------------------------------+----------------------------------------------------+--------------+----------------------------------------------------+
| Reliably automated β the scanner's verdict is trustworthy | 1.1.1 Non-text Content, 1.4.2 Audio Control, 1.4.3 Contrast (Minimum), 2.4.2 Page Titled, 2.5.3 Label in Name, 2.5.8 Target Size (Minimum), 3.1.1 Language of Page, 3.3.2 Labels or Instructions, 4.1.2 Name, Role, Value | 9 of 55 | Read alt text for meaning, confirm target-size exceptions, check that titles and labels describe the right thing |
+----------------------------------------------------+----------------------------------------------------+--------------+----------------------------------------------------+
| Partially automated β real failures surface, a pass is never proven | 1.2.2, 1.3.1, 1.3.2, 1.3.4, 1.3.5, 1.4.4, 1.4.10, 1.4.11, 1.4.12, 2.1.1, 2.1.2, 2.2.2, 2.3.1, 2.4.1, 2.4.4, 2.4.6, 2.4.7, 2.4.11, 3.1.2, 3.3.1, 3.3.8, 4.1.3 | 22 of 55 | Keyboard-walk every interactive path, test at 200% zoom and 320 CSS px reflow, read headings and link text in context |
+----------------------------------------------------+----------------------------------------------------+--------------+----------------------------------------------------+
| Human judgment only β no scanner returns a meaningful result | 1.2.1, 1.2.3, 1.2.4, 1.2.5, 1.3.3, 1.4.1, 1.4.5, 1.4.13, 2.1.4, 2.2.1, 2.4.3, 2.4.5, 2.5.1, 2.5.2, 2.5.4, 2.5.7, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.6, 3.3.3, 3.3.4, 3.3.7 | 24 of 55 | Screen reader pass, caption and audio-description review, error-message quality, cross-page consistency, multi-step process checks |
+----------------------------------------------------+----------------------------------------------------+--------------+----------------------------------------------------+Read the middle tier carefully, because it is where most false confidence lives. A scanner can tell you a button has `outline: none` (2.4.7); it cannot tell you whether the replacement focus style is visible against your background. It can flag an `<h4>` following an `<h2>` (1.3.1); it cannot tell you whether your headings describe the sections beneath them.
Why doesn't 60β70% coverage mean most criteria?
Because issue volume and criterion coverage are different measurements. Automated detection catches 60β70% of the issues on a typical site while fully deciding only 9 of 55 criteria β the failures cluster.
Six error types β low-contrast text, missing alternative text, missing form input labels, empty links, empty buttons, and missing document language β account for 96% of all errors detected across the top one million home pages (WebAIM Million, February 2026). Those six map to six success criteria: 1.4.3, 1.1.1, 3.3.2, 2.4.4, 4.1.2, and 3.1.1. Five of the six sit in the reliably automated tier; the sixth, 2.4.4 Link Purpose, is automatable only for the empty-link case.
So a scanner that closes six criteria can honestly claim to have removed most of your detected errors β while leaving 46 criteria untested. Both statements are true at once, and the gap between them is the entire reason conformance still requires people. Which failures dominate real remediation queues is broken down in our analysis of 35 million fixed WCAG violations.
Which WCAG 2.2 criteria are new, and can machines catch them?
WCAG 2.2 added nine criteria, six of them at Levels A and AA. Only one is comfortably automated; the rest turn on process and intent, which is exactly what scanners cannot read.
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| New in WCAG 2.2 | Level | What it requires | Machine-checkable? |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 2.4.11 Focus Not Obscured (Minimum) | AA | The focused element is not entirely hidden by sticky headers or banners | Partly β needs a scripted focus walk plus geometry comparison |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 2.5.7 Dragging Movements | AA | Any drag operation has a single-pointer alternative | No β a human must try the alternative |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 2.5.8 Target Size (Minimum) | AA | Targets are at least 24 by 24 CSS pixels, with exceptions | Yes β measurable, though exceptions need review |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 3.2.6 Consistent Help | A | Help mechanisms appear in the same relative order across pages | No β requires cross-page comparison |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 3.3.7 Redundant Entry | A | Information already entered is not requested again in a process | No β requires walking a multi-step flow |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+
| 3.3.8 Accessible Authentication (Minimum) | AA | No cognitive function test without an alternative | Partly β CAPTCHA presence and paste-blocking are detectable |
+-----------------------------------------------+------------+----------------------------------------------------+----------------------------------------------------+The nine additions matter for ecommerce specifically: dense filter chips and quantity steppers fail 2.5.8 constantly, and sticky promotional bars break 2.4.11 on nearly every scroll-heavy product page we assess.
How do you run a real WCAG check?
Run it in four phases, each aimed at a different tier of the table above. Automated scanning first, because it is free and fast; human testing after, because it is where conformance is actually won.
- Set scope, not a URL. Pick one page of every template β home, collection, product, cart, checkout, account, search, blog β plus every page in a complete process. Conformance applies to full pages and entire multi-step processes, so a checkout that fails on step three fails the whole flow.
- Automate the nine. Run a scanner across the template set and drive the reliably automated tier to zero. TestParty's free Shopify App Store scanner checks templates rather than single URLs; the comparison of nine free accessibility checkers covers other platforms.
- Work the middle tier by hand. Keyboard-walk each template, watch the focus indicator, zoom to 200%, reflow to 320 CSS px, and read headings and link text out of context. Budget 30β45 minutes per template.
- Test the bottom tier with a screen reader. Complete a purchase with NVDA or VoiceOver, deliberately trigger form errors, and read every caption against its audio.
When TestParty onboards a store, the nine machine-decidable criteria typically close inside the initial 14-day remediation window. The slowest are 2.4.3 Focus Order and 3.3.3 Error Suggestion β both require someone to walk checkout with a screen reader, and neither can be closed from a dashboard. The full audit sequence is documented step by step.
What does a WCAG conformance claim actually require?
Far more than a passing scan. The W3C sets five conformance requirements, and satisfying every criterion at your target level is only the first.
Per the W3C's Understanding Conformance guidance, a Level AA claim requires that the page satisfies all Level A and Level AA criteria (or provides a conforming alternate version); that conformance is claimed for full pages, with no part excluded; that every page in a complete process conforms; that only accessibility-supported ways of using technologies are relied upon; and that non-conforming content does not interfere with the rest of the page. Claims themselves are optional, and partial-conformance statements exist for third-party content outside your control.
No automated checker can produce that claim, because four of the five requirements are about scope and process rather than markup. It is also why "certified compliant" badges from scanning vendors carry no standing under the standard: a conformance claim names the pages, the date, the version, and the level, and the party publishing the content stands behind it.
When do you need a formal audit or an ACR instead?
When someone else is going to evaluate your evidence. Three situations turn a self-check into a formal engagement: enterprise procurement, European market access, and legal exposure.
Procurement teams and public-sector buyers ask for an Accessibility Conformance Report β a VPAT filled in criterion by criterion with supports, partially supports, or does not support, plus remarks. A scan report cannot populate those cells. European Accessibility Act obligations, in force since June 28, 2025, are enforced against EN 301 549, which tracks WCAG at Level AA; penalties reach up to β¬500,000 and vary by member state. And once a demand letter arrives, dated third-party evidence of testing and remediation is worth more than any dashboard.
For the legal framing of testing β what the ADA does and does not require of a checker β see the ADA compliance checker method. For what happens after the findings land, see how source-code WCAG remediation works.
Frequently Asked Questions
How many success criteria does WCAG 2.2 have? The numbered list runs to 87, but 4.1.1 Parsing was declared obsolete and removed when WCAG 2.2 was published, leaving 86 in force: 31 at Level A, 24 at AA, and 31 at AAA (W3C). Level AA conformance requires satisfying all 55 Level A and AA criteria. WCAG 2.1 had 78 criteria, 50 of them at A and AA.
Can a WCAG compliance checker tell me whether I conform? No. A checker can show you that you do not conform β a confirmed failure is disqualifying on its own. It cannot show that you do, because 46 of the 55 Level A and AA criteria are only partially testable or not testable by machine at all. A clean scan is a necessary result, not a sufficient one.
What changes for a checker between WCAG 2.1 AA and 2.2 AA? Six criteria are added at A and AA, and one is removed. Of the six, only 2.5.8 Target Size (Minimum) is comfortably automated; 2.4.11 and 3.3.8 are partly detectable, and 2.5.7, 3.2.6, and 3.3.7 need a human walking a real flow. A tool still reporting on 4.1.1 Parsing is running an outdated rule set.
Should I check against Level AAA? Only selectively. The W3C states that AAA conformance is not achievable for all content, and no regulation requires it. The 31 AAA criteria are worth mining for specific wins β enhanced contrast at 1.4.6, or 2.4.13 Focus Appearance β rather than adopting as a target. Regulators and procurement teams reference AA.
How often should a site be re-checked? Continuously for the automated tier, quarterly for the manual tiers. Average detected errors per home page rose to 56.1 in 2026 as page complexity climbed 22.5% year over year (WebAIM Million) β drift visible in industry-wide data. TestParty runs daily automated scans plus monthly expert manual audits for that reason: theme updates and new apps reintroduce closed criteria.
What is the difference between a scan report and an ACR? A scan report lists detected issue instances at a moment in time. An Accessibility Conformance Report records a decision for every applicable criterion, with the evaluator's rationale. Procurement, EAA documentation, and litigation response all want the second one; a scan report is only an input to it.
Like everything at TestParty, this article reflects our cyborg philosophy: AI handles the heavy lifting, humans bring the expertise. The data and opinions here are based on publicly available sources as of publication. TestParty is a participant in the accessibility market β we believe in transparency, so we encourage you to cross-reference our claims and evaluate all options for your business.
Stay informed
Accessibility insights delivered
straight to your inbox.


Automate the software work for accessibility compliance, end-to-end.
Empowering businesses with seamless digital accessibility solutionsβsimple, inclusive, effective.
Book a Demo