What is WCAG 2.2? A Complete Guide for 2026

What is WCAG?

WCAG stands for the Web Content Accessibility Guidelines, a set of technical standards developed by the World Wide Web Consortium (W3C) to make web content accessible to people with disabilities. These guidelines provide a shared framework that governments, organizations, and developers around the world use to ensure that websites, applications, and digital documents can be used by everyone, regardless of their abilities or the assistive technologies they rely on.

At its core, WCAG is about removing barriers. A person who is blind should be able to use a screen reader to navigate your website. A person with a motor disability should be able to interact with every control using only a keyboard. A person with a cognitive disability should be able to understand your content without unnecessary complexity. WCAG defines testable success criteria that, when followed, make these experiences possible.

The guidelines are organized around four foundational principles known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Each principle contains guidelines, and each guideline contains success criteria at three conformance levels (A, AA, and AAA). The current version, WCAG 2.2, was published in October 2023 and contains 87 success criteria in total.

Who Publishes WCAG?

WCAG is published by the Web Accessibility Initiative (WAI), which is a program within the World Wide Web Consortium (W3C). The W3C is the international standards organization responsible for many of the foundational technologies of the web, including HTML, CSS, and ARIA. The WAI brings together individuals from industry, disability organizations, governments, and research institutions from around the world to develop accessibility standards and resources.

The development of WCAG follows the W3C's consensus-based process, which includes multiple rounds of public review and comment. This means that the guidelines reflect broad international agreement on what constitutes best practice for web accessibility. WCAG is not the product of a single company or government but rather a collaboratively developed global standard.

Why WCAG Matters in 2026

WCAG matters more in 2026 than ever before for three interconnected reasons: the legal landscape, the scale of disability globally, and the business case for accessibility.

On the legal front, the European Accessibility Act (EAA) took effect in June 2025, requiring a wide range of products and services sold in the EU to meet accessibility requirements that map directly to WCAG. In the United States, the Department of Justice has issued guidance explicitly referencing WCAG 2.1 Level AA as the standard websites should meet under the Americans with Disabilities Act (ADA). ADA-related web accessibility lawsuits have continued to increase, with over 4,000 filed in federal courts during 2024, a 14 percent increase over the previous year. Section 508 of the Rehabilitation Act requires US federal agencies and their contractors to meet accessibility standards that incorporate WCAG. Similar laws exist in Canada, the United Kingdom, Australia, and dozens of other countries.

The World Health Organization estimates that 1.3 billion people, about 16 percent of the global population, experience significant disability. This includes people with visual, auditory, motor, cognitive, and neurological disabilities. As populations age, these numbers will continue to grow. Failing to make web content accessible means excluding a substantial portion of potential users, customers, and citizens.

The business case is equally compelling. Accessible websites tend to have better search engine optimization because many accessibility best practices, such as proper heading structure, meaningful link text, and alternative text for images, align with SEO best practices. Accessible sites also tend to have lower bounce rates, higher conversion rates, and broader market reach. Organizations that invest in accessibility demonstrate a commitment to inclusion that resonates with consumers and strengthens brand reputation.

A Brief History of WCAG

Understanding where WCAG came from helps explain why the current version looks the way it does and where the standard is headed next. The guidelines have evolved significantly over more than two decades, each version responding to changes in web technology and a deeper understanding of how people with disabilities use the web.

From WCAG 1.0 to 2.2

WCAG 1.0 was published in May 1999, making it one of the earliest formal standards for web accessibility. It contained 14 guidelines and 65 checkpoints, but its recommendations were tightly coupled to the HTML-based web of the late 1990s. As web technology evolved with the rise of CSS, JavaScript, and rich internet applications, WCAG 1.0 became increasingly difficult to apply to modern web content.

