WCAG 2.1 vs 2.2 — what changed and what to fix on your app
If you're remediating an app for ADA or EAA compliance in 2026, the question is which WCAG version to target. WCAG 2.1 is what most current law references explicitly. WCAG 2.2 is what the next round of regulations and standards will reference. Doing the work twice is wasteful; doing 2.2 first costs almost nothing extra. Here's the differential.
The short version
WCAG 2.2 was published as a W3C Recommendation on October 5, 2023. It adds 9 new success criteria and removes one (4.1.1 Parsing, deemed obsolete because browsers handle malformed HTML gracefully). Everything in WCAG 2.1 carries through unchanged. So a 2.1-compliant app is most of the way to 2.2 compliance — the question is just which of the 9 new criteria apply.
What's new at Level AA (the ones most operators target)
Four new AA-level success criteria. These are the ones to prioritize because most current accessibility legal regimes (ADA case law, Section 508, EU EN 301 549 once revised) target AA conformance:
2.4.11 Focus Not Obscured (Minimum)
When an element gets keyboard focus, the focused element must not be entirely hidden behind sticky headers, sticky footers, cookie banners, or chat widgets. Common failure pattern: keyboard user tabs through a form, the focused input is hidden behind a sticky bottom CTA, user can't see what they're editing. AI-generated layouts with sticky elements fail this rule frequently.
2.5.7 Dragging Movements
Any feature that requires dragging (sliders, drag-to-reorder, drag-and-drop file upload, map panning) must offer a non-dragging alternative. Common failure: a slider control with no clickable +/- buttons; a drag-and-drop file upload with no click-to-browse button.
2.5.8 Target Size (Minimum)
Interactive elements must be at least 24×24 CSS pixels in their hit area (with limited exceptions for inline links in text). This is the rule AI-built apps fail most often. The default touch target in Tailwind's `h-8` / `w-8` (32×32) passes, but smaller icon buttons, dense table-row controls, and pagination dots routinely fail. Mobile-first apps fail this less; desktop-first dashboards fail it constantly.
3.3.8 Accessible Authentication (Minimum)
If your authentication flow requires the user to memorize, transcribe, or perform a cognitive function test, you must offer at least one alternative method that doesn't. Common failure: image-based CAPTCHA with no alternative. Passing patterns: "sign in with Google/Apple," passkeys, magic-link email, password-manager-compatible inputs (which the user fills, not memorizes).
Related: the 5 WCAG rules most-cited in ADA demand letters →What's new at Level A
Two new Level A criteria — these are the baseline conformance level, so if you're claiming any WCAG conformance, you need to meet them:
3.2.6 Consistent Help
If your site offers help (contact info, support link, FAQ, chatbot), it must appear in the same relative location across pages. Putting the contact link in the footer on most pages and in the header on one page fails this rule. AI-generated layouts that vary between pages tend to fail.
3.3.7 Redundant Entry
In a multi-step flow, information the user already entered (or that you have on file) must be auto-populated or be available for the user to select rather than re-type. Common failure: multi-step checkout where shipping address must be re-entered on the billing-address step.
What's new at Level AAA
Most apps don't target AAA — it's a high bar with limited legal relevance. But knowing what's there:
- 2.4.12 Focus Not Obscured (Enhanced) — focused elements must be entirely visible, not just partially.
- 2.4.13 Focus Appearance — focus indicators must meet specific size and contrast requirements.
- 3.3.9 Accessible Authentication (Enhanced) — no cognitive function tests allowed at all (including object-recognition tests like "select all bicycles").
What's removed
4.1.1 Parsing was deemed obsolete and removed in WCAG 2.2. The rationale: modern browsers handle malformed HTML (duplicate IDs, unclosed tags, nesting issues) gracefully enough that the criterion was no longer measuring accessibility — it was measuring HTML hygiene. If a tool you're using still reports 4.1.1 failures, treat them as informational rather than blocking.
Why this matters for legal exposure
Today, most ADA cases reference WCAG 2.1 (or 2.0). That's slowly shifting:
- DOJ's April 2024 rule for state/local government web content explicitly references WCAG 2.1 AA — but federal courts have started accepting 2.2 as the better-practice standard in private-sector ADA cases too.
- Section 508 (federal procurement) still references WCAG 2.0 in its current revision, but a refresh is in progress and is expected to reference 2.2.
- EU's EN 301 549 currently references 2.1 AA; a revision to incorporate 2.2 is in active drafting, expected publication 2026–2027.
- Australia's DTA and Canada's accessibility regulators have both moved to 2.2 as their reference standard in 2024–2025.
Target WCAG 2.2 AA. The marginal cost over 2.1 AA is small (about a half-day of work for a typical app), and you've protected yourself against the next round of regulatory and case-law revisions. Tools like axe-core and Lighthouse both check 2.2 success criteria by default in their current versions.
Where AI-built apps fail the new criteria most
Across scans of vibe-coded apps in production, the 2.2-specific failures cluster in three places:
- Target size (2.5.8) — dense table controls, pagination dots, and icon-only buttons in toolbars. Lovable, Bolt, and Cursor projects fail this in roughly 80% of scans.
- Focus obscured (2.4.11) — sticky footers, cookie banners, and chat widgets covering the bottom 60–80 pixels of the viewport. Almost universal in apps with a sticky CTA at the bottom.
- Accessible authentication (3.3.8) — image CAPTCHAs from default AI-generated auth flows, with no alternative method offered.
All three are fixable in under an hour of work each. Most automated accessibility scanners now check for them — the question is whether you're scanning at all.
Related: Lovable app compliance checklist →Bottom line
WCAG 2.2 is the right target for any app being remediated in 2026. The new criteria are mostly common-sense (don't hide focused elements, make tap targets big enough, don't require memorization for login), the marginal cost over 2.1 is small, and the trajectory of regulation is unmistakably toward 2.2. If your existing scan is reporting 2.1-only results, switch the tool's target to 2.2 and re-run. The deltas will be addressable in a single dev cycle.
Common questions.
Do I have to target WCAG 2.2 to be ADA compliant?
No. Most current ADA case law references WCAG 2.1 or 2.0 as the de facto standard, and DOJ regulations (April 2024) for state/local government content reference 2.1. But targeting 2.2 future-proofs you for the next round of revisions, and the marginal cost is minimal.
What does it cost to upgrade from WCAG 2.1 to 2.2 compliance?
For a typical small app: 4–8 hours of dev time once you have a 2.2-aware scan report. The biggest costs are usually target-size adjustments (because they may require small layout changes) and accessible-authentication workarounds (offering passkey or social login as an alternative to CAPTCHA).
Are tools like axe-core and Lighthouse checking 2.2 by default?
Modern versions (axe-core 4.7+, Lighthouse 11+) check 2.2 success criteria by default. If you're using an older version or a hosted scanner that hasn't updated, you'll get 2.1 results only — switch to a current version.
What about WCAG 3?
WCAG 3 is in draft form (Working Draft as of 2025) and is structurally different from 2.x — it's a complete rewrite, not an increment. Expected adoption is 2027–2028 at the earliest, with a multi-year transition. For practical compliance work in 2026, focus on 2.2.