WCAG 2.2 AA: A Practical Accessibility Guide

WCAG 2.2 AA: A Practical Accessibility Guide

The Web Content Accessibility Guidelines (WCAG) are the international standard for accessible web design, maintained by the W3C. This guide covers what designers and developers actually need to meet WCAG 2.2 Level AA - the level most regulations and lawsuits reference - organized as practical rules with a checklist you can ship against.

This is practical guidance based on the published standard, not legal advice. Accessibility law varies by jurisdiction.

The Short Answer

• WCAG has three conformance levels: A (minimum), AA (the standard target), AAA (enhanced, aspirational for most sites).
• The big five for designers: contrast (4.5:1 body text), keyboard operability, visible focus, meaningful sequence and labels, and no information by color alone.
• Test with a keyboard only (no mouse), a screen reader (NVDA on Windows and VoiceOver on macOS are free), and automated checkers - in that order of importance.
• Accessibility is a design constraint from the start, not a QA phase at the end. Retrofitting costs multiples of building it in.

1. The Four Principles (POUR)

WCAG organizes everything under four principles. Content must be:

1. Perceivable - users can sense it with available senses. Text alternatives for images, captions for audio, sufficient contrast, resizable text.
2. Operable - users can use it with available inputs. Keyboard access, enough time, no seizure triggers, navigable structure.
3. Understandable - users can comprehend it. Readable text, predictable behavior, input assistance (labels, error messages).
4. Robust - it works with current and future tools. Valid markup, proper roles and names for custom components.

When a design decision is unclear, run it through POUR: can everyone perceive, operate, understand it, and does it work with assistive technology?

2. Contrast: The Numbers

What counts as "large text": 18pt (24px) and up, or 14pt (18.66px) bold and up. Note WCAG uses points; CSS pixels at 1pt = 1.333px.

Common failures and fixes:

• Secondary/muted text. The most common failure on the modern web. If it is content, it needs 4.5:1. Use our contrast checker to verify pairs.
• Placeholder text. Almost always too light, and it disappears on input. Always use visible labels.
• Disabled controls are exempt from the contrast requirement - but "disabled-looking" styles on enabled content are not.
• Text over images. Check the worst-case area behind the text; add a scrim when the background varies.

Our accessible color systems guide covers building palettes that pass from the start, and the chart color accessibility checklist covers data graphics.

3. Keyboard Navigation

Everything interactive must work without a mouse:

• Tab order follows the visual/logical order. If the tab order jumps around the page, fix the DOM order - do not patch it with tabindex values.
• All functionality available. Menus, sliders, carousels, modals, custom dropdowns - if it works with a mouse, it must work with a keyboard.
• No keyboard traps. A user must be able to tab into and out of every component. (Modals are the exception: focus stays inside while open, and Escape closes them.)
• Skip links. Provide a "skip to main content" link as the first tab stop on content-heavy pages.
• Visible focus indicators. Every keyboard-focusable element needs a visible focus style. Never remove outlines without providing an equivalent. :focus-visible lets you show focus rings for keyboard users without cluttering mouse clicks:

:focus-visible {
  outline: 3px solid var(--color-primary-600);
  outline-offset: 2px;
}

Test: unplug the mouse (or just do not touch it) and complete the site's core flows with Tab, Shift+Tab, Enter, Space, Escape, and arrow keys.

4. Semantics and Structure

• One h1 per page, headings in logical order (no jumping from h1 to h4). Screen reader users navigate by headings.
• Landmarks: header, nav, main, footer - these let assistive technology jump between page regions.
• Real controls, not divs. Use <button> for buttons, <a> for links, <input> with <label> for fields. Custom div-buttons need roles, keyboard handlers, and focus management reimplemented by hand - use the native element instead.
• Lists as lists. Navigation, breadcrumbs, and grouped items marked up as lists convey structure to screen readers.
• Tables as tables. Data tables need proper <th> headers with scope; layout tables are a relic - use CSS.

5. Images, Media, and Motion

• Informative images need alt text describing the content and function. Decorative images get empty alt (alt="") so screen readers skip them.
• Complex images (charts, diagrams) need a text alternative conveying the same information - a nearby data table or description.
• Video needs captions for dialogue and audio descriptions (or a transcript) for important visual information.
• No auto-playing audio. If media auto-plays, provide an immediate way to pause, stop, or mute.
• Seizure safety: no content flashes more than three times per second.
• Motion: honor prefers-reduced-motion - provide a reduced or static alternative for significant animation.

