Does WCAG 2.2 AA apply to SPAs?

Yes. WCAG is technology‑agnostic. SPAs must expose correct name/role/value, manage focus on route changes and dialogs, and support keyboard interactions. Tools like react‑aria and router focus management helpers make this tractable.

Do we still need manual audits if we automate axe/Pa11y/Lighthouse?

Yes, but less often. Automation catches structural issues at scale; manual reviews validate semantics, complex interactions (drag alternatives), focus order, and screen reader announcements. Use automation to keep the floor high, then schedule targeted human audits.

How do we handle third‑party widgets?

Prefer vendors with WCAG 2.2 AA statements and testable demos. Sandbox them behind adapters; if a widget fails critical checks, block it or isolate it to non‑critical paths and document the risk. Contractually require accessibility fixes with SLAs.

What about native mobile?

Different toolchain, same principles. Use platform accessibility APIs, lint with Android Lint/SwiftLint rules, and automate with XCTest + axe (where supported) or platform equivalents. Track SLOs and gate on critical issues in CI just like web.

Can we keep velocity with these gates?

Yes. Harden components so most engineers never think about ARIA. Run fast local checks (eslint/jest-axe), parallelize CI scans, and ramp gating over a few weeks. Teams speed up once the rules are encoded in the library and pipeline.

Security-compliance · Oct 15, 2025 · 10 minute read

The Week Legal Called: Operationalizing WCAG 2.2 AA + ARIA as Non‑Negotiable Acceptance Criteria

Turn accessibility from a best‑effort into a release gate with automated guardrails, concrete proofs, and zero drama around regulated data.

Back to all posts

The Week Legal Called: Operationalizing WCAG 2.2 AA + ARIA as Non‑Negotiable Acceptance Criteria

Key takeaways

Implementation checklist