Skip to main content
Back to Blog
Compliance

WCAG 2.2: Complete Compliance Guide 2025 - All 9 New Success Criteria

Complete WCAG 2.2 compliance resource hub. Understand all 9 new success criteria, implementation guides, testing protocols, and legal requirements. Your comprehensive guide to WCAG 2.2 AA compliance in 2025.

AllAccessible Team
15 min read
WCAG 2.2Web AccessibilityComplianceSuccess CriteriaADASection 508
WCAG 2.2: Complete Compliance Guide 2025 - All 9 New Success Criteria

WCAG 2.2: Complete Compliance Guide 2025

WCAG 2.2 is the current W3C accessibility standard, adding 9 new success criteria to improve accessibility for users with cognitive disabilities, low vision, and mobile users. Released October 5, 2023, WCAG 2.2 is now the recommended legal standard for ADA, Section 508, and the European Accessibility Act (EAA).

This is your complete resource hub for WCAG 2.2 compliance. Everything you need to understand, implement, and maintain compliance with all 9 new success criteria.

📋 Table of Contents

  1. What's New in WCAG 2.2
  2. The 9 New Success Criteria
  3. Implementation Priority Guide
  4. Legal & Regulatory Context
  5. Testing & Validation
  6. Complete Resource Library

What's New in WCAG 2.2

Key Changes

Release Date: October 5, 2023 Status: Current W3C Recommendation Backward Compatibility: ✅ Fully compatible with WCAG 2.1 (no criteria removed)

Focus Areas

1. Mobile Accessibility

  • Target size requirements for touch interfaces
  • Focus visibility on mobile devices
  • Dragging alternatives for mobile interactions

2. Cognitive Accessibility

  • Simplified authentication methods
  • Consistent help mechanisms
  • Redundant entry prevention

3. Low Vision Users

  • Enhanced focus indicators
  • Improved visibility requirements
  • Better contrast for UI components

The Numbers

  • 9 new success criteria added
  • 3 at Level A (minimum accessibility)
  • 6 at Level AA (recommended legal standard)
  • 0 criteria removed (backward compatible)
  • 86 total criteria across all levels (A, AA, AAA)

The 9 New Success Criteria

Level AA Criteria (Legal Standard)

🎯 2.4.11 Focus Not Obscured (Minimum) - Level AA

What it requires: When a keyboard-focusable element receives focus, at least part of it must not be completely hidden by author-created content (like sticky headers or footers).

Why it matters: Keyboard users need to see where focus is to navigate effectively. Sticky headers that cover focused elements create confusion and prevent task completion.

Who benefits:

  • Keyboard-only users (motor disabilities)
  • Screen magnification users
  • Users navigating with screen readers

Quick implementation:

/* Add scroll padding to prevent sticky header obscuring focus */
html {
  scroll-padding-top: 100px; /* Height of sticky header + buffer */
}

/* Ensure focused elements scroll into view with clearance */
*:focus {
  scroll-margin-top: 120px;
}

📖 Read the complete guide: Focus Not Obscured (Minimum): Implementation Guide (Coming soon)

🎯 2.4.12 Focus Not Obscured (Enhanced) - Level AAA

What it requires: When a keyboard-focusable element receives focus, no part of it is hidden by author-created content.

Difference from 2.4.11: Level AA (2.4.11) allows partial obscuring. Level AAA (2.4.12) requires the entire element to be visible.

When to implement:

  • Government websites
  • Healthcare applications
  • Educational platforms
  • High-stakes forms (financial, legal)

📖 Read the complete guide: Focus Not Obscured (Enhanced): Implementation Guide (Coming soon)

🎯 2.4.13 Focus Appearance - Level AAA

What it requires: When the keyboard focus indicator is visible, it must:

  • Be at least 2 CSS pixels thick
  • Have 3:1 contrast against adjacent colors
  • Not be obscured by other content

Why it matters: Ensures focus indicators are clearly visible for users with low vision or color vision deficiencies.

Quick implementation:

