WCAG 2.2: Complete Guide to the 9 New Success Criteria

10/13/2025

16 min read

A11yied Team

Two years after its release in October 2023, WCAG 2.2 has become the standard for web accessibility compliance—especially following the European Accessibility Act (EAA) deadline in June 2025. If you're still working with WCAG 2.1, now is the time to upgrade.

This comprehensive guide explains all 9 new success criteria introduced in WCAG 2.2, who they help, and how to implement them correctly. Whether you're a developer fixing focus styles or a product manager planning compliance work, you'll leave with actionable knowledge to make your digital products more accessible.

What Changed in WCAG 2.2?

WCAG 2.2 builds on version 2.1 by adding 9 new success criteria focused on three key areas:

Focus visibility - Making keyboard navigation clearer
Mobile accessibility - Improving touch target sizes and drag interactions
Cognitive accessibility - Reducing memory burden and authentication friction

WCAG 2.1 vs 2.2: Quick Comparison

Aspect	WCAG 2.1	WCAG 2.2
Release Date	June 2018	October 2023
Total Success Criteria	78	87
New Criteria	17 (vs 2.0)	9 (vs 2.1)
Focus Areas	Mobile, low vision, cognitive	Focus appearance, authentication, mobile gestures
Level A Criteria	30	32
Level AA Criteria	20	24
Level AAA Criteria	28	31
Removed Criteria	0	1 (4.1.1 Parsing - obsolete)

Key takeaway: WCAG 2.2 doesn't replace 2.1—it extends it. All WCAG 2.1 requirements still apply.

The 9 New Success Criteria Explained

Focus Visibility Improvements (3 Criteria)

2.4.11 Focus Appearance (Minimum) - Level AA

What it requires: When a UI component receives keyboard focus, the focus indicator must be visible and meet specific size and contrast requirements:

Minimum area: At least as large as a 2 CSS pixel thick perimeter around the component
Contrast ratio: At least 3:1 against adjacent colors
Changes clearly: The focused state must look noticeably different from the unfocused state

Who benefits:

Keyboard-only users who can't use a mouse due to motor disabilities
Power users who prefer keyboard navigation for efficiency
Screen magnifier users who need clear visual cues about focus location

Common violations:

<!-- ❌ Bad: Focus indicator too subtle -->
<button style="outline: 1px dotted #ccc;">
  Submit
</button>

<!-- ❌ Bad: Focus indicator removed entirely -->
<a href="/page" style="outline: none;">
  Read more
</a>

<!-- ✅ Good: Clear, high-contrast focus indicator -->
<button style="outline: 2px solid #0066cc; outline-offset: 2px;">
  Submit
</button>

Real-world impact: A study by WebAIM found that 68% of keyboard users struggle with sites that have poor focus indicators. This criterion makes keyboard navigation viable for millions of users.

2.4.12 Focus Not Obscured (Minimum) - Level AA

What it requires: When a UI component receives keyboard focus, it must not be entirely hidden by other content. At least part of the focused element must remain visible.

Who benefits:

Keyboard users who need to see where focus is located
Users with cognitive disabilities who may lose track of focus if it disappears
Screen magnifier users navigating through interfaces

Common scenarios:

Sticky headers that cover focused elements when scrolling
Modal dialogs that don't trap focus properly
Fixed navigation bars that overlap form fields
Cookie consent banners that hide focused content

The problem: Imagine tabbing through a form, only to have your focus disappear behind a sticky header. You know focus moved—but where? This creates confusion and breaks the navigation flow.

The solution: Implement scroll-into-view behavior when elements receive focus, ensuring they're always visible above fixed UI elements.

2.4.13 Focus Appearance (Enhanced) - Level AAA

What it requires: A stricter version of 2.4.11 with higher standards:

Minimum area: At least 2 CSS pixels thick around the entire component perimeter
Contrast ratio: At least 4.5:1 (matching text contrast requirements)
No exceptions: Applies to all interactive elements without exception

Who benefits: Users with low vision who need maximum visual clarity to perceive focus indicators.

When to implement: If you're building government systems, healthcare applications, or products specifically designed for accessibility, aim for this AAA standard. While not required for most compliance work, it represents best practice.

Mobile and Motor Accessibility (2 Criteria)

2.5.7 Dragging Movements - Level AA

What it requires: All functionality that uses dragging movements must also be achievable through simple pointer actions (like clicking or tapping) without requiring dragging.

Who benefits:

Users with tremors or limited fine motor control who can't perform precise dragging
Mobile users with hand impairments
Assistive technology users with alternative input devices

Affected interactions:

Drag-and-drop file uploads → Provide a "Browse files" button
Sortable lists → Provide up/down arrow buttons
Range sliders → Provide number input or +/- buttons
Image croppers → Provide preset crop ratios or coordinate inputs

Example scenarios:

