Standards · WCAG 2.2
WCAG 2.2 success criteria
All 86 success criteria from WCAG 2.2 — 31 at level A, 24 at AA, 31 at AAA. 9 were added in 2.2; 17 in 2.1; 60 carry over from 2.0. Each entry has a plain-language summary, how-to-meet notes, and the failures we see most often in production audits.
1. Perceivable
Information and UI components must be presentable to users in ways they can perceive.
- 1.1.1 A
Non-text Content
Every image, icon, chart, audio file, and other non-text component must have a text alternative that serves the same purpose — so screen-reader, braille, and switch users get the same information sighted users do.
- 1.2.1 A
Audio-only and Video-only (Prerecorded)
Prerecorded audio needs a text transcript. Prerecorded silent video needs either a text description or an audio track that conveys the same information — so users who can't hear or can't see still get the content.
- 1.2.2 A
Captions (Prerecorded)
Every prerecorded video with audio needs synchronized captions covering dialogue, speaker identification, and meaningful non-speech sounds — so deaf and hard-of-hearing users get the same information from the soundtrack as everyone else.
- 1.2.3 A
Audio Description or Media Alternative (Prerecorded)
Prerecorded video needs either an audio description track or a full text alternative for any visual information that isn't conveyed by the soundtrack — so blind users get the same content as sighted viewers.
- 1.2.4 AA
Captions (Live)
Live audio in synchronized media — webinars, live streams, virtual events — must carry real-time captions. Auto-captions can qualify if accuracy is high enough, but professional CART captioning is the safe bet.
- 1.2.5 AA
Audio Description (Prerecorded)
Prerecorded video needs an audio description track that narrates important visual information during natural pauses in dialogue. At AA, a text transcript alone is no longer enough — the description must be in audio form.
- 1.2.6 AAA
Sign Language (Prerecorded)
Prerecorded audio in synchronized media gets a sign-language interpretation. Captions are not a substitute — many Deaf users have sign as a first language and English as a second.
- 1.2.7 AAA
Extended Audio Description (Prerecorded)
When pauses in dialogue aren't long enough to fit a standard audio description, the video must pause to let extended description play — so blind users get the full visual context even in dense, fast-paced content.
- 1.2.8 AAA
Media Alternative (Prerecorded)
Prerecorded synchronized media — and prerecorded video-only — needs a complete text alternative that conveys all the same information. Goes beyond captions and audio description: a full standalone document.
- 1.2.9 AAA
Audio-only (Live)
Live audio-only content — radio streams, audio-only conference calls, live podcasts — needs a real-time text alternative such as live captioning so deaf and hard-of-hearing users get the content as it happens.
- 1.3.1 A
Info and Relationships
Information and relationships conveyed visually — headings, lists, tables, form labels, groupings — must also be expressed in the markup, so assistive technology can render them. Visual styling alone is not enough.
- 1.3.2 A
Meaningful Sequence
When the reading order of content matters for understanding, the DOM order must match the visual order. CSS positioning and float that scramble the sequence break screen readers and keyboard navigation.
- 1.3.3 A
Sensory Characteristics
Instructions must not rely solely on shape, size, location, orientation, sound, or color. "Click the green button on the right" excludes users who can't see the layout or distinguish color.
- 1.3.4 AA
Orientation
Content must not be locked to a single orientation — portrait or landscape — unless that orientation is essential. Users mounted to a wheelchair or holding a phone in a fixed grip can't rotate the device.
- 1.3.5 AA
Identify Input Purpose
Form fields that collect common personal information — name, email, phone, address, credit card — must declare their purpose programmatically using the HTML autocomplete attribute. This lets browsers autofill and assistive tools customize the UI.
- 1.3.6 AAA
Identify Purpose
Beyond form fields, the purpose of UI components, icons, and regions must be programmatically identifiable — so adaptive technologies can swap in symbols, simplify the page, or hide non-essential parts.
- 1.4.1 A
Use of Color
Color must not be the only way information is conveyed. Required fields, error states, link distinctions, chart series — all need a second cue (text, icon, underline, pattern) so color-blind users get the same information.
- 1.4.2 A
Audio Control
Any audio that plays automatically for more than three seconds must have a pause, stop, or volume control independent of the system volume — so it doesn't drown out screen-reader speech.
- 1.4.3 AA
Contrast (Minimum)
Body text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+, or 14pt+ bold) needs 3:1. Logos and decorative text are exempt.
- 1.4.4 AA
Resize text
Text must remain readable and usable when zoomed up to 200% without loss of content or functionality. Captions and images of text are exempt.
- 1.4.5 AA
Images of Text
Text should be implemented as actual text, not as a rasterized image, unless the image is essential (a logo, a screenshot of a UI being discussed) or fully customizable.
- 1.4.6 AAA
Contrast (Enhanced)
AAA-level contrast: 7:1 for body text, 4.5:1 for large text. Stricter than 1.4.3, intended for users with significant low vision who need higher contrast to read comfortably.
- 1.4.7 AAA
Low or No Background Audio
For prerecorded audio that is primarily speech, background sounds must be at least 20 dB below the foreground speech, or absent, or pausable — so users with hearing loss can follow the dialogue.
- 1.4.8 AAA
Visual Presentation
For blocks of text, users must be able to control foreground/background color, line width (max 80 characters), justification (no full-justify), line spacing (1.5x), and paragraph spacing (1.5x line height) — without horizontal scrolling at 200% zoom.
- 1.4.9 AAA
Images of Text (No Exception)
AAA-level: images of text are not allowed at all, except logos and essential cases (a screenshot demonstrating typography). The 1.4.5 "customizable" exception is removed.
- 1.4.10 AA
Reflow
Content must reflow into a single column at 320 CSS pixels wide (vertical scrolling content) or 256 pixels tall (horizontal scrolling content) without loss of information or functionality. No two-directional scrolling.
- 1.4.11 AA
Non-text Contrast
UI components (button borders, form-field outlines, focus indicators, icon-only controls) and meaningful graphical elements (chart series, status icons) must have at least 3:1 contrast against adjacent colors.
- 1.4.12 AA
Text Spacing
When users override text spacing — line height 1.5x, paragraph spacing 2x font size, letter spacing 0.12em, word spacing 0.16em — the page must not lose content or functionality.
- 1.4.13 AA
Content on Hover or Focus
Tooltips, popovers, and other content that appears on hover or focus must be dismissible, hoverable (so users can move the pointer into them), and persistent (they don't disappear until the user dismisses or the trigger loses focus).
2. Operable
UI components and navigation must be operable by everyone.
- 2.1.1 A
Keyboard
Every function on the page must be operable from a keyboard alone — no required mouse moves, drags, or specific timings. Screen-reader, switch, and voice-control users all depend on this baseline.
- 2.1.2 A
No Keyboard Trap
If keyboard focus can move to a component, focus must also be able to move away from it using only the keyboard. Modals, embeds, and custom widgets are the usual offenders.
- 2.1.3 AAA
Keyboard (No Exception)
Same as 2.1.1 Keyboard, but without the path-dependent exception. Every function — including freehand drawing and signature capture — must have a keyboard-operable equivalent.
- 2.1.4 A
Character Key Shortcuts
Single-character keyboard shortcuts (a single letter, number, or symbol) must be turnable off, remappable, or active only when the relevant component has focus. Protects voice-control and dictation users from accidental triggers.
- 2.2.1 A
Timing Adjustable
Any time limit imposed by the content must be turn-off-able, adjustable to at least ten times the default, or extendable by the user with at least 20 seconds' warning. Session timeouts and quiz timers are the main targets.
- 2.2.2 A
Pause, Stop, Hide
Moving, blinking, scrolling, or auto-updating content that lasts more than five seconds must be pausable, stoppable, or hideable by the user. Covers carousels, marquees, news tickers, animated ads, and auto-refreshing feeds.
- 2.2.3 AAA
No Timing
Time limits are not part of the content at all, except for non-interactive real-time events. Stricter than 2.2.1 — there is no warning-and-extend fallback.
- 2.2.4 AAA
Interruptions
Interruptions — pop-ups, notifications, alerts, auto-updates — must be postponable or suppressible by the user, except for those involving an emergency.
- 2.2.5 AAA
Re-authenticating
When an authenticated session expires, the user must be able to continue without losing any data they had already entered. The session ends, but the work in progress doesn't.
- 2.2.6 AAA
Timeouts
Users must be warned about any inactivity timeout that could cause data loss, unless the data is preserved for more than 20 hours of inactivity.
- 2.3.1 A
Three Flashes or Below Threshold
Nothing on the page may flash more than three times per second, unless the flash is below defined size and contrast thresholds. Designed to prevent photosensitive seizures.
- 2.3.2 AAA
Three Flashes
Nothing on the page may flash more than three times per second — full stop. Removes the size and threshold exceptions allowed by 2.3.1.
- 2.3.3 AAA
Animation from Interactions
Motion animation triggered by interaction can be disabled by the user, unless the animation is essential. Honour the `prefers-reduced-motion` media query.
- 2.4.1 A
Bypass Blocks
Provide a way for keyboard and screen-reader users to skip over content that repeats on every page — typically the header, primary nav, and utility links — so they can reach the main content without tabbing through dozens of links.
- 2.4.2 A
Page Titled
Every page must have a `<title>` that describes its topic or purpose. The title is what screen readers announce on page load and what users see in tabs, bookmarks, history, and search results.
- 2.4.3 A
Focus Order
When users tab through a page, the focus order must follow a sequence that preserves meaning and operability — usually the visual reading order. A scrambled tab sequence is functionally broken even if every individual control works.
- 2.4.4 A
Link Purpose (In Context)
The purpose of every link must be clear from its text, or from the link text combined with its surrounding context — the sentence, list item, table cell, or paragraph it sits in. Screen-reader users often hear links out of context, in a links list.
- 2.4.5 AA
Multiple Ways
Users must have more than one way to locate a page within a set — typically a combination of navigation menu, search, sitemap, table of contents, or related-pages list. The exception is pages that are steps in a process (checkout, multi-step forms).
- 2.4.6 AA
Headings and Labels
Headings and form labels must describe the topic or purpose of the content they introduce. They don't have to be unique, but they do have to be informative — a heading that reads 'Information' or a label that reads 'Field' fails this SC.
- 2.4.7 AA
Focus Visible
Any keyboard-operable interface must have a visible focus indicator on the currently-focused element. If a user can't see where keyboard focus is, they can't use the site by keyboard — full stop. One of the most-cited SCs in audits.
- 2.4.8 AAA
Location
Users must be able to tell where they are within a set of pages — typically via breadcrumbs, a current-page indicator in the navigation, or a site map that highlights the active section.
- 2.4.9 AAA
Link Purpose (Link Only)
The stricter AAA version of 2.4.4: the link text alone — no surrounding context — must identify the destination. 'Read more' fails even if the sentence above it explains. Designed for screen-reader users navigating via the links list.
- 2.4.10 AAA
Section Headings
Use headings to organise content. Where a page has distinct sections, each section needs a real heading element (`<h1>`–`<h6>`) — not styled paragraphs that just look like headings.
- 2.4.11 AA New 2.2
Focus Not Obscured (Minimum)
When an element receives keyboard focus, it must not be entirely hidden behind another piece of UI — sticky headers, cookie banners, chat widgets, sticky footers. New in WCAG 2.2 and reshaping how teams build sticky chrome.
- 2.4.12 AAA New 2.2
Focus Not Obscured (Enhanced)
Stricter AAA version of 2.4.11: when an element receives focus, no part of it may be obscured by other content. New in WCAG 2.2.
- 2.4.13 AAA New 2.2
Focus Appearance
The keyboard focus indicator must meet a measurable visual bar: at least 2 CSS pixels thick around the perimeter, at least 3:1 contrast against its previous unfocused state, and not obscured. New in WCAG 2.2; the most concrete focus-styling rule the spec has ever published.
- 2.5.1 A
Pointer Gestures
Any function that uses a multi-point or path-based gesture — pinch-zoom, two-finger rotate, swipe to delete — must also be operable with a single-point activation that does not require a path.
- 2.5.2 A
Pointer Cancellation
Functions triggered by a single pointer must fire on the up-event, not the down-event — so users can drag away to abort. Abort, undo, or pre-activation cancel must be available unless instant activation is essential.
- 2.5.3 A
Label in Name
When a control has visible text, that exact text must appear at the start of its accessible name. Otherwise voice-control users who say what they see cannot activate the control.
- 2.5.4 A
Motion Actuation
Functions triggered by device motion or user motion — shaking, tilting, gesturing in front of a camera — must also be operable through standard UI controls, and motion-triggering must be possible to disable.
- 2.5.5 AAA
Target Size (Enhanced)
Interactive targets should be at least 44×44 CSS pixels. This is the AAA-level enhanced target-size requirement; the AA-level 2.5.8 floor is 24×24.
- 2.5.6 AAA
Concurrent Input Mechanisms
Web content must not restrict use of input modalities available on the platform — except where the restriction is essential, required to secure content, or required to respect user settings.
- 2.5.7 AA New 2.2
Dragging Movements
Any function that uses a dragging movement must also be operable with a single-pointer action that does not require dragging — usually a tap or click. New in WCAG 2.2.
- 2.5.8 AA New 2.2
Target Size (Minimum)
Interactive targets — buttons, links, form controls — must be at least 24×24 CSS pixels, unless an equivalent target on the same page is large enough or the target is in a sentence. New in WCAG 2.2.
3. Understandable
Information and the operation of the user interface must be understandable.
- 3.1.1 A
Language of Page
Set the default human language of every page programmatically — usually with the lang attribute on the html element. Screen readers, braille displays, and translation tools use this to choose pronunciation rules, voice profiles, and character mappings.
- 3.1.2 AA
Language of Parts
When a passage or phrase on the page is in a different language from the page default, mark it with a lang attribute on its container — so screen readers switch voice and pronunciation for that fragment.
- 3.1.3 AAA
Unusual Words
Provide a mechanism for identifying definitions of words used in an unusual or restricted way — jargon, idioms, technical terms. A glossary, inline definitions, or linked definitions all satisfy this AAA criterion.
- 3.1.4 AAA
Abbreviations
Provide a mechanism for identifying the expanded form or meaning of abbreviations. Spelling out on first use, an abbr element with a title, or a linked glossary all satisfy this AAA criterion.
- 3.1.5 AAA
Reading Level
When content requires reading ability beyond a lower-secondary education level, provide a simpler alternative — a plain-language version, a summary, or supplementary materials such as illustrations or audio.
- 3.1.6 AAA
Pronunciation
When the meaning of a word depends on its pronunciation and the correct pronunciation is not obvious from context, provide a mechanism that exposes the pronunciation — phonetic spelling, audio, or a linked guide.
- 3.2.1 A
On Focus
When any user-interface component receives focus, it must not initiate a change of context — no automatic page navigation, no new window, no major content shift. Focus is for orientation, not for action.
- 3.2.2 A
On Input
Changing the setting of any user-interface component must not automatically cause a change of context, unless the user has been warned in advance. Selecting a value should not silently navigate, submit, or reflow the page.
- 3.2.3 AA
Consistent Navigation
Navigational mechanisms repeated across pages — primary nav, footer, breadcrumbs, search — must appear in the same relative order on every page where they occur. Users who rely on muscle memory should not have to rediscover the layout each time.
- 3.2.4 AA
Consistent Identification
Components with the same functionality across a site must be identified consistently — same label, same icon, same accessible name. Two buttons that do the same thing should not be called Search on one page and Find on another.
- 3.2.5 AAA
Change on Request
Changes of context happen only when the user requests them, or the user can turn off the automatic change. No auto-redirect, no surprise refresh, no carousel that swaps content under the cursor.
- 3.2.6 A New 2.2
Consistent Help
If a page offers help mechanisms — contact details, a help link, a chatbot, a self-service form — they must appear in the same relative order across every page where they are present. New in WCAG 2.2.
- 3.3.1 A
Error Identification
When the user makes a form error that is automatically detected, the error must be identified and described to the user in text — not by colour alone, not by an icon alone, not by silence.
- 3.3.2 A
Labels or Instructions
Every form control that requires user input must have a label or instruction telling the user what to enter. Placeholder-only fields, icon-only inputs, and bare boxes are not enough.
- 3.3.3 AA
Error Suggestion
When an input error is detected and a correction is known to the system, the system must offer a suggestion to the user — unless doing so would compromise security or invalidate the purpose of the input.
- 3.3.4 AA
Error Prevention (Legal, Financial, Data)
For submissions with legal commitments, financial transactions, or significant changes to user data, the user must be able to reverse the submission, have it checked for errors with a chance to correct, or confirm it explicitly before it takes effect.
- 3.3.5 AAA
Help
Context-sensitive help is available for forms and user inputs that require it. Help can include format examples, on-page hints, linked guidance, or a contact mechanism.
- 3.3.6 AAA
Error Prevention (All)
For any user submission — not just legal, financial, or data-changing ones — the user must be able to reverse, check, or confirm before the submission takes effect. The AAA generalisation of 3.3.4.
- 3.3.7 A New 2.2
Redundant Entry
Information the user already supplied in the same session must not be required again — it should be auto-populated or selectable from a list, unless re-entry is essential (e.g. confirming a password). New in WCAG 2.2.
- 3.3.8 AA New 2.2
Accessible Authentication (Minimum)
Authentication must not require the user to solve a cognitive function test — remembering, transcribing, identifying objects — unless an alternative or a mechanism to assist is provided. Passwords, image CAPTCHAs, and copy-the-code-from-email flows are the common failures. New in WCAG 2.2.
- 3.3.9 AAA New 2.2
Accessible Authentication (Enhanced)
Authentication must not require any cognitive function test, even object recognition or personal-content identification. The AAA upgrade of 3.3.8 — passkeys, biometrics, and device-bound credentials become the practical paths. New in WCAG 2.2.
4. Robust
Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
- 4.1.2 A
Name, Role, Value
Every UI component must expose a name, a role, and — where applicable — a value and state, programmatically. Without this, screen readers, voice control, and switch devices cannot identify or operate the control.
- 4.1.3 AA
Status Messages
Status messages — confirmations, errors, progress updates, search results counts — must be announced to assistive technology without moving focus. Use role=status, role=alert, or aria-live on a region that already exists in the DOM.
No success criteria match your filters.