WCAG 2.2: What Changed and Why It Matters

# WCAG 2.2: What Changed and Why It Matters

The Web Content Accessibility Guidelines (WCAG) are the global standard for digital accessibility. Published by the World Wide Web Consortium (W3C), WCAG provides a comprehensive technical framework that defines how to make web content accessible to people with disabilities.

WCAG 2.2, released in October 2023, is the latest stable version and builds on the foundation of WCAG 2.0 and 2.1. It introduces nine new success criteria focused on improving the experience for users with cognitive and learning disabilities, low vision, and motor impairments.

This guide breaks down everything you need to know about WCAG 2.2: the four core principles, what changed from 2.1, conformance levels, how WCAG connects to legal requirements, and practical implementation strategies.

The Four Principles of WCAG (POUR)

Every WCAG guideline falls under one of four foundational principles. Content must be:

1. Perceivable

Users must be able to perceive the information being presented. Content cannot be invisible to all of a user's senses.

Key guidelines under Perceivable include:

• Text Alternatives (1.1): All non-text content (images, icons, charts) must have text alternatives that serve the same purpose.
• Time-Based Media (1.2): Video and audio content needs captions, audio descriptions, and transcripts.
• Adaptable (1.3): Content structure must be programmatically determinable. Information conveyed through visual layout (tables, headings, lists) must also be conveyed through proper HTML semantics.
• Distinguishable (1.4): Users must be able to see and hear content. This includes color contrast requirements (at least 4.5:1 for normal text, 3:1 for large text), text resizing up to 200%, and content reflow at 320px width.

2. Operable

Users must be able to operate the interface. Components and navigation must be usable.

Key guidelines under Operable include:

• Keyboard Accessible (2.1): All functionality must be available through a keyboard interface with no timing requirements for individual keystrokes.
• Enough Time (2.2): Users must have enough time to read and use content. Time limits must be adjustable, extendable, or removable.
• Seizures and Physical Reactions (2.3): Content must not flash more than three times per second.
• Navigable (2.4): Users must be able to navigate, find content, and determine where they are. This includes skip links, descriptive page titles, logical focus order, and visible focus indicators.
• Input Modalities (2.5): Users must be able to operate content through various input methods beyond keyboard, including touch, voice, and pointer devices.

3. Understandable

Users must be able to understand the information and the operation of the interface.

Key guidelines under Understandable include:

• Readable (3.1): Text content must be readable and understandable. The language of the page must be programmatically set, and unusual words or abbreviations should be explained.
• Predictable (3.2): Web pages must appear and operate in predictable ways. Navigation should be consistent, and components that look the same should behave the same.
• Input Assistance (3.3): Users must be helped to avoid and correct mistakes. Error messages must be specific, labels must be clear, and important submissions should be reversible or confirmable.

4. Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

• Compatible (4.1): Content must be parsed correctly, elements must have complete start and end tags, and all interactive components must have accessible names, roles, and states communicated through proper ARIA or native HTML.

What Changed in WCAG 2.2

WCAG 2.2 adds nine new success criteria and removes one criterion from WCAG 2.1. Here is what is new:

New Level A Criteria

3.3.7 Redundant Entry: Information previously entered by the user in the same process must be auto-populated or available for selection. Users should not have to re-enter information they have already provided (such as a shipping address being offered as the billing address default). This benefits users with cognitive disabilities and motor impairments.

New Level AA Criteria

2.4.11 Focus Not Obscured (Minimum): When a user interface component receives keyboard focus, the component must not be entirely hidden by author-created content. Sticky headers, cookie banners, and chat widgets commonly violate this criterion by covering focused elements.

2.4.13 Focus Appearance: When a component has keyboard focus, the focus indicator must have a minimum area and contrast ratio. Specifically, the focus indicator must be at least as large as a 2px thick perimeter of the component and must have a contrast ratio of at least 3:1 against adjacent colors.

