verified_user
Standardful
Accessibility

WCAG 2.2 Explained: What Changed and Why Your Website Needs to Care

A plain-English guide to WCAG 2.2 — the nine new success criteria, what they mean for real websites and apps, and how the guidelines connect to legal mandates like ADA Title II and the European Accessibility Act.

calendar_today May 31, 2026schedule 12 min readperson Standardful Team

You ever try to tap a tiny "X" to close a popup on your phone and hit the wrong thing four times in a row? Or get logged out of a banking app and stare at a "solve this puzzle" challenge that you genuinely cannot solve? That frustration you feel for ten seconds is what some people deal with on every single website, every day.

That's the problem WCAG 2.2 is trying to fix. And if you build, design, or own a website or app, it's quietly become the thing regulators around the world point to when they say "make it accessible."

Here's what actually changed, why it matters, and what you should do about it — without the spec-document headache.

First, What Is WCAG (and Why 2.2)?

WCAG stands for Web Content Accessibility Guidelines. It's published by the W3C — the same standards body that defines HTML and CSS — through its Web Accessibility Initiative (WAI). It's not a law. It's a technical standard. But it's the technical standard that nearly every accessibility law on the planet borrows from.

The guidelines are organized around four principles, easy to remember as POUR:

  • Perceivable — people can perceive the content (text alternatives, captions, contrast)
  • Operable — people can operate the interface (keyboard access, enough time, no seizure triggers)
  • Understandable — content and operation make sense (readable, predictable)
  • Robust — it works with assistive tech like screen readers

Each principle has testable "success criteria" rated at three conformance levels: A (bare minimum), AA (the level almost everyone targets), and AAA (gold standard, rarely required wholesale).

WCAG 2.2 became an official W3C Recommendation in October 2023. It's backwards-compatible — if you meet 2.2, you automatically meet 2.1 and 2.0. It just adds nine new success criteria and removes one outdated one (4.1.1 Parsing, which modern browsers made irrelevant).

The Nine New Criteria, Translated to Human

Most "what's new in WCAG 2.2" articles just paste the spec language at you. Here's what each one actually means.

1. Focus Not Obscured (Minimum) — Level AA

When you tab through a page with a keyboard, the thing you've landed on can't be completely hidden behind a sticky header, a cookie banner, or a chat widget. Sounds obvious. It breaks constantly. Sticky headers are the usual culprit.

2. Focus Not Obscured (Enhanced) — Level AAA

Same idea, stricter: the focused element can't be hidden at all, even partially.

3. Focus Appearance — Level AAA

When something has keyboard focus, the focus indicator has to be big enough and high-contrast enough to actually see. No more faint 1px outlines.

4. Dragging Movements — Level AA

If your interface uses a drag gesture — reordering a list, a slider, a map — there has to be a way to do the same thing without dragging. A single tap or click alternative. This is huge for people with motor disabilities or anyone using a head pointer or switch device.

5. Target Size (Minimum) — Level AA

Clickable targets need to be at least 24×24 CSS pixels, or have enough spacing around them. This is the "tiny X button" problem. Note: this is more lenient than the 44×44 figure you might remember from mobile guidelines — 24px is the floor, not the ideal.

6. Consistent Help — Level A

If you offer help — a contact link, a chat button, a phone number — it needs to show up in the same relative place across pages. Don't make people hunt for support every time.

7. Redundant Entry — Level A

Don't make people re-enter information they already gave you in the same process. Auto-fill the shipping address into billing, carry the email forward across a multi-step form. Anyone with memory or cognitive disabilities (and, honestly, everyone) benefits.

8. Accessible Authentication (Minimum) — Level AA

This is the big one. You can't force a cognitive function test — like solving a puzzle, transcribing distorted text, or remembering a password from scratch — as the only way to log in. You have to support alternatives: password managers (don't block paste!), passkeys, email links, or "copy the code we sent you." Those squint-and-solve CAPTCHAs? On notice.

9. Accessible Authentication (Enhanced) — Level AAA

Same as above but removes the object-recognition exception. Strictest version.

For most teams, the criteria that bite hardest in practice are Target Size, Dragging Movements, Focus Not Obscured, and Accessible Authentication. Start there.

