WCAG Compliance Testing: The Full Program, Methods, Tools, and Cadence

Last updated: October 30, 2026

WCAG compliance testing means checking a site against the 55 Level A and AA success criteria in WCAG 2.2 — a pass/fail record per criterion, never a single score. No one method covers all 55: automated scanning, manual keyboard and assistive-technology testing, and periodic user testing each cover different ground, and each needs its own schedule. This guide maps the three methods, the tools that actually cover each layer, and the cadence that keeps a fixed site fixed.

Key numbers: WCAG 2.2 defines 55 success criteria at Levels A and AA — the complete set a conformance test has to clear, evaluated one at a time (W3C). Automated scanning covers roughly 60–70% of accessibility issue volume; the remaining 30% needs expert manual testing (TestParty remediation data across 100+ brands, as of August 2026). In 2026, 95.9% of the top one million home pages carried a detectable WCAG failure, averaging 56.1 errors per page (WebAIM Million). Only 11% of cart and checkout pages meet minimum WCAG standards (AccessibilityChecker.org, 2025 eCommerce Accessibility Study). TestParty's post-remediation reference thresholds — Lighthouse 90+, WAVE errors at 5 or fewer, axe errors at 3 or fewer — are a regression floor to clear, never proof of conformance.

What is WCAG compliance testing?

WCAG compliance testing is the practice of evaluating a website against the 55 Level A and AA success criteria in WCAG 2.2, recording each one as pass, fail, or not applicable — never averaged into a percentage or a letter grade.

WCAG 2.2 numbers its criteria up to 87; one, 4.1.1 Parsing, is obsolete, leaving 86 in force, 55 of them at Levels A and AA — the set nearly every commercial conformance target names (W3C). "Testing" and "scanning" get used interchangeably in vendor marketing, and the gap between them is this whole article: a scan runs a rule engine against markup and returns a score, while testing evaluates every applicable criterion — including the ones no rule engine can touch — and returns a record a third party can rely on. Run all 55 against your own site with TestParty's WCAG 2.2 AA checklist before reading further — it turns this section into a punch list.

What are the three testing methods?

Three methods cover WCAG compliance testing — automated scanning, manual keyboard and assistive-technology testing, and periodic user testing with people with disabilities — and each earns its place by catching a different class of failure, not by replacing the others.

Automated scanning is fast and free: it walks the rendered DOM and evaluates deterministic conditions — contrast ratios, missing alt attributes, empty buttons — at the cost of judgment. In TestParty's remediation work across 100+ brands, that layer reliably catches 60–70% of real issue volume, running on every page, every day, at effectively zero marginal cost. Manual testing is a trained person working the keyboard and a screen reader through the interface, and it's the only method that catches failures deciding whether a task can be completed at all — a focus trap, an announcement that never fires, alt text that's present but meaningless. It runs on a fixed cadence, because it can't scale to every page, every day. User testing — sessions with people who use assistive technology daily, not accessibility specialists — is the rarest layer: it doesn't find more violations than a trained tester, but it surfaces workflow friction no single criterion captures, which is why it belongs before a major redesign ships rather than after. For the detailed cost and coverage comparison of the first two, see manual vs. automated accessibility testing.

Which tools cover what?

No single tool covers WCAG compliance testing end to end: axe-core, WAVE, and Lighthouse split the automated layer by job, category-level commercial platforms add scale and workflow, and nothing on the market catches meaning — alt text quality, focus traps, or whether an announcement is heard.

Most teams start with a first look: TestParty's free Shopify accessibility checker scans a live storefront in seconds and shows where a theme stands before anything else is chosen. Beyond that free layer, commercial platforms split into enterprise governance suites, monitoring SaaS, and developer-tooling platforms sold to engineering teams — a category TestParty also operates in, with Bouncer, Spotlight, and PreGame. For the full 2026 stack wired into a pipeline, see automated accessibility testing: 2026 implementation.

Three failures survive every clean scan from any tool above: alt text that exists but says nothing (`alt="IMG_4471.jpg"` passes every rule in every engine), a modal or cart drawer that traps keyboard focus with no way back out, and a status update — a cart total, an error message — that changes visibly but is never announced to a screen reader. All three need a person testing the interface, which is the argument for the cadence below.

What cadence actually holds the line?

A testing program holds the line at four checkpoints — dev-time linting, a per-pull-request CI gate, daily production scans, and monthly manual audits — each catching regressions before the next, costlier stage ever sees them.

