What Changed in WCAG 2.2 vs WCAG 2.1

The Web Content Accessibility Guidelines (WCAG) are the standard most accessibility laws point at. WCAG 2.2 became a W3C Recommendation on 5 October 2023, added nine new success criteria, and removed one. It is now ISO/IEC 40500:2025. If you maintain a website, design system, or product in 2026, the practical question is: what changed, what does each new criterion actually require, and how should you prioritise the fixes? This post answers each in turn, with sources cited so you can verify before you act.

A short history of WCAG

The W3C published the first Web Content Accessibility Guidelines on 5 May 1999. WCAG 1.0 was prescriptive and HTML-specific; it became dated quickly as the web moved past plain documents into rich applications.

WCAG 2.0 came on 11 December 2008. It abstracted the guidance away from any one technology, organised it under the four principles "Perceivable, Operable, Understandable, Robust" (POUR), and introduced the three-level conformance scheme A/AA/AAA that practitioners still use today. It is the version most U.S. and international regulations originally referenced.

WCAG 2.1 followed on 5 June 2018. It added 17 new success criteria covering mobile (orientation, touch targets, motion actuation), low-vision users (reflow, text spacing, non-text contrast), and cognitive accessibility (label-in-name, status messages). It is the version baked into the European Accessibility Act's referenced standard EN 301 549 v3.2.1.

WCAG 2.2 was published on 5 October 2023 and re-published with editorial updates on 12 December 2024. It adds nine new success criteria, removes one (4.1.1 Parsing), and is now also ISO/IEC 40500:2025. WCAG 3, a substantially different framework with new scoring, is still in draft and not expected for general adoption before 2027.

The nine new success criteria

The new criteria fall into three thematic clusters: focus, input modality, and cognitive accessibility.

Focus cluster

2.4.11 Focus Not Obscured (Minimum), Level AA. When a user-interface component receives keyboard focus, the component must not be entirely hidden by author-created content (sticky headers, cookie banners, chat widgets). The component can be partially obscured; the criterion only fails when none of it is visible. Most failures in the wild come from sticky bottom bars that float over a focused input in a form, leaving the focus invisible while the user types.

2.4.12 Focus Not Obscured (Enhanced), Level AAA. Tighter version of 2.4.11: when a component receives focus, no part of it may be hidden. This is the AAA version most enterprise design systems target.

2.4.13 Focus Appearance, Level AAA. The focus indicator itself must be at least 2 CSS pixels thick around the focused control, and the focus indicator's contrast against the adjacent unfocused state must be at least 3:1. A 1-pixel browser-default focus ring on a dark button fails this criterion; a 2-pixel high-contrast ring passes.

Input modality cluster

2.5.7 Dragging Movements, Level AA. Anything that can be done with a drag gesture must also be possible without one. Examples: sortable lists that only respond to drag, sliders that only respond to drag, map panning that requires drag. The criterion does not ban drag; it requires an alternative such as up/down arrows for reorder, or text-input fields for slider values.

2.5.8 Target Size (Minimum), Level AA. Pointer targets must be at least 24 by 24 CSS pixels, unless they are inline (links in a paragraph), exposed in a user-agent default (like a <select> dropdown), essential to the function (a fretboard simulator), or have an equivalent control elsewhere on the page that does meet 24x24. The earlier WCAG 2.1 criterion 2.5.5 set the threshold at 44x44 but at Level AAA; 2.5.8 makes a smaller 24x24 floor mandatory at AA.

Cognitive accessibility cluster

3.2.6 Consistent Help, Level A. If help mechanisms (a "Contact us" link, a chat widget, a help link, a help phone number) appear on multiple pages, they must appear in the same relative order on each page. The intent is to lower cognitive load: users find help in the place they expect, every time.

3.3.7 Redundant Entry, Level A. Users should not be required to re-enter information they already entered in the same process. Multi-step forms must remember earlier inputs. The criterion does not prohibit re-asking when it is essential (security verification) or when the information has changed.

3.3.8 Accessible Authentication (Minimum), Level AA. Authentication cannot require cognitive function tests like remembering a password, solving a puzzle, or transcribing an image-based CAPTCHA, unless an alternative is provided. Acceptable alternatives include a password manager, a one-time code, biometric, or a hardware token. This is the criterion that ended the "type the letters from this image" pattern for accessible sites.

