When the W3C published WCAG 2.2 as an official recommendation on October 5, 2023, it marked the first major update to the Web Content Accessibility Guidelines since June 2018. Five years of feedback from auditors, developers, and people with disabilities shaped a set of changes that address gaps the previous version left open. If you have been working toward WCAG 2.1 AA compliance, the good news is that nothing you have already done becomes invalid. WCAG 2.2 builds on top of 2.1 rather than replacing it. But there are nine new success criteria you need to understand, plus one criterion that was formally removed. This article walks through every change, explains why each one matters, and gives you concrete steps to check your own site.
Quick Summary of Changes Between WCAG 2.1 and 2.2
Before diving into the details, here is the high-level picture. WCAG 2.2 adds nine new success criteria spread across three conformance levels. Six of them fall under A or AA, which means they affect most compliance targets. Three are AAA, relevant if you aim for the highest standard or want to future-proof your work.
At the same time, WCAG 2.2 removes one criterion that existed since WCAG 2.0: success criterion 4.1.1 Parsing. That removal is not a technicality. It reflects a genuine shift in how browsers handle HTML.
The breakdown by conformance level looks like this:
- Level A (2 new): 3.2.6 Consistent Help, 3.3.7 Redundant Entry - Level AA (4 new): 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum) - Level AAA (3 new): 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 3.3.9 Accessible Authentication (Enhanced) - Removed: 4.1.1 Parsing
If your current compliance goal is WCAG 2.1 AA, upgrading to WCAG 2.2 AA means addressing six additional requirements. That is a manageable scope for most teams.
New Success Criteria in WCAG 2.2
Each of the nine new criteria targets a specific usability gap that real users reported. Let us go through them one by one.
2.4.11 Focus Not Obscured (Minimum) - Level AA
This criterion requires that when a user interface component receives keyboard focus, it is not entirely hidden by author-created content. Think about sticky headers, cookie banners, or chat widgets that sit on top of the page. A keyboard user tabs through a form, and the focused field disappears behind a fixed navigation bar. They can tell the focus moved somewhere, but they cannot see where.
The minimum version asks that at least part of the focused element remains visible. You do not need to guarantee the entire element is visible at AA level, just enough that the user can orient themselves.
Practical check: Tab through your entire page with a sticky header enabled. Does the focused element ever vanish completely behind the header? If yes, you need to add scroll padding or adjust your fixed positioning. A simple CSS fix is often enough: scroll-padding-top set to the height of your sticky element.
2.4.12 Focus Not Obscured (Enhanced) - Level AAA
The enhanced version raises the bar. No part of the focused component can be hidden by author-created content. Where the AA version tolerates partial occlusion, AAA demands full visibility.
This matters most on pages with multiple layered elements: a sticky header at the top, a floating action button at the bottom, a cookie consent banner, and maybe a live chat bubble in the corner. On a small viewport, these overlapping layers can cover a surprising amount of screen space.
Practical check: Same tab-through test, but now verify that the focused element is fully visible at every step. Tools that highlight focus indicators can help you spot partial overlaps you might miss visually.
2.4.13 Focus Appearance - Level AAA
This criterion specifies what a focus indicator should look like. It requires that the focus indicator has sufficient size and contrast. Specifically, the indicator area must be at least as large as a 2 CSS pixel thick perimeter of the unfocused component, and it must have a contrast ratio of at least 3:1 between its focused and unfocused states.
Many websites strip the default browser focus outline with outline: none and replace it with nothing, or with a faint dotted line that disappears on certain backgrounds. This criterion pushes back against that pattern.
Practical example: A navigation link with a 1px light gray dotted outline on a white background fails this criterion. A 2px solid blue outline (like the browser default in Chrome) on the same white background passes comfortably. The takeaway is straightforward: stop removing browser defaults unless you replace them with something at least as visible.
2.5.7 Dragging Movements - Level AA
Any functionality that uses a dragging movement must also be operable with a single pointer without dragging. This one matters for people with motor impairments who cannot maintain pointer contact while moving across the screen.
Drag-and-drop interfaces are everywhere: reordering lists, moving cards on a Kanban board, adjusting sliders, placing pins on a map. The criterion does not say you must remove drag functionality. It says you must provide an alternative.
Practical example: A sortable list where users drag items to reorder them should also include up/down arrow buttons on each item. A range slider should accept direct value input, either through a text field or through clicking on the track to set the value. A map that lets users drag a pin should also let them type an address or coordinates.
This is one of the criteria most likely to require actual development work. If your product relies heavily on drag interactions, plan time for building alternatives.
2.5.8 Target Size (Minimum) - Level AA
Interactive targets must be at least 24 by 24 CSS pixels, or they must have sufficient spacing from adjacent targets so that a 24px circle centered on the target does not overlap another target.
WCAG 2.1 already had 2.5.5 Target Size at AAA with a 44px requirement. The 2.2 version introduces a more practical AA-level requirement at 24px, acknowledging that 44px was too aggressive for many interface patterns.
There are exceptions. Inline links within a text block are exempt. So are targets whose size is determined by the user agent (like default checkboxes). Targets that are legally required to be a certain size are also exempt.
Practical check: Open your browser DevTools, inspect your smallest interactive elements. Icon buttons, close buttons on modals, pagination links, and social media icons are common offenders. A 16px icon button with no padding fails. Adding 4px of padding on each side brings it to 24px and passes.
This is the criterion that affects the most websites. Small touch targets have been a persistent problem, and having an AA-level requirement gives teams concrete numbers to work with.
3.2.6 Consistent Help - Level A
When a website provides help mechanisms such as contact information, a chat widget, a FAQ link, or a phone number, those mechanisms must appear in the same relative order across pages. If your contact link appears in the footer on the homepage, it should appear in the footer on every other page too, not in the sidebar on some pages and the header on others.
This sounds obvious, but it trips up sites that use different page templates for different sections. A blog might have help links in the sidebar, while the product pages have them in a footer, and the checkout flow hides them entirely.
Practical check: Visit five or six different pages on your site and note where help-related links appear. Are they always in the same place relative to other repeated content? If your site uses a consistent header and footer template, you are probably fine. If different sections use different layouts, check each one.
3.3.7 Redundant Entry - Level A
Information that the user has already entered in a process must either be auto-populated or available for the user to select, unless re-entering the information is essential for security or the previously entered information is no longer valid.
Multi-step forms are the primary target here. A checkout flow that asks for your address on step 2 and then asks for it again on step 4 as a billing address violates this criterion, unless it offers a checkbox like "billing address same as shipping address."
Practical example: A loan application that spans five pages asks for the applicant's name and date of birth on page one for identity purposes, then asks for the same name and date of birth on page three for the loan agreement. The second instance should be pre-filled from the first entry.
This criterion benefits everyone, not just people with disabilities. But it is particularly important for people with cognitive disabilities or memory difficulties who struggle with repetitive data entry.
3.3.8 Accessible Authentication (Minimum) - Level AA
If an authentication process requires a cognitive function test, such as remembering a password or solving a puzzle, at least one alternative method must be available that does not rely on cognitive function. Alternatives include copy-pasting a password from a password manager, using biometric authentication, or receiving a one-time code via email.
The key word here is "cognitive function test." Remembering a password counts as one. Solving a CAPTCHA definitely counts. Transcribing a code from one device to another counts.
Practical example: A login form that blocks paste on the password field violates this criterion because it prevents password managers from functioning. A CAPTCHA that requires solving a puzzle with no audio or alternative also violates it.
The fix is often simple: do not block paste on password fields. Allow password managers to work. If you use CAPTCHAs, provide alternatives. If you support two-factor authentication, allow email-based codes in addition to authenticator apps.
This criterion also explicitly allows object recognition ("click all the bicycles") and personal content recognition ("which of these is your profile picture") as acceptable alternatives, since these do not require memorization or transcription.
3.3.9 Accessible Authentication (Enhanced) - Level AAA
The enhanced version tightens the requirements further. No step in the authentication process may require a cognitive function test, with narrower exceptions. Object recognition and personal content recognition, which the AA version permits, are no longer accepted at AAA.
This essentially means that AAA-conformant authentication must support fully automated methods: password managers, biometrics, or magic links. No puzzles, no image recognition, no memorization of any kind.
Practical relevance: Very few sites target AAA for authentication. But the direction is clear. The industry is moving toward passwordless authentication, and this criterion aligns with that trajectory. If you are designing a new authentication system, building it to meet AAA from the start saves future retrofitting.
Removed Criterion: 4.1.1 Parsing
WCAG 2.2 formally removes success criterion 4.1.1 Parsing, which required that HTML be well-formed with complete start and end tags, properly nested elements, unique IDs, and no duplicate attributes.
Why remove a rule about valid HTML? Because modern browsers have become extraordinarily good at handling malformed markup. The HTML5 parsing algorithm specifies exactly how browsers should recover from errors, and all major browsers implement it consistently. A missing closing tag or a duplicate ID no longer causes the kind of accessibility failures it might have caused in 2008.
More importantly, the issues that 4.1.1 was meant to prevent, such as assistive technology misinterpreting the page structure, are now better covered by other criteria like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
Does this mean you should stop writing valid HTML? Absolutely not. Valid markup is still easier to maintain, debug, and test. But you no longer need to treat every validation warning as an accessibility failure. The removal acknowledges that parsing errors and accessibility errors are no longer the same thing.
Note: If you are testing against WCAG 2.0 or 2.1 specifically, 4.1.1 still applies. The removal only affects 2.2 conformance claims.
What the European Accessibility Act Requires
The European Accessibility Act (EAA) takes effect on June 28, 2025, and it references the harmonized European standard EN 301 549, which in turn references WCAG 2.1 Level AA as its baseline for web content.
So technically, EAA compliance does not require WCAG 2.2. But there are several reasons to target 2.2 anyway.
First, standards evolve. EN 301 549 will eventually update its reference from WCAG 2.1 to 2.2. When that happens, organizations already conforming to 2.2 will have no additional work to do.
Second, WCAG 2.2 is backward compatible. Every WCAG 2.2 conformant site automatically conforms to WCAG 2.1 as well. You cannot lose compliance by targeting the newer version.
Third, several of the new criteria in 2.2 address issues that are likely to come up in EAA enforcement anyway. Target size problems, authentication barriers, and inconsistent help mechanisms are exactly the kinds of usability issues that regulators and advocacy groups flag. Meeting 2.2 proactively reduces your risk surface.
Fourth, some EU member states may adopt stricter national standards that go beyond EN 301 549. Targeting 2.2 gives you headroom.
The practical advice: use WCAG 2.2 AA as your target. Claim WCAG 2.1 AA conformance for regulatory purposes if needed, but build to the 2.2 standard.
Should You Target WCAG 2.2?
The short answer is yes, with some nuance depending on your situation.
If you are starting a new project, target WCAG 2.2 AA from day one. The additional criteria are not burdensome when designed in from the start. Building with 24px minimum target sizes, consistent help placement, and paste-friendly authentication is straightforward when these are part of your initial requirements.
If you have an existing site that meets WCAG 2.1 AA, the upgrade path is manageable. Run through the six new AA criteria one by one. In many cases, you will find that your site already partially complies. The most common gaps are target size issues (2.5.8) and drag-only interfaces without alternatives (2.5.7).
If you are mid-way through a WCAG 2.1 remediation project, consider expanding your scope to include 2.2. Adding six criteria to an active remediation effort is more efficient than completing 2.1 and then starting a separate 2.2 project.
The cost of waiting is real. Every month you delay 2.2 adoption is another month of accumulating non-conformant content. New pages, new features, and new components all need to be revisited later if they are built to the older standard.
One more consideration: WCAG 2.2 compliance is becoming a market differentiator. As awareness grows, procurement processes and RFPs increasingly specify 2.2. Being ahead of that curve is a competitive advantage.
How to Test for WCAG 2.2 Compliance
Testing for WCAG 2.2 requires a combination of automated scanning and manual verification. No automated tool catches everything, and several of the new criteria require human judgment.
For automated testing, make sure your tool supports WCAG 2.2 rules. Many popular tools updated their rulesets throughout 2024. Check the version and rule coverage before relying on scan results. Our accessibility checker tests against WCAG 2.2 criteria out of the box.
For manual testing, here is a practical checklist organized by the new criteria:
Focus visibility (2.4.11): Tab through every interactive element on the page. Watch for the focused element disappearing behind sticky headers, footers, modals, or floating widgets. Test on at least two viewport sizes.
Dragging alternatives (2.5.7): Identify every drag-and-drop interaction on your site. For each one, verify that a non-dragging alternative exists. Try completing the same task using only keyboard or a single click/tap.
Target size (2.5.8): Use browser DevTools to measure your smallest interactive elements. Pay special attention to icon buttons, close buttons, pagination controls, and inline action links that sit close together. The 24px requirement applies to both width and height.
Consistent help (3.2.6): Visit at least five different page templates and verify that help mechanisms appear in the same relative position. Check the header, footer, and any sidebar areas.
Redundant entry (3.3.7): Complete every multi-step form on your site from start to finish. Note every instance where you are asked for information you already provided. Verify that auto-population or selection options are available.
Authentication (3.3.8): Attempt to log in using a password manager. Verify that paste is not blocked on any authentication field. If CAPTCHAs are present, check for alternatives. Try the entire authentication flow using only a keyboard.
Document your testing process. Record which pages you tested, which criteria you checked, and what you found. This documentation is valuable for compliance claims and for tracking remediation progress.
A structured approach works best: test one criterion at a time across your key page templates rather than trying to test all criteria on a single page. This reduces the chance of missing issues and makes it easier to assign fixes to the right team.