Why This Isn't Optional Anymore

Here's the part that turns a "nice to have" into a board-level conversation: WCAG is now baked into law across major markets.

United States. ADA Title II now explicitly requires state and local governments to meet WCAG 2.1 Level AA, with compliance deadlines landing in 2026 and 2027 depending on population size. Private businesses (Title III) don't have a codified technical standard yet, but courts have consistently treated WCAG AA as the de facto benchmark in thousands of accessibility lawsuits. Section 508 covers federal agencies.

European Union. The European Accessibility Act (EAA) started applying in June 2025. It requires e-commerce, banking, e-books, transport ticketing, and a range of digital services to be accessible. The harmonized standard behind it, EN 301 549, leans directly on WCAG. If you sell to EU consumers online, this almost certainly touches you.

Everywhere else. Canada (ACA), the UK (Equality Act + public sector regs), Australia, and dozens of other jurisdictions reference WCAG AA. It's the closest thing accessibility has to a universal currency.

The pattern is clear: the laws say "be accessible," and when you ask "according to what?", the answer is WCAG. Meeting 2.2 AA is the safest position to be in.

A Practical Path to Conformance

Don't try to boil the ocean. Here's a sane order of operations.

  1. Run an automated scan first. Tools like axe, WAVE, or Lighthouse catch maybe 30–40% of issues in minutes. They're a starting line, not a finish line.
  2. Do a keyboard-only pass. Unplug your mouse. Tab through every key flow — nav, forms, checkout, login. You'll find most of the new 2.2 issues (focus obscured, no drag alternative) this way.
  3. Test with a real screen reader. NVDA (free, Windows), VoiceOver (built into Mac/iOS), or TalkBack (Android). Twenty minutes here teaches you more than any checklist.
  4. Fix the high-traffic, high-stakes flows first. Login, search, checkout, contact. That's where lawsuits and lost customers come from.
  5. Bake it into your process. Add accessibility checks to design reviews and your CI pipeline. Retrofitting is expensive; preventing regressions is cheap.

Best Practices Worth Internalizing

  • Never block paste on password fields. It quietly breaks password managers and fails Accessible Authentication.
  • Design touch targets at 24px minimum — and honestly, aim higher for primary actions.
  • Always provide a non-drag alternative for any drag interaction.
  • Keep help in a consistent spot across the whole site.

FAQ

Is WCAG 2.2 a legal requirement? WCAG itself is a technical standard, not a law. But laws like ADA Title II and the EAA require accessibility and point to WCAG as the measuring stick — usually Level AA. So in practice, meeting WCAG AA is how you demonstrate compliance.

Do I need 2.2 or is 2.1 enough? Most current laws still cite 2.1 AA. But 2.2 is backwards-compatible and represents where regulation is heading. Targeting 2.2 AA future-proofs you and costs little extra once you're already doing the work.

What's the difference between A, AA, and AAA? A is the minimum, AA is the practical target nearly every law requires, and AAA is aspirational — even W3C doesn't recommend requiring full AAA conformance across a whole site.

How long does it take to get conformant? For an existing site with no prior work, expect weeks to months depending on size and complexity. The first audit usually surfaces a long list; prioritizing core user flows gets you most of the risk reduction quickly.

The Bottom Line

WCAG 2.2 didn't reinvent accessibility — it sharpened it. The nine new criteria mostly target real, everyday friction: tiny buttons, drag-only controls, hidden focus, and login puzzles that lock people out. Meeting them makes your product better for everyone, not just users with disabilities.

And with ADA Title II deadlines and the European Accessibility Act now in force, the legal cost of ignoring it keeps climbing. The cheapest time to start was during your last redesign. The second cheapest is now.

References

  1. WCAG 2.2 Recommendation — W3C (October 2023)
  2. What's New in WCAG 2.2 — W3C Web Accessibility Initiative
  3. How to Meet WCAG (Quick Reference) — W3C WAI
  4. ADA Title II Web Rule — U.S. Department of Justice (2024)
  5. European Accessibility Act — European Commission

Related Topics

WCAG 2.2Web AccessibilityADA ComplianceEuropean Accessibility ActWCAGDigital Accessibility