What is WCAG 2.2? Complete Guide to Web Content Accessibility Guidelines

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines—the international standard that defines how to make websites, applications, and digital content accessible to people with disabilities. Published by the World Wide Web Consortium (W3C) in October 2023, WCAG 2.2 builds on previous versions to address emerging accessibility challenges, particularly around mobile interactions, cognitive accessibility, and authentication.

Understanding WCAG isn't just a technical exercise. These guidelines form the backbone of digital accessibility law worldwide. The Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, the European Accessibility Act, and accessibility regulations in Canada, Australia, and dozens of other countries all reference or incorporate WCAG standards. When a lawsuit alleges that a website is inaccessible, the complaint typically points to specific WCAG failures.

Why WCAG Matters in 2025

Q: Why should businesses care about WCAG?

A: WCAG compliance has become a legal requirement in most major markets. In the United States, the Department of Justice has stated that websites of public accommodations must be accessible under the ADA, and courts consistently reference WCAG as the technical standard. The European Accessibility Act takes effect in June 2025, mandating WCAG compliance across EU member states.

Beyond legal requirements, accessible websites reach a larger audience. The World Health Organization estimates that 1.3 billion people globally experience significant disability. In the United States, the CDC reports that 1 in 4 adults lives with a disability. These are customers, employees, and community members who deserve equal access to digital services.

The financial case is equally compelling. According to the Return on Disability Group, people with disabilities and their families control approximately $13 trillion in annual disposable income globally. Inaccessible websites forfeit this market entirely.

Understanding the Core Concepts

What Does WCAG Stand For?

Q: What does WCAG stand for?

A: WCAG stands for Web Content Accessibility Guidelines. These are technical standards published by the Web Accessibility Initiative (WAI), which is part of the World Wide Web Consortium (W3C)—the same organization that maintains HTML, CSS, and other foundational web standards.

The Structure of WCAG

WCAG is organized into a four-level hierarchy:

1. Principles (4) The four foundational principles known as POUR: Perceivable, Operable, Understandable, and Robust. All guidelines fall under one of these principles.

2. Guidelines (13) High-level goals within each principle. For example, Guideline 1.1 states "Provide text alternatives for any non-text content."

3. Success Criteria (86 in WCAG 2.2) Specific, testable requirements. Success Criterion 1.1.1 specifies exactly how text alternatives must be provided. Each success criterion is assigned a conformance level (A, AA, or AAA).

4. Techniques Advisory documentation explaining how to meet success criteria. Techniques are not mandatory requirements but provide practical implementation guidance.

The POUR Principles Explained

Q: What are the four POUR principles?

A: The POUR principles provide the conceptual framework for all WCAG requirements:

Perceivable: Information and user interface components must be presentable to users in ways they can perceive. This means providing text alternatives for images, captions for videos, and ensuring content isn't exclusively visual or auditory.

Operable: User interface components and navigation must be operable. Users must be able to interact with all functionality using a keyboard, have enough time to read and use content, and not encounter content that could cause seizures.

Understandable: Information and the operation of the user interface must be understandable. Text must be readable, pages must operate predictably, and users must receive help avoiding and correcting errors.

Robust: Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This requires using proper HTML semantics and ensuring compatibility with current and future technologies.

For a deeper exploration of POUR principles, see our guide to POUR Principles in Web Design.

WCAG Conformance Levels: A, AA, and AAA

Q: What is the difference between WCAG Level A, AA, and AAA?

A: WCAG success criteria are categorized into three conformance levels based on their impact on accessibility:

Level A (Minimum)

Level A represents the baseline requirements for web accessibility. These are considered the absolute minimum—failure to meet Level A criteria typically makes content completely inaccessible to some users.

Examples of Level A requirements:

• Non-text content must have text alternatives (1.1.1)
• Information conveyed through color must also be available without color (1.4.1)
• All functionality must be available via keyboard (2.1.1)
• Pages must have descriptive titles (2.4.2)

Level AA (Standard Target)

Level AA is the internationally accepted compliance target. Most accessibility laws, including ADA guidance and the European Accessibility Act, require Level AA conformance. Level AA includes all Level A criteria plus additional requirements.

Examples of Level AA requirements:

• Text must have a contrast ratio of at least 4.5:1 (1.4.3)
• Text can be resized up to 200% without loss of functionality (1.4.4)
• Multiple ways to navigate must be provided (2.4.5)
• Headings and labels must be descriptive (2.4.6)

