WCAG 2.2 Compliance Services: The 9 New Criteria That Matter

WCAG 2.2 became the official W3C recommendation in October 2023, and a significant portion of the web still has not caught up. Sites that proudly passed a 2.1 audit two years ago now fail against the current standard, because nine new success criteria were added and one was dropped. If you are shopping for WCAG 2.2 compliance services, the first question to ask a vendor is which version they are auditing against. If the answer is 2.1, the report you are paying for is already obsolete — and in jurisdictions where enforcement has caught up to the new baseline, that gap is legally meaningful.

What Actually Changed in WCAG 2.2

WCAG 2.2 is backward-compatible with 2.1 and 2.0 — meeting 2.2 means you also meet the older versions — but it introduces nine additional success criteria that specifically target pain points for users with cognitive, motor, and low-vision disabilities. Six apply at Level AA, which is the enforcement baseline for most regulators including the ADA's effective standard and the EU Accessibility Act.

The new criteria are: Focus Not Obscured (Minimum and Enhanced), Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, Accessible Authentication (Minimum and Enhanced), and Findable Help. One criterion from 2.1 — Parsing (4.1.1) — was removed, because modern browsers handle the underlying issues automatically. The net effect: more work to pass, not less.

The Target Size Rule That Broke Half the Web

Success Criterion 2.5.8 requires that pointer targets be at least 24×24 CSS pixels, with some documented exceptions. This sounds trivial. In practice, it breaks an enormous number of sites immediately. Tiny social icon rows, footer link lists where link text is 11px and there is no padding, inline "X" close buttons on banners, the chevrons inside carousel controls — all of these commonly fail.

The fix is not always visual. Exceptions exist: inline links inside a paragraph are exempt, as are equivalents offered elsewhere at larger size, and targets that are spaced out so that a 24px circle around each does not overlap with another. Applying those exceptions correctly requires reading the actual specification, not relying on an automated scanner that flags every small element without checking context. A proper website accessibility audit distinguishes a real failure from an exempt inline link — and scanners routinely do not.

Accessible Authentication Without Cognitive Tests

One of the most impactful additions is SC 3.3.8 (Level AA), Accessible Authentication (Minimum). It prohibits login flows from requiring a cognitive function test — memorizing, transcribing, solving a puzzle, or recognizing specific objects — unless an alternative exists. Password entry is generally exempt, but the common patterns that layer extra cognitive load are not.

The practical impact falls on CAPTCHAs that require identifying traffic lights or crosswalks, security questions that ask users to recall past answers, and MFA flows that force manual transcription of codes rather than accepting paste or autofill. Every one of these can stay on the site if an accessible alternative is offered — biometric login, magic links, WebAuthn, trusted device recognition. What fails is the "our CAPTCHA is the only option" stance that is still industry standard. A site that cannot be logged into by a blind user with a screen reader fails on this criterion and fails in court.

Focus Visibility Under Sticky Headers

SC 2.4.11, Focus Not Obscured (Minimum), requires that when a component receives keyboard focus, it is not entirely hidden by author-created content. The most common violator is the sticky header. A user tabs down the page, focus lands on a link that has just scrolled behind a 64-pixel header, and visually there is nothing to see — the focus indicator is off-screen.

The fix is usually a CSS scroll-margin on interactive elements, so that when focus moves to them they are scrolled clear of the header. It is a one-line change per selector but has to be applied systematically across component libraries. Companion criterion 2.4.13, Focus Appearance, goes further and dictates minimum contrast and size for the focus indicator itself — a thin dotted outline in 2023-style UI usually does not meet the bar.

Dragging Movements and Alternative Inputs

SC 2.5.7 requires that any functionality operated by a dragging motion has an alternative single-pointer input that accomplishes the same task. Sliders, sortable lists, drag-to-reorder galleries, map pan interfaces, signature canvases — all have to offer a non-drag alternative for users who cannot perform a sustained drag motion.

The alternative does not have to be elegant. A slider can add plus and minus buttons. A sortable list can add up/down arrows beside each row. A map can add directional buttons alongside the drag area. The point is that no primary functionality depends on a motor skill the user may not have. Retrofitting this into a site built around drag-heavy interactions is substantially more expensive than building it in from day one, which is why this particular criterion tends to trigger a redesign conversation more than a remediation one.

The EAA Deadline and Why Timelines Matter

The European Accessibility Act took effect June 28, 2025, and any business selling digital products or services to EU consumers has to meet EN 301 549 — which directly references WCAG 2.1 Level AA today and is expected to adopt 2.2 within its next revision cycle. US enforcement is increasingly consolidating around WCAG 2.1/2.2 AA as the de facto standard, with the DOJ's 2024 Title II rule for state and local government making WCAG 2.1 AA explicit at the federal level.

The practical read for businesses is that waiting for "the dust to settle" on accessibility standards is a strategy that stopped working a decade ago. WCAG moves forward every few years, enforcement follows, and sites that skipped 2.1 end up paying for 2.0, 2.1, and 2.2 remediation at once. Programs that stay within one version of current — combined with the discipline described in ADA website compliance — cost a fraction over time of the reactive approach.

Building a Real Remediation Roadmap

A working WCAG 2.2 compliance services engagement moves in four phases. First, a baseline audit that combines automated scanning, manual testing with screen readers and keyboard-only navigation, and user testing with people who use assistive technology daily. Automated tools catch roughly 30 percent of issues — the rest require human testers who understand the standard.

Second, a prioritized remediation plan that sequences fixes by severity and user impact. Target size fixes are often cheap but broad; authentication rebuilds are expensive but load-bearing. Third, implementation — usually a combination of CSS changes, template updates, and component library revisions, with accessibility test cases added to the CI pipeline so regressions cannot ship. Fourth, ongoing monitoring, because every content edit and new feature is a potential new issue. Pair this with the practices in accessibility for visually impaired users and coverage extends past 2.2's letter into the spirit of what the standard exists to enforce.