You are currently viewing WCAG 2.2: Navigating the New Standards For Web Accessibility (+ Simple Checklist)

WCAG 2.2: Navigating the New Standards For Web Accessibility (+ Simple Checklist)

Learn everything you need to know about the new WCAG 2.2 guidelines and how to implement them to improve your site’s accessibility. 

A hand tapping on a table on a flat surface. There are tooltips rising from the tablet's surface to show that the web content meets required standards.

The WCAG 2.2 release date of October 5, 2023, marks a significant evolution in web standards. This new update has become a focal point for everyone involved in web content creation and digital inclusivity. 

You might wonder, “Do I need to implement these changes anytime soon?” While conformance might not be a legal must yet in your area, getting familiar with WCAG 2.2 is a smart move. It shows you’re proactive about accessibility. Plus, you’ll stay ahead of the curve when these guidelines become standard practice.

In this article, we’ll break down WCAG 2.2 to help anyone understand and implement these changes easily. Whether you’re updating your website or building a new one, these insights will help you make your site accessible and inclusive. So, let’s dive in!

What is WCAG 2.2?

WCAG 2.2 stands for the Web Content Accessibility Guidelines (version 2.2). It serves as the global standard for making web content accessible to people with disabilities. These include visual, auditory, physical, speech, cognitive, language, learning, and neurological impairments.

WCAG aims to ensure everyone, regardless of their abilities, can easily navigate and interact with web content. This means using accessible graphic design techniques to ensure websites and digital content are as easy for people with disabilities to access and use as they are for everyone else.

WCAG 2.1 vs 2.2

As a website owner or someone interested in digital accessibility, it’s vital to understand the differences between WCAG 2.1 vs 2.2 and how this upgrade affects your site. WCAG 2.2 builds on the foundation laid by WCAG 2.1, with a specific emphasis on improving accessibility for three major groups. These include:

  • Users with cognitive or learning disabilities
  • Users with low vision
  • Mobile devices users

Like earlier versions, WCAG 2.2 is backward-compatible. That means if your site conforms to WCAG 2.2, it also meets WCAG 2.1 requirements. The new version introduces nine new success criteria that build on the previous ones. We’ll talk about them in detail soon. 

One notable change in WCAG 2.2 is the removal of Success Criterion 4.1.1 (Parsing). This is due to technological advancements that make the criterion redundant in the current digital landscape.

WCAG 2.2 Checklist (Grouped by Conformance Level)

Following the WCAG 2.2 release date, nine new success criteria have been added that target various aspects of web accessibility. To make it easier to understand and implement these changes, let’s break them down by their conformance level: A, AA, and AAA.

Level A Criteria

Success Criterion 3.2.6 - Consistent Help

This criterion requires that if a website offers a help option, such as a phone number, chat service, or FAQ page, which appears on multiple pages, it should always be in the same place. This way, all users, especially people with cognitive or learning disabilities, can get the support they need quickly and efficiently. 

There are a few exceptions and limitations to this rule, though:

  • If a user changes the page’s zoom level or orientation, the location of help mechanisms can also change.
  • If your site has different sections for different tasks, you can place the help options in separate spots for each section. However, keep these changes as consistent as possible.
  • You don’t need to have help options on downloadable PDFs or other static documents. This criterion only applies to interactive web pages.
  • You don’t need to have human support on standby at all times. If your live help has off-hours, ensure users know when they can reach out.

In a nutshell…
Keep your help and support mechanisms in the same spot across your web pages. It makes your site more user-friendly, especially for those who might find navigation challenging.

Success Criterion 3.3.7 - Redundant Entry 

This success criterion aims to reduce the need for users to re-enter information already provided during the same session.

Exceptions are where:

  • Re-entering information is essential, such as for security purposes,
  • Previously entered information is no longer valid.

Why it matters: It reduces repetitive tasks on your site and makes it accessible for users with memory or mobility impairments. Plus, it enhances the overall user experience without compromising user privacy and data security.

Level AA Criteria

A checklist of WCAG 2.2 A/AA success criterion

Success Criterion 2.4.11 - Focus Not Obscured

This WCAG 2.2 AA criterion aims to improve keyboard accessibility. It requires content on the site not to completely hide interactive elements. 

Exceptions to this rule are:

  • User-movable content: If your site allows users to move content around, ensure their default positions don’t cover focus. Once a user moves something, it is on them if it hides something else.
  • User-opened content: When users open menus or panels, these can overlap other content. But they shouldn’t hide the currently focused element. Think of it as opening a book on a table; it might cover part of the table, but it should not cover the part you’re reading.
  • Non-persistent opened information: Some elements on your site might temporarily pop up (like a combo box list or a tooltip). These are all right as long as they don’t remain open when they’re not in use.

