What a WCAG 2.2 checker actually covers

Putting “2.2” on a product name does not add 2.2 coverage.

A WCAG 2.2 checker is an automated accessibility checker whose rules are mapped to WCAG 2.2 Level A and AA. “WCAG checker” in a search box usually means the same thing: flag machine-testable failures on a live page.

Complience.app runs axe-core for that pass. The homepage and tool pages lead with “checker” because that is the word people type. 2.2 stays in the method, not stuffed into every H1.

Client questions about the version number are a trap. Pages scanned, rules failed, and a manual plan for the new 2.2 criteria are the useful answer. A single grade is the answer that gets people in trouble.

What axe-core is good at

Missing form labels, empty buttons, images without alt, contrast below the numeric ratio, duplicate names, landmark mistakes the engine is taught to see. Those map cleanly to WCAG-style rule IDs in the report.

The WebAIM Million (WAVE-style, same class of automation) found low-contrast text on 83.9% of the top 1,000,000 home pages in February 2026. Missing alternative text sat at 53.1%, missing form labels at 51%. That is the slice a WCAG 2.2 checker actually covers well: numeric and presence checks.

The accessibility checker page lists the job and the gaps. Scores are computed on the server from those issues, not guessed in the browser.

In practice, axe-core is honest about what it is. Deque’s axe-core ruleset is mapped to WCAG. Mapped is not “complete.”

What 2.2 added that you still might miss

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added 9 success criteria covering focus not obscured, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication. 4.1.1 Parsing was removed.

Some of that is automated. Much of it still needs a person on the actual flow: login without a cognitive test, drag-and-drop with a keyboard, tap targets on a phone.

If a client asks “are we 2.2?”, answer with pages scanned, rules failed, and a manual plan. Do not answer with a single grade.

What actually works is naming the new criteria you did not machine-test. Accessible authentication is a login sitting, not a homepage score.

Cookies and headers are extra

WAVE-style checkers stop at accessibility. Complience.app also records cookies before consent and a short header set. That does not make the a11y portion more complete. It makes the PDF more useful for the same URL.

The UK ICO’s cookies guidance is explicit: you cannot set non-essential cookies on the homepage before the user has consented. A WCAG 2.2 checker that never looks at first-load tags will not tell you that leak happened.

Run the checker on a public homepage, then read scoring so the grade is not a mystery.