Reference

WCAG 2.2 explained — 56 success criteria in plain English.

The Web Content Accessibility Guidelines are the technical standard accessibility audits are scored against. This page covers every WCAG 2.1 Level A + AA criterion plus the 6 additions from WCAG 2.2 — 56 in total — with one-line plain-English summaries of what each one tests for.

The POUR principles

WCAG organises its 78 success criteria under four principles — the “POUR” mnemonic. Every criterion fits into one bucket:

Perceivable — users can see/hear/feel the content (text alternatives, captions, contrast).
Operable — users can interact with the controls (keyboard access, no seizure-inducing flashes, time limits).
Understandable — users can comprehend the content + the UI (language declarations, predictable behaviour, error help).
Robust — assistive tech can parse the markup (semantic HTML, accessible names + roles + states).

The list below is grouped by these four buckets. ClearShield’s VPAT/ACR/EAA reports use the same grouping.

Level A vs Level AA

WCAG criteria come in three conformance levels:

Level A — the absolute minimum. Failing these blocks entire categories of users from using your site.
Level AA — the practical bar for most regulations: Section 508, ADA, EAA. Most accessibility lawsuits cite AA failures.
Level AAA — the highest tier. Not required by most regulations and often impractical for general-purpose websites.

ClearShield audits Level A + AA by default (the regulatory bar). AAA is out of scope — reach out if you need it covered.

WCAG 2.1 vs 2.2

WCAG 2.2 (published October 2023) adds 6 new criteria on top of WCAG 2.1, mostly addressing mobile / touch / cognitive accessibility:

2.4.11 Focus Not Obscured — sticky headers can’t hide focused elements
2.5.7 Dragging Movements — non-drag alternatives
2.5.8 Target Size — minimum 24×24px tappable targets
3.2.6 Consistent Help — help mechanisms in consistent locations
3.3.7 Redundant Entry — don’t re-ask for known info
3.3.8 Accessible Authentication — no cognitive puzzles for login

The EU EAA and US Section 508 currently reference WCAG 2.1; WCAG 2.2 is forward-compatible. ClearShield audits against both so reports stay valid as regulations adopt 2.2.

Perceivable

Users can see, hear, or feel the content.

1.1.1Non-text ContentLevel A
Every image, icon, and non-text element has a text description that a screen reader can read aloud.
1.2.1Audio-only and Video-only (Prerecorded)Level A
Audio-only and video-only recordings have a text transcript or audio description.
1.2.2Captions (Prerecorded)Level A
Pre-recorded videos have synchronised captions for the audio.
1.2.3Audio Description or Media AlternativeLevel A
Pre-recorded videos have an audio description of important visual content (or a text alternative).
1.2.4Captions (Live)Level AA
Live videos (e.g. webinars) have real-time captions.
1.2.5Audio Description (Prerecorded)Level AA
Pre-recorded videos have audio description of all important visual info.
1.3.1Info and RelationshipsLevel A
The visual structure of the page (headings, lists, tables, form fields) is encoded so a screen reader can navigate by it.
1.3.2Meaningful SequenceLevel A
Content reads in a meaningful order when CSS is disabled — screen readers follow the DOM order.
1.3.3Sensory CharacteristicsLevel A
Instructions don't rely only on sensory characteristics like "the button on the right" or "the green box".
1.3.4OrientationLevel AA
Content works in both portrait and landscape orientation.
1.3.5Identify Input PurposeLevel AA
Common form fields (name, email, phone) have programmatically identifiable input purposes so browsers can autofill.
1.4.1Use of ColorLevel A
Color is never the only way information is conveyed (e.g. error fields also have a text label, not just a red border).
1.4.2Audio ControlLevel A
Audio that auto-plays for more than 3 seconds has a way to pause or stop.
1.4.3Contrast (Minimum)Level AA
Text has at least a 4.5:1 contrast ratio against its background (3:1 for large text).
1.4.4Resize TextLevel AA
Text can be resized up to 200% without breaking the layout or hiding content.
1.4.5Images of TextLevel AA
Images of text are only used for decorative purposes or logos — real text is preferred everywhere else.
1.4.10ReflowLevel AA
Content reflows to fit narrow viewports (320 CSS pixels) without horizontal scrolling.
1.4.11Non-text ContrastLevel AA
UI components (buttons, form fields, icons) have at least 3:1 contrast against their surroundings.
1.4.12Text SpacingLevel AA
Text remains readable when users override line-height, paragraph spacing, letter spacing, and word spacing.
1.4.13Content on Hover or FocusLevel AA
Content that appears on hover or focus (tooltips, dropdowns) is dismissible, hoverable, and persistent.

