WCAG 2.2 vs 2.1: What Changed and What You Need to Update
WCAG 2.2 has been the official standard since October 2023, but I still see a lot of sites targeting 2.1. If that's you, it's time to catch up. The DOJ Title II compliance deadline hits in April 2026, and courts are increasingly pointing to the latest version.
I'll break down every change for you: the 9 new success criteria, the one that got removed, and exactly what you need to update on your site.
In This Article
Quick Summary: WCAG 2.2 vs 2.1
WCAG 2.2 became an official W3C Recommendation on October 5, 2023, replacing WCAG 2.1 (which came out in June 2018). It's the version you should be targeting today.
Here's the quick comparison:
| Aspect | WCAG 2.1 | WCAG 2.2 |
|---|---|---|
| Published | June 5, 2018 | October 5, 2023 |
| Total success criteria | 78 | 86 (78 − 1 removed + 9 new) |
| New Level A criteria | None | 2 (SC 3.2.6, 3.3.7) |
| New Level AA criteria | None | 4 (SC 2.4.11, 2.5.7, 2.5.8, 3.3.8) |
| New Level AAA criteria | None | 3 (SC 2.4.12, 2.4.13, 3.3.9) |
| Removed criteria | None | 1 (SC 4.1.1 Parsing) |
| Backward compatible | Yes; passing 2.2 means you pass 2.1 | |
Key Takeaway
WCAG 2.2 is fully backward compatible. If your site passes 2.2 AA, you automatically pass 2.1 AA too. There's no reason to target 2.1 over 2.2, since the newer version is strictly better. If you're aiming for AA conformance (which is what most regulations require), you have 6 new criteria to address (2 at Level A, 4 at Level AA).
The 9 New Success Criteria
WCAG 2.2 adds 9 new success criteria across three levels. If you're targeting Level AA (which is what most regulations require), you need to meet 6 of them. I've included the 3 AAA criteria below too, but those aren't required for standard compliance.
2.4.11 Focus Not Obscured (Minimum) Level AA
Guideline 2.4 NavigableWhen a user interface element receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers, fixed footers, cookie consent banners, or chat widgets.
Why it matters: Keyboard users need to see which element is focused. A sticky navigation bar that covers a focused link makes it impossible to know where you are on the page.
What to do: Test your site by tabbing through every interactive element. If any focused element disappears behind a sticky header, a cookie banner, or a floating chat widget, you need to adjust z-index stacking, add scroll padding, or reposition the fixed element. CSS scroll-padding-top is an effective fix for sticky headers.
2.4.12 Focus Not Obscured (Enhanced) Level AAA
Guideline 2.4 NavigableThe enhanced version of 2.4.11 requires that no part of the focused element is hidden by author-created content, not just that it isn't entirely hidden.
Note: This is a Level AAA criterion. It is not required for standard AA compliance but is recommended as a best practice. If you are already fixing focus obscuring for 2.4.11, consider going the extra step to ensure focused elements are fully visible.
2.4.13 Focus Appearance Level AAA
Guideline 2.4 NavigableDefines minimum requirements for focus indicator size and contrast. The focus indicator must have a contrasting area of at least 2 CSS pixels on each side and a contrast ratio of at least 3:1 against the unfocused state.
Note: Level AAA only. Not required for AA compliance, but having clear, visible focus indicators is already required by SC 2.4.7 (Focus Visible) at Level AA. See our keyboard accessibility guide for practical focus indicator implementations.
2.5.7 Dragging Movements Level AA
Guideline 2.5 Input ModalitiesAny functionality that uses a dragging movement (drag-and-drop) must also be operable with a single pointer without dragging. This means providing an alternative such as click-to-select then click-to-place, up/down buttons, or a text input.
Why it matters: Users with motor disabilities, tremors, or those using assistive pointing devices often cannot perform drag gestures. Mobile users with certain assistive technologies also cannot drag.
What to do: Audit your site for drag-and-drop interactions: sortable lists, kanban boards, sliders, map interactions, and file upload areas. For each one, ensure there is an accessible alternative. For example, a sortable list should also offer "move up" and "move down" buttons.
2.5.8 Target Size (Minimum) Level AA
Guideline 2.5 Input ModalitiesInteractive targets (buttons, links, form controls) must be at least 24×24 CSS pixels, or have sufficient spacing from adjacent targets so the total clickable area meets the minimum.
Exceptions: Inline links within text, targets whose size is determined by the browser default (unstyled links), and targets where a specific size is essential to the information being conveyed (e.g., a map pin).
What to do: Check buttons, icon buttons, navigation links, form controls, and any tightly packed interactive elements. The most common failures are small icon buttons (social media icons, close buttons) and closely spaced navigation links in footers. Set a minimum size of 24px or add sufficient padding.
3.2.6 Consistent Help Level A
Guideline 3.2 PredictableIf your website provides help mechanisms (such as a contact phone number, email link, chat widget, FAQ link, or self-help option) on multiple pages, those help mechanisms must appear in the same relative order on each page.
Why it matters: Users with cognitive disabilities rely on consistency to find help. If the support chat appears in the bottom-right on one page but in the header on another, it creates unnecessary confusion.
What to do: Pick a consistent location for your help mechanisms (footer, header, or sidebar) and apply it across every page. This criterion does not require you to provide help on every page; it only requires that when help is present, it's in the same spot. Most websites already pass this if they use a consistent template.
3.3.7 Redundant Entry Level A
Guideline 3.3 Input AssistanceWhen a user has already entered information in a multi-step process, that information must either be auto-populated or available for selection in subsequent steps. Do not ask users to type the same data twice.
Why it matters: Re-entering information is burdensome for all users but especially for those with cognitive disabilities, memory impairments, or motor difficulties. A checkout form that asks for a shipping address and then makes the user re-type the same address for billing is a common violation.
What to do: Add a "same as shipping address" checkbox for billing. Pre-fill confirmation pages with data the user already provided. Use autocomplete attributes (autocomplete="email", autocomplete="tel") to help browsers fill in fields automatically.
3.3.8 Accessible Authentication (Minimum) Level AA
Guideline 3.3 Input AssistanceAuthentication processes must not require cognitive function tests (memorizing a password, transcribing a code, solving a puzzle, or recognizing objects) unless one of these conditions is met:
- An alternative authentication method is available that does not rely on a cognitive function test
- A mechanism (such as a password manager or copy-paste) can assist the user
- The test involves recognizing objects from the user's own content (e.g., "which of these is your profile photo?")
What this means in practice: Standard username/password login is fine as long as users can paste passwords (enabling password managers). CAPTCHAs that require identifying objects in photos ("select all traffic lights") violate this criterion unless an alternative like audio CAPTCHA is offered. Puzzle CAPTCHAs ("drag the piece to complete the image") fail because they require a cognitive function test with no alternative.
What to do: Ensure password fields allow paste. Offer passwordless login options (magic links, passkeys, SSO). If you use CAPTCHAs, provide alternatives or switch to invisible CAPTCHA methods that don't require user interaction. See our accessible forms guide for more on authentication patterns.
3.3.9 Accessible Authentication (Enhanced) Level AAA
Guideline 3.3 Input AssistanceThe stricter version of 3.3.8 that does not allow any cognitive function tests at all for authentication, even with an alternative method. Only object recognition based on the user's own content is permitted.
Note: Level AAA only. Not required for standard AA compliance. If you are already implementing passkey or SSO authentication for 3.3.8, you likely meet this criterion as well.
What Was Removed: SC 4.1.1 Parsing
WCAG 2.2 removes Success Criterion 4.1.1 Parsing, which required valid HTML: no duplicate IDs, proper nesting, complete open/close tags, and unique attributes. This criterion dates back to WCAG 2.0 (2008) when browser parsing of malformed HTML was inconsistent and could cause assistive technology failures.
Modern browsers now use standardized parsing algorithms (the HTML5 parser) that handle malformed markup consistently. Screen readers and other assistive technologies also rely on the browser's accessibility API rather than parsing raw HTML. As a result, parsing errors no longer cause the accessibility failures they once did.
Should You Stop Writing Valid HTML?
No. Valid HTML is still a best practice for maintainability, SEO, and cross-browser compatibility. The removal of SC 4.1.1 simply acknowledges that parsing errors are no longer an accessibility barrier specifically. If you had 4.1.1 on your compliance checklist, you can remove it, but keep writing clean markup.
What This Means for Your Website
If you're already meeting WCAG 2.1 AA, you're most of the way there. The gap is just 6 new criteria, and for most sites, closing it is way less work than getting to 2.1 was in the first place.
Here's what I'd check first, in priority order:
- Focus not obscured by sticky elements (SC 2.4.11): Tab through your site and verify no focused element is hidden behind sticky headers, cookie banners, or chat widgets. This is a common issue on sites with fixed navigation.
- Drag alternatives exist (SC 2.5.7): If your site has any drag-and-drop functionality, confirm there is a single-pointer alternative. Common areas: sortable lists, kanban boards, sliders, image cropping tools.
- Touch targets are at least 24px (SC 2.5.8): Measure your buttons, icon links, and form controls. Pay special attention to mobile navigation, social media icon rows, and footer link lists.
- Authentication doesn't rely on cognitive tests (SC 3.3.8): Verify that password fields allow paste, and that any CAPTCHAs have accessible alternatives.
- Help mechanisms are consistent (SC 3.2.6): If you have a chat widget, support link, or contact info, confirm it appears in the same location on every page.
- No redundant data entry (SC 3.3.7): Review multi-step forms (checkout flows, registration wizards, applications) for unnecessary re-entry of previously provided information.
Priority Action Items
Start with SC 2.4.11 (focus not obscured) and SC 2.5.8 (target size). These are the two new AA criteria most likely to cause failures on existing websites. Sticky headers that cover focused elements and small icon buttons are extremely common issues. Fix those first, then work through the remaining four criteria.
DOJ Title II and WCAG 2.2
The DOJ published a rule in April 2024 requiring state and local government websites to meet WCAG 2.1 Level AA. Notice it says 2.1, not 2.2, but don't let that make you think you should stop at 2.1.
Meeting 2.2 AA automatically satisfies the 2.1 requirement. And more importantly, courts tend to reference the current standard when evaluating compliance. Targeting 2.2 gives you stronger legal protection and better accessibility for your users.
If you're a private business (ADA Title III), there's no formal regulation specifying a WCAG version yet. But court settlements consistently reference the latest standard. 2.2 AA is the safest position you can be in.
Compliance Deadline
April 24, 2026: State and local governments with populations of 50,000 or more must comply with WCAG 2.1 AA under the DOJ Title II rule. Smaller entities have until April 24, 2027. Private businesses should treat these deadlines as a signal that enforcement expectations are rising across the board. Read our ADA compliance checklist for 2026 for a complete breakdown of requirements and deadlines.
How to Check Your Site
You'll need a mix of automated scanning and manual testing. Here's how I'd approach it:
Step 1: Run an Automated Scan
Run a free WCAG 2.2 AA scan to catch machine-detectable issues. Automated tools are effective at finding target size problems (SC 2.5.8), missing form labels, contrast failures, and many other criteria. Our scanner uses axe-core, which is updated to test against WCAG 2.2 success criteria.
Step 2: Manual Keyboard Testing
Several of the new WCAG 2.2 criteria are difficult or impossible to test automatically:
- Focus not obscured (SC 2.4.11): Tab through every page and visually confirm that focused elements are not hidden behind sticky or fixed elements
- Dragging alternatives (SC 2.5.7): Identify every drag interaction and verify it has a non-drag alternative
- Consistent help (SC 3.2.6): Compare help mechanism placement across multiple pages
- Redundant entry (SC 3.3.7): Walk through multi-step forms and check for re-entry requirements
For a complete keyboard testing guide, see our article on keyboard accessibility.
Step 3: Review Authentication Flows
Test your login, registration, and password reset flows against SC 3.3.8. Verify that password fields allow paste and that CAPTCHAs have accessible alternatives. See our accessible forms guide for detailed authentication patterns.
Step 4: Use a Checklist
Work through our ADA compliance checklist for 2026, which covers all WCAG 2.2 AA requirements along with legal context and testing procedures.
Start Your WCAG 2.2 Audit Today
The gap between 2.1 and 2.2 is totally manageable, but you do need to give it attention. Run a free scan to see where your site stands right now, then work through the priority list above. For more background, check out common WCAG mistakes and our 2026 compliance checklist.