WCAG 2.2 Compliance Guide
A comprehensive guide to understanding the Web Content Accessibility Guidelines (WCAG) 2.2, the international standard for making web content accessible to people with disabilities. Learn what changed, who must comply, and how to test your site.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG) are a set of technical standards developed by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). First published in 1999 as WCAG 1.0, the guidelines have evolved through multiple versions — WCAG 2.0 in 2008, WCAG 2.1 in 2018, and now WCAG 2.2 in 2023 — to keep pace with the changing web landscape and to address the needs of an increasingly diverse user population.
WCAG provides a shared, globally recognized framework for making web content more accessible to people with a wide range of disabilities, including visual, auditory, motor, speech, cognitive, language, learning, and neurological disabilities. The guidelines are organized around testable success criteria, each assigned a conformance level (A, AA, or AAA), allowing organizations to set measurable targets for accessibility.
Because WCAG is technology-agnostic and maintained by an international standards body, it has been adopted or referenced by accessibility laws and regulations around the world. The European Union's EN 301 549 standard incorporates WCAG directly, the United States Department of Justice has cited WCAG 2.1 Level AA as the benchmark for ADA web compliance, and countries from Canada to Australia use WCAG as the foundation for their own digital accessibility mandates. Understanding WCAG is therefore not only a best practice — it is often a legal requirement.
WCAG 2.2 vs 2.1: What Changed?
WCAG 2.2 was officially published as a W3C Recommendation on October 5, 2023. It builds directly on top of WCAG 2.1, meaning every success criterion from 2.1 remains in effect — WCAG 2.2 is fully backward compatible. The update adds nine new success criteria, most of which target Level A and Level AA conformance, making them relevant to the vast majority of organizations that aim for AA compliance. One existing criterion (4.1.1 Parsing) was made obsolete since modern browsers and assistive technologies no longer depend on strict HTML parsing rules.
The primary focus areas of WCAG 2.2 are improved support for users with cognitive and learning disabilities, better usability on mobile and touch devices, and reducing unnecessary friction in common interaction patterns like authentication and form entry. These additions reflect years of research and public feedback showing that earlier WCAG versions, while strong on sensory and motor disabilities, did not adequately address the challenges faced by people with cognitive impairments.
Key new criteria you should know about include Focus Not Obscured (ensuring focused elements are at least partially visible), Dragging Movements (providing alternatives for drag-based interactions), Target Size (Minimum) (requiring at least 24x24 CSS pixels for interactive elements), Consistent Help (placing help mechanisms in a predictable location), Redundant Entry (avoiding asking users to re-enter information already provided), and Accessible Authentication (not requiring cognitive function tests like CAPTCHA puzzles as the sole login method). Together, these criteria make the web meaningfully easier to use for millions of people.
The Four Principles (POUR)
All WCAG success criteria are organized under four foundational principles, often referred to by the acronym POUR. These principles define the qualities that web content must exhibit in order to be usable by people with disabilities. If any one of these principles is not met, users with certain disabilities will be unable to access the content.
Perceivable
Information and user interface components must be presentable to users in ways they can perceive. This means providing text alternatives for non-text content (images, icons, video), offering captions and audio descriptions for multimedia, ensuring content can be presented in different ways without losing meaning (e.g., screen reader compatibility), and making it easy to see and hear content — including sufficient color contrast ratios of at least 4.5:1 for normal text and 3:1 for large text.
Operable
User interface components and navigation must be operable by all users. All functionality must be available via keyboard, users must be given enough time to read and interact with content, content must not cause seizures or physical reactions (no flashing more than three times per second), navigation must be logical and consistent, and input modalities beyond keyboard — such as touch and pointer — must be supported. WCAG 2.2 strengthens this principle with new target size and dragging movement requirements.
Understandable
Information and the operation of the user interface must be understandable. Text content must be readable and set to the correct language, pages must behave in predictable ways (no unexpected context changes on focus or input), and users must receive adequate input assistance — including clear error messages, labels, and instructions. WCAG 2.2 adds criteria for consistent help placement, redundant entry avoidance, and accessible authentication to further reduce cognitive burden.
Robust
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies like screen readers, magnifiers, and voice control software. This means using valid, semantic HTML, ensuring custom components expose the correct name, role, and value to the accessibility tree, and providing programmatic status messages so users are aware of dynamic changes without losing focus. Proper use of ARIA attributes and semantic elements is essential for robustness.
Conformance Levels
WCAG defines three levels of conformance, each building on the previous one. Every success criterion is assigned to exactly one level, and conforming at a higher level means you have also met all criteria at the lower levels. Understanding these levels is critical for setting realistic compliance goals and meeting legal obligations.
Most accessibility laws worldwide — including the ADA (as interpreted by the DOJ), Section 508, the European Accessibility Act, and Canada's Accessible Canada Act — require Level AA conformance as the minimum standard. Level AAA is aspirational for most organizations and is not typically mandated by law, but pursuing AAA criteria where practical demonstrates a strong commitment to inclusion.
Level A — Minimum
The baseline level of accessibility. Level A criteria address the most fundamental barriers that would completely block some users. For example, all non-text content must have a text alternative (SC 1.1.1), all functionality must be available via keyboard (SC 2.1.1), and pages must have descriptive titles (SC 2.4.2). Failing to meet Level A means your content is inaccessible to significant groups of users.
Level AA — Recommended & Legally Required
The standard target for most organizations and the level referenced by virtually all accessibility legislation. Level AA includes criteria such as minimum color contrast ratios (SC 1.4.3), the ability to resize text up to 200% without loss of functionality (SC 1.4.4), visible focus indicators (SC 2.4.7), and consistent navigation (SC 3.2.3). Meeting Level AA removes the majority of barriers for the majority of users and is considered the balanced, achievable standard for web accessibility.
Level AAA — Gold Standard
The highest level of accessibility conformance. Level AAA criteria include enhanced contrast of 7:1 (SC 1.4.6), sign language interpretation for audio content (SC 1.2.6), and reading level requirements (SC 3.1.5). While full AAA conformance is not realistic for all content types, pursuing individual AAA criteria — particularly those related to cognitive accessibility — can significantly improve the user experience for people with disabilities.
New Success Criteria in WCAG 2.2
WCAG 2.2 introduces nine new success criteria that address gaps identified in earlier versions. These criteria focus heavily on cognitive accessibility, touch/pointer interaction, and reducing user friction. Below is a summary of each new criterion, its conformance level, and what it requires.
Focus Not Obscured (Minimum)
Level AAWhen a user interface component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers, footers, or modal overlays. At least part of the focused element must remain visible.
Focus Not Obscured (Enhanced)
Level AAAA stricter version of 2.4.11 — the focused component must be fully visible, not just partially. No portion of the focused element can be hidden by other content.
Focus Appearance
Level AAAWhen a component has keyboard focus, the focus indicator must have a minimum area (at least as large as a 2px border around the component) and a contrast ratio of at least 3:1 between its focused and unfocused states.
Dragging Movements
Level AAAny functionality that uses dragging (e.g., sliders, sortable lists, map panning) must also be achievable through a single-pointer action without dragging, such as clicking, tapping, or using arrow keys.
Target Size (Minimum)
Level AAInteractive targets must be at least 24 by 24 CSS pixels in size, unless the target is inline in a sentence, the user agent controls the sizing, the size is essential, or an equivalent target of sufficient size is available elsewhere on the page.
Consistent Help
Level AIf a website provides help mechanisms (such as contact information, chat, FAQ links, or self-help options), these mechanisms must appear in the same relative order across pages, making them predictable and easy to find.
Redundant Entry
Level AInformation previously entered by or provided to the user during a process must be auto-populated or available for selection, unless re-entering it is essential for security or the information is no longer valid.
Accessible Authentication (Minimum)
Level AAAuthentication processes must not require cognitive function tests (such as remembering a password or solving a puzzle) unless the test allows pasting, offers an alternative, or provides an object or personal content recognition method.
Accessible Authentication (Enhanced)
Level AAAA stricter version of 3.3.8 — authentication must not rely on any cognitive function test, including object recognition or personal content identification. Biometrics, password managers, and passkeys are acceptable alternatives.
Who Needs to Comply?
The short answer is: almost every organization with a public-facing website. While the specific legal requirements vary by jurisdiction, the global trend is clear — digital accessibility is becoming a legal obligation, not merely a recommendation. Below is an overview of the major regulatory frameworks that reference or mandate WCAG compliance.
In the United States, the Americans with Disabilities Act (ADA) Title III applies to "places of public accommodation," which federal courts have increasingly interpreted to include websites and mobile applications. In March 2022, the Department of Justice published formal guidance confirming that the ADA applies to web content and that WCAG 2.1 Level AA is the appropriate standard. The number of ADA web accessibility lawsuits has risen sharply, with over 4,000 filed in federal courts in 2023 alone. Section 508 of the Rehabilitation Act separately requires all federal agency information and communication technology to conform to WCAG 2.0 Level AA (with pending updates to reference WCAG 2.1+).
The European Union has adopted some of the most comprehensive accessibility legislation in the world. The European Accessibility Act (EAA), which member states must enforce starting June 28, 2025, requires a broad range of products and services — including e-commerce websites, banking platforms, and transportation services — to meet accessibility requirements derived from EN 301 549, which directly incorporates WCAG 2.1 Level AA. The Web Accessibility Directive (WAD), in effect since 2016, already mandates WCAG 2.1 AA compliance for all public sector websites and mobile applications across all EU member states.
Canada enforces accessibility through the Accessible Canada Act (ACA) at the federal level and provincial legislation such as Ontario's Accessibility for Ontarians with Disabilities Act (AODA), which requires WCAG 2.0 Level AA compliance for all organizations with 50 or more employees. The United Kingdom applies the Public Sector Bodies Accessibility Regulations 2018 (based on WCAG 2.1 AA) to government websites and apps. Australia, Israel, Japan, South Korea, and numerous other countries have their own legislation that aligns with or directly references WCAG. The trajectory is unmistakable: WCAG compliance is rapidly becoming a universal legal baseline for digital content.
How to Check WCAG 2.2 Compliance
Checking your website for WCAG 2.2 compliance requires a layered approach. No single method can catch every issue, but combining automated scanning with manual testing and assistive technology evaluation provides thorough coverage. The goal is to identify barriers, prioritize them by impact, and systematically remediate them.
Start with automated scanning. Automated accessibility tools can scan your pages in seconds and identify common issues such as missing alt text, insufficient color contrast, empty links, missing form labels, and incorrect heading hierarchy. Research consistently shows that automated tools can reliably detect approximately 30 to 40 percent of WCAG violations — a significant number that represents the low-hanging fruit of accessibility remediation. Automated scanning is especially effective as a first pass on large sites where manual testing every page would be impractical.
Complement with manual testing. The remaining 60 to 70 percent of accessibility issues require human judgment to identify. Manual testing involves navigating your site using only a keyboard (checking tab order, focus visibility, and keyboard traps), reviewing content for readability and logical structure, verifying that interactive components work correctly without a mouse, and testing forms for adequate error messaging and label associations. Manual testing is where you catch issues like ambiguous link text, poor reading order, and confusing navigation patterns.
Test with assistive technologies. To truly understand the experience of users with disabilities, test your site with screen readers (such as NVDA, JAWS, or VoiceOver), screen magnifiers, voice control software (like Dragon NaturallySpeaking or Voice Control on macOS), and switch access devices. This type of testing reveals issues that neither automated tools nor manual inspection can catch, such as screen reader announcing content in the wrong order or ARIA attributes that technically validate but create a confusing experience.
Set up ongoing monitoring. Accessibility is not a one-time fix — it requires continuous monitoring. Code changes, content updates, and third-party widget additions can all introduce new barriers. Regular automated scans, periodic manual audits, and integrating accessibility checks into your CI/CD pipeline ensure that compliance is maintained over time rather than degrading after an initial remediation effort.
Start with a free automated scan
Enter your URL below to check your site against WCAG 2.2 success criteria. CompliaScan identifies accessibility issues, explains what to fix, and helps you prioritize remediation.
Related Resources
Free WCAG Checker
Scan your website for WCAG 2.2 violations instantly with our free automated accessibility checker.
ADA Compliance Guide
Learn how the Americans with Disabilities Act applies to websites and what steps you need to take to comply.
How to Audit
A step-by-step guide to conducting a thorough web accessibility audit, from automated scans to manual testing.