*:focus {
  outline: 3px solid #0066CC; /* At least 2px thick, high contrast */
  outline-offset: 2px;
}

📖 Read the complete guide: Focus Appearance: Implementation Guide (Coming soon)

🎯 2.5.7 Dragging Movements - Level AA

What it requires: All functionality that uses dragging movements must have a single-pointer (click/tap/keyboard) alternative.

Examples:

  • Drag-and-drop file uploads → Add "Browse" button
  • Slider controls → Add increment/decrement buttons or keyboard support
  • Sortable lists → Add up/down arrow buttons
  • Map pan/zoom → Add +/- buttons and keyboard controls

Who benefits:

  • Users with tremors or limited dexterity
  • Touch device users
  • Keyboard-only users
  • Screen reader users

Quick implementation:

<!-- Sortable list with keyboard alternative -->
<ul role="list">
  <li draggable="true" tabindex="0">
    <button aria-label="Move up">↑</button>
    <button aria-label="Move down">↓</button>
    Task 1
  </li>
</ul>

📖 Read the complete guide: Dragging Movements: Implementation Guide (Coming soon)

🎯 2.5.8 Target Size (Minimum) - Level AA

What it requires: Interactive targets (buttons, links, form inputs) must be at least 24×24 CSS pixels.

Exceptions:

  • Inline links within paragraphs can be smaller
  • Targets controlled by user agent (browser controls)
  • Essential presentation (where size is critical to meaning)

Why it matters: Small touch targets are difficult to activate for users with:

  • Motor impairments
  • Tremors
  • Large fingers
  • Screen magnification

Quick implementation:

/* Ensure minimum 24×24px touch targets */
button,
a,
input,
select,
textarea {
  min-width: 24px;
  min-height: 24px;
  padding: 4px; /* Visual content can be smaller, clickable area 24×24 */
}

/* Primary actions should be even larger */
.primary-button {
  min-width: 44px;
  min-height: 44px;
}

📖 Read the complete guide: Target Size (Minimum): Implementation Guide (Coming soon)

🎯 3.2.6 Consistent Help - Level A

What it requires: When help mechanisms appear on multiple pages (contact link, chat widget, help page, phone number), they must appear in the same relative order.

Examples:

  • Chat widget always in bottom-right corner
  • Help link always last item in navigation
  • Contact form link always in footer (same position)

Why it matters: Consistent placement reduces cognitive load for users with:

  • Learning disabilities
  • Memory impairments
  • Cognitive disabilities
  • Users new to your site

Quick implementation:

<!-- All pages: Help in consistent location -->
<header>
  <nav>
    <a href="/">Home</a>
    <a href="/products">Products</a>
    <a href="/about">About</a>
    <a href="/help">Help</a> <!-- Always last in nav -->
  </nav>
</header>

<!-- Fixed chat widget (always bottom-right) -->
<button
  class="chat-widget"
  style="position: fixed; bottom: 20px; right: 20px;"
  aria-label="Open help chat">
  Help
</button>

📖 Read the complete guide: Consistent Help: Implementation Guide (Coming soon)

🎯 3.3.7 Redundant Entry - Level A

What it requires: Don't make users enter the same information twice within a single process unless:

  • It's essential for security (confirm password)
  • Previously entered information is no longer valid

Examples:

  • Copy shipping address to billing address
  • Pre-fill form fields from previous steps
  • Use autocomplete attributes
  • Remember user preferences

Why it matters: Reduces cognitive load and errors for users with:

  • Memory impairments
  • Cognitive disabilities
  • Motor impairments (typing is difficult)

Quick implementation:

<form>
  <!-- Option to use same address -->
  <fieldset>
    <legend>Billing Address</legend>
    <label>
      <input type="checkbox" id="same-as-shipping" checked>
      Same as shipping address
    </label>

    <div id="billing-fields" style="display:none;">
      <!-- Billing fields only shown if needed -->
    </div>
  </fieldset>

  <!-- Use autocomplete to remember data -->
  <label for="email">Email</label>
  <input type="email" id="email" autocomplete="email">

  <label for="phone">Phone</label>
  <input type="tel" id="phone" autocomplete="tel">
