The Great WCAG 2.2 Incident: How We Broke Accessibility and Found Out at 2 AM

The Timeline Nobody Wants to Live Through

Picture this: It's September 2024, and your website is humming along fine. Users are clicking things, filling out forms, navigating with their keyboards - life is good. Then WCAG 2.2 drops with four shiny new success criteria, and suddenly your site is the digital equivalent of showing up to a potluck with gas station sushi. Nobody says anything at first, but everyone knows something's wrong.

This is how the incident unfolded for one mid-sized SaaS platform, and it's probably happening to you right now without you even knowing it.

Detection: The 3 AM Slack Message That Changed Everything

A power user - you know the type, they navigate with a keyboard like some people drive race cars - reported that they couldn't see where the focus was on the login form. Not couldn't find it. Couldn't see it. The new WCAG 2.2 focus appearance criterion (2.4.7) requires a visible focus indicator with at least a 3-to-1 contrast ratio. This company's focus outline? A barely-there 1-pixel gray line on a light gray background. Basically invisible. It's the web development equivalent of writing the WiFi password in pencil.

Within 24 hours, customer support had fielded seven similar reports. Then ten. The company's accessibility coordinator pulled the incident thread and discovered something worse: the mobile checkout flow required a drag gesture to complete payment - and there was no keyboard alternative. That's WCAG 2.2's Target Size and Pointer Gestures criterion (2.5.5) getting absolutely demolished. Published research suggests roughly 15-20% of users rely on keyboard navigation or voice control, which means this company just locked a significant chunk of their customer base out of spending money. Bad business. Worse optics.

The Root Cause (Spoiler: It Was Everywhere)

The post-incident investigation revealed the real villain: the company updated to WCAG 2.2 compliance on paper but never actually tested anything. They'd gone through their checklist like filling out a survey at the dentist - checking boxes without reading the questions.

• The focus appearance problem lived in their CSS because the designer had prioritized "clean aesthetics" over, you know, usability
• The drag gesture issue existed because their mobile dev team built the checkout flow using a trendy gesture library without considering that 100% of users aren't able-bodied
• Their accessible authentication flow was missing because they'd never heard of WCAG 2.2's new requirement (2.5.3) that authentication shouldn't rely solely on gesture or voice input without alternatives

The Cleanup: Chaos and Coffee

The remediation took two weeks. Two weeks of developers scrambling like they're trying to defuse a bomb while it's still attached to the website. Here's what actually happened:

Week One: Triage and "Oh God, How Many Are Broken?" The team ran a comprehensive WCAG 2.2 audit using automated scanning tools (plug: tools like SCOUTb2 catch these things fast) and found that focus appearance issues lived in seven different components across the entire platform. The drag gesture problem was thankfully isolated to one checkout flow, but it required a complete rewrite of the payment UX. The authentication screens needed keyboard-accessible alternatives added. This is the moment someone realized they'd need to rebuild stuff they thought was already done.

Week Two: The Actual Fixes They implemented visible focus indicators with proper contrast ratios across all interactive elements. The drag gesture got replaced with button-based alternatives. Authentication flows now offer both gesture and traditional input methods. They also added keyboard shortcuts for power users because, let's be honest, if you're navigating with a keyboard, you probably want efficiency too.

Prevention: How Not to Be That Company

The real lesson here isn't that WCAG 2.2 is hard (it's not, it just requires actual attention). It's that compliance isn't a checkbox - it's a practice. Here's what prevents this incident at your organization:

1. Test with real keyboards and assistive technology. Not just automated scans, though those help. Have actual humans navigate your site using only a keyboard. Have them use screen readers. This catches the invisible-focus-line problem immediately.
2. Build accessibility into your definition of done. If focus appearance isn't verified before code review, it ships broken. If drag gestures go in without keyboard alternatives, they're shipping broken. Make it non-negotiable.
3. Audit for WCAG 2.2 specifically. The new success criteria (focus appearance, target size, dragging movements, accessible authentication) require intentional testing. Automated tools are your first line, but they're not your only line.
4. Create a monitoring baseline. Don't wait for angry users. Run regular scans and track issues over time.

Here's the uncomfortable truth: Your site probably has at least one of these WCAG 2.2 issues right now. The focus indicator might be too subtle. A gesture-based feature might lack keyboard support. Your login flow might be inaccessible without JavaScript. And you won't know until someone tries to use it and can't.

Do yourself a favor - spend 20 minutes running your site through a WCAG 2.2 scanner today. Find out what's broken before your 3 AM Slack message finds you.

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.