6. Forms: The Accessibility Gauntlet

Forms concentrate nearly every accessibility requirement:

• Every input has a visible, programmatically associated label (<label for="...">). Placeholder is not a label.
• Required fields indicated by more than color - text like "required" or a symbol explained in text.
• Errors described in text, associated with the field (aria-describedby), and announced. Summarize form-level errors at the top with links to each field.
• Instructions provided before the input when the format matters ("Date as MM/DD/YYYY" or, better, separate fields).
• No timeouts without warning and a way to extend - or avoid session timeouts on forms entirely.

7. The Ship Checklist

Run this before every release:

• Keyboard-only pass: all core flows completable without a mouse
• Focus visible on every interactive element
• No keyboard traps; modals trap-and-release correctly with Escape
• Contrast: 4.5:1 body text, 3:1 large text and UI components (spot-check, do not assume)
• All images have appropriate alt (informative) or empty alt (decorative)
• Headings in logical order; landmarks present
• Forms: labels, error association, required-field marking beyond color
• No information conveyed by color alone
• prefers-reduced-motion honored; no flashing content
• Screen reader spot-check of key flows (NVDA/VoiceOver are free)
• Automated checker run (axe, Lighthouse, or WAVE) - as a supplement, not a substitute

Automated tools catch roughly a quarter to a third of issues. They are useful; they are not a compliance verdict.

8. Testing Tools and Workflow

Automated checkers (use all of them as supplements, none as verdicts):

• axe DevTools (browser extension) - the most thorough automated checker; integrates into development workflow.
• Lighthouse accessibility audit (built into Chrome DevTools) - quick, catches the basics.
• WAVE (browser extension) - visual overlay showing errors directly on the page; excellent for designers.

Manual testing (where real compliance is determined):

• Keyboard-only pass - Tab through every flow. This single test catches the most severe issues automated tools miss.
• Screen reader pass - NVDA (free, Windows) or VoiceOver (built into macOS/iOS). Listen to the page: does the heading structure make sense? Are form errors announced? Do custom components expose their state?
• Zoom and reflow - 200% browser zoom and 400% zoom: content must reflow without horizontal scrolling or overlap (WCAG 1.4.10).
• Color-blind simulation - DevTools can emulate vision deficiencies; verify that color-coded information survives.

Workflow that works. Run axe during development (catch issues at creation), do a keyboard pass per feature (catch interaction issues), and schedule a full manual audit - keyboard, screen reader, zoom - before major releases. Log findings as bugs with the same severity as functional defects, because for affected users, they are.

Frequently Asked Questions

What is the difference between WCAG 2.1 and 2.2? WCAG 2.2 (published October 2023) adds nine success criteria to 2.1, including focus appearance minimums, dragging-movement alternatives, and consistent help. If you were compliant with 2.1 AA, review the new 2.2 criteria - particularly target size minimums (24x24 CSS pixels) and focus visibility.

Is WCAG legally required? It depends on jurisdiction and sector. In the US, the ADA has been applied to websites through case law; the EU's Accessibility Act references EN 301 549 (which incorporates WCAG AA). Treat AA as the baseline regardless - it is also just good design.

What is the difference between AA and AAA? AA is the standard target: achievable for most content. AAA adds stricter requirements (7:1 contrast, sign-language video, no background audio) that are not achievable for all content types. Aim for AA everywhere; adopt AAA criteria where practical.

Can automated tools certify compliance? No. They catch mechanical issues (missing alt, contrast failures, structural problems) but cannot judge meaning, keyboard logic, or whether alternatives are equivalent. Manual testing with keyboard and screen reader is required.

Where do I start on an existing inaccessible site? In impact order: keyboard operability (nothing else matters if people cannot operate the site), contrast on body text, form labels and errors, heading structure and landmarks, then alt text and media alternatives.

Continue Reading

• Accessible Color Systems Guide - palettes that pass contrast
• Chart Color Accessibility Checklist - accessible data visualization
• Building a Design System from Scratch - baking accessibility into components