WCAG 2.2: What Changed and Why It Matters

WCAG 2.2 became a W3C Recommendation in October 2023. That was over two years ago. And yet, in the audits I conduct week after week, I still find that most organisations are testing against WCAG 2.1 — or worse, 2.0. The new success criteria aren't optional extras. They address real gaps that people like me encounter every single day.

I want to walk through what actually changed, what each new requirement means in practice, and which ones I think deserve your immediate attention. This isn't a theoretical overview. I test against these criteria with my screen reader, my keyboard, and my own experience of navigating the web without sight.

A Quick Refresher: What WCAG Is

The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility. They're maintained by the W3C's Accessibility Guidelines Working Group, and they form the basis of accessibility legislation in most countries — including the European Accessibility Act, the Americans with Disabilities Act (as interpreted by the DOJ), and India's own evolving regulatory landscape.

WCAG organises its requirements into three conformance levels:

• Level A — the bare minimum. If you fail these, your product has fundamental barriers that prevent access entirely.
• Level AA — the standard most laws and policies reference. This is where your organisation should be aiming.
• Level AAA — the highest standard. Not typically required for full conformance, but individual AAA criteria are often worth meeting, especially when they directly affect your user base.

WCAG 2.2 builds on 2.1. It doesn't replace the existing criteria — it adds nine new ones and removes one. If you're already conformant with 2.1, you're most of the way there. But "most of the way" isn't the same as "done."

The 9 New Success Criteria

Let me go through each one. I'll explain what it requires, give you a practical example, and share my own take on how much it matters.

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a component receives keyboard focus, it must not be entirely hidden by other content that the author has positioned on the page. Think of sticky headers, cookie banners, or chat widgets that sit on top of the page. If I Tab to a link and the focused element is completely behind a fixed footer bar, I have no visual indication of where I am.

Now, I'm blind — I don't rely on the visual focus indicator myself. But I work alongside sighted keyboard users constantly, and I've watched this problem frustrate them to the point of giving up. A colleague of mine with a motor impairment uses keyboard navigation exclusively. When focus disappears behind a sticky banner, she loses her place entirely and has to start over. This criterion addresses a real, common barrier.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

This is the stricter version: no part of the focused component may be hidden by author-created content. The AA version (2.4.11) allows partial obscuring — as long as the element isn't entirely hidden, it passes. The AAA version says the entire focused component must be fully visible.

In my view, this is the standard you should aim for even though it's AAA. Partial visibility isn't much better than no visibility when you're trying to track your focus position across a complex interface.

2.4.13 Focus Appearance — Level AAA

This criterion specifies minimum requirements for the focus indicator itself: it must have sufficient size and contrast. Specifically, the focus indicator must have a contrast ratio of at least 3:1 between its focused and unfocused states, and it must be at least as large as a 2 CSS pixel thick perimeter around the component.

I've been advocating for strong focus indicators for years. The number of websites I audit that use outline: none in their CSS with no replacement focus style is staggering. Even though this criterion is AAA, I recommend every team treat it as a baseline requirement. If your focus indicator is a faint dotted line that barely registers against your background colour, keyboard users are navigating blind — and I mean that without irony.

2.5.7 Dragging Movements — Level AA

Any functionality that uses dragging movements must also be operable with a single pointer action without dragging. This means if you've built a drag-and-drop interface — for reordering a list, moving items between columns, adjusting a slider — there must be an alternative that doesn't require dragging.

This one matters enormously to me. I can't drag and drop. My screen reader doesn't support it. When I encounter a Kanban board where the only way to move a task from "In Progress" to "Done" is to drag it, that feature is completely inaccessible to me. I need a button, a menu, a select dropdown — any single-pointer alternative.

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 other targets. There are exceptions for inline links within text, targets where the size is determined by the user agent, and cases where a larger alternative target exists on the same page.

While I don't interact with touch targets visually, I see the impact of this criterion in every mobile audit I conduct. Users with motor impairments, tremors, or limited dexterity struggle with tiny buttons packed closely together. I've tested mobile banking apps where the "Transfer" and "Delete" buttons were 18 pixels apart. That's a recipe for costly mistakes. This criterion sets a sensible minimum.

3.2.6 Consistent Help — Level A

If your site provides help mechanisms — contact information, a chatbot, a FAQ link, a phone number — these must appear in the same relative order across pages. If "Contact Us" is in the footer on one page and in the header on another, that's a failure.

This one resonates with me deeply. When I navigate a website with my screen reader, I build a mental model of where things are. I learn that the help link is the third item in the footer navigation. If it moves to a different location on a different page, I have to hunt for it all over again. For sighted users, this is a minor inconvenience. For me, it means re-scanning the entire page. Consistency isn't a nice-to-have — it's how I navigate efficiently.

3.3.7 Redundant Entry — Level A

Information a user has already entered in a process must not be asked for again, unless re-entering it is essential, the user is given a way to select previously entered data, or the information is no longer valid. Think of multi-step forms that ask for your address on step one and again on step three.

Filling out forms with a screen reader is slow. Every field requires me to navigate to it, listen to the label, type my response, and move on. When I've already entered my postal address once and the form asks me to type it again on the next page, that's not just annoying — it's a significant time penalty. This criterion respects the effort that form completion requires for people who use assistive technology.

3.3.8 Accessible Authentication (Minimum) — Level AA