2.5.7 Dragging Movements: Any functionality that uses dragging must also have a single-pointer alternative. For example, a sortable list that uses drag-and-drop must also offer up/down buttons or another single-pointer mechanism.

2.5.8 Target Size (Minimum): Interactive targets must be at least 24x24 CSS pixels, or there must be sufficient spacing between undersized targets. This replaces the AAA-level target size criterion from 2.1 with a more practical AA-level minimum. Inline links within text are exempt.

3.3.8 Accessible Authentication (Minimum): Authentication processes must not require cognitive function tests (such as memorizing a password or solving a puzzle) unless an alternative method is available, the mechanism assists the user (like a password manager), or the test involves object recognition or personal content.

New Level AAA Criteria

2.4.12 Focus Not Obscured (Enhanced): No part of the focused component may be hidden by author-created content. This is the stricter version of 2.4.11.

3.2.6 Consistent Help: If a page provides help mechanisms (such as contact information, chat, or FAQ links), those mechanisms must appear in the same relative order across pages within the site.

3.3.9 Accessible Authentication (Enhanced): A stricter version of 3.3.8 that removes the exceptions for object recognition and personal content.

Removed Criterion

4.1.1 Parsing: This criterion was removed from WCAG 2.2 because modern browsers and assistive technologies handle parsing errors gracefully. Issues previously caught by 4.1.1 are now covered by other criteria or are no longer relevant.

Conformance Levels: A, AA, and AAA

WCAG defines three conformance levels, each building on the previous:

Level A (Minimum)

Level A criteria address the most critical barriers. Failing to meet Level A means some users will be completely unable to access your content. Examples include providing alt text for images (1.1.1), making content keyboard-accessible (2.1.1), and ensuring pages have titles (2.4.2).

Level AA (Standard)

Level AA is the standard that most laws and regulations reference. It includes all Level A criteria plus additional requirements for color contrast, text resizing, consistent navigation, and error handling. If you are targeting compliance with the ADA, Section 508, the European Accessibility Act, or most other accessibility laws, Level AA is your goal.

Level AAA (Enhanced)

Level AAA represents the highest level of accessibility. While meeting all AAA criteria is ideal, WCAG itself acknowledges that it is not possible to satisfy all AAA criteria for all types of content. AAA conformance should be a stretch goal for specific content types, not a blanket requirement.

How WCAG Relates to Legal Requirements

WCAG is a technical standard, not a law. However, it is referenced by virtually every major accessibility law and regulation:

• ADA (United States): The DOJ's 2024 Title II rule formally adopts WCAG 2.1 Level AA. Courts routinely reference WCAG in Title III cases as well.
• Section 508 (United States): Federal agencies must meet WCAG 2.0 Level AA under the Revised Section 508 Standards.
• European Accessibility Act (EU): References the harmonized European standard EN 301 549, which incorporates WCAG 2.1 Level AA. See our EAA compliance guide for details.
• Accessibility for Ontarians with Disabilities Act (Canada): Requires WCAG 2.0 Level AA for public sector and large organizations.
• Equality Act 2010 (United Kingdom): While it does not reference WCAG explicitly, courts treat WCAG conformance as evidence of meeting the duty to make reasonable adjustments.

Meeting WCAG 2.2 Level AA positions your website to comply with all of these frameworks simultaneously.

Practical Implementation Tips

Start with a Baseline Audit

Before fixing anything, understand the scope of the problem. Run an automated scan to identify low-hanging fruit, then conduct manual testing to find issues that automation misses. Compliable's free audit provides both automated and expert analysis.

Fix the Foundations First

Many WCAG failures stem from the same root causes:

• Missing or incorrect semantic HTML: Use proper headings (h1 through h6 in order), lists, landmarks, and form labels. Semantic HTML solves a surprising number of accessibility issues at once.
• Missing alt text: Audit every image on your site. Decorative images should have empty alt attributes (alt=""). Informative images need concise, descriptive alt text.
• Poor color contrast: Use a contrast checker to verify all text meets the 4.5:1 ratio (3:1 for large text). Do not rely on color alone to convey information.
• Keyboard traps: Navigate your entire site using only the Tab, Enter, Space, Escape, and Arrow keys. Every interactive element must be reachable and operable.