WCAG 2.0, published in December 2008, represented a fundamental redesign. Rather than being tied to specific technologies, WCAG 2.0 was written to be technology-agnostic. Its success criteria describe outcomes rather than techniques, meaning they can be applied to HTML, PDF, mobile applications, and emerging technologies alike. WCAG 2.0 introduced the four POUR principles and the three conformance levels (A, AA, AAA) that remain the foundation of the standard today. WCAG 2.0 was also adopted as the international standard ISO/IEC 40500:2012.

WCAG 2.1, published in June 2018, extended WCAG 2.0 by adding 17 new success criteria. These additions addressed gaps that had become apparent as the web shifted toward mobile devices and as the accessibility community gained a deeper understanding of the needs of people with cognitive and learning disabilities and people with low vision. WCAG 2.1 was designed to be backward-compatible with WCAG 2.0, meaning any site that conforms to WCAG 2.1 also conforms to WCAG 2.0.

WCAG 2.2, published on October 5, 2023, follows the same backward-compatible approach. It adds nine new success criteria and removes one (4.1.1 Parsing, which was made obsolete by improvements in how browsers and assistive technologies process HTML). The new criteria continue the emphasis on cognitive accessibility, mobile usability, and improved support for people with low vision.

WCAG 2.2 Conformance Levels Explained

Every WCAG success criterion is assigned one of three conformance levels: A, AA, or AAA. These levels indicate the impact and difficulty of the criterion. Understanding the levels is essential for setting compliance targets and prioritizing remediation efforts.

Level A — Minimum Accessibility

Level A criteria address the most fundamental barriers to accessibility. If these criteria are not met, one or more groups of users will find it impossible or extremely difficult to access the content. Examples include providing text alternatives for non-text content (images, icons, charts), making all functionality available from a keyboard, and not using content that flashes more than three times per second.

Meeting Level A is the bare minimum for any website, but Level A alone does not make a site genuinely accessible. Many significant barriers are addressed only at Level AA. Think of Level A as removing the most severe roadblocks that would completely prevent access for entire groups of users.

Level AA — The Standard Target

Level AA is the most widely referenced conformance level in laws, regulations, and organizational policies around the world. The ADA, the European Accessibility Act, Section 508, and EN 301 549 all point to WCAG Level AA as the target. Level AA criteria address issues that create significant barriers but may not completely block access. Key examples include sufficient color contrast between text and background (a minimum ratio of 4.5:1 for normal text), the ability to resize text up to 200 percent without loss of content or functionality, visible focus indicators for keyboard navigation, and providing captions for prerecorded audio content.

For most organizations, Level AA conformance should be the target. It provides a strong level of accessibility for the vast majority of users with disabilities and satisfies the requirements of most accessibility-related legislation. Level AA conformance includes all Level A criteria plus the additional AA criteria, totaling 58 success criteria in WCAG 2.2.

Level AAA — Enhanced Accessibility

Level AAA represents the most stringent accessibility requirements. These criteria provide additional enhancements that benefit users with disabilities but may not be achievable for all types of content. Examples include an enhanced color contrast ratio of 7:1 for normal text, sign language interpretation for all prerecorded audio content, and limiting all content to a lower secondary education reading level.

The W3C does not recommend Level AAA as a general conformance target for entire websites because it is not possible to satisfy all AAA success criteria for all types of content. However, organizations should aim to meet individual AAA criteria wherever practical, as doing so further improves the experience for users with disabilities. Meeting specific AAA criteria in areas that are most relevant to your audience can make a meaningful difference.

The Four Principles of WCAG (POUR)

The entire WCAG framework rests on four foundational principles commonly referred to by the acronym POUR. Every success criterion in WCAG falls under one of these four principles. Understanding POUR provides a mental model for thinking about accessibility that extends beyond any specific checklist or testing tool.

Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means that content cannot rely on a single sense alone. If information is conveyed visually, there must be a non-visual alternative. If content is presented as audio, there must be a text-based alternative. Key requirements under the Perceivable principle include providing text alternatives (alt text) for all non-text content such as images, icons, and charts; providing captions and transcripts for audio and video content; ensuring content can be presented in different ways without losing information or structure (for example, using proper heading hierarchy and semantic HTML); and maintaining sufficient color contrast between text and its background so that users with low vision or color blindness can read the content.

