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): All interactive components must have accessible names, roles, and states communicated through proper ARIA or native HTML, and status messages must be announced to assistive technologies.

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.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.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.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 adds a practical AA-level minimum alongside the stricter AAA target size criterion from 2.1 (now called 2.5.5 Target Size (Enhanced)). 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.

2.4.13 Focus Appearance: When a component has keyboard focus, the focus indicator must meet a minimum size and contrast. In general, it must be at least as large as a 2 CSS pixel thick perimeter of the component and have a contrast ratio of at least 3:1 between its focused and unfocused states.

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 (Ontario, Canada): Requires WCAG 2.0 Level AA for public-sector organizations and businesses with 50 or more employees, in force since January 1, 2021.
• Accessible Canada Act (Canada): Federally regulated organizations are covered, and the new ICT requirements reference CAN/ASC-EN 301 549, which builds in WCAG 2.1.
• Equality Act 2010 (United Kingdom): It does not reference WCAG directly, but WCAG conformance is widely used as the benchmark for meeting the duty to make reasonable adjustments.

Because each version of WCAG builds on the last, meeting WCAG 2.2 Level AA positions your website well for all of these frameworks at once.

Measured against the oldest of these benchmarks, many sites still fall short. Compliable's July 2026 census of 7,485 page scans across 1,045 Ontario public-sector organizations found that at least 89.4% of the 884 AODA-bound organizations showed at least one detectable WCAG 2.0 AA violation.

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 scan covers the automated part for any single page, and an expert audit adds the manual testing.

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

WebAIM's annual "WebAIM Million" analysis of one million home pages finds the most common detectable failures are remarkably consistent from year to year (see the latest report for current percentages):

1. Low contrast text
2. Missing alt text for images
3. Missing form input labels
4. Empty links
5. Empty buttons
6. Missing document language

These six categories account for most of the errors that automated tools detect. 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 quickly. Compliable's free scan renders a page in headless Chrome on desktop and mobile and tests it with axe-core.
• 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 a Canadian company that helps organizations work toward WCAG 2.2 Level AA:

• Automated scanning against WCAG 2.0, 2.1 and 2.2 rules using axe-core v4.11.1, the open-source accessibility engine, in a real headless Chrome browser on desktop and mobile
• Scoring and reports mapped to WCAG, the AODA, the Accessible Canada Act, the ADA and Section 508
• Expert audits that add manual testing for the many criteria automation cannot fully check

Automated scanning detects only part of all barriers, and no tool can guarantee conformance on its own.

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 scan with Compliable and get a score and a list of the detectable issues on your page.