WCAG 2.2 Compliance in 2026: Audit Tools, Checklist & Costs

Introduction: accessibility just became a procurement gate

Two regulatory clocks are ticking simultaneously. In the United States, ADA-based lawsuits over inaccessible websites continue at a rate of thousands per year, and Section 508 keeps federal and state procurement doors closed to non-conforming vendors. In Europe, the European Accessibility Act (EAA) began applying to private-sector products and services — e-commerce, banking, transport, e-books, and more — in June 2025, with market surveillance following.

For a small B2B software company, the practical consequence shows up earlier than any fine: enterprise and public-sector buyers now ask for a VPAT/ACR or an accessibility conformance statement during procurement. If you cannot produce one, the deal stalls before legal is even involved.

This guide walks through what a modern WCAG 2.2 audit involves, why AI-generated code changes the failure profile, and which tooling fits which team.

Suggested external link placement: link "WCAG 2.2" to the W3C recommendation, the "European Accessibility Act" to the European Commission page, and "Section 508" to section508.gov on first mention.

The standards landscape in 90 seconds

WCAG 2.2 — what changed from 2.1

WCAG 2.2 (a W3C Recommendation since late 2023) added nine success criteria focused on cognitive and motor accessibility — things like focus appearance, target size (minimum), dragging movements, and accessible authentication (no memory or transcription puzzles). It also removed one 2.1 criterion (4.1.1 Parsing). If your last audit was against 2.1 AA, you have new gaps to close even though nothing regressed.

How ADA, Section 508, and the EAA map onto WCAG

• ADA (US, private sector): no statutory technical standard, but DOJ and courts treat WCAG 2.1 AA as the de facto benchmark; consent decrees usually specify it.
• Section 508 (US, federal): formally incorporates WCAG 2.0 AA as its ICT standard; buyers increasingly ask for 2.1/2.2 AA anyway.
• European Accessibility Act (EU, private sector): harmonized standards built on EN 301 549, which references WCAG — conforming to WCAG 2.1 AA/2.2 AA is the clean path to a presumption of conformity.

The operating rule: build and audit to WCAG 2.2 AA once, and you satisfy the strictest buyer asking any of the three questions.

Why AI-generated frontends fail differently

Most scanning tools were tuned for human-written HTML. Code produced by LLMs, site builders, and low-code platforms fails in patterns that deserve their own checklist:

The four characteristic failures

1. Div-soup interactivity. Generated components often use <div onclick> instead of <button>. The click works; the keyboard, the screen reader, and the focus ring all silently break.
2. Contrast from arbitrary palettes. Generative layouts invent color pairs that look plausible in a screenshot and fail the 4.5:1 contrast minimum in practice — especially text over gradient or image backgrounds.
3. Missing landmarks and heading hierarchy. AI output frequently skips <main>, <nav>, and logical <h1>–<h3> order, which scrambles how assistive tech users navigate the page.
4. Focus order and traps. Copy-pasted modal and carousel components can trap keyboard focus or skip it entirely — invisible in visual review, disqualifying in an audit.

What this means for your workflow

If your team ships landing pages, docs, or product UIs generated with AI assistance, your audit tooling needs to recognize these patterns — not just run generic rules. A generic scanner will report some of these issues; a checker tuned for AI-generated output (as A11yGuard is) catches them as a class and generates code-level fixes, which is what actually shortens the remediation loop.

The audit workflow that fits a small team

Step 1 — Automated baseline scan

Run a full-site automated scan to enumerate violations by criterion. Expect the scan to cover roughly a third of WCAG criteria — contrast, alt text, ARIA validity, label presence, focus visibility. That third is enough to fill most of your first fix backlog.

Step 2 — Manual pass on the 60–70% machines cannot see

Keyboard-only walkthrough of every critical flow, screen-reader spot checks (NVDA or VoiceOver), and a review of focus order, meaningful alternatives, and cognitive criteria (consistent identification, error suggestions). For a 10-page marketing site this is a half-day; for a product UI, budget a day per major flow.

Step 3 — Remediate by class, not by instance

Fix the pattern once (e.g., replace the div-button helper in your component library) and the scan count drops in bulk. Instance-by-instance fixing is the most common way small teams burn their accessibility budget.

Step 4 — Evidence and statement

Produce a VPAT/ACR or a conformance statement naming the standard (WCAG 2.2 AA), the evaluation date, known exceptions, and the contact for accessibility feedback. Store scan reports as versioned evidence — buyers and regulators both ask for recency, not just existence.

Internal link suggestion: link the checklist section to your product page https://a11yguard.lxsaihub.com/ and to a future post "VPAT in one afternoon" if you create it.

Tool landscape: seven ways to run WCAG audits

The market has four families: browser extensions (free, page-by-page), open-source rule engines (CI-integrable), enterprise monitoring suites (continuous, org-scale), and overlay widgets (runtime patches — controversial, covered below).

Comparison table

* Indicative as of 2026; verify current pricing on vendor sites.

A11yGuard — deep dive

