SEO & Performance
Designing for WCAG 2.2 AA in 2026: The Practical Checklist
WCAG 2.2 AA is the de facto baseline in 2026. Here's what it actually means in design and code, with a checklist you can ship against.
Marco Elizalde
WCAG 2.2 was published in October 2023 and has since become the de facto accessibility baseline in 2026. The European Accessibility Act enforcement, ADA lawsuits in the US, platform store requirements, and procurement contracts all reference it.
If you’re building a customer-facing app or marketing site in 2026 and haven’t audited against WCAG 2.2 AA, you’re shipping liability.
This isn’t a re-read of the spec. It’s a practical checklist of what AA means in design and code, distilled from auditing real production systems.
The 10 things that matter most
1. Contrast ratios
Body text and meaningful icons need at least 4.5:1 against their background. Large text (24px+ regular or 18.66px+ bold) gets a relaxed 3:1.
This is the rule that catches most teams. Brand red on white might pass — but brand red on a slightly off-white surface? Probably not. The light gray text we love for “secondary information”? Almost never.
Use the Contrast Checker on every text-on-background pair before you ship. Don’t eyeball it.
2. Focus indicators
Every interactive element must have a visible focus indicator with at least 3:1 contrast against the adjacent background. The default browser ring is fine; what’s not fine is outline: none with no replacement.
WCAG 2.2 specifically introduced Focus Appearance requirements: the focus indicator must be at least 2 CSS pixels thick and not entirely obscured by other content.
In practice: use :focus-visible instead of :focus to avoid showing rings on mouse clicks, and set a clear outline rule.
:focus-visible {
outline: 2px solid var(--color-accent);
outline-offset: 2px;
}3. Target size
WCAG 2.2 added a new criterion: interactive targets must be at least 24x24 CSS pixels. Buttons in mobile-first designs already meet this; the issue is dense list rows, icon buttons in headers, and small “X” close buttons.
If your design has 16px or 20px close buttons, they’re now AA failures.
4. Don’t rely on color alone
If your error state is “the field turns red,” you’ve failed. Color isn’t enough — the user must be able to identify the state without relying on hue.
Add an icon, a text label, or both. Pattern: 🔴 Required field is acceptable; just 🔴 on its own is not.
5. Keyboard navigation
Every action that’s possible with a mouse must be possible with the keyboard. Tab order should follow visual order. There must be no “keyboard traps” — places where Tab gets stuck.
Common failures:
- Custom dropdowns that don’t open with Enter or Space
- Modals that don’t trap focus while open
- Skip links missing from the main page
Add a Skip to content link as the first focusable element on every page. Test by Tabbing through your entire app once a sprint.
6. Form labels
Every form input needs a programmatically associated label. placeholder is not a label. aria-label is acceptable when a visual label would be redundant; visible labels are still strongly preferred.
<!-- ✓ Pass -->
<label for="email">Email</label>
<input id="email" type="email" />
<!-- ✗ Fail (placeholder vanishes when typing) -->
<input type="email" placeholder="Email" />7. Headings hierarchy
Pages should have a single h1, then h2 → h3 → h4 in order. Don’t skip levels. Don’t use heading tags for visual styling — use the right semantic level and style with CSS.
Screen readers navigate by heading level. A page with h1 → h3 → h2 is confusing to navigate.
8. Alt text
Every meaningful image needs an alt attribute that describes what the image conveys. Decorative images get alt="" (empty, but present).
Common failures:
alt="image"(says nothing)alt="image of a cat"(when “a cat” suffices)- Missing
altentirely (worst — screen readers will read the file name)
9. Page language
The <html> element must declare a language: <html lang="en">. This isn’t optional. Screen readers use it to pick the right pronunciation engine.
Multi-language pages add lang attributes on the elements that switch language: <span lang="es">hola</span>.
10. Motion
Respect prefers-reduced-motion. If a user has set “reduce motion” at the OS level, your animations should disable or significantly reduce.
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}What’s NOT in this list (because it’s been correct for a decade)
- Don’t trap users in a flash of unstyled content.
- Don’t autoplay audio.
- Don’t use blink/marquee tags. (You’re not, right?)
- Don’t ship pages that fail to load with JavaScript disabled if they don’t have to.
A concrete audit workflow
- Run axe DevTools on every page in your CI pipeline. It catches ~50% of issues automatically.
- For the other 50%, do a manual keyboard-only navigation pass. Disable your mouse for 10 minutes per release.
- Test with a screen reader at least once per quarter. NVDA on Windows or VoiceOver on macOS — both are free.
- Use DevZap’s CSS Inspector on real pages to extract and audit color values.
- Use the Contrast Checker on every brand color × background combination during design review.
WCAG 2.2 AA is a floor, not a ceiling. Hit it. Then care about your users beyond the regulation.
