"We're WCAG 2.1 AA, we're covered." It is one of the most common sentences in an accessibility kickoff meeting, and it has been quietly out of date for a while. WCAG 2.2 became a formal W3C recommendation in 2023, and most teams that confirmed compliance against 2.1 have never gone back and specifically audited against what 2.2 actually added. Not because anyone is cutting corners deliberately. Because "we already did this" is a very easy sentence to believe once, and a very easy one to never revisit.
WCAG 2.2 is not a full rewrite. It kept everything from 2.1 intact except one criterion it removed (4.1.1 Parsing, which had become largely redundant with modern browser HTML parsing behavior), and it added nine entirely new success criteria on top. Nine is a small enough number that auditing against all of them specifically is a genuinely achievable afternoon of work, and yet a meaningful share of sites, including plenty that market themselves as WCAG 2.1 AA compliant, have never done it.
The Stat: WCAG 2.2 added exactly nine new Success Criteria and removed one (4.1.1 Parsing), bringing the total to 86; of the nine, 2.5.8 Target Size (Minimum), 2.4.11 Focus Not Obscured (Minimum), and 2.5.7 Dragging Movements are the three most commonly failed on real sites. (Source: W3C WCAG 2.2, TR/WCAG22)
Why These Three, Specifically
All nine new criteria matter, but they are not equally likely to already be broken on a typical, already-launched site. Some of the nine (like Accessible Authentication, which restricts cognitive-function tests like memorized password puzzles without an alternative) tend to already be handled correctly by modern authentication flows that use standard password fields or passkeys. The three below are different: they are usually broken not because a team disagrees with the requirement, but because the interaction pattern involved was built years before WCAG 2.2 existed and has simply never been revisited since.
Failure One: 2.5.8 Target Size (Minimum)
This criterion requires interactive elements, buttons, links, form controls, to have a minimum clickable or tappable area of 24 by 24 CSS pixels, with limited exceptions for inline text links and controls that are already sufficiently spaced from their neighbors. It is a Level AA requirement, meaning it is part of the conformance level almost every organization targets.
Where this breaks most often: icon-only buttons in a dense toolbar or header, close (x) buttons on modals and toasts, and tightly packed navigation items on mobile, all frequently built with the icon's own visual size as the entire clickable area, well under 24 pixels once actually measured. The fix rarely requires changing how the control looks. It requires expanding the invisible hit area around it, via padding or a pseudo-element, so the visual and interactive sizes are decoupled.
Failure Two: 2.4.11 Focus Not Obscured (Minimum)
This criterion requires that when a keyboard user moves focus to an element, at least some part of that element must not be hidden by other content, sticky headers, cookie banners, chat widgets, or anything else layered on top of the page. It is a Level AA requirement that exists specifically because sticky headers and floating widgets became common well after most existing focus-management code was written.
Where this breaks most often: a sticky header with a fixed height sitting on top of a page, where tabbing through content below it moves focus to elements that scroll directly underneath the header and become completely invisible, with no scroll-into-view logic accounting for the header's height. A sighted mouse user never notices, because they can see and scroll past the obstruction naturally. A keyboard user tabbing through the page has no such visual cue and effectively loses track of where their focus went.
Failure Three: 2.5.7 Dragging Movements
This criterion requires that any functionality performed via a dragging motion (reordering a list, adjusting a slider, dismissing a card) also be available through a single-pointer action without dragging, like a pair of up/down buttons or a tap-to-select-then-tap-to-place pattern. It is a Level AA requirement aimed specifically at users with motor impairments who can click or tap precisely but cannot perform a sustained, controlled drag gesture.
Where this breaks most often: drag-to-reorder list interfaces (settings panels, kanban boards, priority rankings) built as drag-only from the start, with no alternative control ever added because dragging felt sufficiently intuitive during design review. Our existing piece on a keyboard alternative to drag-and-drop walks through exactly this fix in more depth.
A Quick Note on the Other Six
The remaining six new criteria in WCAG 2.2 are worth naming even though they are less frequently broken on already-shipped sites: 3.2.6 Consistent Help (a help mechanism, if one exists, must appear in the same relative order across pages), 3.3.7 Redundant Entry (don't force a user to re-enter information already provided earlier in the same process), 3.3.8 Accessible Authentication (no cognitive-function test, like a memorized password puzzle, without an alternative), 2.4.13 Focus Appearance (a stronger, more specific visual focus-indicator requirement than 2.1's general one), 2.5.7's close cousin at the AAA level, and refinements to existing pointer-related criteria. Most modern authentication and form flows already satisfy several of these by default, simply because current UX conventions (standard password fields, autofill-friendly forms, sticky navigation) happen to align with them. That is exactly why they show up less often in real audits than the three above, not because they matter less on paper.
This Is a Narrower List on Purpose
The site already has broader pieces comparing the full arc of the standard, our WCAG 2.1 vs 2.2 vs 3.0 roadmap and a full 2.1 versus 2.2 differences breakdown, both worth reading for the complete picture of all nine new criteria and where WCAG 3.0 is heading next. This piece is deliberately narrower: three criteria, chosen specifically because they are the ones real, already-shipped sites are most likely to be quietly failing right now, with a concrete fix for each rather than a full survey.
If your last WCAG audit happened before your team had specifically checked target size, focus obscuring, and dragging alternatives, it was very likely a 2.1 audit wearing a 2.2 label. That gap is worth closing directly rather than assuming it does not apply. Our free accessibility audit checks against the current standard, not an outdated one, and our team is reachable at experts@wcag.world if you want help prioritizing a fix for any of these three specifically. The full WCAG 2.2 recommendation and the detailed guidance on Target Size are both worth reading directly from the source.