If an authentication step requires a cognitive function test — like remembering a password, solving a puzzle, or recognising an image — an alternative must be available. Alternatives include allowing password managers to fill credentials, providing a copy-paste option, or offering an authentication method that doesn't rely on cognitive function tests (such as a hardware security key or biometric authentication).

This is one of the most impactful criteria in WCAG 2.2, and I say that from direct experience. CAPTCHAs have been my nemesis for over a decade. Image-based CAPTCHAs are completely inaccessible to me. Audio CAPTCHAs are often so distorted they're unusable. Puzzle CAPTCHAs that ask me to drag a piece into position are impossible with a screen reader. Every time I encounter one without an accessible alternative, I'm locked out. Not slowed down — locked out entirely.

This criterion also protects people with cognitive disabilities who struggle with memory-based authentication. Requiring someone to transcribe a one-time code from memory (without allowing paste) is a barrier. Let people use their password managers. Let them paste. Provide alternatives.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

This is the stricter version of 3.3.8. It removes the exception that allows object recognition and personal content recognition as cognitive function tests. Under 3.3.8, a site could ask you to identify which image contains a bicycle. Under 3.3.9, even that isn't permitted without an alternative that requires no cognitive function test at all.

I'd argue this should be the standard, not the enhanced version. Image recognition CAPTCHAs are inaccessible to blind users regardless of which conformance level you're targeting.

What Was Removed: 4.1.1 Parsing

WCAG 2.2 officially removed Success Criterion 4.1.1 Parsing. This criterion previously required that HTML be well-formed — no duplicate IDs, proper nesting, complete start and end tags. It was removed because modern browsers and assistive technologies now handle parsing errors gracefully. The issues that 4.1.1 was designed to prevent are effectively handled by the technology itself.

That said, writing clean, valid HTML is still good practice. The removal of 4.1.1 doesn't mean you should stop caring about markup quality. Duplicate IDs still cause real problems for screen readers — if two elements share the same ID and a label references that ID, my screen reader may associate the label with the wrong element. It's just that this is now covered by other criteria (like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value) rather than a standalone parsing requirement.

Which Criteria Matter Most — My Perspective

If I had to rank the nine new criteria by their real-world impact on users with disabilities, here's how I'd prioritise them:

1. 3.3.8 Accessible Authentication (Minimum) — because it's a gatekeeper. If you can't log in, nothing else matters. I've been locked out of services I'm paying for because of inaccessible CAPTCHAs. This is the most urgent fix for most organisations.
2. 2.5.7 Dragging Movements — because drag-and-drop without alternatives renders entire features unusable for keyboard and screen reader users. This isn't a minor inconvenience; it's a complete blocker.
3. 3.3.7 Redundant Entry — because forms are already the hardest part of the web for assistive technology users. Asking us to repeat information we've already provided is a significant and unnecessary burden.
4. 2.4.11 Focus Not Obscured (Minimum) — because sticky UI elements are everywhere now, and keyboard users lose their place constantly when focus slips behind them.
5. 3.2.6 Consistent Help — because when I need help, I need to find it quickly. Inconsistent placement forces me to search the entire page.
6. 2.5.8 Target Size (Minimum) — because mobile usage continues to grow, and small touch targets disproportionately affect people with motor impairments.
7. 2.4.13 Focus Appearance — because even though it's AAA, strong focus indicators are essential for every keyboard user.
8. 2.4.12 Focus Not Obscured (Enhanced) — because full visibility is always better than partial visibility.
9. 3.3.9 Accessible Authentication (Enhanced) — because if you've already met 3.3.8 properly, you're likely close to meeting this one too.

Your priorities may differ depending on your user base. But if you're asking me where to start, start with authentication and interactive patterns. Those are where the barriers are most severe.

What Your Organisation Should Do Now

Here's a practical action plan:

1. Audit against WCAG 2.2, not 2.1. Update your conformance target. If your accessibility statement still references WCAG 2.1, it's time to revise it. The European Accessibility Act, which becomes enforceable in June 2025, references the latest harmonised standard.
2. Review your authentication flows first. Can users log in with a password manager? Can they paste one-time codes? Is there a CAPTCHA, and if so, is there an accessible alternative? Fix this before anything else.
3. Inventory your drag-and-drop interactions. Every drag-based feature needs a single-pointer alternative. If your project management tool or content editor relies on drag-and-drop without alternative controls, add them.
4. Check your sticky elements. Tab through every page with your sticky headers, cookie banners, and chat widgets active. If focus disappears behind any of them, adjust your scroll offset or element positioning.
5. Audit your multi-step forms. Map out every piece of information you collect across form steps. If you're asking for the same data twice without pre-populating it, refactor the flow.
6. Verify help mechanism placement. Check that your help links, contact information, and support options appear in the same location on every page.
7. Update your testing checklist. Add the nine new criteria to your QA process. Train your testers on what to look for. Better yet, include people with disabilities in your testing — we'll find the real-world failures that checklists miss.

The Bottom Line

WCAG 2.2 isn't a revolution. It's a targeted set of improvements that address gaps the accessibility community has been raising for years. The new criteria focus on areas where real users face real barriers: authentication, focus visibility, touch targets, dragging, and form efficiency.

The standard has been final for over two years now. If your organisation hasn't updated its conformance target, you're already behind. And more importantly, your users with disabilities are encountering barriers that these criteria were specifically written to prevent.

I test against WCAG 2.2 in every audit I conduct. If you want to understand where your product stands against the current standard, get in touch. I'd rather help you fix these issues now than find them in a compliance review later.