Level AAA (Enhanced)

Level AAA represents the highest level of accessibility. While achieving Level AAA is commendable, the W3C acknowledges it's not achievable for all content types. Most organizations target Level AA with selective Level AAA implementations.

Examples of Level AAA requirements:

• Text contrast ratio of at least 7:1 (1.4.6)
• Sign language interpretation for all prerecorded audio (1.2.6)
• Extended audio description for video (1.2.7)
• Reading level at lower secondary education level (3.1.5)

Q: Which WCAG level should my organization target?

A: Target WCAG 2.2 Level AA. This is the standard referenced by most accessibility laws globally, including U.S. DOJ guidance, the European Accessibility Act, and Section 508. For a complete implementation roadmap, see our WCAG 2.2 Level AA Compliance Checklist.

The Evolution of WCAG: 1.0 to 2.2

Understanding WCAG's history helps contextualize current requirements:

WCAG 1.0 (1999)

The original guidelines focused primarily on HTML-based websites. Many requirements were tied to specific technologies rather than outcomes, making them difficult to apply as the web evolved.

WCAG 2.0 (2008)

A major rewrite that introduced technology-agnostic principles. The POUR framework and success criteria structure originated here. WCAG 2.0 was designed to remain relevant regardless of underlying technology.

WCAG 2.1 (2011)

Extended WCAG 2.0 with 17 new success criteria addressing:

• Mobile accessibility
• Low vision needs
• Cognitive and learning disabilities

All WCAG 2.0 requirements remain, with new criteria added.

WCAG 2.2 (October 2023)

The current standard adds 9 new success criteria focused on:

• Cognitive accessibility improvements
• Mobile and touch interaction
• Authentication accessibility
• Focus appearance requirements

Q: What's new in WCAG 2.2?

A: WCAG 2.2 introduces nine new success criteria:

Level A:

• 3.3.7 Redundant Entry: Don't require users to re-enter information already provided
• 3.2.6 Consistent Help: If help mechanisms exist, they must appear in consistent locations

Level AA:

• 2.4.11 Focus Not Obscured (Minimum): Focused elements must not be entirely hidden
• 2.5.7 Dragging Movements: Single-pointer alternatives for drag-and-drop
• 2.5.8 Target Size (Minimum): Touch targets at least 24x24 CSS pixels
• 3.3.8 Accessible Authentication (Minimum): No cognitive function tests for login

Level AAA:

• 2.4.12 Focus Not Obscured (Enhanced): Focused elements must be fully visible
• 2.4.13 Focus Appearance: Enhanced focus indicator visibility requirements
• 3.3.9 Accessible Authentication (Enhanced): No object or image recognition for login

For a detailed comparison, see our WCAG 2.2 vs 2.1 Comparison Guide.

How WCAG Connects to Law

Q: Is WCAG legally required?

A: WCAG itself is a voluntary technical standard, but it has been incorporated into binding legal requirements worldwide:

United States

• ADA Title III: Courts consistently reference WCAG as the standard for determining website accessibility under the Americans with Disabilities Act
• Section 508: Federal agencies and their contractors must meet accessibility standards that align with WCAG 2.0 Level AA (currently being updated to 2.1)
• State laws: California, New York, and other states have accessibility requirements referencing WCAG

European Union

• European Accessibility Act (EAA): Effective June 2025, requires digital products and services to meet EN 301 549, which incorporates WCAG 2.1 Level AA
• Web Accessibility Directive: Already requires public sector websites to meet WCAG 2.1 Level AA

Other Jurisdictions

• Canada (AODA): Ontario's accessibility law requires WCAG 2.0 Level AA
• Australia: Discrimination law has been interpreted to require accessible websites
• United Kingdom: Public sector bodies must meet WCAG 2.1 Level AA

The practical implication: meeting WCAG 2.2 Level AA positions your organization for compliance with accessibility laws in virtually every major market.

Common WCAG Failures

Research from WebAIM's annual accessibility analysis consistently finds the same issues on millions of websites:

Most Frequent Violations

1. Low contrast text (83% of home pages)

- WCAG 1.4.3 requires 4.5:1 contrast for normal text, 3:1 for large text

1. Missing alternative text (54% of home pages)

- WCAG 1.1.1 requires text alternatives for meaningful images