Operable

User interface components and navigation must be operable by all users. This principle ensures that people who cannot use a mouse, who need extra time, or who have seizure disorders can still interact with the content. Key requirements include making all functionality accessible via keyboard, providing users enough time to read and interact with content, not designing content in a way that is known to cause seizures or physical reactions (such as flashing content), providing mechanisms to help users navigate and find content (headings, landmarks, skip links), and ensuring that users can operate the interface through various input modalities beyond just a traditional keyboard and mouse, including touch, voice, and other assistive technologies.

Understandable

Information and the operation of the user interface must be understandable. Users must be able to comprehend both the content itself and how the interface works. Key requirements include making text readable and understandable by specifying the language of the page and any language changes within the content; making web pages appear and operate in predictable ways, so that navigation is consistent, components behave as expected, and changes of context do not occur without user initiation; and providing input assistance such as clear labels, helpful error messages, and error prevention mechanisms for forms. This principle is particularly important for users with cognitive and learning disabilities, who may be disproportionately affected by confusing layouts, unclear instructions, or unpredictable interface behavior.

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This principle focuses on technical compatibility and future-proofing. Key requirements include using valid, well-formed markup so that browsers and assistive technologies can accurately parse and present the content; ensuring that custom user interface components have correct names, roles, and values that can be programmatically determined by assistive technologies (using ARIA attributes when native HTML semantics are insufficient); and providing status messages that can be programmatically determined so screen readers can announce them without receiving focus. The Robust principle ensures that as browsers and assistive technologies evolve, content remains accessible.

What Is New in WCAG 2.2

WCAG 2.2 introduces nine new success criteria that were not present in WCAG 2.1. These criteria address areas where users with disabilities continued to face significant barriers despite conformance with previous versions. The new criteria place particular emphasis on focus visibility, authentication, and reducing cognitive load. Here is a detailed look at each one.

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a user interface component receives keyboard focus, that component must not be entirely hidden behind other content such as sticky headers, footers, or modal overlays. This criterion recognizes that sighted keyboard users depend on the focus indicator to know where they are on the page. If the focused element is completely obscured by a sticky navigation bar or a cookie consent banner, the user loses track of their position and cannot interact effectively. Partial obscuring is allowed at this level, but the focused element must not be fully concealed.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

This enhanced version of the previous criterion requires that no part of the focused component is hidden by author-created content. While the AA level allows partial obscuring, this AAA criterion demands that the focused element be fully visible at all times. This provides an even better experience for sighted keyboard users by ensuring they can always see the complete focus indicator and the focused element in its entirety.

2.4.13 Focus Appearance — Level AAA

This criterion defines minimum requirements for focus indicators to ensure they are sufficiently visible. The focus indicator must have a minimum area that is at least as large as a 2 CSS pixel thick perimeter of the unfocused component, and it must have a contrast ratio of at least 3:1 between its focused and unfocused states. This criterion addresses the common problem of focus indicators that are technically present but too subtle to be noticed by users with low vision.

2.5.7 Dragging Movements — Level AA

Any functionality that uses a dragging movement for operation must also be achievable through a single pointer without dragging, unless dragging is essential to the underlying activity. This criterion helps users with motor disabilities who may not be able to perform drag-and-drop actions. For example, a sortable list that allows items to be dragged into a new order must also provide up and down buttons or another single-pointer mechanism to achieve the same result.

2.5.8 Target Size (Minimum) — Level AA

The size of interactive targets (buttons, links, form controls) must be at least 24 by 24 CSS pixels, or there must be sufficient spacing between undersized targets so that they are not too close together. This criterion acknowledges that users with motor disabilities, users with tremors, and users on touch devices may have difficulty accurately tapping or clicking on small targets. There are exceptions for inline links within text, targets whose size is determined by the user agent, and cases where the target size is essential to the information being conveyed.

