Why does ADA Title II Final Rule target WCAG 2.1 AA instead of WCAG 2.2?

Two reasons. (1) Regulatory timing: the Final Rule's text was finalized inside DOJ in 2023 before WCAG 2.2 was published as a W3C Recommendation (October 2023). DOJ does not update standards mid-rulemaking. (2) Backward compatibility logic: WCAG 2.1 AA conformance is a subset of WCAG 2.2 AA conformance — all 50 Level A + AA criteria from 2.1 remain in 2.2 (except 4.1.1 Parsing). Adopting 2.1 as the legal floor gives covered entities a stable target while allowing 2.2 to layer on top for procurement and forward compatibility.

Do I have to redo my audit to move from WCAG 2.1 to 2.2?

No. WCAG 2.2 is backward compatible — all 50 success criteria from WCAG 2.1 remain in WCAG 2.2 (except 4.1.1 Parsing, retired as obsolete). Your existing WCAG 2.1 conformance carries forward. You need to test the 9 new 2.2 criteria specifically and update your VPAT to reference 2.5 (which lists 2.2 criteria). acipta's A11Y suite covers all 86 WCAG 2.2 criteria — meaning per-criterion evidence exists for both the federal floor (2.1) and the enhancement layer (2.2) simultaneously.

What's the safest audit posture in 2026 — target 2.1 or 2.2?

Layered. Target WCAG 2.1 AA for ADA Title II Final Rule defensibility (this is the federal floor). Target WCAG 2.2 AA on top for Section 508 VPAT 2.5, EU Accessibility Act alignment, and modern procurement contracts. The cost difference is minimal because 2.2 adds only 9 net criteria. The benefit is that a single signed-evidence pack defends across multiple regulatory regimes. Producing evidence per-criterion (rather than per-page) is what makes the layered posture practical.

Which WCAG 2.2 criteria do most sites fail today?

Three new criteria see the highest failure rates: 2.5.8 Target Size (most mobile and desktop nav fails the 24×24 CSS pixel requirement somewhere), 2.4.11 Focus Not Obscured (sticky headers and cookie banners cover the focused element), and 3.3.8 Accessible Authentication (typing-CAPTCHAs and image-grid challenges are non-conformant). Plan remediation in that order. None of these are federally mandated under Title II — but all are procurement-relevant under VPAT 2.5.

Audit-Defensible Compliance: Why Agent-Based Defense Beats Compliance Theater

If you've spent any time evaluating compliance platforms, you've seen the demo. A clean dashboard. Green checkmarks. A control matrix populated from cloud-account integrations. Maybe a SOC 2 readiness score. The pitch is that the platform turns a months-long audit prep into a continuous, automated motion. That pitch is true — for the part of compliance that's about collecting evidence on a schedule and presenting it well. That is compliance automation. It is real, it has value, and it is what most of the category sells.

But there's a second category that the first doesn't cover: audit-defensible compliance. This is the layer that comes into play when the question isn't "did we follow the process" but "can we cryptographically prove the verdict held at the moment we made it — and reproduce it five years later, byte-identically, in front of a regulator or plaintiff's counsel who wasn't there." That's not a UI question. That's an evidence-architecture question.

What "agent-based defense" actually means in this context

Security people use the term "defense in depth": layered controls so an attacker who beats one layer still has to beat the next. Audit-defensible compliance applies the same logic to evidence: every customer-impacting compliance verdict gets its own layered defense so that an auditor or regulator probing one piece — the timestamp, the framework mapping, the input artifact, the signing chain — finds verifiable proof at every layer.

That's where the phrase agent-based defense compliance platform lands. It isn't security-industry language repurposed; it's the precise architectural shape: 164 specialized agents, each defending a specific success criterion or regulatory clause, producing per-verdict cryptographic evidence at the moment the verdict is reached. Not a control-matrix screenshot taken yesterday. Not a dashboard reading we'll trust because the platform vendor told us to. Signed proof, replayable five years out, verifiable with standard cryptographic tools and no proprietary viewer.

Why "compliance theater" is the failure mode worth naming