Between checkpoints, treat Lighthouse 90+, WAVE errors at 5 or fewer, and axe errors at 3 or fewer as a regression floor — a build clearing them hasn't proven conformance, only that it hasn't gotten worse. Disclosure: TestParty builds tooling at three of these checkpoints — PreGame, Bouncer, and Spotlight — paired with monthly expert audits at the one no product replaces; treat this as a map of the cadence, not a pitch for any box. For the full stage-by-stage pipeline mechanics, see continuous accessibility testing.

How do you test the checkout and other critical paths?

Test checkout and other critical paths as a complete process under W3C's WCAG-EM methodology, evaluating every step from cart to confirmation rather than sampling a page here and there — because a single broken step blocks the entire path.

WCAG-EM's sampling step calls out "complete processes" by name: a multi-step task like checkout has to be tested start to finish, since one inaccessible step — an unlabeled quantity stepper, a focus trap in an address form — makes the rest irrelevant (W3C WCAG-EM). That rule exists because checkout is where testing programs fail most in practice: only 11% of cart and checkout pages meet minimum WCAG standards industry-wide (AccessibilityChecker.org, 2025 eCommerce Accessibility Study). In TestParty's monthly expert audits, the checkout failures that survive a clean automated scan are almost always process failures rather than page failures — a cart drawer that never returns focus after closing, an address autofill that skips a required field silently. Apply the same rule to any multi-step flow, not only the primary purchase path. For the full sampling methodology behind a formal evaluation, see WCAG audits: methodology, tools & sample findings.

What documentation should testing produce?

Testing should produce three dated artifacts — a findings register engineers fix from, a signed WCAG compliance report stating conformance status, and a running record of scan and audit dates — because an undated claim is worth less than no claim at all if it's ever challenged.

Each artifact serves a different reader. The register is the working list — every finding, its severity, a fix specification — for the engineering team closing tickets. The compliance report is the short, signed summary built from it: pass/fail counts by POUR category, known exceptions with target dates, and a next review date, for procurement, counsel, or a board approving budget. The running record is just the dates: when each scan ran, when each audit happened, what it found. That record turns "we fixed it once" into a documented, ongoing program — the piece most testing efforts skip. For the full seven-part structure with a filled sample, see WCAG compliance report: template + sample.

Frequently Asked Questions

Does WCAG compliance testing produce a compliance score? No. Conformance is recorded criterion by criterion — pass, fail, or not applicable — across all 55 Level A and AA criteria, never averaged into a percentage or letter grade. A "92% compliant" claim is a marketing number, not a WCAG conformance statement; the legitimate version is a pass/fail count with a stated scope and date.

How often should each testing method run? Automated scanning runs continuously: every pull request plus a daily production crawl. Manual testing runs monthly for stores shipping frequently, quarterly at minimum, and after any major release. User testing runs less often — before a significant interface change, since it answers different questions than the other two.

Can automated testing alone establish WCAG conformance? No. Automated tools fully evaluate only a minority of the 55 Level A and AA criteria and catch roughly 60–70% of real issue volume in TestParty's remediation work. A zero-error scan means the automatable checks passed — it says nothing about focus order, alt-text quality, or whether a keyboard-only shopper can finish checkout.

Do we need to test every page, or just templates? Test every template and interaction state once, plus every step of any complete process such as checkout, rather than every URL. A store with thousands of product pages on one template needs that template tested thoroughly, plus every product's images checked for meaningful alt text — not thousands of separate manual passes.

What is user testing, and do small stores need it? User testing means observing people who use assistive technology daily complete real tasks on the site — distinct from a trained auditor's expert review. It's most valuable before a major redesign or a new checkout flow ships; a small store running steady-state automation plus monthly audits can generally defer it until a significant change is planned.

Does passing a CI gate mean the site is legally compliant? No. A CI gate enforces a regression floor — Lighthouse 90+, WAVE errors at 5 or fewer, axe errors at 3 or fewer — which stops a build from getting worse. It doesn't evaluate the roughly 30% of criteria needing manual and assistive-technology testing, and no automated threshold is a legal conformance claim on its own.

Humans + AI = this article. TestParty uses a cyborg approach to content — combining human accessibility expertise with AI capabilities to produce accurate, comprehensive guides. This content is for educational purposes and reflects our analysis of publicly available information as of the publication date. TestParty competes in the digital accessibility market, and we encourage readers to evaluate all solutions independently based on their specific needs.