What you need to know about WCAG 2.2

Web Accessibility Knowledgebase

WCAG 2.2 is the most up-to-date version of the World Wide Web Consortium (W3C)'s web accessibility standards. But what sets this version of WCAG apart from its predecessors? And what must you do to conform to it?

Yoni Yampolsky

The information presented within this guide is aimed at website owners seeking to learn the ropes of web accessibility and to create a more inclusive online environment for people with disabilities. Technical elements are described in layman’s terms, and, as a rule, all topics pertaining to the legalities of web accessibility are presented in as simplified a manner as possible. This blog has no legal bearing, and cannot be relied on in the case of litigation.

A little over a year ago, on October 23rd, 2023, the Web Content Accessibility Guidelines 2.2 were officially published. 

The latest version of these guidelines, WCAG 2.2 has since been adopted as the optimal standard to which websites and web-based applications should meet to be considered accessible. 

But what exactly was introduced in WCAG 2.2? 

What led the World Wide Web Consortium (W3C) to publish it? 

And, most importantly, should you take action to conform to this latest version of WCAG? 

In this blog, we will cover everything you need to know about WCAG 2.2

We will cover the nine new guidelines added in this most recent edition of the world’s most important web accessibility standards, and show how to test your website to see whether it conforms to WCAG 2.2 Level AA.

What is WCAG 2.2?

WCAG 2.2 is the latest version of the Web Content Accessibility Guidelines (WCAG). Created by the World Wide Web Consortium (W3C), WCAG is the standard by which websites are deemed accessible, and serves as the foundation for many web accessibility laws and regulations around the world.

Why the need for WCAG 2.2?

The first version of WCAG, WCAG 1.0 was published twenty five years ago, in 1999.

Nine years later, in 2008, the next version of these guidelines, WCAG 2.0 was released. It would be another ten years before the third version of WCAG, WCAG 2.1 was published. 

Each new version of WCAG tackles accessibility issues introduced by new and emerging technologies that could not have been properly addressed in the former  versions.

WCAG 2.1, while still considered the golden standard for web accessibility (more on that in a minute), WCAG 2.2 is the most updated version of these guidelines, and one which most accounts for current web-based trends.

WCAG is a topic in and of itself, which we highly recommend you check into as you prepare to begin your accessibility journey. To that end, we encourage you to take a look at these guides:

What’s the difference between WCAG 2.2 and WCAG 2.1?

All versions of WCAG are composed of various design and technical criteria. Prominent examples of such criteria call for alternative text to be added to meaningful images (Success Criterion 1.1.1: Non-text Content), captions to be added to videos (Success Criterion 1.2.4: Captions), colors to sufficiently contrast with each other (Success Criterion 1.4.3: Contrast), and for text to be able to be resized by 200% without losing functionality (Success Criterion 1.4.5: Resize Text).

Building upon those appearing in WCAG 2.1, WCAG 2.2 introduces a number of new success criteria. 

These address accessibility issues that can arise when adopting and implementing new technologies, but not only.

Additionally, a single success criterion existing within WCAG 2.1 has not been included in WCAG 2.2.  

We will detail this success criterion later in the blog. You can press here to skip straight to that section. 

The nine new success criteria added to WCAG 2.2 that do not appear in WCAG 2.1 

WCAG 2.2 introduces nine new success criteria that do not appear in WCAG 2.1 

Let’s break them down into categories:


Success criteria relating to focus indicators:

A focus indicator is a visual marker that shows which element on a web page is currently selected or interactive, especially when navigating with a keyboard. It is crucial for web accessibility because it allows people with disabilities, particularly those with low vision or mobility impairments, to track their position on a page and navigate without using a mouse.

Under this category the following criteria have been added:

1. Success Criterion 2.4.11 Focus Not Obscured (Minimum): The focus indicator must not be hidden or blocked by other elements when navigating with a keyboard.

2. Success Criterion 2.4.12 Focus Not Obscured (Enhanced): The focus indicator must always remain fully visible, even in complex layouts where elements may overlap

3. Success Criterion 2.4.13 Focus Appearance (Minimum): The focus indicator must be clear, with a minimum size and contrast ratio to ensure it can be easily seen