Bruce Schneier coined "security theater" to describe controls that look like security but don't actually reduce risk. The compliance analog is exactly the same pattern: the platform produces artifacts that look like evidence — PDFs, dashboards, control summaries — but cannot survive cross-examination years later because the evidence chain is missing primitives. There's no signing at write time. There's no anchored timestamp. There's no deterministic replay. The artifact is a document, and a document is only as good as the platform that produced it — which means it's only as good as the platform that's still running in 2031.

The audit floor is moving. ADA Title II Final Rule deadlines, the EU AI Act's GPAI enforcement window starting August 2, 2026, HIPAA Security Rule updates for AI-augmented PHI handling, SEC AI disclosure rules — each one is a regulator implicitly asking the same question: "show me the verifiable evidence, not the dashboard you screenshotted." Programs whose evidence chain is a folder of PDFs will struggle to answer. Programs with cryptographic per-verdict evidence will not.

The four primitives that make compliance defensible

Audit-defensible compliance — and the agent-based defense platform that produces it — rests on four primitives that compliance automation tools don't ship:

Per-verdict cryptographic signing at write time. Every compliance conclusion the platform reaches gets an Ed25519 signature tied to a hardware security module before it leaves the agent that produced it. The signing key never leaves the HSM. The signed artifact is the evidence.
RFC 3161 trusted timestamping. Every signed verdict is timestamped by an independent timestamp authority. The timestamp is part of the evidence package, which means "when this verdict was reached" is not the platform vendor's word — it's a third-party cryptographic anchor any auditor can verify independently.
Hash-chained verdict ledger. Each verdict's signature is hash-linked to the previous verdict's signature, building a tamper-evident chain across the entire compliance history — any change to a past verdict breaks the chain forward and is immediately detectable on replay.
Deterministic byte-identical replay. Given the input artifact + the framework version at the time + the agent definition at the time, the platform can re-run the verdict five years later and produce the byte-identical signed output. This is the test that separates audit-defensible compliance from everything else: can you reproduce the verdict, not just describe it.

None of these primitives is novel in isolation. Each one is well-understood cryptographic engineering. What's novel — and what makes it an agent-based defense compliance platform rather than a workflow tool — is treating the combination as the architectural commitment from day one. Targets and timelines on the replay-pass-rate and the per-framework verdict count are aspirational at this stage (pre-customer baseline applies) and will publish weekly after general availability on August 23, 2026.

When compliance becomes defensible (and when it doesn't)

The honest test is one question: five years from now, when the framework version has shifted and the platform vendor may or may not still exist, can the customer independently verify the verdicts the platform produced today? If yes, that's audit-defensible compliance. If the answer requires logging into a platform UI, running a proprietary viewer, or asking the vendor for help — that's compliance automation, and it stops being defensible the day the vendor stops returning calls.

This isn't an academic distinction. It's the practical difference between a compliance program that survives a major regulatory cycle and one that depends on the vendor's continued existence to be auditable. Both are useful. They're not substitutes.

Where this fits in the broader category

If you've been reading about AI agent governance, audit-defensibility is the second of the three layers in that category map — the evidence layer underneath runtime governance and AI security. If you've been comparing acipta to Vanta, Drata, or OneTrust, the audit-defensibility primitive is the wedge that explains the architectural difference. If you've been searching for an "agent-based defense compliance platform" the way you'd search for any other class of infrastructure, this is the page that defines the category clearly.

Bottom line

Compliance theater produces artifacts that look like evidence. Audit-defensible compliance produces evidence that survives the year-five regulator review. The architectural commitment to the second — per-verdict signing, RFC 3161 timestamping, hash-chained ledger, byte-identical replay — is what makes the agent-based defense layer fundamentally different from the workflow layer that sits above it. Both have value. Only one of them defends the verdict.

If your compliance program is heading into a regulatory window where the dashboard screenshot will no longer be enough — and most are, by 2030 — the agent-based defense layer is the bet worth making early.

Audit-defensible compliance: why agent-based defense beats compliance theater.