</form>

📖 Read the complete guide: Redundant Entry: Implementation Guide (Coming soon)

🎯 3.3.8 Accessible Authentication (Minimum) - Level AA

What it requires: Cognitive function tests (remembering passwords, solving puzzles) must have an alternative method such as:

  • Password managers/autofill
  • Email/SMS one-time codes
  • Biometric authentication
  • Object recognition (not text transcription)

Examples to avoid:

  • ❌ CAPTCHA with distorted text (no audio alternative)
  • ❌ "Remember your password" with no password manager support
  • ❌ Math puzzles to prove you're human
  • ❌ "Type these characters exactly as shown"

Compliant alternatives:

  • ✅ Allow password managers (autocomplete="current-password")
  • ✅ Email verification codes
  • ✅ SMS/text message codes
  • ✅ Biometric (Face ID, Touch ID, fingerprint)
  • ✅ reCAPTCHA v3 (invisible, no user interaction)

Quick implementation:

<form>
  <label for="password">Password</label>
  <input
    type="password"
    id="password"
    autocomplete="current-password"
    aria-describedby="password-help">
  <p id="password-help">Your browser can save this password for you.</p>

  <button type="submit">Log In</button>
</form>

<p>
  <a href="/reset-password">Forgot password?</a>
  (We'll email you a reset link - no cognitive test required)
</p>

📖 Read the complete guide: Accessible Authentication: Implementation Guide (Coming soon)

🎯 3.3.9 Accessible Authentication (Enhanced) - Level AAA

What it requires: Same as 3.3.8, but with no exceptions. All cognitive function tests must have alternatives.

Difference from 3.3.8:

  • Level AA (3.3.8) allows object recognition as authentication
  • Level AAA (3.3.9) requires alternatives that don't rely on any cognitive tests

When to implement:

  • Government services
  • Healthcare portals
  • Educational platforms
  • Critical public services

📖 Read the complete guide: Accessible Authentication (Enhanced): Implementation Guide (Coming soon)

Implementation Priority Guide

Phase 1: Critical (Week 1-2)

Start with these 3 high-impact criteria:

  1. 2.5.8 Target Size (Minimum) - Easiest to implement

    • Audit all buttons, links, inputs
    • Add CSS for min-width/min-height: 24px
    • Test on mobile devices
    • Time: 4-8 hours

  2. 3.3.7 Redundant Entry - High user satisfaction

    • Add "same as shipping" checkboxes
    • Implement autocomplete attributes
    • Review multi-step forms
    • Time: 6-12 hours

  3. 3.2.6 Consistent Help - Quick win

    • Audit help mechanism locations
    • Move to consistent positions
    • Update all page templates
    • Time: 2-4 hours

Phase 2: Important (Week 3-4)

  1. 3.3.8 Accessible Authentication - Legal requirement

    • Enable password manager support
    • Add email/SMS verification option
    • Replace CAPTCHAs with reCAPTCHA v3
    • Time: 8-16 hours

  2. 2.5.7 Dragging Movements - User experience

    • Audit drag-and-drop interactions
    • Add keyboard alternatives
    • Implement click/tap alternatives
    • Time: 12-20 hours

Phase 3: Enhanced (Week 5-6)

  1. 2.4.11 Focus Not Obscured (Minimum) - Technical

    • Add scroll-padding to prevent obscuring
    • Test with sticky headers/footers
    • Fix modal focus management
    • Time: 8-12 hours

  2. 2.4.7 Focus Visible (existing WCAG 2.1, often forgotten)

    • Ensure all interactive elements have visible focus
    • Add 3px outlines with high contrast
    • Test keyboard navigation
    • Time: 4-8 hours

Phase 4: Optional AAA (Future)

  1. 2.4.12 Focus Not Obscured (Enhanced) - AAA level
  2. 2.4.13 Focus Appearance - AAA level
  3. 3.3.9 Accessible Authentication (Enhanced) - AAA level

When to implement AAA:

  • Government contracts requiring AAA
  • Healthcare/medical platforms
  • Educational institutions
  • Organizations with high accessibility maturity

Legal & Regulatory Context

United States

ADA Title III

  • Current standard: WCAG 2.1 Level AA (courts reference this)
  • Emerging standard: WCAG 2.2 Level AA (DOJ updating guidance)
  • Lawsuits: 4,605 federal lawsuits filed in 2024
  • Trend: Courts increasingly citing WCAG 2.2

Section 508

  • Current: WCAG 2.0 Level AA (outdated)
  • Update expected: WCAG 2.2 AA by 2026
  • Applies to: Federal agencies and contractors
  • Enforcement: Access Board, DOJ

State Laws:

  • California (Unruh Act): WCAG 2.1 AA minimum
  • New York (NYCCHR): WCAG 2.0/2.1 AA
  • Colorado (HB21-1110): WCAG 2.1 AA for state websites

European Union

European Accessibility Act (EAA)

  • Enforcement: June 28, 2025 (now in force)
  • Standard: EN 301 549 (harmonized with WCAG 2.1 AA)
  • Update: Moving to WCAG 2.2 AA
  • Applies to: E-commerce, banking, transport, ebooks, communication services
  • Penalties: Up to €100,000 or 4% of annual revenue

Web Accessibility Directive (WAD)

  • Applies to: Public sector websites
  • Standard: WCAG 2.1 Level AA
  • Monitoring: Member states conduct audits
  • Reporting: Accessibility statements required

Other Jurisdictions

United Kingdom:

  • Equality Act 2010: Reasonable adjustments required
  • Public Sector: WCAG 2.1 AA mandatory

Canada:

  • Accessible Canada Act: Phased WCAG 2.1 AA
  • AODA (Ontario): WCAG 2.0 AA (updating to 2.1/2.2)

Australia:

  • DDA 1992: WCAG 2.1 AA recommended
  • Government: AS EN 301 549 required

Testing & Validation

Automated Testing Tools

1. axe DevTools (Recommended)

2. WAVE (WebAIM)

3. Lighthouse (Chrome)

  • Built into Chrome DevTools
  • Accessibility scoring
  • WCAG 2.2 checks included

4. Pa11y (Command Line)

npm install -g pa11y
pa11y --standard WCAG2AA https://your-site.com

Manual Testing Protocol

1. Keyboard Navigation (30 minutes)

  • Tab through entire site
  • Verify focus visible (2.4.7)
  • Check focus not obscured (2.4.11)
  • Test all interactive elements
  • Verify no keyboard traps

2. Touch Target Testing (20 minutes)

  • Measure button/link sizes (dev tools)
  • Verify 24×24px minimum (2.5.8)
  • Test on mobile device
  • Check spacing between targets

3. Form Testing (40 minutes)

  • Verify autocomplete attributes (3.3.7)
  • Check for redundant entry (3.3.7)
  • Test password manager support (3.3.8)
  • Verify consistent help placement (3.2.6)

4. Interaction Testing (30 minutes)

  • Test drag-drop alternatives (2.5.7)
  • Verify keyboard alternatives
  • Check slider controls
  • Test sortable lists

Screen Reader Testing

NVDA (Windows - Free):

  1. Download: https://www.nvaccess.org/
  2. Navigate site with keyboard
  3. Verify focus announcements
  4. Test form interactions

VoiceOver (Mac - Built-in):

  1. Enable: Cmd+F5
  2. Navigate with VO+Arrow keys
  3. Test interactive elements
  4. Verify help mechanisms consistent

Complete Resource Library

📥 Free Downloads

WCAG 2.2 Compliance Checklist

  • All 9 new criteria checklist
  • Implementation priority guide
  • Testing protocols
  • Download PDF → (Coming soon)

Code Examples Repository

  • HTML/CSS/JavaScript examples
  • React component library
  • WordPress snippets
  • View on GitHub → (Coming soon)

Testing Template

  • Manual testing checklist
  • Automated testing scripts
  • Report templates
  • Download → (Coming soon)

📚 Deep Dive Guides

By Success Criterion:

  1. 2.4.11 Focus Not Obscured (Minimum) (Coming soon)
  2. 2.4.12 Focus Not Obscured (Enhanced) (Coming soon)
  3. 2.4.13 Focus Appearance (Coming soon)
  4. 2.5.7 Dragging Movements (Coming soon)
  5. 2.5.8 Target Size (Minimum) (Coming soon)
  6. 3.2.6 Consistent Help (Coming soon)
  7. 3.3.7 Redundant Entry (Coming soon)
  8. 3.3.8 Accessible Authentication (Minimum) (Coming soon)
  9. 3.3.9 Accessible Authentication (Enhanced) (Coming soon)

Implementation Guides:

🔗 Related Resources

Compliance Guides:

Platform Guides:

Legal Context:

Quick Start Guide

New to WCAG 2.2?

Step 1: Assess Current State (Week 1)

  1. Run automated scan (axe DevTools)
  2. Identify WCAG 2.2 gaps
  3. Prioritize fixes by impact

Step 2: Implement Critical Fixes (Week 2-3)

  1. Fix target sizes (2.5.8)
  2. Add redundant entry prevention (3.3.7)
  3. Make help consistent (3.2.6)

Step 3: Advanced Implementation (Week 4-6)

  1. Add dragging alternatives (2.5.7)
  2. Enable accessible authentication (3.3.8)
  3. Fix focus obscuring (2.4.11)

Step 4: Continuous Monitoring

  1. Integrate automated testing in CI/CD
  2. Quarterly manual audits
  3. Stay updated on WCAG updates

Frequently Asked Questions

Q: Is WCAG 2.2 required by law? A: Not yet universally, but it's the recommended standard. The EAA (EU) and Section 508 (U.S.) are updating to reference WCAG 2.2. Many courts now cite WCAG 2.2 in ADA lawsuits.

Q: Do I need to implement all 9 new criteria? A: For Level AA compliance (legal standard), you need 6 of the 9 criteria. The 3 Level AAA criteria are optional but recommended for government/healthcare.

Q: Is WCAG 2.2 backward compatible with 2.1? A: Yes! WCAG 2.2 adds criteria but doesn't remove any. If you're WCAG 2.1 AA compliant, you only need to implement the 6 new Level AA criteria.

Q: What's the timeline to become WCAG 2.2 compliant? A: 4-8 weeks for most sites with moderate accessibility issues. Simple sites: 2-3 weeks. Complex web apps: 2-3 months.

Q: Can automated tools check WCAG 2.2? A: Partially. Automated tools detect ~40% of WCAG 2.2 issues. Manual testing required for focus visibility, consistent help, redundant entry, and authentication.

Q: What's the difference between Level AA and AAA? A: Level AA = legal compliance standard (recommended). Level AAA = enhanced accessibility (optional, not achievable for all content).

Get Expert Help

AllAccessible Platform:

  • Automated WCAG 2.2 scanning
  • Real-time remediation
  • Compliance monitoring
  • Expert manual audits
  • Starting at $10/month

Start Free Trial →

Need a Custom Audit?

  • Comprehensive WCAG 2.2 AA assessment
  • Detailed remediation roadmap
  • Developer training
  • Ongoing support

Contact Us →

Stay Updated

WCAG 2.2 is the current standard, but accessibility evolves. WCAG 3.0 is in development (expected 2026+).

Subscribe for updates:

  • New WCAG releases
  • Legal developments
  • Implementation guides
  • Best practices

Subscribe to Newsletter → (Coming soon)

Published: November 25, 2025 Last Updated: November 25, 2025 Reading Time: 25 minutes

About this guide: This is a living document updated regularly as new WCAG 2.2 resources, legal developments, and implementation techniques emerge. Bookmark this page as your WCAG 2.2 resource hub.

About AllAccessible: We provide automated WCAG 2.2 compliance solutions including real-time monitoring, AI-powered remediation, and comprehensive manual audits. Learn more at allaccessible.org.

Share this article