What it does. A11yGuard runs WCAG 2.2 / ADA checks with rule coverage for contrast, keyboard access, ARIA usage, alt text, and focus order — and adds an AI-frontend awareness layer that specifically detects the failure classes listed above (semantic gaps, generated-component focus traps, low-contrast generative palettes). It supports batch scanning of entire sites or component libraries, returns concrete code-level remediation per issue, and exports compliance-ready reports suitable for VPAT attachments.

Pros

• Fix suggestions are code, not descriptions — the remediation loop is measured in hours.
• Batch mode covers component libraries, so a design-system fix propagates everywhere at once.
• Reports are structured for procurement: standard, criteria, severity, evidence.
• Self-serve pricing that fits a startup budget.

Cons

• Not a continuous enterprise monitoring platform; if you run dozens of properties with non-developer owners, Siteimprove's governance layer fits better.
• Automated coverage is still ~a third of WCAG — pair with a manual pass (Accessibility Insights' guided assessments are a free, disciplined way to do it).

Real use case. A seed-stage SaaS team generated its marketing site with an AI builder before an enterprise RFP demanded an ACR. A11yGuard's batch scan surfaced 40+ issues, the majority in two repeating patterns (div-buttons and a contrast-failing hero palette). After the two pattern fixes, a re-scan supported a WCAG 2.2 AA statement with documented exceptions — the RFP gate cleared in under a week.

Real use case (second segment). A public-sector consultancy used A11yGuard as a pre-audit gate on client deliverables: every AI-drafted landing page gets scanned before handoff, which turned "we found problems during the final audit" into "issues were fixed before we ever invoiced."

The overlay question (accessiBe et al.)

Overlays inject a script that patches the rendered DOM at runtime. They can help some users and generate a conformance claim instantly, but overlays are widely criticized — hundreds of accessibility advocates signed statements against them, and multiple lawsuits have targeted sites using overlays. A defensible position: overlays as a stopgap on legacy properties, never as the compliance strategy for code you control.

The 10-point WCAG 2.2 quick checklist

1. Every interactive element is a semantic control (<button>, <a href>, <input>).
2. All meaningful images have alt text; decorative images have alt="".
3. Text contrast ≥ 4.5:1 (≥ 3:1 for large text and UI components).
4. Visible focus indicator on every focusable element (2.2 adds focus-appearance criteria).
5. Full keyboard operability, logical focus order, no traps in modals/carousels.
6. Page has one <h1> and a non-skipping heading hierarchy; landmarks (main, nav) exist.
7. Form fields have programmatically associated labels; errors are announced in text.
8. Targets are at least 24×24 CSS pixels (new 2.2 minimum target size).
9. No functionality that requires dragging (2.2 dragging-movements criterion).
10. Login does not require memorization or transcription puzzles (2.2 accessible authentication).

Run the automated scan for 1–3 and 6; walk 4–5, 7–10 by hand. That split is the realistic shape of a small-team audit.

Frequently asked questions

Which WCAG version should we claim conformance to in 2026?

WCAG 2.2 AA. It is a superset of 2.1 AA (minus one obsolete criterion), satisfies the strictest buyer language, and is the version the EAA-era harmonized work is converging on. Claiming 2.0 AA today reads as outdated in procurement.

Can an automated scanner certify compliance?

No. Automation reliably covers roughly 30–40% of WCAG criteria. Scanners are the fast, repeatable baseline; a conformance claim needs the manual pass and human judgment documented alongside it.

Our site was built by AI — is it automatically accessible?

No, and it fails in characteristic ways: div-based interactivity, contrast failures from generated palettes, missing landmarks, and focus traps. AI-generated output needs an audit exactly like human-written code — arguably more so, because the failure patterns repeat across every page the model produced.

What does an ADA lawsuit actually cost a small business?

Beyond potential settlements (commonly five figures) and legal fees, the largest cost is the rushed remediation and lost deals while the site is "under review." A one-week proactive audit is almost always cheaper than the first demand letter.

Is an overlay widget like accessiBe enough for ADA compliance?

Overlays do not create real conformance: they patch runtime output, not the underlying code, and they have been named in lawsuits and criticized by the accessibility community. Use them, if at all, as a stopgap on properties you cannot re-code.

How often should we re-audit?

Re-scan on every significant release and at least quarterly. Reports have a shelf life in procurement — an ACR dated 14 months ago invites questions about everything shipped since.

What is a VPAT/ACR and do we need one?

A VPAT (Voluntary Product Accessibility Template) documents how your product conforms to accessibility standards; completed with evidence, it becomes an ACR (Accessibility Conformance Report). If you sell to US government, education, or increasingly any enterprise with an accessibility policy — yes, you will be asked for one. ---

Sources

• W3C — WCAG 2.2 Recommendation. www.w3.org/TR/WCAG22.
• Section 508 (US federal ICT accessibility). www.section508.gov.
• Deque axe-core. github.com/dequelabs/axe-core.
• WebAIM WAVE. wave.webaim.org.