The Ultimate WCAG 2.2 Checklist for Developers (AA & AAA)

WCAG (Web Content Accessibility Guidelines) is the bible of digital accessibility. But let's be honest—the official documentation is dense. That's why we've broken down the most critical parts of the latest version, WCAG 2.2, into a practical checklist for coders.

WCAG 2.2 does not replace 2.1; it extends it. The main focus is on users with cognitive disabilities and mobile interfaces. If you're aiming for Level AA compliance (required by most accessibility laws), this is what you need to know.

We'll walk through each new criterion with concrete code examples and practical solutions you can implement today.

What's new in WCAG 2.2?

Version 2.2 introduced 9 new success criteria. Here are the most impactful for standard websites:

Focus Appearance

Removing the browser's default focus (outline: none) is a cardinal sin in accessibility unless replaced with something better. WCAG 2.2 tightens these rules significantly.

2.4.11 Focus Not Obscured (AA): This new criterion states that focused elements must not be completely hidden. The most common culprits? Sticky headers and cookie banners that overlay focused elements.

CSS Solution:

html { scroll-padding-top: 80px; } — Ensures anchor links and focus account for header height.

For focus ring appearance, follow these guidelines:

Rule of thumb: If you can't immediately see the focus indicator when tabbing through your page, you have a problem.

Target Size (Minimum)

For users with motor impairments, or just large fingers on a bumpy bus, small buttons are frustrating.

WCAG 2.5.8 (AA) requires the target size to be at least 24x24 CSS pixels. If the button is smaller, there must be enough spacing around it so the total area includes 24px distance to the next clickable element.

Exceptions:

Xrayd recommends: Don't settle for 24px. Apple and Google recommend 44x44px for touch targets. It's better UX for everyone. Ensure your CSS buttons have sufficient padding:

.btn { min-height: 44px; min-width: 44px; padding: 12px 24px; }

Redundant Entry

Criterion 3.3.7 addresses cognitive load. If a user has already entered their address in a previous step, don't ask them to type it again.

Common cases:

Solutions:

This doesn't just reduce friction—it significantly improves conversion rates. Win-win.

Dragging Movements

2.5.7 Dragging Movements (AA) is new and important. If your application has drag-and-drop functionality, there must be an alternative that doesn't require dragging.

Examples that need alternatives:

Implementation tip:

The alternative method doesn't need to be as elegant as drag-and-drop. What matters is that the functionality is accessible to everyone.

Practical Implementation Tips

1. Authentication (3.3.8)

Password requirements are okay, but offer alternatives: 'Sign in with Google/Apple', 'Send login link to email', or support for password managers (make sure autocomplete='current-password' is set).

2. Test with real users

WCAG 2.2's focus on cognitive disabilities is difficult to test automatically. Consider user testing with people who have dyslexia, ADHD, or memory difficulties.

3. Build accessibility in from the start

It's 10x more expensive to fix accessibility retroactively. Add WCAG 2.2 criteria to your Definition of Done now.

4. Prioritize correctly

Level A criteria first (they're foundational), then AA (the legal requirement), then AAA (bonus). WCAG 2.2 added several A-level criteria that should be addressed immediately.