3.2.6 Consistent Help — Level A

If a website provides help mechanisms such as contact information, a chat feature, a help page link, or a self-service FAQ, those mechanisms must appear in the same relative order on every page. Users with cognitive disabilities rely on consistent placement of help features. If the help link is in the footer on one page and in the header on another, it creates confusion and increases cognitive load. This criterion does not require that help mechanisms be present, but if they are, they must be consistent.

3.3.7 Redundant Entry — Level A

Information that the user has previously entered during a process must either be auto-populated or available for the user to select rather than requiring them to enter it again. For example, if a user enters their shipping address during checkout, the billing address form should offer the option to reuse the shipping address rather than forcing the user to type it a second time. This criterion reduces cognitive load and physical effort, benefiting users with cognitive disabilities, motor disabilities, and everyone else.

3.3.8 Accessible Authentication (Minimum) — Level AA

Authentication processes must not rely on cognitive function tests such as remembering a password, solving a puzzle, or performing a calculation, unless an alternative method is provided or a mechanism exists to assist the user (such as allowing password managers to fill in credentials or supporting copy-paste into password fields). This criterion recognizes that cognitive function tests create disproportionate barriers for users with cognitive disabilities. Authentication methods that support password managers, biometric login, or passkeys satisfy this criterion.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

This enhanced version of the authentication criterion goes further by also prohibiting object recognition and personal content recognition as authentication methods. At the AA level, recognizing objects in images (such as selecting all pictures containing traffic lights) is permitted as an alternative. At the AAA level, even this type of test is not allowed. This ensures that authentication is accessible to users with the broadest range of cognitive disabilities.

WCAG 2.2 vs. WCAG 2.1: Key Differences

WCAG 2.2 builds upon WCAG 2.1 in a backward-compatible manner. This means that all success criteria from WCAG 2.1 remain in WCAG 2.2, with one exception: Success Criterion 4.1.1 Parsing has been removed. This criterion required that HTML be well-formed and free of parsing errors. It was removed because modern browsers and assistive technologies have become robust enough to handle most parsing issues, making the criterion largely redundant.

In its place, WCAG 2.2 adds nine new success criteria. Six of these are at the A or AA level, meaning they are relevant for organizations targeting the most commonly required conformance level. The new criteria reflect three key areas of focus: improving the experience for users with cognitive and learning disabilities by reducing authentication barriers and preventing redundant data entry; improving support for users with low vision and motor disabilities through better focus visibility and minimum target sizes; and improving mobile usability by ensuring alternatives to dragging gestures.

A site that already conforms to WCAG 2.1 Level AA needs to address five additional AA-level criteria (Focus Not Obscured Minimum, Dragging Movements, Target Size Minimum, Accessible Authentication Minimum) and two new A-level criteria (Consistent Help, Redundant Entry) to conform to WCAG 2.2 Level AA. The removal of 4.1.1 Parsing means one fewer criterion to worry about, though most sites were already meeting it.

Legal Requirements That Reference WCAG

WCAG is not a law in itself, but it serves as the technical standard that numerous laws and regulations around the world point to when defining accessibility requirements. Understanding the legal landscape is essential for organizations that want to manage risk and meet their obligations.

Americans with Disabilities Act (ADA)

The ADA prohibits discrimination on the basis of disability in places of public accommodation, and federal courts have increasingly held that websites qualify as places of public accommodation. The Department of Justice (DOJ) has issued guidance stating that the ADA applies to websites and referencing WCAG 2.1 Level AA as the appropriate standard. In April 2024, the DOJ published a final rule under ADA Title II requiring state and local government websites to conform to WCAG 2.1 Level AA by 2026 or 2028, depending on the size of the jurisdiction. While no similar formal rule exists yet for private sector websites under Title III, courts have consistently used WCAG as the benchmark in settlement agreements and consent decrees. The number of ADA web accessibility lawsuits continues to grow each year, making proactive WCAG compliance a critical risk management strategy.

