Your site was checked against WCAG 2.1 a while back, or your developer built it with 2.1 in mind. Now a contract, a vendor questionnaire or an auditor mentions 2.2, and you want to know whether that means starting again. It does not. Comparing WCAG 2.2 vs 2.1 is mostly a matter of nine additions and one deletion, and on a typical WordPress site only a handful of them create real work.
This post walks through exactly what is new in WCAG 2.2, what each change looks like on a real business site, and which version you should be working toward. It does not repeat the full AA list; for that, see the plain guide to WCAG 2.2 AA requirements.
WCAG 2.2 vs 2.1 in brief
The newer version reached W3C Recommendation status in October 2023. It keeps every 2.1 criterion except one, 4.1.1 Parsing, and adds nine new success criteria. Of those nine:
- two are Level A,
- four are Level AA,
- three are Level AAA.
If your target is Level AA, which it almost always is, six new criteria apply to you. The three AAA additions are worth reading but are not part of a normal AA project.
The themes behind the changes are easy to summarize. People with low vision who use keyboards lost track of focus under sticky headers. People with tremors or limited dexterity struggled with tiny targets and drag-only controls. People with memory or cognitive disabilities were blocked by login puzzles, re-typing the same details, and help links that moved around. Version 2.2 addresses each of those.
The six new criteria that matter for AA
| Criterion | Level | Where it bites on a WordPress site |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, cookie bars and chat buttons covering the focused link |
| 2.5.7 Dragging Movements | AA | Price range sliders, before/after image sliders, drag-to-reorder uploads |
| 2.5.8 Target Size (Minimum) | AA | Social icons, pagination numbers, carousel dots, close buttons |
| 3.2.6 Consistent Help | A | Phone number or chat link that sits in a different place on different templates |
| 3.3.7 Redundant Entry | A | Checkout and multi-step forms asking for the same address twice |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login forms that block paste, puzzle CAPTCHAs, “retype the code” steps |
2.4.11 Focus Not Obscured (Minimum)
When someone tabs to a link or button, that item must not be completely hidden by content you added to the page. The classic case is a sticky header. You tab down the page, the browser scrolls, and the focused link slides underneath the header where nobody can see it. Cookie banners pinned to the bottom of the screen and floating chat bubbles do the same thing.
The minimum version only fails when the focused item is entirely hidden. Partly covered is allowed at AA, though it is still annoying. The usual fix is CSS that adds scroll padding equal to the header height, so the browser stops the focused item below it. This sits right next to the older focus-visible criterion; our post on focus indicators and sticky headers covers both together.
2.5.7 Dragging Movements
Anything that works by dragging needs a way to do the same thing with single pointer actions, such as clicks or taps, unless dragging is essential. A WooCommerce price filter with two drag handles is the common example. Adding number inputs beside the slider, or plus and minus buttons, solves it. Note that this is about pointer use. A slider that responds to arrow keys still fails this one if the mouse or touch user has no click alternative, because the criterion is about people who can point but cannot hold and drag.
2.5.8 Target Size (Minimum)
Click and tap targets need to be at least 24 by 24 CSS pixels, or have enough space around them that a 24 pixel circle centered on each one does not overlap its neighbors. Links inside a sentence are exempt, as are controls whose size the browser decides. On WordPress sites the failures are predictable: a row of 16 pixel social icons in the footer, page numbers squeezed together, tiny carousel dots, and the little “x” on a popup. The details and exceptions are in our guide to touch target sizes.
3.2.6 Consistent Help
If your site offers a way to get help, such as a phone number, an email address, a contact page link or a chat widget, it should appear in the same relative order on each page where it appears. You are not required to offer help at all. This criterion only says that if you do, people should not have to hunt for it. Sites usually fail it when a landing page template drops the header phone number, or when chat loads on some pages and not others.
3.3.7 Redundant Entry
Within one process, people should not have to type information again that they already gave, unless re-entry is essential (such as confirming a new password) or the earlier information is no longer valid. Either fill it in automatically or let people select it. “Shipping address same as billing” is the textbook answer. Multi-step quote and booking forms built with form plugins are where we tend to look, especially when step three asks for the email address from step one.
3.3.8 Accessible Authentication (Minimum)
Logging in should not depend on a cognitive function test, such as remembering a password or solving a puzzle, unless there is an alternative or help. In practice, allowing password managers to fill the field and allowing paste covers most of it, because the person then does not have to remember or transcribe anything. Login forms that disable paste, and image-based CAPTCHAs on the login or checkout page, are the usual problems. Recognizing common objects is allowed at AA, but text-transcription and math puzzles are not a safe choice. We go deeper on fields like these on our accessible form fixes page.
The three AAA additions, briefly
Version 2.2 also adds an enhanced version of focus not obscured, where no part of the focused item may be hidden; a focus appearance criterion that sets how large and how contrasting the focus indicator must be; and an enhanced authentication criterion that removes the object-recognition allowance. None of these is part of an AA target. Many teams use the focus appearance criterion as a design guide anyway, because meeting it means nobody will argue about whether your focus outline is visible.
The criterion that was removed
4.1.1 Parsing used to require that HTML was well formed: elements opened and closed properly, no duplicate IDs in certain situations, and so on. When WCAG 2.0 was written, assistive technology sometimes parsed messy HTML itself and got it wrong. Browsers now build a consistent structure from almost any markup and pass that to assistive technology, so the criterion no longer protected anyone. The real problems it used to catch, such as broken label associations or duplicate IDs breaking an ARIA reference, are still caught under other criteria like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
For a site owner weighing WCAG 2.2 vs 2.1, the practical effect of this deletion is small. Validator warnings that used to fill audit reports under 4.1.1 should now appear only when they cause a real barrier.
Which version should you target?
Aim for 2.2 Level AA. The versions are designed to be backward compatible, so content that meets 2.2 AA also meets the remaining 2.1 AA criteria. There are a few reasons people still hear about 2.1:
- The DOJ’s April 2024 rule for state and local governments under ADA Title II adopts WCAG 2.1 Level AA. If you run a city, county, school district or library site, that is the legal reference; our Title II web accessibility page explains what that work involves. Check ada.gov for the current compliance dates.
- Older contracts, procurement forms and settlement agreements often name 2.1 because that was current when they were written.
- Some automated tools label rules by the version they were first added in, which makes reports look like a mix.
For private businesses there is no DOJ technical standard for websites, and WCAG 2.1 or 2.2 AA is what audits and demand letters generally point to. Building to 2.2 means you are not caught out when a document names the newer version. This is general information; for anything legal, talk to a lawyer.
Upgrading a site from 2.1 to 2.2: a sensible order
If your site already passed a 2.1 AA audit, you do not need a fresh full audit to account for 2.2. You need a focused pass on the six new A and AA criteria, plus a check that nothing has regressed since the last review. A reasonable order:
- Tab through every template with the sticky header active. Note any link or button that disappears behind the header, a cookie bar or a chat bubble.
- Measure small targets. Social icons, pagination, close buttons, carousel controls, quantity buttons. Browser developer tools show the rendered size.
- Find every drag interaction. Filters, sliders, galleries, file uploads, sortable lists. Check each has a click or tap alternative.
- Walk each multi-step process. Checkout, booking, quote request, account signup. Note any field asked twice.
- Try logging in with a password manager and with paste. Look at the CAPTCHA type on login and checkout.
- Compare where help appears. Header, footer and sidebar on the home page, a service page, a blog post and the shop.
Many of these fixes are CSS changes, a plugin setting, or swapping one component. The drag and CAPTCHA items occasionally mean replacing a plugin. If you would like to know more about the bigger picture first, our page on ADA website accessibility help sets out the overall approach. For background on the standard itself, there is our introduction to how WCAG is organized.
Frequently asked questions
Is WCAG 2.2 backward compatible with 2.1?
Yes, by design. Every 2.1 success criterion carries over except 4.1.1 Parsing, so content that meets 2.2 Level AA also meets the 2.1 AA criteria that remain. The reverse is not true: a site that passed a 2.1 audit may still fail some of the six new A and AA criteria.
Do I need a new audit because WCAG 2.2 came out?
Not necessarily a full one. If a 2.1 audit was done recently and the site has not changed much, a focused check of the new A and AA criteria plus a regression pass is usually enough. If the site has had a redesign or many plugin changes since, a fresh audit makes more sense.
Which of the new criteria cause the most work?
On WordPress sites, target size and focus not obscured come up most often, but they are usually CSS fixes. Dragging movements and accessible authentication occasionally take more effort, because a slider plugin or a CAPTCHA may need to be replaced rather than adjusted.
Is WCAG 3 replacing 2.2 soon?
WCAG 3 is a separate, much larger project at the W3C, and at the time of writing it was still a draft. It is not something your site can be measured against today. For any current audit, contract or remediation work, the 2.x series is what applies, and 2.2 is the latest version.
If you want someone to check your site against the six new criteria, or the full 2.2 AA set, with clear evidence for each finding, take a look at our WCAG audit and what it includes.
Next in this series: WCAG Levels A, AA and AAA: What Each One Means
