WCAG 2.2 vs 2.1: What Changed and What to Do in 2026

Accessibility, without the guesswork

Understand where your website stands and what to improve.

WCAG 2.2 was published in October 2023. That’s over two years ago, which means it’s no longer a future consideration or something to put on the roadmap. It’s the current standard, and it’s what most accessibility regulations now reference or are moving toward.

If your site was built to WCAG 2.1 and hasn’t been reviewed since, there’s a reasonable chance it’s missing several requirements. This guide covers exactly what changed between the two versions, which new criteria are most likely to affect your site, and what the practical steps look like to close the gap.

How WCAG 2.2 Relates to WCAG 2.1

WCAG 2.2 doesn’t replace WCAG 2.1. It builds on it. Every success criterion from 2.1 carries over into 2.2, with one exception (more on that below). This means any site conforming to WCAG 2.2 automatically conforms to 2.1 as well.

The W3C developed the updates after research and feedback from the accessibility community, focusing on gaps that affected users with cognitive disabilities, low vision, and motor impairments, particularly on mobile devices. Nine new success criteria were added. One outdated criterion was removed.

If you want to understand the full foundation these versions build on, the WCAG compliance guide covers the core principles and conformance levels in detail.

What Was Removed: Success Criterion 4.1.1 Parsing

WCAG 2.2 dropped criterion 4.1.1 (Parsing), which required HTML to be properly formed with complete start and end tags, unique IDs, and correctly nested elements. It became obsolete because modern browsers and assistive technologies handle minor HTML errors without breaking accessibility.

Valid, well-structured HTML remains a best practice for maintainability and consistent rendering, but it’s no longer a formal WCAG requirement.

The Nine New Success Criteria in WCAG 2.2

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a user navigates to an element using keyboard controls, that element cannot be completely hidden by other content such as sticky headers, cookie banners, or chat widgets. At the AA level, at least some portion of the focused element must stay visible.

This is a common failure on sites with persistent overlays or fixed navigation bars. Keyboard users end up with their focus position hidden behind page chrome with no visual feedback about where they are.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

The enhanced version requires the focused element to be fully visible, not just partially. Level AAA isn’t typically required for legal compliance, but it’s worth knowing the distinction when designing focus behavior.

2.4.13 Focus Appearance — Level AAA

This criterion sets specific requirements for focus indicators: a minimum size of at least a 2 CSS pixel perimeter around the component, and a contrast ratio of at least 3:1 against adjacent colors. Default browser focus rings often don’t meet this threshold, which means custom focus styles are needed for sites aiming at this level.

2.5.7 Dragging Movements — Level AA

Any functionality that requires dragging must have an alternative single-pointer method available. If users can reorder a list by dragging items, they must also be able to do it another way, such as up/down buttons or a selection mechanism. This benefits users with motor impairments and anyone on a touch device where precision dragging is difficult.

2.5.8 Target Size (Minimum) — Level AA

Interactive elements must be at least 24 by 24 CSS pixels. Exceptions apply for inline links within text, elements where the user agent controls the size, or cases where spacing around a smaller element effectively creates a larger target area.

This replaces the previous Level AAA criterion (2.5.5) which set the bar at 44 by 44 pixels. The lower minimum reflects practical design constraints while still addressing real usability problems for users with limited dexterity. Mobile-first designs often already comply, but desktop interfaces with small icon buttons or tightly packed navigation links frequently do not.

3.2.6 Consistent Help — Level A

If a website provides help mechanisms, such as contact information, chatbots, or self-service options, these must appear in the same relative location across pages. Users, particularly those with cognitive disabilities, shouldn’t have to hunt for help in different places on different pages.

3.3.7 Redundant Entry — Level A

Users should not be required to re-enter information they’ve already provided within the same session, unless re-entry is essential for security or the data has changed. The clearest example is e-commerce checkout: if a billing address matches the shipping address, users shouldn’t have to type it twice.

3.3.8 Accessible Authentication (Minimum) — Level AA

Authentication processes cannot rely solely on cognitive function tests, such as remembering a password or solving a puzzle, unless an alternative is provided. Alternatives include recognizing objects or personal content, using a supporting mechanism such as a password manager, or offering passkey or biometric authentication.

Password managers satisfy this criterion when they can successfully autofill credentials. The requirement is effectively pushing sites away from authentication patterns that create unnecessary cognitive barriers.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

The enhanced version prohibits cognitive function tests entirely, including recognizing objects. Only mechanisms that require no memory or cognitive test are permitted at this level.

WCAG 2.1 vs 2.2 at a Glance

Criterion	Level	What It Requires	New in 2.2?
Focus Not Obscured (Minimum)	AA	Focused elements partially visible	Yes
Focus Not Obscured (Enhanced)	AAA	Focused elements fully visible	Yes
Focus Appearance	AAA	Minimum focus indicator size and contrast	Yes
Dragging Movements	AA	Alternative to drag interactions	Yes
Target Size (Minimum)	AA	24x24px minimum touch/click targets	Yes
Consistent Help	A	Help in same location across pages	Yes
Redundant Entry	A	No re-entering information in same session	Yes
Accessible Authentication (Min)	AA	No cognitive-only auth without alternative	Yes
Accessible Authentication (Enhanced)	AAA	No cognitive function tests at all	Yes
Parsing (4.1.1)	A	Valid HTML structure	Removed

