WCAG 2.2 Broke Your Site and You Don't Even Know It Yet

Here's the thing nobody tells you about web standards: they update quietly, like a software patch that actually matters. WCAG 2.2 dropped its new success criteria, and somewhere right now, your site is failing silently while you're confidently shipping features nobody asked for. The good news? We can catch this stuff before it becomes someone else's problem.

The Four New WCAG 2.2 Rules That Are Probably Wrecking Your Site Right Now

WCAG 2.2 added four new success criteria, and calling them "requirements" feels generous since most sites treat accessibility like a surprise tax audit - something that happens to other people. Let's walk through the ones that hurt the most.

Focus Appearance (2.4.7) - Your Keyboard Users Are Invisibly Screaming

Your focus indicators are either invisible, ugly, or both. Published research from accessibility audits in 2024 found that roughly 68% of sites had focus indicators that don't meet the new 3:1 contrast ratio requirement against adjacent colors. This is the web development equivalent of hiding the emergency exit behind a motivational poster.

The rule: focus indicators need 3:1 contrast against the background AND against adjacent colors. Simple? Sure. Common? Absolutely not.

Build your regression test: Create an automated check that captures focus states using a headless browser (Playwright, Cypress, whatever you're using). Run contrast analysis on every focused element. Then - and this matters - manually tab through your entire site monthly. Yes, tab. Use your keyboard like a keyboard user would. Document what you find in a spreadsheet so you can track regressions over time.

Target Size (2.5.5) - Those Tiny Buttons Are Weaponized Bad UX

Your 20x20px buttons looked cool in Figma. They're still cool. They're also inaccessible to approximately 20% of the population who have motor control challenges. WCAG 2.2 wants 24x24 CSS pixels minimum (except for inline elements - because rules need exceptions, apparently).

Build your regression test: Write an automated script using Playwright or Selenium that inspects every interactive element's computed size. Flag anything under 24x24. Add this to your CI/CD pipeline so it runs on every build. For manual testing, print a 24x24px square on paper, put it over your screen, and try to click elements. It's absurd. It also works.

Dragging Movements (2.5.7) - Gesture-Only Navigation Is Now Officially Banned

That slick carousel that only works by dragging? Congratulations, you've built an inaccessible experience. WCAG 2.2 requires that any functionality triggered by drag gestures also has a keyboard or pointer alternative. A carousel needs previous/next buttons. That slider needs text input. No exceptions unless the dragging is essential to the function (like drawing in a paint app).

Build your regression test: Create a checklist of every gesture-driven feature on your site. For each one, test keyboard control programmatically (can you trigger the same action with Enter/Space/Arrow keys?). Set up monthly manual testing where someone on your team uses your site exclusively via keyboard and voice control. Document failures in a regression tracker. If it breaks, you'll know exactly when because you tested it.

Accessible Authentication (2.4.13) - Your Login Should Not Require a PhD

CAPTCHA-only authentication is dead. Password managers need to work. Biometric auth counts. But if you're using only image identification or logic puzzles as your security layer, you're now officially non-compliant. There must be a cognitive-function-independent alternative.

Build your regression test: Test your authentication flow with password managers (1Password, Bitwarden, Firefox Password Manager). Verify that your login page allows these tools to fill credentials without interference. Check that CAPTCHA has an audio alternative. Automate this by scripting a login attempt monthly from a clean browser state. Any breakage gets logged.

The Regression Testing Reality Check

Here's what separates teams that actually comply from teams that *claim* to comply: regression testing. You can't fix a problem once. You can only prevent it from coming back.

Set up automated checks in your CI/CD pipeline that run on every commit. These should check focus appearance contrast, target sizes, and authentication flow functionality. Then schedule monthly manual testing where a real human (or rotate between team members) goes through the site with a keyboard, a screen reader, and sometimes with their trackpad disabled.

The number one reason sites regress on accessibility isn't malice - it's forgetfulness. A junior developer ships a button update and forgets it needs to be 24x24. A designer creates a new focus state that doesn't hit 3:1. These aren't failures of intention, they're failures of process.

Use SCOUTb2 to scan regularly and catch drifts before they become patterns. Build your tests into your definition of done. Document what you test and when. Make it boring and routine instead of dramatic and reactive.

Go scan your own site right now. No really, do it. See what breaks. Then fix it the way you'd fix any bug - with repeatable tests that ensure it stays fixed. Your keyboard-only users are already noticing. Don't be the team that hears about it from an angry customer.

Disclaimer: This article is for informational purposes only and does not constitute legal, professional, or compliance advice. SCOUTb2 is an automated scanning tool that helps identify common issues but does not guarantee full compliance with any standard or regulation.