Address the New 2.2 Criteria

If you were already conformant with WCAG 2.1 Level AA, here are the new items to address for 2.2:

1. Check focus visibility: Ensure sticky headers, banners, and modals do not cover focused elements. Test by tabbing through your entire site.
2. Verify target sizes: Audit all buttons, links, and interactive controls. Targets should be at least 24x24 CSS pixels or have adequate spacing.
3. Test drag interactions: If your site uses drag-and-drop, confirm that a single-pointer alternative exists for every drag action.
4. Review authentication flows: Ensure login and signup processes do not require memorization of passwords without supporting paste and password managers.
5. Check for redundant entry: Multi-step forms should not ask users to re-enter information they already provided.
6. Verify consistent help placement: If you have a help widget, contact info, or FAQ link, confirm it appears in the same position across all pages.

Integrate Accessibility into Your Development Workflow

The most cost-effective approach is to prevent accessibility issues from being introduced in the first place:

• Design reviews: Check wireframes and mockups for color contrast, target sizes, focus states, and content structure before any code is written.
• Component libraries: Build accessible components once and reuse them. Ensure buttons, form fields, modals, and navigation components are accessible by default.
• Automated testing in CI/CD: Add accessibility checks to your build pipeline. Tools like axe-core can catch many Level A and AA issues automatically.
• Manual testing cadence: Schedule regular manual testing with screen readers (NVDA, VoiceOver, JAWS) and keyboard-only navigation.

Common WCAG Failures to Watch For

Based on the WebAIM Million analysis, which scans the top one million websites annually, the most common WCAG failures are remarkably consistent:

1. Low contrast text (found on over 80% of home pages)
2. Missing alt text for images (found on over 54% of home pages)
3. Missing form input labels (found on over 45% of home pages)
4. Empty links (found on over 44% of home pages)
5. Empty buttons (found on over 28% of home pages)
6. Missing document language (found on over 17% of home pages)

These six issues alone account for the vast majority of detectable accessibility barriers on the web. Fixing them gets you a significant portion of the way to WCAG 2.2 Level AA conformance.

Testing Tools and Resources

A solid accessibility testing strategy combines multiple tools:

• Automated scanners: Catch common, pattern-based issues at scale. Compliable's Ally platform provides continuous automated monitoring.
• Browser extensions: Tools like axe DevTools and WAVE allow developers to test individual pages during development.
• Screen readers: Test with at least one screen reader. NVDA (Windows, free) and VoiceOver (macOS/iOS, built in) are the most commonly used.
• Keyboard testing: Simply unplug your mouse and try to use your site. This often reveals issues that no automated tool catches.
• Color contrast analyzers: Verify that all text and interactive elements meet the required contrast ratios.

How Compliable Helps with WCAG 2.2 Compliance

Compliable is built to simplify the path to WCAG 2.2 Level AA conformance:

• Comprehensive audits that combine automated scanning with expert manual testing against all WCAG 2.2 success criteria
• Prioritized remediation plans that tell your team exactly what to fix, in what order, with code-level guidance
• Continuous monitoring that catches new issues as your site evolves, so you do not fall out of compliance
• Compliance documentation including VPATs and accessibility conformance reports that demonstrate your commitment to stakeholders

Conclusion

WCAG 2.2 represents the most complete accessibility standard to date. Its new criteria address real-world barriers that affect millions of users, from obscured focus indicators to inaccessible authentication flows. Whether you are starting from scratch or updating an already-accessible site, understanding WCAG 2.2 is essential for meeting legal requirements, serving all users, and building a better web.

Want to know how your site measures up against WCAG 2.2? Run a free accessibility audit with Compliable and get a detailed report with actionable recommendations.