Every coverage claim, backed by public tests.

The problem with accessibility tool marketing

Most accessibility tools claim “full WCAG compliance” without defining what they actually test. A tool that runs axe-core and nothing else covers roughly 30 of 78 WCAG 2.2 criteria — but their marketing says “WCAG 2.2 compliant.”

We take a different approach: for every criterion we claim to cover, we maintain a test fixture with a known-pass and known-fail case. If our tool doesn't detect the failure, we don't claim coverage.

Our validation framework

Every criterion in our coverage matrix is backed by a 4-column validation record:

Criterion

WCAG 2.2 success criterion ID and name

Checker

Which of our 12 checkers covers it (axe-core, keyboard, AI vision, etc.)

Detection method

How it's detected: DOM query, Playwright action, screenshot analysis, or manual

Test fixture

A purpose-built HTML page with a known pass and known fail for that criterion

What we test

Our fixture suite covers these categories, each with at least one known-pass and one known-fail HTML page:

• Color contrast failures (1.4.3, 1.4.6, 1.4.11)
• Keyboard traps and focus order violations (2.1.1, 2.1.2, 2.4.3)
• Missing form labels and error identification (1.3.1, 3.3.1, 3.3.2)
• Viewport reflow failures at 320px (1.4.10)
• Text spacing override tolerance (1.4.12)
• Motion and autoplay detection (2.2.2, 2.3.1)
• Target size violations (2.5.8)
• CAPTCHA and accessible authentication (3.3.8)
• Multi-page consistency violations (3.2.3, 3.2.4)
• Images of text (1.4.5, 1.4.9) — via AI vision review

What we don't test

Three WCAG 2.2 Level A+AA criteria are not automated by our tool:

• 1.2.3 — Audio Description or Media Alternative (Prerecorded)
• 1.2.4 — Captions (Live)
• 1.2.5 — Audio Description (Prerecorded)

These criteria require human evaluation of media content that no automated tool can reliably assess. We flag media elements for manual review but do not claim automated detection.

Source-line resolution

Findings are mapped to source files via a multi-signal resolver that assigns a confidence level to each match:

exact

data-wcag-src attribute stamped by the @wcag-audit/next-plugin at build time. Pinpoints the exact JSX line.

likely

Next.js route-to-file heuristic. Maps a page URL to its most probable source file.

guess

Multi-token grep across the repo. Used when no framework mapping is available.

AI vision cost model

AI vision review runs once per page per scan. It does not re-run during wcag-audit verify calls — verify uses only deterministic checkers and costs nothing. This means the per-customer AI cost is bounded: each page is evaluated once, results are cached for 24 hours, and re-runs on unchanged pages skip the AI call entirely.

Cross-checking against industry tools

We regularly run our test fixtures through other accessibility tools — Lighthouse, axe DevTools, WAVE, and IBM Equal Access — to verify that our detection rates are at least as good as industry standards, and to identify criteria where we have unique coverage (like keyboard traps, viewport reflow, and accessible authentication) that other tools miss.

Re-validation cadence

• Every release — the full fixture suite runs as part of CI. A regression in any criterion blocks the release.
• Quarterly — we re-run cross-tool comparisons and update the coverage matrix at /coverage.
• On WCAG updates — when the W3C publishes new understanding documents or errata, we review affected criteria.

Reporting issues

If you find a criterion where our tool claims coverage but fails to detect a real violation, report it to security@wcagaudit.io. Coverage integrity issues are triaged as P0 — same priority as security vulnerabilities.

Need help? Book a demo