WCAG 2.1 vs 2.2: What Changed and Which Standard to Follow

Ask a web developer whether your site meets WCAG, and a good one will answer with a question of their own: which version? The Web Content Accessibility Guidelines are the technical standard behind nearly every website accessibility requirement in the United States, and they have been updated twice since most business websites were last rebuilt.

WCAG 2.1 became a W3C Recommendation in 2018. WCAG 2.2 followed on October 5, 2023. The difference between them is smaller than the version numbers suggest, but it touches things visitors notice every day: sticky headers that hide what you are typing into, buttons too small to tap, and login screens that make you remember a code. Here is what changed, which version US rules actually point to, and how to plan your next round of website work.

Why a new version at all?

WCAG 2.0 was written in 2008, before most people browsed on a phone. Version 2.1 filled in gaps for mobile users and people with low vision, adding requirements for things like content that reflows on small screens and text spacing. Version 2.2 continues that work, with a particular focus on people with cognitive and motor disabilities: the visitor who loses their place when a banner covers the page, or who can’t make a precise dragging motion with a mouse.

W3C designed WCAG 2.2 to build on 2.1 rather than replace it. In practice, a site that meets 2.2 generally meets 2.1 as well. That makes the choice between them less of a fork in the road and more a question of how far ahead you want to be.

What WCAG 2.2 adds

WCAG 2.2 introduces nine new success criteria. Six of them sit at Levels A and AA, the levels most laws and policies require, and each one maps to a frustration you have probably experienced yourself.

Keeping focus visible

2.4.11 Focus Not Obscured (Minimum), Level AA, says the element a keyboard user is on must not be completely hidden by other content. Sticky headers, chat bubbles and cookie banners are the usual culprits. If someone tabs to a link and it slides underneath your fixed navigation bar, they have no idea where they are on the page.

Making targets easier to hit

2.5.8 Target Size (Minimum), Level AA, sets a floor of 24 by 24 CSS pixels for buttons, icons and other pointer targets, with sensible exceptions such as links inside a sentence or small targets with enough space around them. 2.5.7 Dragging Movements, Level AA, requires that anything done by dragging, such as a slider or a sortable list, can also be done with a simple click or tap.

Reducing the memory load

Three criteria make tasks easier to complete. 3.2.6 Consistent Help, Level A, asks that contact details, chat or other help appear in the same place across pages. 3.3.7 Redundant Entry, Level A, means people shouldn’t have to retype information they already gave earlier in the same process. And 3.3.8 Accessible Authentication (Minimum), Level AA, says logging in shouldn’t depend on remembering or transcribing something unless there is an alternative or help, which in practice means letting password managers work and letting people paste.

The remaining three criteria are at Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance and 3.3.9 Accessible Authentication (Enhanced). Few organizations are required to meet AAA, but they are useful design goals.

What WCAG 2.2 removes

Version 2.2 also retires one requirement: 4.1.1 Parsing, which asked for well-formed markup. W3C concluded that modern browsers and assistive technologies handle markup errors consistently, so the criterion no longer protected anyone. The problems it used to catch, such as duplicate IDs that break a form label, are still covered by other criteria, including 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

Which version do US rules point to?

This is where the practical answer lives, and for now it is still WCAG 2.1.

The Department of Justice rule for state and local government websites and mobile apps under Title II of the ADA adopts WCAG 2.1 Level AA. For businesses covered by Title III, there is no website regulation at all, but courts, settlements and DOJ guidance have long treated WCAG 2.1 AA, and before it 2.0 AA, as the benchmark. Federal agencies follow Section 508 standards, which incorporate WCAG 2.0 Level AA.

Putting the new criteria to work

The good news is that most of the WCAG 2.2 additions are inexpensive to address when you know to look for them. On a typical business website, the fixes look like this:

• Add scroll padding so sticky headers and banners never cover the element that has keyboard focus.
• Check buttons, social icons, pagination and close buttons for a 24-pixel target, or enough spacing around smaller ones.
• Give sliders, sortable lists and map interactions a click or tap alternative.
• Keep your phone number, contact link or chat in the same spot in the header or footer on every page.
• Carry information forward in multi-step forms, for example with a “billing address same as shipping” option.
• Let password managers fill login fields, allow pasting, and replace puzzle-style CAPTCHAs with invisible spam protection.

At EVERNET we build these into the templates first, so a single change fixes every page that uses them. We also run accessiBe on our own site to give visitors extra controls for contrast, text size and motion, but a widget can’t resize a button or move a sticky header. The template work comes first.

Where to go from here

Knowing which version you are aiming for is only useful once you know where your site stands. An EVERNET website accessibility audit tests your pages against WCAG 2.1 AA and can include the WCAG 2.2 criteria. For the legal background, read ADA website requirements and recent lawsuits, and to try some checks yourself, start with our guide to keyboard and screen reader testing.