European Accessibility Act (EAA)

The European Accessibility Act, which became enforceable in June 2025, requires that a wide range of products and services placed on the EU market meet accessibility requirements. This includes e-commerce websites, banking services, transportation services, and electronic communications. The EAA references the European harmonized standard EN 301 549, which in turn maps its web accessibility requirements to WCAG 2.1 Level AA. The EAA applies to businesses of all sizes with limited exceptions for micro-enterprises with fewer than 10 employees and an annual turnover below 2 million euros. Non-compliance can result in fines and market restrictions determined by each EU member state.

Section 508 and EN 301 549

Section 508 of the Rehabilitation Act requires US federal agencies to make their electronic and information technology accessible to people with disabilities. The Section 508 standards, refreshed in 2017, incorporate WCAG 2.0 Level AA by reference. This means federal agencies and their contractors must ensure that websites, documents, and software meet WCAG 2.0 AA criteria. In practice, many agencies target WCAG 2.1 or 2.2 to stay ahead of potential standard updates.

EN 301 549 is the European harmonized standard for ICT accessibility. It maps web content requirements directly to WCAG, currently at version 2.1 Level AA, and covers a broader range of ICT products including software, hardware, and documents. EN 301 549 is referenced by the European Accessibility Act, the EU Web Accessibility Directive, and procurement requirements across EU member states.

How to Test for WCAG 2.2 Compliance

Testing for WCAG compliance requires a combination of approaches. No single method can catch every issue, but together they provide comprehensive coverage. The three pillars of accessibility testing are automated testing, manual expert testing, and user testing with people with disabilities.

Automated Testing

Automated testing tools scan web pages programmatically and flag issues that can be detected through code analysis. These tools are fast, consistent, and excellent for catching a wide range of common issues such as missing alt text on images, insufficient color contrast ratios, missing form labels, incorrect heading hierarchy, missing language attributes, and ARIA usage errors. Automated scanning is the best starting point for any accessibility effort because it quickly identifies the low-hanging fruit. You can scan your website for WCAG 2.2 compliance using our free tool to get a comprehensive report of automated findings within seconds. Industry research suggests that automated tools catch approximately 30 to 40 percent of all WCAG issues.

Manual Testing

Manual testing involves a human evaluator working through the website using assistive technologies and testing methodologies. This includes navigating the entire site using only a keyboard to verify that all interactive elements are reachable, operable, and have visible focus indicators; using screen readers such as NVDA (free, Windows), JAWS (Windows), and VoiceOver (built into macOS and iOS) to experience the site as a blind or low-vision user would; verifying that all content reflows properly at 400 percent zoom; checking that custom components have the correct ARIA roles, states, and properties; evaluating whether the reading order makes logical sense; and assessing the quality and accuracy of alternative text. Manual testing catches issues that automated tools cannot, such as whether an image's alt text is actually meaningful or whether a complex interactive widget is truly usable with a screen reader.

User Testing with People with Disabilities

User testing with people who actually have disabilities is the most comprehensive form of accessibility evaluation. While automated tools check code and manual testers simulate the experience, users with disabilities reveal real-world barriers that even expert testers may miss. A screen reader user may discover that a technically compliant form is confusing because the tab order does not match the visual layout. A user with a cognitive disability may find that a process that passes all WCAG criteria is still too complex to complete. User testing provides insights that no amount of automated or manual testing can replicate. Organizations committed to genuine accessibility should include people with a range of disabilities in their testing programs.

A Step-by-Step WCAG 2.2 Compliance Roadmap

Achieving WCAG 2.2 compliance is a journey, not a one-time project. The following roadmap provides a structured approach that organizations of any size can follow to systematically improve their web accessibility posture.

