The Complete Guide to WCAG 2.2 Compliance in 2025

Introduction

Web accessibility isn't optional anymore — it's a legal requirement in an increasing number of jurisdictions, and WCAG 2.2 is the benchmark. Published by the W3C's Web Accessibility Initiative, the latest version of the Web Content Accessibility Guidelines introduces nine new success criteria that address real-world gaps left by WCAG 2.1.

Whether you're a developer shipping production code, a designer crafting user flows, or a product owner steering a roadmap, this guide walks you through every change — with practical implementation steps, code samples, and common pitfalls to avoid.

What is WCAG 2.2?

WCAG 2.2 is the latest stable recommendation from the W3C, extending WCAG 2.1 with criteria that primarily benefit users with cognitive or learning disabilities, users with low vision, and users with motor impairments. It maintains backward compatibility — every site that meets WCAG 2.2 also meets WCAG 2.1 and 2.0.

The standard is organized under four principles — Perceivable, Operable, Understandable, and Robust (POUR) — and each new criterion maps to one of these pillars.

Conformance levels remain the same: A (minimum), AA (recommended for most regulation), and AAA (highest). Most legal frameworks reference Level AA, which is also the focus of this guide.

New Success Criteria Overview

WCAG 2.2 adds nine new success criteria. Here are the ones most critical for Level AA compliance:

• 2.4.11 Focus Not Obscured (Minimum) — AA: When an element receives keyboard focus, it must not be entirely hidden by other author-created content.
• 2.4.12 Focus Not Obscured (Enhanced) — AAA: No part of the focused element is hidden.
• 2.4.13 Focus Appearance — AAA: The focus indicator must have sufficient area and contrast.
• 2.5.7 Dragging Movements — AA: Any functionality requiring dragging must have a non-dragging alternative.
• 2.5.8 Target Size (Minimum) — AA: Interactive targets must be at least 24×24 CSS pixels.
• 3.2.6 Consistent Help — A: Help mechanisms appear in a consistent location across pages.
• 3.3.7 Redundant Entry — A: Information already entered doesn't need re-entry.
• 3.3.8 Accessible Authentication (Minimum) — AA: Login processes don't rely on cognitive function tests.
• 3.3.9 Accessible Authentication (Enhanced) — AAA: No cognitive function test is required at all.

Focus Appearance (2.4.11 & 2.4.13)

Sticky headers, floating toolbars, and chat widgets regularly obscure focused elements — making keyboard-only navigation a guessing game. The new Focus Not Obscured criteria directly target this problem.

What to check

Tab through every interactive element on your page. If any focused element is fully hidden behind a sticky header, modal overlay, or drawer, you fail 2.4.11. Partially hidden elements fail the enhanced 2.4.12 (AAA).

How to fix it

Use scroll-margin-top on focusable elements to account for your sticky header's height. For focus indicators, ensure a minimum 2px solid outline with at least a 3:1 contrast ratio against adjacent colors.

Dragging Movements (2.5.7)

Drag-and-drop interfaces — kanban boards, sliders, sortable lists — exclude users who can't perform continuous pointer movements. WCAG 2.2 requires a single-pointer alternative for every drag action.

Practical example

If your app uses a sortable list with drag-and-drop reordering, provide "Move up" and "Move down" buttons alongside each item. For range sliders, allow direct numeric input or increment/decrement buttons.

Target Size — Minimum (2.5.8)

Interactive touch targets must be at least 24×24 CSS pixels, or have sufficient spacing to achieve an equivalent target area. This criterion catches the tiny icon buttons, close icons, and inline links that plague mobile experiences.

Exceptions

Inline text links within sentences, browser-default controls, and elements where the size is essential to conveying meaning are exempt. However, if you're designing custom buttons, form controls, or navigation items, the 24px minimum applies.

While 24px is the WCAG minimum, best practice is to aim for 44×44px targets (the Apple Human Interface Guidelines recommendation) to ensure a comfortable tap area on mobile.

Accessible Authentication (3.3.8)

Cognitive function tests — CAPTCHAs, memory-based security questions, puzzle-solvers — create barriers for users with cognitive disabilities. WCAG 2.2 requires that no step in a login flow relies on such tests unless an alternative method is available.

What counts as a cognitive function test?

Anything that requires the user to remember, transcribe, calculate, or solve a puzzle. Traditional CAPTCHAs, image recognition challenges, and "type the word shown" tests all qualify.

Compliant alternatives

• Passkeys and WebAuthn (biometric/device-based login)
• Magic links sent to email or SMS
• OAuth/SSO (social login buttons)
• Password managers with autofill support — ensure your login form uses correct autocomplete attributes

Your Compliance Roadmap

Achieving WCAG 2.2 Level AA doesn't happen overnight, but it doesn't need to be overwhelming either. Here's a phased approach:

1. Audit: Run an automated scan with Zylyn's accessibility audit tool to identify existing WCAG 2.1 and 2.2 violations. This gives you a prioritized list of issues.
2. Triage: Categorize findings by severity (critical, major, minor) and impact. Focus on Level A failures first, then Level AA.
3. Fix — Quick Wins: Address missing alt text, form labels, color contrast, and link purposes. These often require minimal code changes but affect the most users.
4. Fix — Structural: Tackle focus management, keyboard navigation, ARIA patterns, and touch target sizing. This may require refactoring component libraries.
5. Test: Combine automated re-scans with manual keyboard testing and screen reader testing (NVDA, VoiceOver, JAWS).
6. Monitor: Integrate accessibility checks into your CI/CD pipeline. Zylyn's API can run on every deploy and flag regressions before they reach production.

Conclusion

WCAG 2.2 closes real gaps that affect millions of users with cognitive, motor, and visual disabilities. The new criteria aren't abstract — they map to concrete UI patterns you likely ship today: sticky headers, drag interactions, small buttons, and CAPTCHA flows.

The good news? Every fix makes your product better for all users, not just those with disabilities. Larger touch targets reduce misclicks. Better focus management improves power-user keyboard workflows. Accessible authentication reduces login friction and abandonment.

Start with an audit, prioritize ruthlessly, and build accessibility into your development workflow — not as a one-time project, but as a continuous quality gate. Your users deserve it, and increasingly, the law requires it.