1. Missing form labels (46% of home pages)

- WCAG 1.3.1 and 4.1.2 require form inputs to have accessible names

1. Empty links (44% of home pages)

- WCAG 2.4.4 requires links to have discernible text

1. Missing document language (39% of home pages)

- WCAG 3.1.1 requires the page language to be programmatically determinable

1. Empty buttons (26% of home pages)

- WCAG 4.1.2 requires all interactive elements to have accessible names

These six issues alone account for the vast majority of detectable accessibility problems. Addressing them provides significant compliance progress. For a complete breakdown, see our article on Common WCAG Failures by Industry.

Implementing WCAG Compliance: A Practical Approach

Step 1: Baseline Assessment

Conduct a comprehensive audit to understand current compliance status. This should include:

• Automated scanning for detectable issues (roughly 30-40% of all problems)
• Manual testing for issues requiring human judgment
• Assistive technology testing with screen readers and keyboard-only navigation

Step 2: Prioritize Remediation

Not all WCAG failures carry equal impact. Prioritize based on:

• User impact: Issues that completely block access (keyboard traps, missing form labels) before cosmetic issues
• Legal risk: Violations commonly cited in lawsuits (alt text, form accessibility, color contrast)
• Traffic volume: Fix issues on high-traffic pages first

Step 3: Fix at the Source

Accessibility must be implemented in the actual source code, not through overlay widgets or JavaScript patches. Proper remediation includes:

• Semantic HTML structure
• Proper ARIA implementation
• Native keyboard accessibility
• Adequate color contrast in design

For more on why source code fixes matter, see our comparison of Overlay vs Source Code Approaches.

Step 4: Integrate into Development

Prevent new accessibility issues by:

• Adding accessibility checks to CI/CD pipelines
• Training developers on WCAG requirements
• Including accessibility in design reviews
• Testing with assistive technologies before release

Step 5: Monitor Continuously

Websites change constantly. A compliance audit from three months ago may not reflect current status. Continuous monitoring catches:

• Regressions from code changes
• New violations introduced by content updates
• Third-party component issues

How TestParty Enables WCAG Compliance

TestParty's platform is designed to help organizations achieve and maintain WCAG 2.2 Level AA compliance through source code remediation—not overlay widgets that fail to provide genuine accessibility.

Spotlight continuously monitors production websites for WCAG violations, prioritizing issues by severity and legal risk. Unlike one-time audits that become outdated immediately, Spotlight provides real-time visibility into compliance status.

Bouncer integrates with GitHub to catch accessibility issues in pull requests before they reach production. Developers receive specific feedback on WCAG violations during code review, preventing new issues from being introduced.

PreGame brings accessibility checking directly into VS Code, providing real-time guidance as developers write code. This shifts accessibility left in the development process, making it part of initial implementation rather than post-launch remediation.

Together, these tools create a comprehensive compliance system that addresses accessibility at every stage of the development lifecycle.

Key Takeaways

• WCAG 2.2 is the current standard for web accessibility, published in October 2023 with nine new success criteria
• Level AA is the compliance target referenced by ADA guidance, the European Accessibility Act, and most international accessibility laws
• POUR principles (Perceivable, Operable, Understandable, Robust) provide the conceptual framework for all WCAG requirements
• 86 success criteria across three conformance levels define specific, testable accessibility requirements
• Common failures are consistent: low contrast text, missing alt text, unlabeled form fields, and empty links account for most issues
• Source code remediation is required for genuine compliance; overlay widgets cannot achieve WCAG conformance
• Continuous monitoring is essential because websites change constantly

Conclusion

WCAG 2.2 represents the culmination of over two decades of work to define how digital content can be made accessible to everyone. These guidelines aren't abstract principles—they're the specific, testable requirements that determine whether your website works for the 1.3 billion people globally who live with disabilities.

Understanding WCAG is the first step. Implementation requires systematic auditing, prioritized remediation, and continuous monitoring. The organizations that succeed treat accessibility as an ongoing commitment integrated into development workflows, not a one-time checkbox exercise.

For those ready to move from understanding to implementation, TestParty provides the tools to achieve and maintain WCAG 2.2 Level AA compliance efficiently. Our platform catches issues at the source code level, integrates with existing development workflows, and provides continuous visibility into compliance status.

Schedule a TestParty demo and get a 14-day compliance implementation plan.