<!-- ❌ Bad: Only drag-and-drop available -->
<div class="dropzone">
  Drag files here to upload
</div>

<!-- ✅ Good: Drag-and-drop PLUS alternative -->
<div class="dropzone">
  Drag files here to upload
</div>
<button type="button">Or browse files</button>

<!-- ✅ Good: Slider with alternative input -->
<div>
  <input type="range" min="0" max="100" value="50" aria-label="Volume">
  <input type="number" min="0" max="100" value="50" aria-label="Volume (numeric)">
</div>

Important exception: If dragging is essential to the functionality (like a drawing or signature application), this criterion doesn't apply—but consider if there's any way to provide alternatives.

2.5.8 Target Size (Minimum) - Level AA

What it requires: Interactive elements must be at least 24×24 CSS pixels, ensuring they're large enough to activate without accidentally hitting adjacent targets.

Who benefits:

Users with motor impairments who have difficulty with precise movements
Mobile users tapping with fingers on small screens
Older adults with decreased dexterity
Anyone using a device in motion (walking, riding transit)

Exceptions (you don't need 24×24 pixels if):

Spacing: The target is smaller but has sufficient spacing (24px) from other targets
Inline: The target is in a sentence or block of text
User agent controlled: The browser controls the sizing (like default form controls)
Essential: A particular size is legally or functionally required

Common violations:

Social media share icons under 24×24px
Pagination links with small click areas
Close buttons on modals
Icon-only buttons without adequate padding

Quick audit: Use browser DevTools to measure interactive elements. If you see width: 20px; height: 20px; on a button, you're below the threshold.

Cognitive and Input Accessibility (4 Criteria)

3.2.6 Consistent Help - Level A

What it requires: If help mechanisms appear on multiple pages, they must be in the same relative order on each page.

Examples of help mechanisms:

Contact information (phone, email, address)
Live chat widgets
Self-help options (FAQ links)
Contact forms

Who benefits:

Users with cognitive disabilities who rely on predictable patterns
Users with memory impairments who have difficulty remembering where help is located
Anyone in a stressful situation needing quick access to support

The problem: Imagine looking for customer service contact info. On the homepage, it's in the footer. On the product page, it's in the header. On the checkout page, it's in a sidebar. This inconsistency creates unnecessary cognitive load.

The solution: Pick a location and stick with it. If your footer has "Contact Us → FAQ → Live Chat" on one page, maintain that exact order throughout the site.

Important note: This doesn't mean help must appear on every page—only that when it does appear, it's consistently positioned.

3.3.7 Redundant Entry - Level A

What it requires: Information previously entered by the user in the same process must be either auto-filled or available for selection—users shouldn't have to enter the same information twice.

Who benefits:

Users with cognitive disabilities who struggle to remember previously entered information
Users with motor disabilities for whom typing is physically taxing
Mobile users dealing with small keyboards

Common scenarios:

Shipping and billing addresses that are identical
Email confirmation fields
Multi-step forms asking for the same data
Payment information across checkout steps

Acceptable solutions:

Auto-populate: Fill fields automatically with previously entered data
Selection: Let users select from previously entered options (checkboxes like "Same as shipping address")
Session persistence: Remember data across form steps

Exceptions: You can ask for the same information twice if:

It's essential for security (password confirmation)
Previous information is no longer valid
Re-entering confirms user intent

Example in practice: E-commerce checkout flows should offer "Use shipping address for billing" checkboxes rather than forcing users to type addresses twice.

3.3.8 Accessible Authentication (Minimum) - Level AA

What it requires: Authentication processes must not require users to solve cognitive function tests (like memorizing passwords or solving puzzles) unless an alternative is provided.

Acceptable authentication methods:

Password managers (let users paste passwords)
Email/SMS verification codes the user can copy from another application
Biometric authentication (fingerprint, Face ID)
Personal information available to the user (username, email address)
Object recognition (select items from a personal image library)

Unacceptable without alternatives:

Memorizing passwords without paste functionality
Transcribing characters from images (distorted CAPTCHAs)
Remembering and typing security questions from memory

Who benefits:

Users with cognitive disabilities who struggle with memory tasks
Users with dyslexia who have difficulty transcribing text
Users with intellectual disabilities who find puzzles challenging

The CAPTCHA problem: Traditional distorted-text CAPTCHAs fail this criterion. Acceptable alternatives include:

reCAPTCHA v3 (invisible behavioral analysis)
hCaptcha Accessibility cookie (bypasses challenges for verified users)
Device-based authentication
Email verification links

Code consideration:

<!-- ❌ Bad: Password field blocking paste -->
<input
  type="password"
  onpaste="return false;"
  autocomplete="off"
>

<!-- ✅ Good: Allow paste and autocomplete -->
<input
  type="password"
  autocomplete="current-password"
>

Real-world impact: Many users rely on password managers due to memory impairments. Blocking paste functionality creates an insurmountable barrier for these users.

3.3.9 Accessible Authentication (Enhanced) - Level AAA

What it requires: A stricter version of 3.3.8 that eliminates cognitive function tests entirely, even for object recognition tasks.

The difference from 3.3.8: At Level AA, you can use object recognition (like "select all images containing traffic lights"). At Level AAA, even this is not allowed unless the objects are provided by the user themselves.

Acceptable at AAA level:

Passwordless authentication (magic links via email)
Biometric authentication only
Hardware security keys (YubiKey, etc.)
Authentication apps (Google Authenticator, Authy) that the user chooses

Who benefits: Users with severe cognitive disabilities who cannot complete any form of cognitive challenge.

When to implement: Healthcare applications, government services, and financial systems serving vulnerable populations should consider this standard.

How A11yied Tests WCAG 2.2 Criteria

A11yied's browser-based validation engine implements automated checks for the testable WCAG 2.2 criteria:

Automated Detection

2.4.11 Focus Appearance (Minimum):

Measures actual focus indicator dimensions using browser computed styles
Calculates contrast ratios between focus states and adjacent colors
Validates outline thickness meets 2px minimum
Reports specific contrast values in findings

2.5.8 Target Size (Minimum):

Measures interactive element bounding boxes in real browser context
Calculates spacing between adjacent clickable targets
Identifies elements below 24×24px threshold
Accounts for exceptions (inline text links, spacing rules)

3.2.6 Consistent Help:

Scans multiple pages to identify help mechanisms
Compares relative order of help elements across pages
Flags inconsistencies in help placement
Validates same-order requirements across site

3.3.7 Redundant Entry:

Analyzes multi-step forms for repeated input requests
Checks for autocomplete attributes on form fields
Validates auto-population mechanisms
Flags duplicate information requests

3.3.8 Accessible Authentication:

Detects password fields with paste disabled
Checks for missing autocomplete attributes
Identifies traditional CAPTCHA implementations
Validates alternative authentication paths exist

Manual Review Guidance

Some criteria require human judgment:

2.4.12 Focus Not Obscured: A11yied flags fixed-position elements that may obscure focus but requires manual keyboard testing to confirm actual obstruction scenarios.

2.4.13 Focus Appearance (Enhanced): Automated checks for enhanced 4.5:1 contrast with manual verification recommendations.

2.5.7 Dragging Movements: Identifies drag interactions through event listeners but requires manual confirmation that alternatives exist.

3.3.9 Accessible Authentication (Enhanced): Flags authentication patterns requiring cognitive tests with recommendations for passwordless alternatives.

Migration Guide: Moving from WCAG 2.1 to 2.2

Step 1: Audit Current State (Week 1)

Run an A11yied scan to identify existing violations against WCAG 2.2 criteria. Focus on:

Focus indicators: Check every interactive element
Touch targets: Measure buttons, links, and controls
Forms: Review multi-step processes for redundant entry
Authentication: Test login and registration flows

Expected findings: Most sites will have focus appearance and target size issues.

Step 2: Prioritize by Impact (Week 1-2)

High priority (affects daily user experience):

2.5.8 Target Size (Minimum) - AA
2.4.11 Focus Appearance (Minimum) - AA
3.3.7 Redundant Entry - A

Medium priority (requires code changes):

2.5.7 Dragging Movements - AA
3.3.8 Accessible Authentication - AA
2.4.12 Focus Not Obscured - AA

Lower priority (often already compliant):

3.2.6 Consistent Help - A (many sites already do this)

Aspirational (AAA criteria):

2.4.13 Focus Appearance (Enhanced)
3.3.9 Accessible Authentication (Enhanced)

Step 3: Implement Changes (Weeks 2-6)

Quick wins (1-2 weeks):

Update global CSS for focus styles:

/* Add to your base stylesheet */
*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Increase button minimum sizes:

/* Update button base styles */
button, .btn {
  min-height: 44px;
  min-width: 44px;
  padding: 8px 16px;
}

Medium effort (2-3 weeks):

Add alternative inputs for drag interactions
Implement scroll-into-view for focus management
Add autocomplete attributes to forms
Remove paste-blocking on password fields

Larger refactors (3-6 weeks):

Redesign authentication flows
Consolidate help mechanism locations
Implement session-based form persistence
Update component libraries with new standards

Step 4: Continuous Monitoring

Integrate A11yied into CI/CD: Catch regressions before they reach production. Set up automated scans on pull requests to ensure new code maintains WCAG 2.2 compliance.

Quarterly audits: Run comprehensive scans every quarter to catch issues introduced by new features.

Training: Educate your team about the new criteria so compliance becomes part of your development culture, not an afterthought.

Common Migration Challenges

Challenge 1: Focus Styles Breaking Design System

Problem: Design teams resist prominent focus indicators, claiming they're "ugly" or "inconsistent with brand."

Solution:

Show designers examples from major brands (Google, Microsoft, Apple) using clear focus styles
Demonstrate that 3:1 contrast allows brand colors—just requires thoughtful implementation
Use outline-offset to create space between outline and element
Consider :focus-visible to show outlines only for keyboard users

Challenge 2: Small Touch Targets in Dense UIs

Problem: Data tables, calendars, and mobile navs have many small interactive elements.

Solution:

Use the spacing exception: smaller elements with 24px gaps are compliant
Consider responsive design: smaller on desktop, larger on mobile
Evaluate if all elements need to be interactive (maybe show details on row click, not cell)

Challenge 3: Drag-and-Drop Components

Problem: Existing sortable lists and file uploaders only support dragging.

Solution:

Add keyboard controls (arrow keys + modifier for reordering)
Provide "Move up/down" buttons for mouse and touch users
For file uploads, always include a traditional file input button

Challenge 4: Authentication Systems

Problem: Third-party authentication providers may not meet 3.3.8 standards.

Solution:

Prioritize providers with passwordless options (email magic links)
Enable OAuth/SSO (Google, Microsoft, Apple) as alternatives
If using CAPTCHA, implement hCaptcha Accessibility or reCAPTCHA v3
Ensure password fields allow paste and have proper autocomplete

Frequently Asked Questions

Do I need to comply with WCAG 2.2 immediately?

In Europe: Yes. The European Accessibility Act (EAA) requires WCAG 2.2 Level AA compliance as of June 2025.

In the US: Section 508 still references WCAG 2.0, but best practice is to implement 2.2. The ADA doesn't specify a WCAG version, but courts increasingly expect current standards.

Globally: WCAG 2.2 is the internationally recognized standard. Most accessibility professionals now audit against 2.2.

Can I claim WCAG 2.1 conformance instead?

Technically yes, but it's not recommended. WCAG 2.2 builds on 2.1, and the new criteria address critical accessibility barriers. Staying on 2.1 means ignoring known issues that affect real users.

Are WCAG 2.1 and 2.2 mutually exclusive?

No—WCAG 2.2 is fully backward compatible. If you conform to WCAG 2.2, you automatically conform to WCAG 2.1. However, conforming to 2.1 does not mean you conform to 2.2.

What happened to WCAG 2.1 criterion 4.1.1 Parsing?

It was removed in WCAG 2.2 because modern browsers handle HTML parsing errors gracefully. Invalid HTML is no longer a conformance barrier, though valid HTML is still best practice.

How long does WCAG 2.2 migration typically take?

For most organizations:

Small sites (< 50 pages): 2-4 weeks
Medium sites (50-200 pages): 4-8 weeks
Large sites (200+ pages): 8-16 weeks
Complex applications: 3-6 months

Timelines depend heavily on existing technical debt and team familiarity with accessibility.

Do I need to test every criterion manually?

No. A11yied automates testing for most criteria, but some require manual verification:

2.4.12 Focus Not Obscured needs keyboard testing
2.5.7 Dragging Movements needs interaction testing
Cognitive criteria need user flow analysis

Combine automated A11yied scans with targeted manual testing for best results.

What about WCAG 3.0?

WCAG 3.0 (formerly called Silver) is still in draft status and not expected to become a recommendation until 2026 or later. Focus on WCAG 2.2 compliance now—it will remain the standard for years to come.

How do AAA criteria affect compliance?

Level AAA criteria (2.4.13, 3.3.9) are not required for general WCAG 2.2 AA conformance. However, they represent best practices and may be required for:

Government websites in certain jurisdictions
Healthcare applications
Educational institutions
Organizations with specific accessibility commitments

Start Your WCAG 2.2 Compliance Journey

WCAG 2.2 represents meaningful progress toward a more accessible web. The 9 new success criteria address real barriers faced by users with disabilities every day—from unclear focus indicators to inaccessible authentication flows.

Take action today:

Audit your site: Run a comprehensive A11yied scan to identify WCAG 2.2 violations
Fix quick wins: Update focus styles and touch target sizes in your global CSS
Plan migrations: Prioritize authentication and form improvements
Educate your team: Share this guide with designers, developers, and product managers

A11yied makes WCAG 2.2 compliance achievable by providing specific, actionable guidance for each criterion. Our browser-based validation catches issues that static analyzers miss, giving you confidence that your fixes actually work.

Ready to ensure your website meets WCAG 2.2 standards? Start your free A11yied scan today and get a comprehensive report showing exactly which criteria need attention—complete with code examples and fix recommendations.

Last updated: October 2025. Written by the A11yied team based on the official WCAG 2.2 recommendation published October 5, 2023 by the W3C.

Back to Blog