Understanding WCAG 2.2: What's New and What It Means for Your Website

WCAG 2.2 represents the most significant update to web accessibility standards since WCAG 2.1 was released in 2018. With 9 new success criteria—and one removed—understanding these changes is essential for maintaining compliance and providing an accessible experience for all users.

What is WCAG 2.2?

The Web Content Accessibility Guidelines (WCAG) are developed by the World Wide Web Consortium (W3C) and serve as the global standard for web accessibility. WCAG 2.2 builds on previous versions, adding new requirements while maintaining backward compatibility with WCAG 2.0 and 2.1.

The new guidelines primarily focus on improving accessibility for three groups: users with cognitive or learning disabilities, users with low vision, and users on mobile devices. Many of the new criteria address real-world usability issues that weren't fully covered in previous versions.

The 9 New Success Criteria

WCAG 2.2 introduces nine new success criteria across Levels A, AA, and AAA. Here's what you need to know about each one:

Level A (Minimum Compliance)

2.4.11 Focus Not Obscured (Minimum)

When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content. This addresses the frustrating experience of tabbing to an element only to have it hidden behind a sticky header or modal overlay.

How to comply: Ensure sticky headers, cookie banners, and chat widgets don't completely cover focused elements. Use scroll-padding in CSS to account for fixed elements.

3.2.6 Consistent Help

If a website provides help mechanisms (like contact information, chat support, or FAQ links), these must appear in the same relative location across pages. This helps users with cognitive disabilities find help consistently.

How to comply: Place your help links, contact information, or support chat in the same location (e.g., footer or header) on every page.

3.3.7 Redundant Entry

Information previously entered by or provided to the user that is required to be entered again in the same process must be auto-populated or available for selection. This reduces cognitive load and prevents errors.

How to comply: Use autocomplete attributes, pre-fill forms with previously entered data, and provide options to copy billing address to shipping address.

Level AA (Standard Compliance)

2.4.12 Focus Not Obscured (Enhanced)

A stricter version of 2.4.11—when focused, no part of the component should be hidden by author-created content. This ensures complete visibility of focused elements.

2.5.7 Dragging Movements

Any functionality that uses dragging must have a single-pointer alternative that doesn't require dragging. This helps users with motor disabilities who can't perform precise drag operations.

How to comply: For drag-and-drop interfaces, provide buttons to move items up/down or input fields to specify positions directly.

2.5.8 Target Size (Minimum)

Interactive targets must be at least 24×24 CSS pixels, with some exceptions for inline links and user-agent-controlled elements. This makes touch targets easier to activate.

How to comply: Ensure buttons, links, and form controls are at least 24px in both dimensions, or have sufficient spacing between smaller targets.

3.3.8 Accessible Authentication (Minimum)

Cognitive function tests (like remembering passwords or solving puzzles) must not be required for authentication unless an alternative is provided. This removes barriers for users with cognitive disabilities.

How to comply: Support password managers (don't block paste), offer biometric authentication, provide email/SMS verification codes, or use passkeys.

3.3.9 Accessible Authentication (Enhanced)

A stricter version that removes all cognitive tests from authentication, even object recognition and personal content identification.

Level AAA (Enhanced Compliance)

2.4.13 Focus Appearance

Focus indicators must meet specific size and contrast requirements—a focus outline of at least 2px with a 3:1 contrast ratio against adjacent colors.

How to comply: Create custom focus styles that are clearly visible, using solid outlines or borders with sufficient contrast.

What Was Removed?

WCAG 2.2 removes one success criterion from WCAG 2.1: 4.1.1 Parsing. This criterion required valid HTML, but modern browsers and assistive technologies are now robust enough to handle parsing errors. The requirement has become obsolete.

However, this doesn't mean you should write invalid HTML. Clean, valid markup still improves maintainability and reduces the risk of accessibility issues.

Implementation Timeline

While WCAG 2.2 is now official, adoption timelines vary:

• Private businesses: Should begin implementing immediately to stay ahead of legal requirements
• Federal agencies: Section 508 references WCAG 2.0, but updates typically follow W3C releases
• EU organizations: EN 301 549 will likely update to reference WCAG 2.2
• Legal proceedings: Courts increasingly reference the latest WCAG version

"WCAG 2.2 addresses real barriers that people with disabilities face every day. These aren't arbitrary requirements—they're based on extensive research and user feedback."

— W3C Web Accessibility Initiative

How to Get Started

Preparing for WCAG 2.2 compliance doesn't have to be overwhelming. Here's a practical approach:

1. Audit your current state: Understand where you stand with WCAG 2.1 before addressing 2.2 requirements
2. Prioritize by impact: Start with Level A and AA criteria, as these are most likely to be legally required
3. Focus on authentication: The accessible authentication requirements may require significant changes
4. Review interactive elements: Check all buttons, links, and form controls for target size compliance
5. Test with real users: Conduct usability testing with people who have disabilities