1. Audit your current state. Begin by establishing a baseline understanding of where your website stands today. Use our free scanner as a starting point to get an automated assessment of your most critical pages, including the homepage, key landing pages, login and registration flows, and checkout or contact forms. Document the number and severity of issues found.
2. Prioritize critical and serious issues. Not all accessibility issues have the same impact. Focus first on issues that completely block access for users with disabilities (Level A failures), then on issues that create significant barriers (Level AA failures). Within each level, prioritize issues that affect the largest number of users or that appear on the most heavily trafficked pages.
3. Fix issues by POUR principle. Organize your remediation work around the four POUR principles. Start with Perceivable issues (missing alt text, missing captions, insufficient contrast), then address Operable issues (keyboard access, focus management, timing), followed by Understandable issues (form labels, error messages, consistent navigation), and finally Robust issues (valid markup, ARIA attributes, status messages). This approach ensures systematic coverage rather than ad-hoc fixes.
4. Test with assistive technologies. After fixing issues, test your pages with actual assistive technologies. Navigate with a keyboard alone, test with NVDA or VoiceOver, verify zoom and reflow behavior, and check touch targets on mobile devices. This step catches issues that automated scanning misses and verifies that your fixes actually work as intended.
5. Document conformance. Create an accessibility statement or Voluntary Product Accessibility Template (VPAT) that documents your conformance level, known limitations, and remediation plans. An accessibility statement demonstrates transparency and good faith, which can be valuable both legally and in terms of public trust. Learn more about how our scanner works and how it can support your documentation process.
6. Establish ongoing monitoring. Accessibility is not a checkbox; it is an ongoing commitment. New content, design changes, and code updates can introduce new issues at any time. Establish a regular scanning schedule, integrate accessibility checks into your CI/CD pipeline, train your content team on accessibility best practices, and conduct periodic manual audits to maintain conformance over time.

Frequently Asked Questions

Is WCAG 2.2 legally required?

WCAG 2.2 is not directly written into law in most jurisdictions, but numerous laws and regulations reference it as the technical standard for accessibility. The ADA in the United States, the European Accessibility Act in the EU, Section 508 for US federal agencies, and EN 301 549 in Europe all point to WCAG (typically at Level AA) as the benchmark. Courts in the US have increasingly used WCAG conformance as the measure of ADA compliance for websites. As a practical matter, meeting WCAG 2.2 Level AA is the safest approach for managing legal risk.

What is the difference between WCAG 2.1 and 2.2?

WCAG 2.2 adds nine new success criteria to WCAG 2.1 and removes one (4.1.1 Parsing). The new criteria focus on improving the experience for users with cognitive disabilities (accessible authentication, redundant entry), users with low vision (focus not obscured, focus appearance), users with motor disabilities (target size minimum, dragging movements), and all users (consistent help). WCAG 2.2 is backward-compatible with WCAG 2.1, so a site that conforms to 2.2 automatically conforms to 2.1 as well.

Do I need to meet Level AAA?

Level AAA is not typically required as an overall conformance target by any law or regulation. The W3C does not recommend AAA as a general policy because it is not possible to satisfy all AAA criteria for every type of content. Level AA is the standard target for most organizations and legal frameworks. However, meeting individual AAA criteria where feasible, such as enhanced contrast ratios or sign language interpretation, can further improve accessibility for your users.

Can automated tools find all WCAG issues?

No. Automated accessibility testing tools can detect approximately 30 to 40 percent of WCAG issues. They are excellent at finding technical violations such as missing alt text, insufficient color contrast, missing form labels, and incorrect heading structure. However, many success criteria require human judgment to evaluate, such as whether alt text is meaningful, whether content is logically ordered, or whether ARIA attributes are used correctly in complex widgets. A comprehensive accessibility evaluation requires automated scanning, manual expert testing, and user testing with people with disabilities.

When did WCAG 2.2 become official?

WCAG 2.2 became an official W3C Recommendation on October 5, 2023. It is the latest stable version of the Web Content Accessibility Guidelines and supersedes WCAG 2.1 as the current standard. You can explore our accessibility blog for more detailed guides on specific WCAG criteria and compliance strategies.