---
title: "Designing for WCAG 2.2 AA in 2026: The Practical Checklist"
description: "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."
url: https://devzap.io/blog/wcag-2-2-aa-2026/
published: 2026-04-22T00:00:00.000Z
updated: 2026-04-22T00:00:00.000Z
category: seo-performance
tags: ["accessibility", "wcag", "a11y", "design-systems", "css"]
author: marco
---

# 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.

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](/tools/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.

```css
: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.

```html
<!-- ✓ 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 `alt` entirely (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.

```css
@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

1. Run [axe DevTools](https://www.deque.com/axe/) on every page in your CI pipeline. It catches ~50% of issues automatically.
2. For the other 50%, do a manual keyboard-only navigation pass. Disable your mouse for 10 minutes per release.
3. Test with a screen reader at least once per quarter. NVDA on Windows or VoiceOver on macOS — both are free.
4. Use [DevZap's CSS Inspector](/features/css-inspector/) on real pages to extract and audit color values.
5. Use the [Contrast Checker](/tools/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.