What does WCAG 2.2 checker actually covers

Putting “2.2” in a product name does not mean the checker tests every part of WCAG 2.2.

A WCAG 2.2 checker uses automated rules mapped to WCAG 2.2 Level A and AA to find accessibility issues that can be detected by a machine. Complience.app uses axe-core for this part of the scan.

The important distinction is between automated coverage and full WCAG coverage. A checker can find many technical problems, but some success criteria still need human testing.

What axe-core is good at

axe-core is particularly useful for accessibility issues that can be checked from the page structure.

That includes missing form labels, empty buttons, images without alt text, insufficient color contrast, duplicate names, and certain landmark and ARIA problems.

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 just a slice of what WCAG 2.2 checker actually covers well: numeric and presence checks.

These are the kinds of issues a WCAG 2.2 checker can identify consistently and report against specific accessibility rules.

But a rule being mapped to WCAG doesn't mean the entire success criterion can be tested automatically.

What WCAG 2.2 adds that automation can miss

WCAG 2.2 became a W3C Recommendation in October 2023. It adds 9 new success criteria, including requirements around focus visibility, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication.

The 24 by 24 CSS pixel rule is WCAG target size. The scan can flag a crowded control. It does not close the exceptions.

Some of these can be tested automatically. Others need to be checked in the context of a real user flow.

For example, a tool can find certain problems with a login form, but it can't fully judge whether the authentication process is accessible to someone using assistive technology.

So if someone asks whether a website is "WCAG 2.2 compliant", the useful answer isn't a single score. It's which pages were tested, which rules failed, and what still needs manual review.

Cookies and headers are separate

Complience.app also records cookies before consent and selected HTTP headers during the scan.

That's separate from WCAG coverage. It simply gives you additional evidence about the same URL.

A checker that focuses only on accessibility won't tell you if a marketing cookie was set during the first page load. Complience.app can show that alongside the accessibility findings.

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 a free accessibility check on a public URL and see exactly what the automated scan finds.