What WCAG 2.2 Means for Your EAA Compliance in 2026
Giriprasad Patil·· 7 min read·EAA & Global Laws
The European Accessibility Act launched enforcement in June 2025 referencing WCAG 2.1. By late 2026, it will reference WCAG 2.2 — and every business that audited for EAA compliance against the old standard will need to re-examine nine new success criteria. If you are building EAA compliance today and not targeting WCAG 2.2, you are engineering to a standard with a known expiry date.
This is not a hypothetical future concern. The updated EN 301 549 standard — version 4.1.1, which incorporates WCAG 2.2 — is expected to be published in the EU Official Journal in 2026. Once published, it becomes the binding technical standard for both the Web Accessibility Directive (public sector) and the EAA (private sector). Any business audited after that publication date will be evaluated against WCAG 2.2.
## What Is EN 301 549 and Why Does It Drive EAA Compliance?
The EAA does not reference WCAG directly. It references **EN 301 549** — the European harmonised standard for ICT accessibility, maintained by ETSI, CEN, and CENELEC. EN 301 549 incorporates WCAG as its web content requirements and extends beyond it to cover hardware, documentation, mobile apps, and specific software requirements that WCAG doesn't address.
Currently, EN 301 549 v3.2.1 (2021) references **WCAG 2.1 Level AA**. When EN 301 549 v4.1.1 is published and listed in the EU Official Journal, WCAG 2.2 AA becomes the presumption of conformity for EAA compliance.
**The key distinction:** WCAG 2.2 does not remove any WCAG 2.1 criteria. The nine new success criteria are additions. Meeting WCAG 2.2 AA means meeting all of WCAG 2.1 AA plus the new requirements.
## The Nine New WCAG 2.2 Criteria — EAA Impact Assessment
| WCAG 2.2 Criterion | Level | What It Requires | E-Commerce / SaaS Impact |
|-------------------|-------|-----------------|-------------------------|
| 2.4.11 Focus Appearance (Minimum) | AA | Keyboard focus indicators must meet minimum size and contrast | Affects all custom UI components, buttons, links |
| 2.4.12 Focus Appearance (Enhanced) | AAA | Stricter focus indicator requirements | Bonus tier — ADAGuard checks this on all plans |
| 2.4.13 Focus Appearance | AAA | Focus area must enclose the component | Bonus tier — ADAGuard checks this on all plans |
| 2.5.3 Label in Name | A | Already in 2.1 — no change | — |
| 2.5.7 Dragging Movements | AA | Any drag-based interface must have a pointer alternative | Product carousels, drag-and-drop cart builders |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24×24 CSS pixels | Mobile CTAs, checkout buttons, filter chips |
| 3.2.6 Consistent Help | A | Help mechanisms must appear in consistent location | Chat widgets, support links |
| 3.3.7 Redundant Entry | A | Don't ask users to re-enter information in same session | Checkout forms re-asking address data |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login must not require cognitive tests unless alternative exists | CAPTCHA-only login flows |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Login must not require object/image recognition | Bonus tier |
**Three criteria have the highest commercial impact** for e-commerce and SaaS:
**2.5.8 Target Size (Minimum)** — The 24×24 pixel minimum for interactive targets catches the small filter buttons, close icons, and mobile CTAs that are common in product pages and checkout flows. This is an extremely common failure on mobile-optimised sites.
**3.3.8 Accessible Authentication (Minimum)** — Requiring accessible login without cognitive tests blocks the most common implementation of CAPTCHA-only authentication. If your login page has no alternative to a visual CAPTCHA, it fails this criterion. This applies directly to B2C e-commerce and SaaS login flows.
**3.3.7 Redundant Entry** — Forcing users to re-enter their email address at the payment confirmation step, or re-enter their address after auto-fill, fails this criterion. This is surprisingly common in multi-step checkout implementations.
## What Is Currently in Force for EAA
While EN 301 549 v4.1.1 is in preparation, the currently enforceable standard remains EN 301 549 v3.2.1 = WCAG 2.1 AA. Here's how the timeline looks:
| Date | Status | Standard |
|------|--------|---------|
| June 28, 2025 | EAA enforcement began | EN 301 549 v3.2.1 = WCAG 2.1 AA |
| 2026 (expected) | EN 301 549 v4.1.1 published in EU Official Journal | WCAG 2.2 AA becomes binding presumption |
| June 28, 2030 | All existing products/services must comply | WCAG 2.2 AA (or whatever version EN 301 549 references) |
| Ongoing | UK public sector | WCAG 2.2 AA (already required) |
The gap between now and v4.1.1 publication is not a window to delay — it is a window to remediate. Businesses that wait for the new standard will face two simultaneous problems: fixing WCAG 2.1 failures and fixing WCAG 2.2 gaps, under active enforcement pressure.
## Why Building to WCAG 2.2 Now Is the Correct Strategy
**Legal future-proofing:** Auditing to WCAG 2.2 today means your compliance doesn't expire when EN 301 549 v4.1.1 publishes. You won't need a re-audit 12 months from now.
**UK public sector alignment:** If you serve public sector clients in the UK, or are a UK public sector entity, WCAG 2.2 AA is already required under the Public Sector Bodies Accessibility Regulations 2018 — since August 2020.
**No backward compatibility issue:** All WCAG 2.1 AA criteria remain in 2.2. Fixing 2.1 failures never becomes wasted effort. The nine 2.2 additions are incremental.
**Competitive differentiation:** Few businesses in the market have audited against WCAG 2.2 yet. Doing so creates a genuine defensible position in procurement, enterprise sales, and regulatory inquiries.
## What a WCAG 2.2 Audit Looks Like in Practice
The critical gap in WCAG 2.2 compliance evaluation is that most automated tools still evaluate primarily against WCAG 2.1. Lighthouse's accessibility audits do not flag Target Size (2.5.8) or Accessible Authentication (3.3.8). WAVE evaluates a subset of WCAG 2.1 criteria with approximately 40% overall coverage.
**ADAGuard** includes WCAG 2.2 criteria in its scan coverage — including the bonus AAA criteria 2.4.12 and 3.3.9, which appear on every plan including Free. With **~78% WCAG 2.2 AA automated coverage** across 22 custom checker modules plus axe-core integration, ADAGuard identifies the 2.2-specific failures that Lighthouse and WAVE miss.
The scan output maps every detected failure to its specific WCAG success criterion number — critical for EAA remediation workflows where your developers and vendors need to know exactly which criterion to address, not just a generic "fix your buttons."
ADAGuard's authenticated scanning capability is particularly relevant for WCAG 3.3.7 and 3.3.8 — criteria that apply to login flows and multi-step forms, which are only accessible behind authentication. Static scanner tools cannot evaluate these pages at all.
## What to Do When You Find WCAG 2.2 Gaps
When your scan identifies a WCAG 2.2 failure:
Failures in your own codebase (Target Size, Focus Appearance, Redundant Entry) require developer remediation. Bring the WCAG criterion number and the specific element identified in your scan report to your development team. These are typically straightforward CSS or markup changes, but they need to be targeted correctly.
Failures in third-party components (CAPTCHA systems, checkout payment widgets, chat overlays) require a conversation with your vendor. Cite the specific criterion. EAA-exposed vendors are increasingly responsive because they face the same regulatory pressure.
The most important step is knowing which failures you actually have, in your live site, on the pages that EU customers use. Without a live-DOM scan, you are making remediation decisions based on incomplete data.
## The 30-Second Fix
Go to **[adaguard.io](https://www.adaguard.io)** and paste your URL for a free scan. The report identifies WCAG 2.1 and 2.2 failures on your live site, mapped to criterion numbers, with severity ratings. No signup required.
EN 301 549 is changing. The businesses that will handle that transition smoothly are the ones that know their current baseline now — before the new standard publishes and before a regulator runs the comparison for them.