Success criteria relating to input methods and gestures

Input methods refer to the various ways users interact with a web page, such as using a keyboard, mouse, or touchscreen. Gestures are specific actions like tapping, dragging, or swiping on touch-enabled devices. Ensuring these methods are accessible is crucial for users with motor disabilities or those who rely on alternative input devices.

Under this category, the following criteria have been added:

4. Success Criterion 2.5.7 Dragging Movements: For any function requiring dragging (like sliders), an alternative must be available that doesn't rely on dragging

5. Success Criterion 2.5.8 Pointer Target Spacing: Interactive elements need enough space between them to prevent accidental clicks or taps on nearby items


Success criteria relating to user assistance and consistency 

User assistance involves providing accessible help options, like contact forms or live chat, to guide users through interactions on a website. Consistency ensures that these assistive features are always available when needed, reducing confusion and improving user experience for everyone, including those with disabilities.

Under this category, the following criterion has been added:

6. Success Criterion 3.2.6 Consistent Help: Help options such as contact forms or chat support must be available consistently across relevant pages, ensuring users can easily access assistance when needed.


Success criteria relating to form usability and error prevention

Forms are essential for user interaction on websites, from filling out contact details to completing transactions. Ensuring that forms are easy to use and minimizing errors improves accessibility, especially for users with cognitive or motor disabilities, by making the process more efficient and less frustrating.

Under this category, the following criteria have been added:

7. Success Criterion 3.3.7 Redundant Entry: Users should not be required to re-enter the same information multiple times within a process, unless absolutely necessary.

8. Success Criterion 3.3.8 Accessible Authentication: Authentication processes must offer accessible alternatives, such as password managers or biometric logins, so users do not need to rely solely on memory or cognitive tasks.

9. Success Criterion 3.3.9 Error Prevention (All): For complex tasks (such as submitting forms), website visitors must be able to review, correct, and confirm their input before final submission, helping prevent critical mistakes.

What success criterion appearing in WCAG 2.1 was removed from WCAG 2.2?

One success criterion appearing in WCAG 2.1 was removed from WCAG 2.2: 

Success Criterion 4.1.1 Parsing, which requires web pages to be well-formed so that user agents, including assistive technologies, could correctly interpret and interact with the content. 

The removal of this criterion reflects the understanding that modern web technologies have evolved, and most browsers now handle these issues automatically.

Do you need to conform to WCAG 2.2?

Conforming to WCAG is critical to becoming accessible to all website visitors, including those with disabilities. 

However, what exact version of WCAG you should conform to does not have a straightforward answer, at least at the moment. 

Most web accessibility laws reference earlier versions of WCAG as the standard websites should conform to.

Many U.S. courts now apply the Americans with Disabilities Act (ADA), to websites, pointing to WCAG 2.0 and WCAG 2.1 at Level AA as the standard websites should conform to, under the law.

Other laws specifically set WCAG 2.0 Level AA as the standard for compliance. These include:

Bottom line: 

WCAG 2.1 Level AA is still considered by many to be a more than acceptable standard to conform to. 

However, given that WCAG 2.2 is the most up-to-date version of WCAG, and one which addresses all the most common trends and technologies, it is recommended you take action so that your website conforms to it. 

How to test a website for WCAG 2.2 conformance

You can use a variety of approaches to test a website or web-based application for WCAG 2.2. Conformance:

  • Test your website manually: This approach is typically carried out by web accessibility experts, like accessServics. With an intimate knowledge of WCAG, expert service providers can examine all areas of your website and spot elements that fall short of WCAG 2.2 requirements
  • Test your website using automated tools: WCAG testing tools like accessScan provide you with quick insights of your website’s level of WCAG conformance. Once you submit its URL, your web page will be quickly audited by acccessScan, after which you will be presented with a detailed report, highlighting the accessibility issues existing within it
  • Test your website using a blended approach: The ideal testing approach will see you combining both methods. You can use accessScan for a quick (but comprehensive) accessibility audit. Then, web accessibility experts can take the report provided by accessScan to further investigate your website’s true level of WCAG conformance