Which Version Do Legal Requirements Reference?

This is where it gets practical.

United States: The ADA doesn’t specify a WCAG version, but DOJ guidance and most legal settlements reference WCAG 2.1 AA. Courts have increasingly accepted this as the expected standard. WCAG 2.2 compliance exceeds the current legal minimum, but the gap is small and getting smaller.

European Union: The European Accessibility Act, which became enforceable in June 2025, references EN 301 549, which is aligned with WCAG 2.1 AA. However, WCAG 2.2 is widely expected to be incorporated in future updates to that standard. Organizations meeting WCAG 2.2 are ahead of the curve. More detail on the EAA and what it requires is covered in the European Accessibility Act compliance guide.

The practical answer: Build to WCAG 2.2 AA. It covers everything 2.1 requires and adds criteria that are largely achievable without major overhaul. There’s no reason to target a standard that’s already two versions behind.

What’s Most Likely to Affect Your Site

Not all nine new criteria are equally likely to cause failures. Based on common site patterns, these are the ones most worth auditing first:

Touch target size (2.5.8) affects almost every site with icon buttons, small navigation items, or tightly spaced links. This is especially common in mobile navigation menus and footers.

Focus not obscured (2.4.11) affects any site with a sticky header, fixed navigation bar, cookie banner, or chat widget that sits on top of page content.

Redundant entry (3.3.7) affects e-commerce checkout flows, multi-step forms, and account registration processes where the same data appears more than once.

Accessible authentication (3.3.8) affects any site with a custom login form that doesn’t support password managers, or CAPTCHA-based verification without an alternative.

Consistent help (3.2.6) affects sites where contact links, chat buttons, or help documentation appear on some pages but not others, or appear in different locations depending on the template.

How to Audit Your Site Against WCAG 2.2

Step 1: Run an Automated Scan

Automated tools catch a substantial portion of WCAG failures quickly. Run a full site scan to identify issues with color contrast, missing labels, heading structure, and other detectable problems. Scanluma scans against current WCAG 2.2 criteria and produces reports organized by criterion and severity, which makes it straightforward to prioritize. If you haven’t scanned your site recently, start with a free accessibility check.

Step 2: Focus the New Criteria

If your site already met WCAG 2.1 AA, the nine new criteria are your primary focus. Review focus behavior with sticky elements, check touch target sizes across your mobile layout, audit authentication flows, and walk through any multi-step forms.

Step 3: Test With a Keyboard

Tab through your most important pages without touching the mouse. Verify that every interactive element is reachable, that the focus indicator is always visible, and that no overlay content obscures where the focus currently sits.

Step 4: Check Mobile Specifically

Touch target sizing failures almost always show up more clearly on mobile. Test your navigation, CTAs, and any interactive components on a real device or in DevTools mobile view.

Step 5: Monitor Continuously

Accessibility regresses. Content gets added, plugins update, design changes get pushed, and new failures appear. Continuous monitoring catches issues before they accumulate. Scanluma can scan your site automatically and alert you when new problems appear, so you’re not relying on periodic manual reviews.

Common Mistakes When Updating for WCAG 2.2

Assuming WCAG 2.1 compliance is close enough. It covers the baseline, but the new AA-level criteria are not optional for organizations targeting current compliance standards. Touch targets, focus visibility, redundant entry, and accessible authentication are all Level A or AA requirements now.

Only testing on desktop. Several new criteria relate directly to mobile interaction patterns. A site that passes every check on desktop can still fail on a phone.

Fixing isolated instances instead of templates. If touch targets are too small in your navigation, fix the navigation template. If focus gets obscured by your sticky header, fix the header logic globally. Issue-by-issue fixes without addressing the source create a maintenance problem.

Ignoring authentication. Login forms are one of the most commonly overlooked areas. Verify that password managers can autofill your login form correctly. If they can’t, that’s a failure under 3.3.8.

What Comes After WCAG 2.2?

WCAG 3.0 is in active development. It represents a more significant structural departure from the 2.x series, introducing a new conformance model and expanded guidance on cognitive accessibility. As of 2026, it remains a working draft and is not yet referenced by any legal standard.

The practical implication: WCAG 2.2 AA is the target for the foreseeable future. Organizations that meet it will be well-positioned when 3.0 eventually becomes a formal requirement, since the underlying principles remain consistent across versions.

The Bottom Line

WCAG 2.2 has been the current standard for over two years. The changes from 2.1 are real but manageable. Nine new criteria, mostly focused on mobile usability, cognitive accessibility, and authentication, with one outdated criterion removed.

If your site was last audited against WCAG 2.1, the gap is worth closing. The new AA-level requirements address genuine barriers that real users encounter, and the legal and regulatory landscape is already treating WCAG 2.2 as the expected baseline.

Run a free scan with Scanluma to see exactly where your site stands against the current WCAG 2.2 criteria, organized by severity and mapped to specific fixes.

Related reading: