WCAG 2.2 Audit Checklist

Every image, icon, chart, or other non-text element must have a text alternative that serves the same purpose as the original.

Prerecorded audio (e.g., a podcast clip) needs a transcript. Prerecorded video with no audio (e.g., a silent product demo) needs either a transcript or an audio track.

All prerecorded video that contains audio must have captions. Captions must be synchronised with the audio and include all speech and important non-speech sounds.

Prerecorded video with audio track must have either an audio description (narration of visual information) or a full text alternative describing what is shown.

Live video streams (webinars, live events, broadcasts) must have live captions provided in real time.

At Level AA, audio description (not just a text alternative) is required for all prerecorded video. The full audio description track must be provided.

Visual structure (headings, lists, tables, form groupings) must be conveyed in the code, not just through styling.

When the order of content matters for understanding, the DOM order must reflect the correct reading sequence — not just the visual layout.

Instructions must not rely exclusively on visual cues like shape, color, or position. Include text-based references alongside sensory ones.

Websites and apps must not lock to portrait or landscape. Users with mounted devices (e.g., wheelchair-mounted tablets) may be unable to rotate.

Form fields collecting personal data must have autocomplete attributes so browsers and assistive technologies can autofill them.

Never use color as the only way to communicate something. Always provide a secondary non-color cue.

Audio that auto-plays for more than 3 seconds must be pausable or have independent volume control.

Normal text needs 4.5:1 contrast ratio against its background. Large text (18pt/24px or 14pt/~19px bold) needs 3:1.

Users must be able to zoom to 200% without losing content or functionality.

Use real HTML text instead of images of text wherever technically possible. Images of text cannot be resized, reflowed, or read by screen readers without alt text.

At 320px viewport width (equivalent to 400% zoom on a 1280px screen), all content must be accessible without horizontal scrolling.

The visual boundaries of form fields, buttons, checkboxes, and graphical elements used to understand content must have 3:1 contrast against adjacent colors.

When users override text spacing (line height 1.5×, paragraph spacing 2×, letter spacing 0.12em, word spacing 0.16em), no content should be lost or obscured.

Tooltips and hover popups must be: hoverable (mouse can move over them), dismissible (Escape closes them), and persistent (they stay until explicitly closed).

Everything a mouse user can do, a keyboard user must also be able to do. No functionality should require a mouse.

Keyboard users must never get stuck. Focus must always be escapable. Intentional focus traps in modals are acceptable only if Escape closes the modal.

Single-character keyboard shortcuts (like 'G' to go, 'F' for find) must be disableable or remappable. They conflict with speech input users who dictate text.

Session timeouts, time-limited forms, and timed quizzes must give users a way to turn off, adjust, or extend the time limit.

Moving, blinking, or auto-updating content must have a pause/stop/hide control. This includes carousels, tickers, animated banners, and live feeds.

Content must not flash more than 3 times per second. Flashing content can cause seizures in people with photosensitive epilepsy.

Keyboard users must be able to skip past repeated navigation blocks to reach the main content quickly.

Every page must have a descriptive <title> element that helps users understand what the page is about.

The keyboard Tab order must follow a logical sequence — typically top-to-bottom, left-to-right in Western languages — that preserves meaning.

Link text must be descriptive enough to understand its destination — either from the text alone or from its surrounding context.

Users must have more than one way to find any page on the site (e.g., navigation + site search, or navigation + sitemap).

When headings and form labels are used, they must be descriptive — they need not be comprehensive, but they must accurately describe their associated content.

Keyboard users must always be able to see which element has focus. Never suppress the focus outline completely.

New in WCAG 2.2: sticky headers, cookie banners, and chat bubbles must not completely cover the focused element.

At AAA level: the focused element must be completely visible — not even partially obscured by sticky content.

Level AA (WCAG 2.2): the focus indicator must cover at least a 2 CSS pixel perimeter of the unfocused component and have 3:1 contrast between focused and unfocused states.

Any feature requiring a swipe, pinch, or multi-finger gesture must have an equivalent single-tap or click alternative.

Don't trigger actions on mousedown/touchstart if the user might accidentally tap. Use mouseup/click (which fires on up-event) so users can cancel by moving away.

The accessible name of a button or link must contain the visible text label — this is essential for voice control users who say what they see.

Features that use device shake, tilt, or motion must also be operable via standard UI controls, and motion must be disableable.

New in WCAG 2.2: drag-and-drop must have a click/tap alternative. Sliders must be adjustable without dragging.

New in WCAG 2.2: interactive targets must be at least 24×24 CSS pixels, OR have sufficient spacing between targets.

The <html> element must have a lang attribute set to the page's primary language.

When content switches language (e.g., a French quote in an English article), the language change must be marked with a lang attribute.

Receiving focus must never automatically navigate, submit a form, or launch a popup. Focus changes must be predictable.

Changing a form control (selecting a dropdown option, checking a box) must not automatically navigate or submit without warning.

Navigation menus must appear in the same order on every page. Users with cognitive disabilities rely on consistent placement.

The same function must have the same label everywhere on the site. A search button should not be labelled 'Search' on one page and 'Find' on another.

New in WCAG 2.2: help mechanisms (phone number, live chat, FAQ link) must appear in the same relative position on every page where they appear.

When a form error is detected automatically, the specific field in error must be identified and described in text.

Every form input must have a visible label. Instructions about required format (date format, password rules) must be provided before the input.

Error messages must tell users how to fix the error — not just that an error occurred. Exceptions apply for security-sensitive validations.

High-stakes forms (purchases, legal agreements, exam submissions, data deletion) must let users review, correct, or reverse the action.

New in WCAG 2.2: if users must re-enter data they already provided in the same session, auto-populate it or let them select it from a list.

New in WCAG 2.2: authentication must not require a cognitive-only challenge unless an alternative exists. Password managers and magic links must be supported.

New in WCAG 2.2 (AAA): No authentication step may require a cognitive function test of any kind. Unlike SC 3.3.8, there are no exceptions for object recognition or personal content — all authentication must be cognitive-test-free.

SC 4.1.1 is obsolete in WCAG 2.2 and always passes with modern browsers. It was removed because modern browsers handle malformed HTML gracefully and assistive technologies do not rely on valid HTML parsing.

Every interactive element must expose its name (what it is called), role (what type of control it is), and current state/value to assistive technologies.

Success messages, loading states, result counts, and errors must be announced by screen readers without moving focus to them.