In summary…
Ensure that users can see where they are and their actions on your site at every step. Design your site so nothing covers vital content or interactive elements. 

Success Criterion 2.5.7 - Dragging Movements

If your website has drag-and-drop features, provide an easier way to use them with a simple click or tap.

Why it matters: Some website visitors might find dragging actions difficult or impossible. They might use a trackball, a head pointer, or even voice commands to navigate your site. Providing an alternative to drag-and-drop actions helps them engage with your site’s features.


  • If the dragging action is essential and cannot be replicated by a simple click or tap, then it’s exempt.
  • This criterion doesn’t apply to actions for using browsers or assistive technologies.

💡Keep in mind that…
Meeting this criterion does not mean your drag-and-drop feature is keyboard-accessibility. When running a website accessibility audit, you need to check both aspects separately.

Success Criterion 2.5.8 - Target Size

This criterion sets a minimum target size for clickable elements to be at least 24 by 24 CSS pixels. This reduces the frustration of struggling to click or clicking the wrong thing. Users that benefit include people with tremors, large fingers, or those using a mobile device.

Exceptions – When smaller is okay!

While the general rule is to keep targets at least 24 by 24 CSS pixels, there are a few exceptions where you can go smaller:

  • If you have smaller targets, provide enough room around them. This gives enough space to tap without mistakes.
  • If there’s a smaller target, provide an alternative to do the same thing elsewhere on your page that meets the size criteria. 
  • For inline targets (like text links in a paragraph), don’t worry too much. Due to text flow and line height constraints, they can be smaller as long as they’re part of a sentence or constrained by text size. 
  • If your target size is browser-controlled (like a date picker in a form) and you haven’t modified it, it’s exempt. 
  • It’s okay to have a smaller target size if this is crucial for the information you’re conveying (like pins on a digital map). This exception is relevant for detailed maps or legal forms that require a specific layout. 

Success Criterion 3.3.8 - Accessible Authentication

This criterion aims to make login processes easier for users with cognitive disabilities. It requires providing an alternative method for cognitive function tests. Such tests include remembering a specific password or solving complex CAPTCHAs.

Exceptions – When cognitive tests are okay:

  • Where the site provides a different way to log in that doesn’t require memory or puzzle-solving. Using biometric data (fingerprint or facial recognition) is a great alternative.
  • If you must use a cognitive test, ensure there’s help available. One way is to allow the use of password managers. Another is to enable copy-paste functionality for entering codes or passwords.
  • Asking users to recognize general objects (like animals or cars) in a CAPTCHA is okay. However, these tests must not be too complex or culturally specific. 
  • You can allow the use of non-text personal content (like a photo the user has uploaded before) for authentication. But, you must ensure your site can handle such information securely.

Level AAA Criteria

These are the highest standards for web accessibility. Most web accessibility laws and standards in the world require Level AA conformance. But adding Level AAA features where you can helps to make your site more inclusive. Here’s a quick look at them:

Success Criterion 2.4.12 - Focus Not Obscured (Enhanced)

This is the stricter version of Success Criterion 2.4.11. It requires that no content on a webpage should hide a focused element. This benefits people who rely only on the keyboard to navigate web pages. They need to see which element they’re interacting with at all times. If they can’t see it, they might think something is broken or not know what to do next.

Success Criterion 2.4.13 - Focus Appearance

This aims to improve the visibility of keyboard focus indicators, such as outlines or highlights around interactive elements. It specifies minimum contrast ratios and sizes for these indicators. Meeting this criterion helps keyboard users, including those with visual impairments, to track their focus on the page.

Success Criterion 3.3.9 - Accessible Authentication (Enhanced)

This is an advanced level of accessible authentication that removes certain exceptions found in the AA level. Meeting this criterion provides a more accessible authentication experience for users with severe cognitive disabilities.

How Equally AI can help you meet WCAG 2.2 standards

Equally AI provides cutting-edge technology to help you meet accessibility requirements, minimize the risk of non-compliance, and enhance the user experience for all your visitors. Our platform offers a 360 solution for all your accessibility needs, with tools and resources to make compliance simple and easy.

You have the flexibility to tailor your accessibility features to fit your brand. This allows you to offer value-added, personalized experiences while prioritizing accessibility and inclusivity. 

Ready To Become

Leave a Reply