What’s New With WCAG 2.2

The World Wide Web Consortium (W3C) is expected to release the latest version of its Web Content Accessibility Guidelines (WCAG) in early 2023. Here’s what you need to know about the proposed changes — and how they 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.

What’s Changing In WCAG 2.2?

As of September 6, 2022, 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 Appearance (Minimum)

The intent of WCAG Success Criterion (SC) 2.4.11 is to help low-vision users who use a keyboard to navigate websites be able to easily tell where they are on a page by ensuring the current point of focus is clearly visible.

It builds on two existing WCAG criteria that affect focus indicators, or the visual markers that indicate the currently focused element on a page: WCAG SC 2.4.7: Focus Visible and WCAG SC 1.4.11: Non-text Contrast.

Where 2.4.7 merely requires a visible focus indicator, this criterion defines a minimum level of visibility. And where 1.4.11 requires a component to have adequate contrast against the background in both states, this criterion requires sufficient contrast for the focus indicator itself.

Success Criterion 2.4.12: Focus Not Obscured (Minimum) and Success Criterion 2.4.13: Focus Appearance (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.

The Candidate Recommendation of WCAG 2.2 proposes two new success criteria: a Level AA version (2.4.12) requiring that at least part of the focus indicator is not obscured by other content on the page, and a Level AAA version (2.4.13) requiring that no part of the focus indicator is hidden by other content.

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 Criterion 3.3.7 Accessible Authentication and Success Criterion 3.3.8 Accessible Authentication (No Exception)

The intent of WCAG SC 3.3.7: 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.8: Accessible Authentication (No Exceptions) takes this a step further by not allowing any exceptions for cognitive function tests, such as displaying a section of images and requiring users to choose which ones contain a particular object. It is being proposed as a Level AAA guideline.

Success Criteria 3.3.9: 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.

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.