3.3.9 Accessible Authentication (Enhanced), Level AAA. Stronger version: object-recognition and personal-content puzzles (which images contain a bus?, what was your first pet's name?) are also disallowed, unless an alternative is provided.

The one removed criterion

4.1.1 Parsing was withdrawn as obsolete. It required content to be parseable: complete start/end tags, no duplicate IDs, properly nested elements. In 2008 this mattered because assistive technologies parsed HTML themselves and would fail on malformed markup. In 2024 every assistive technology consumes the browser's accessibility tree, not raw HTML; the browser already recovers from malformed markup gracefully. WCAG 2.2 acknowledges this by dropping the criterion. It still appears in WCAG 2.0 and 2.1 conformance, but does not in 2.2.

This is the only criterion ever removed from WCAG. Existing 2.0 / 2.1 audits that flagged 4.1.1 failures should re-test against 2.2; some of those failures are now non-issues.

Conformance levels recap

WCAG keeps the three-tier scheme:

WCAG 2.2 adds 4 Level A or AA criteria (2.5.7, 2.5.8, 2.4.11, 3.2.6, 3.3.7, 3.3.8) and 4 Level AAA criteria (2.4.12, 2.4.13, 3.3.9, plus the AAA branch of 2.4.11). For most legal compliance work, focus on the AA additions first.

Practical impact, what to fix first

For a typical site already conforming to WCAG 2.1 AA, the 2.2 AA gap is usually:

1. 2.5.8 Target Size (Minimum), 24x24 CSS pixels. Audit your buttons, icon links, and small toggles. Smaller-than-24x24 controls need either a bigger hit area, more spacing around them, or an equivalent larger control on the page. This is the single most common 2.2 failure on existing sites.
2. 2.4.11 Focus Not Obscured (Minimum). Look for sticky bottom bars, sticky footers, chat widgets, cookie banners that overlay the bottom of the viewport. When a focusable element scrolls behind one of them, the criterion fails. Fix by adding scroll-margin-bottom to focusable elements equal to the sticky bar's height.
3. 3.3.8 Accessible Authentication (Minimum). Remove image-based CAPTCHA from login flows; replace with an invisible-CAPTCHA or rate-limited approach. Allow password managers (do not disable autocomplete on password fields). Allow paste of one-time codes.
4. 2.5.7 Dragging Movements. Provide a non-drag alternative for any drag-only interaction. Sortable lists need up/down arrows; sliders need a number input; maps need pan buttons.
5. 3.2.6 Consistent Help. If your "Contact" or "Help" link appears on multiple pages, position it consistently. Most sites already do this; the failure is on sites that move the help link based on page type.
6. 3.3.7 Redundant Entry. Multi-step forms must remember earlier inputs. Most modern frameworks already do this if you wire state correctly; the failure is on legacy multi-page forms that reset state between steps.

Common pitfalls in implementing the new criteria

• Treating 4.1.1 Parsing as gone everywhere. 4.1.1 is removed from WCAG 2.2 but is still required by WCAG 2.0 and 2.1. If your contract or regulation specifies 2.1, the parsing rule still applies.
• Misreading 2.5.8 Target Size. The 24x24 minimum is for the target, not the visible icon. A 16x16 icon inside a 24x24 button passes. A 16x16 icon in a 16x16 button fails.
• Forgetting the exceptions to 2.5.8. Inline links in a paragraph, default user-agent controls, essential targets, and equivalent larger controls elsewhere on the page are all exempt.
• Implementing 3.3.8 by removing all CAPTCHA. You can keep CAPTCHA; you just need an accessible alternative path. Reverse Turing tests, rate limits, magic links, passkeys, or hardware tokens all qualify.
• 2.4.11 confused with 2.4.13. Focus Not Obscured (2.4.11) is about whether the focused element is visible at all. Focus Appearance (2.4.13) is about the focus indicator itself being thick and contrasty. They are different requirements at different levels.
• Skipping 2.4.13 because it is AAA. Several governments (Norway, parts of Canada) have adopted AAA-level rules for public-sector sites. Check your jurisdiction.

Tools to check WCAG 2.2 compliance

Some tools have already updated to test the new 2.2 criteria; others still test against 2.0 / 2.1 only.

Automated tools catch roughly 30 to 40 % of WCAG failures even at their best. The new 2.2 criteria are particularly hard to automate (2.5.7 Dragging, 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Authentication) because they require understanding user flow, not just markup. Plan for manual keyboard testing on every release.

Privacy and the tools

The color contrast checker, WCAG heading checker, and accessible palette generator on Absolutool all run entirely in your browser. The HTML or color values you paste are processed by JavaScript on your device, results render to the page, and nothing is sent to a server. No telemetry on the input, no third-party scripts touching the content, no cache after navigation. For internal design system audits, unreleased brand colors, or any audit data under embargo, that local-only flow is the right default. The tools can run offline once the page is loaded, which you can verify by switching off your network and rechecking a contrast pair.