This guide assumes you already know your organization needs WCAG 2.2 AA conformance and you are choosing software to get there. If you are still at "do we need this," start with our compliance intelligence definition and come back. The short version of why you need it: ADA Title III lawsuits hit 4,605 federal filings in 2024 (UsableNet) plus tens of thousands of demand letters; EU Accessibility Act enforcement began July 12, 2025; Section 508 procurement gates close every federal deal. WCAG 2.2 AA is the legal floor.
ADA Title II · WCAG 2.1 AA
Check your WCAG 2.1 AA deadline & exposure
The DOJ's ADA Title II Final Rule (28 CFR Part 35) makes WCAG 2.1 AA the technical standard for state and local government. Pick your organization to see your deadline and what's now enforceable.
Source: U.S. DOJ ADA Title II Final Rule, 28 CFR Part 35 (2024). Deadlines are statutory. Informational only — not legal advice.
What WCAG 2.2 AA actually requires
The Web Content Accessibility Guidelines version 2.2, published by W3C in October 2023, define 86 total success criteria organized under four principles: Perceivable, Operable, Understandable, Robust (POUR). Each criterion has a conformance level — A (must), AA (should target), AAA (highest).
What's new in WCAG 2.2 vs WCAG 2.1
WCAG 2.2 adds 9 new criteria and removes 1 (4.1.1 Parsing is now obsolete due to modern HTML parsers).
| New criterion | Level | What it covers |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Focused element must not be entirely hidden by author-created content. |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | Focused element must not be hidden at all. |
| 2.4.13 Focus Appearance | AAA | Focus indicators must meet specific size/contrast requirements. |
| 2.5.7 Dragging Movements | AA | Single-pointer drag interactions need a single-click alternative. |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24×24 CSS pixels (with exceptions). |
| 3.2.6 Consistent Help | A | Help mechanisms must appear in consistent order across pages. |
| 3.3.7 Redundant Entry | A | Don't make users re-enter info already provided in the same flow. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Authentication cannot require cognitive function tests (no transcribing CAPTCHAs by hand, etc). |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Tighter authentication requirements with fewer exceptions. |
The new criteria emphasize cognitive accessibility, touch-target sizing, and authentication friction — areas WCAG 2.1 underweighted. If your last accessibility audit was against WCAG 2.1, you almost certainly fail at least 3 of the 9 new 2.2 criteria today.
AA vs AAA — which to target
The honest answer: AA across the entire site, AAA selectively on highest-risk surfaces. Universal AAA is rarely required and sometimes counterproductive (some AAA criteria like 1.4.6 Contrast (Enhanced) 7:1 are visually restrictive and conflict with brand systems).
Surfaces that warrant AAA selectively:
- Payment flows and checkout — exclusion here causes direct revenue loss and regulatory exposure under PSD2, payment card brand rules.
- Account recovery and authentication — locking a disabled user out of their own account is the worst-case failure mode.
- Healthcare patient portals — HIPAA + ADA overlap creates compounding liability (see our HIPAA × accessibility deep-dive, publishing Jul 7).
- Government services — Section 508 procurement increasingly references AAA selectively.
- Content-creation surfaces — if disabled users cannot author content, they cannot participate as creators, not just consumers.
Acipta's A11Y suite covers all 86 criteria including AAA, so you can stage AAA adoption without re-scoping the platform. The cost of AAA-readiness is in the remediation work, not in the platform license.
The four layers of a defensible WCAG 2.2 AA program
Real compliance — the kind that survives a regulator's questionnaire or a plaintiff's discovery — has four layers. Tools that cover only one or two of these are not WCAG 2.2 AA compliance software; they are a single ingredient.
Layer 1 · Automated scanning
Static + dynamic scanning of HTML, ARIA, color contrast, focus order. Catches roughly 30–35% of WCAG violations (per Deque/WebAIM research). This is what tools like axe-core, Pa11y, Lighthouse do. Necessary, far from sufficient.
Layer 2 · Manual audit augmentation
The remaining 65–70% of violations require human judgment — alt text accuracy, form label clarity, reading order, semantic structure of complex widgets, screen-reader compatibility. acipta's agents augment human auditors rather than replace them: the agent surfaces candidates and proposed remediations; a certified accessibility specialist reviews and signs off. This is the defensibility model.
Layer 3 · Per-success-criterion evidence chain
For each of the 86 WCAG 2.2 criteria, signed evidence: what was tested, what was found, what was remediated, who signed off, on what date. Ed25519-signed, RFC 3161-timestamped, persisted for the statute-of-limitations window (typically 4–6 years for ADA depending on jurisdiction). This is the layer most platforms skip entirely.
Layer 4 · Continuous monitoring + change detection
Accessibility regresses with every deploy. A WCAG 2.2 AA program that doesn't watch for regression is producing a snapshot, not a posture. acipta's monitoring agents re-scan on each deploy and emit a signed delta — what changed, what regressed, what needs immediate attention.
How acipta's A11Y Suite works
The acipta A11Y suite ships 25 specialized agents, each accountable to a specific subset of WCAG 2.2 criteria. They are not a single model fine-tuned on WCAG — they are domain-bounded agents with capability tokens limited to the parts of WCAG they own.
| Agent family | Covers criteria | Output |
|---|---|---|
| Perceivable agents (1.x) | Text alternatives, time-based media, adaptable content, distinguishable | Alt-text proposals · color-contrast deltas · captioning gaps |
| Operable agents (2.x) | Keyboard, timing, seizures, navigable, input modalities (incl. 2.2's 2.4.11 + 2.5.7/8) | Keyboard trap detection · focus-not-obscured · target-size violations |
| Understandable agents (3.x) | Readable, predictable, input assistance (incl. 2.2's 3.2.6 + 3.3.7/8/9) | Authentication-accessibility audit · consistent-help check · redundant-entry detection |
| Robust agents (4.x) | Compatible (ARIA, name/role/value) | ARIA usage audit · semantic structure validation |
| Document agents | PDF UA, Word, PowerPoint accessibility | Document accessibility scoring · remediation paths |
| Evidence agents | Cross-cutting | Ed25519 signing · VPAT generation · Determinism Ledger writes |
Each verdict from each agent gets:
- Signed at write time with Ed25519
- Timestamped via RFC 3161 (independent third-party trusted timestamp authority)
- Hash-chained to the prior verdict
- Persisted in the Evidence Locker for 5+ years
- Mapped to the specific WCAG 2.2 criterion via the Control Mapping Catalog
This is the per-success-criterion architecture. When a regulator or plaintiff asks "show me the evidence for 1.1.1 Non-text Content on the checkout page as of November 12, 2026," acipta produces a signed evidence pack with the source HTML, the agent's verdict, the human auditor's sign-off, and the cryptographic proof that the record has not changed since.
VPAT generation, the right way
A VPAT (Voluntary Product Accessibility Template) is the standardized form federal agencies and enterprise procurement teams use to evaluate accessibility. The current version is VPAT 2.5, covering WCAG 2.2 + Section 508 + EN 301 549 (European Accessibility Act).
Most accessibility tools either don't generate VPATs at all or generate them as a separate manual exercise. acipta auto-generates VPAT 2.5 from the signed evidence already in the Evidence Locker, so the VPAT a buyer reads is byte-identically derivable from the platform's audit trail. If a buyer disputes a VPAT claim, acipta can produce the underlying signed evidence pack on demand. Most vendors cannot.
Implementation timeline
For a typical mid-market customer (50–500 page templates, 5–20 dev teams contributing):
| Week | Activity | Output |
|---|---|---|
| Day 1 | Platform integration via Cloudflare Worker or direct API | First signed scan within hours · day-one evidence chain |
| Week 1 | Full site scan + criticality scoring by criterion impact | Prioritized remediation list · per-template scorecard |
| Week 2–3 | Remediation on critical criteria (keyboard 2.1.1, focus 2.4.7/11, color contrast 1.4.3, form labels 1.3.1) | ~80% of AA criteria satisfied · interim VPAT available |
| Week 4 | Long-tail AA criteria + AAA pass on high-risk surfaces · final VPAT 2.5 generation | Full WCAG 2.2 AA conformance posture · signed VPAT |
| Ongoing | Continuous monitoring per deploy · quarterly auditor sign-off | Per-deploy regression deltas · year-five replay readiness |
Compare to alternatives: manual audits run 8–12 weeks and produce a point-in-time PDF that's obsolete by the next deploy. Widget installs claim "compliance in 1 hour" and produce no defensible evidence — the legal exposure persists indefinitely. The defensibility approach is both faster than manual audit and infinitely more defensible than widgets.