What’s New With WCAG 2.2

This post has been updated to reflect the latest information from the World Wide Web Consortium (W3C).

The World Wide Web Consortium (W3C) is expected to release the latest version of its Web Content Accessibility Guidelines (WCAG) in Q3 2023. Here’s what you need to know about WCAG 2.2 — and how these changes affect earlier versions of WCAG.

What Are the Web Content Accessibility Guidelines?

Published by the W3C, the Web Content Accessibility Guidelines provide a set of accessibility standards and instructions on making digital content more accessible to people with disabilities.

WCAG is regularly updated to keep pace with the latest technologies and user preferences. In 2021, the Web Accessibility Initiative (WAI) — which helps develop standards and support materials for web accessibility — announced a working draft of WCAG 2.2.

How Does WCAG 2.2 Relate to Previous Versions?

As with previous versions, WCAG 2.2 will build on the 78 success criteria already outlined in WCAG 2.1. These criteria will be broken into three levels: A, AA, and AAA.

Level A success criteria represent a minimum conformance level for accessibility. However, many global accessibility laws — including Section 508 of the Rehabilitation Act and The Accessibility for Ontarians with Disabilities Act (AODA) — require Level AA conformance.

What’s Changing In WCAG 2.2?

As of May 17, 2023, the WCAG 2.2 proposal (or Candidate Recommendation) included nine new success criteria. Each of these criteria is still up for feedback and changes, so there’s no guarantee that all of them will make it into the final version of WCAG 2.2.

Here’s a quick overview of the new guidelines — and how each one can help address digital accessibility issues:

Success Criterion 2.4.11: Focus Not Obscured (Minimum) and Success Criterion 2.4.12: Focus Not Obscured (Enhanced)

For sighted users who use a keyboard or keyboard-like device (like a switch or voice input), knowing the current point of focus is important. However, focused elements can occasionally be obscured by sticky headers, pop-ups, and other content that appears on-screen while a user is browsing the page.

When a user interface component receives keyboard focus, WCAG Success Criterion (SC) 2.4.11 requires that at least a portion of it remain visible and not be obscured by other content on the screen.

SC 2.4.12 requires that no part of the focus indicator is hidden by other content on the page.

Success Criterion 2.4.13: Focus Appearance

Focus indicators must have sufficient color contrast (at least 3:1 between the same pixels in the focused and unfocused states) and be large enough to be clearly visible.

Success Criterion 2.5.7: Dragging Movements

Drag and drop can be cumbersome and error-prone for many people, whether they use a keyboard, have a mobility impairment, or rely on adapted input devices like head pointers or speech-controlled mouse emulators.

WCAG SC 2.5.7 requires that dragging movements are not the only way certain actions on a page can be accomplished, whether it’s manipulating a slider or reordering components in a drag-and-drop interface. For example, a website could enable the keyboard to work with up/down/left/right arrows or provide on-screen buttons that a user could press to move a slider or sort a list.

Success Criterion 2.5.8: Target Size (Minimum)

When buttons and other clickable elements are small, it’s difficult for people with hand tremors and other fine motor impairments to activate them without accidentally activating another element.

This Success Criterion requires that the minimum size of the target for all clickable elements, such as call-to-action buttons, is at least 24 by 24 CSS pixels. It also requires websites to provide at least 24 CSS pixels of spacing between adjacent targets.

WCAG SC 2.5.8: Target Size (Minimum) provides a Level AA alternative to WCAG SC 2.5.5: Target Size (Enhanced), which was introduced as part of WCAG 2.1 and requires the target size for all clickable elements to be at least 44 by 44 CSS pixels.

Success Criterion 3.2.6: Consistent Help

The goal of this Success Criterion is to ensure that all users can easily find help for completing tasks on a web page. If a help feature — such as human contact details or a self–help option — is available on multiple pages of a website, it must appear in the same relative place and order on each of the pages where it appears.

Success Criteria 3.3.7: Redundant Entry

Some forms require users to enter the same information more than once, which can be a burden for people with motor impairments or cognitive disabilities. This Success Criterion requires websites to auto-populate fields or allow users to re-use data that’s already been entered.

Success Criterion 3.3.8 Accessible Authentication (Minimum) and Success Criterion 3.3.9 Accessible Authentication (Enhanced)

The intent of WCAG SC 3.3.8: Accessible Authentication is to provide people with cognitive disabilities an easy, accessible way to log into websites and mobile apps. If a cognitive function test — such as memorizing a password or identifying images or characters — is used, websites must provide at least one other authentication method.

WCAG SC 3.3.9: Accessible Authentication (Enhanced) takes this a step further by not permitting authentication by using object recognition or user-provided content, such as a picture uploaded by the user.

Getting Ready for WCAG 2.2

It’s important to remember that the current version of WCAG 2.2 is only a working draft authored by the Accessibility Guidelines Working Group (AG WG). The official release of WCAG 2.2 will likely include a few updates, but reviewing the draft can provide a sense of outstanding accessibility issues that the people behind WCAG would like to address.

Want to see how well your website conforms to WCAG 2.1? Enter any URL to get a free scan of your website and identify accessibility issues you can fix today.