WCAG 2.2 vs 2.1: What Changed and Which One to Target
Short answer: WCAG 2.2 adds six new Level A and AA criteria and removes 4.1.1 Parsing. It is largely backward compatible with 2.1, so most sites should target 2.2 AA, unless a contract, settlement, or demand letter names 2.1 AA specifically, in which case meet that first.
The short version
WCAG 2.2 is the current version of the Web Content Accessibility Guidelines from the W3C. It builds on 2.1 rather than replacing it. For the A and AA levels, it adds six success criteria and removes one obsolete criterion (4.1.1 Parsing).
If you already work to WCAG 2.1 AA, you are most of the way to 2.2 AA. The new criteria mostly cover keyboard users, touch and pointer users, and people with cognitive or motor disabilities.
This guide explains each change and gives a practical recommendation on which version to target. It is general information, not legal advice. For questions about your legal exposure, talk to an attorney.
What stayed the same
WCAG 2.2 keeps every 2.1 success criterion except 4.1.1. Contrast, alt text, keyboard access, labels, and name/role/value all still apply in the same way. See the WCAG 2.1 AA checklist for that baseline.
The W3C designed 2.2 to be backward compatible. Content that meets 2.2 should also meet 2.1, with the 4.1.1 exception covered below. You can read the official text at w3.org/TR/WCAG22 and the W3C's summary at What's new in WCAG 2.2.
The new criteria at a glance
WCAG 2.2 adds nine criteria in total. Three are Level AAA, which most legal and procurement references do not require. The six at Level A and AA are the ones that matter for most small businesses.
| Criterion | Level | What it asks |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Keyboard focus is not entirely hidden by other content |
| 2.5.7 Dragging Movements | AA | Anything done by dragging has a single-pointer alternative |
| 2.5.8 Target Size (Minimum) | AA | Pointer targets are at least 24 by 24 CSS pixels, with exceptions |
| 3.2.6 Consistent Help | A | Help options appear in the same relative place across pages |
| 3.3.7 Redundant Entry | A | Users don't re-enter information they already gave in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logging in doesn't depend on a cognitive test without an alternative |
The three AAA additions are 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced).
The six new criteria explained
2.4.11 Focus Not Obscured (Minimum)
When a keyboard user tabs to an element, that element must not be completely hidden behind content you created. The usual culprits are sticky headers, cookie banners, chat widgets, and bottom-pinned promo bars.
The Minimum level only fails when the focused element is entirely covered. If part of it is still visible, it passes at AA. The AAA version requires that no part is hidden.
A common fix is to reserve space for the sticky header when the browser scrolls a focused element into view:
html {
scroll-padding-top: 5rem; /* height of your sticky header */
}This works alongside 2.4.7 Focus Visible, which requires a visible focus indicator in the first place. Test it by tabbing through a page with your banners and widgets active.
2.5.7 Dragging Movements
If a feature works by dragging, users need another way to do it with a simple click or tap. Examples include sliders, sortable lists, kanban boards, and map panning or image cropping tools.
The alternative can be simple: buttons to move an item up or down, a field where you type a value, or tap-to-select then tap-to-place. There is an exception where dragging is essential to the function.
2.5.8 Target Size (Minimum)
Clickable and tappable targets should be at least 24 by 24 CSS pixels. This helps people with tremors, limited dexterity, or large fingers, and it helps everyone on a phone.
There are exceptions. A smaller target passes if enough spacing separates it from neighboring targets. The criterion also exempts inline links within sentences or blocks of text, controls whose size is set by the browser and not modified by the author, and cases where the size is essential. A different control that does the same thing and meets the size requirement also counts.
Typical problem areas are icon-only buttons, tightly packed footer links, close buttons on modals, and pagination controls.
.icon-button {
min-width: 24px;
min-height: 24px;
}This is the minimum. Larger targets are friendlier in practice.
3.2.6 Consistent Help
If your site offers help (a contact link, phone number, chat, or FAQ link) on multiple pages, it must appear in the same relative position each time. The point is that someone who struggles with a task can find help without hunting for it.
This applies only when you repeat a help mechanism across pages. The criterion doesn't require you to offer help on every page. Putting the same contact link in the same spot in a shared header or footer usually satisfies it.
3.3.7 Redundant Entry
Within a single process, such as a checkout or multi-step form, don't make people retype information they already provided. Either fill it in automatically or let them select it.
The classic example is a "billing address same as shipping" option. Exceptions include cases where re-entry is essential (such as confirming a new password) or where the earlier information is no longer valid.
<label>
<input type="checkbox" name="same-as-shipping" checked>
Billing address is the same as shipping
</label>3.3.8 Accessible Authentication (Minimum)
Logging in shouldn't require a cognitive function test, such as remembering a password, solving a puzzle, or transcribing characters, unless you offer an alternative or a mechanism that helps.
In practice, the most important steps for a typical small-business site are:
- Allow pasting into password fields.
- Support password managers by using standard fields and autocomplete attributes.
- Offer an alternative to character-transcription CAPTCHAs.
<input type="email" name="email" autocomplete="username">
<input type="password" name="password" autocomplete="current-password">Email links, one-tap passkeys, and authenticator prompts that don't require transcription are ways to meet this. The criterion has exceptions for object recognition (such as picking pictures of a certain thing) and for identifying content you provided to the site yourself.
What was removed: 4.1.1 Parsing
WCAG 2.2 removes 4.1.1 Parsing. It once required things like complete start and end tags and unique IDs. Browsers and assistive technologies now handle most of those errors reliably, so the criterion no longer addressed real barriers.
This does not mean markup quality stopped mattering. Duplicate IDs can still break label associations and ARIA references, which can fail other criteria such as 4.1.2 Name, Role, Value or 1.3.1 Info and Relationships. Keep validating your HTML. You just no longer need to track 4.1.1 as its own item.
Which version should you target?
The legal picture is the main reason people ask. Here is what can be said generally:
- For state and local governments, the DOJ's ADA Title II web rule names WCAG 2.1 AA as its technical standard. It does not apply to private businesses.
- For private businesses, no single technical standard is written into the ADA's text for websites. WCAG 2.1 AA is commonly referenced in demand letters, settlements, and agency materials, but how courts treat it varies. See ADA website lawsuits explained for the background.
- Contracts, settlement agreements, and customer requirements may name a specific version. If yours does, that version controls.
Given that, a practical approach looks like this:
- If a document names 2.1 AA, meet 2.1 AA first. This applies to a demand letter, settlement, or contract that names it. Treat the 2.2 items as a follow-on step. If you received a demand letter, read what to do with an ADA website demand letter and speak with an attorney.
- If nothing names a version, target 2.2 AA. It includes everything in 2.1 AA, so you aren't giving anything up. Most of the extra work is small CSS and form changes.
- Build the 2.1 AA foundation first. Alt text, contrast, keyboard access, labels, and page structure are where most real-world failures occur. The six new criteria are important, but they sit on top of that foundation.
No version guarantees any particular legal outcome. Meeting a standard reduces barriers for real users, which is the main goal, but it is not a legal safe harbor.
A practical order of work
If you are updating a site from 2.1 AA to 2.2 AA, this order tends to be efficient:
- Tab through key pages with banners and sticky elements active, and check that focus is never fully hidden.
- Audit buttons, icons, and small links for size and spacing.
- Check any sliders, sortable lists, or drag-and-drop features for a non-drag alternative.
- Review login and checkout flows for paste support, password manager support, and redundant fields.
- Confirm your help or contact link sits in the same place on every page where it appears.
Afterward, keep a dated record of what you tested and what you fixed. A dated accessibility audit record shows ongoing effort and makes the next review faster. To see where your site stands today, you can run a free scan with Proof of Access.
Frequently asked questions
Is WCAG 2.2 replacing WCAG 2.1?
WCAG 2.2 is the newer version, but 2.1 is still widely referenced in laws, settlements, and policies. The W3C keeps older versions available, and many organizations name 2.1 specifically. Check which version applies to your situation before choosing.
Do I need to do anything about 4.1.1 Parsing?
No, 4.1.1 is removed from WCAG 2.2, so it is no longer a separate requirement to test. You should still write valid, clean HTML, because problems like duplicate IDs can cause failures under other criteria.
If I meet WCAG 2.1 AA, do I already meet 2.2 AA?
Not fully. You would still need to address the six new Level A and AA criteria: focus not obscured, dragging movements, target size, consistent help, redundant entry, and accessible authentication. Many sites already meet some of them, so the gap is often small.
Does WCAG 2.2 AA protect me from an ADA lawsuit?
No standard can promise that. Following WCAG 2.2 AA can reduce real barriers for users, but it is not a guarantee of any legal outcome. For questions about your specific risk, consult an attorney.
Which new criterion is most likely to affect a small business site?
Target size and focus not obscured are common trouble spots, because sticky headers, cookie banners, and small icon buttons are everywhere. Login and checkout forms are also worth a look, mainly for paste support and repeated fields.
Related
- WCAG 2.1 AA checklist for business websites
- Got an ADA website demand letter? What to do in the first two weeks
- WCAG 2.4.7 Focus Visible
- Why a dated accessibility audit record matters
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.