Operable

Users can interact with the controls without barriers.

2.1.1KeyboardLevel A
Every interactive element is reachable and operable with the keyboard alone.
2.1.2No Keyboard TrapLevel A
Keyboard focus never gets trapped inside a widget — you can always tab out.
2.1.4Character Key ShortcutsLevel A
Character-key shortcuts (single-key hotkeys) can be turned off or remapped, so users with speech input aren't broken.
2.2.1Timing AdjustableLevel A
Users can extend, adjust, or disable time limits on the page.
2.2.2Pause, Stop, HideLevel A
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
2.3.1Three Flashes or Below ThresholdLevel A
No content flashes more than 3 times per second (seizure risk).
2.4.1Bypass BlocksLevel A
A "Skip to main content" link or similar mechanism lets keyboard users bypass repeated navigation.
2.4.2Page TitledLevel A
Every page has a unique, descriptive <title>.
2.4.3Focus OrderLevel A
Focus moves through the page in a logical order (matches the visual layout).
2.4.4Link Purpose (In Context)Level A
Every link's purpose is clear from the link text or its surrounding context.
2.4.5Multiple WaysLevel AA
Multiple ways exist to find any page (nav menu, search, sitemap, etc).
2.4.6Headings and LabelsLevel AA
Headings and form labels accurately describe what they introduce.
2.4.7Focus VisibleLevel AA
Keyboard focus is always visibly indicated (e.g. a visible outline on the focused element).
2.5.1Pointer GesturesLevel A
Multi-finger gestures (pinch, swipe) have a single-pointer alternative.
2.5.2Pointer CancellationLevel A
Click actions are triggered on release, not on press — so users can drag off to cancel.
2.5.3Label in NameLevel A
A button's accessible name (read by screen readers) includes the visible label text.
2.5.4Motion ActuationLevel A
Functions triggered by device motion (shake to undo, etc) have an alternative input method.
2.4.11Focus Not Obscured (Minimum)Level AA
When a user focuses an element, it isn't fully hidden by another element (like a sticky header).
2.5.7Dragging MovementsLevel AA
Functions that require dragging have an alternative single-pointer method.
2.5.8Target Size (Minimum)Level AA
Interactive targets (buttons, links) are at least 24×24 CSS pixels (or have enough spacing around them).

Understandable

Users can comprehend the content and the UI behaviour.

3.1.1Language of PageLevel A
The page declares its primary language (e.g. <html lang="en">).
3.1.2Language of PartsLevel AA
Inline foreign-language passages are marked with their language so screen readers pronounce them correctly.
3.2.1On FocusLevel A
Focusing an element doesn't cause unexpected navigation or context changes.
3.2.2On InputLevel A
Changing a form input doesn't cause unexpected navigation or context changes.
3.2.3Consistent NavigationLevel AA
Navigation elements are in the same relative order across pages.
3.2.4Consistent IdentificationLevel AA
Things that do the same job are labeled consistently (a "Search" button is always called "Search").
3.3.1Error IdentificationLevel A
Form errors identify the field and explain the problem.
3.3.2Labels or InstructionsLevel A
Form fields have visible labels or instructions.
3.3.3Error SuggestionLevel AA
When errors occur, suggestions for fixing them are provided where known.
3.3.4Error Prevention (Legal, Financial, Data)Level AA
Forms with legal / financial / data-deletion consequences are reversible, checked, or confirmable.
3.2.6Consistent HelpLevel A
Help mechanisms (contact info, FAQ link) appear in the same place across pages where they exist.
3.3.7Redundant EntryLevel A
Information the user already entered in a session isn't requested again unless essential.
3.3.8Accessible Authentication (Minimum)Level AA
Authentication doesn't depend on remembering a password, transcribing a CAPTCHA, or performing a calculation (unless an alternative is offered).

Robust

Assistive technology can reliably parse the content.

4.1.1Parsing (Obsolete in WCAG 2.2)Level A
HTML parses cleanly with no nested/unclosed tag errors. (Obsolete in WCAG 2.2 — modern browsers handle this; kept for back-compat.)
4.1.2Name, Role, ValueLevel A
Every UI component exposes its name, role, and state to assistive technology.
4.1.3Status MessagesLevel AA
Status messages (e.g. "Saved", "3 results found") are announced by screen readers without stealing focus.

Scan your site against all 56 criteria.

ClearShield maps every WCAG SC to an axe-core rule and renders the verdict in a printable conformance report.

Start a free scan

All docs