WCAG 2.2 quick reference

Every WCAG 2.2 success criterion translated into plain English, with a concrete example of how it typically fails, who it affects, and the ExceedAbility tools and services that address it. Australian-aligned. No signup, no paywall.

Use this page as the one-stop look-up when a criterion comes up in an audit, a design review, a procurement spec or a piece of writing. Each criterion has a stable URL anchor. Link to /wcag-quick-reference.html#sc-1-4-3 from anywhere on the site.

All 86 WCAG 2.2 success criteria covered.
Quick answer

How many WCAG 2.2 criteria are there?

WCAG 2.2 has 86 active success criteria organised under four principles (Perceivable, Operable, Understandable, Robust) across three conformance levels (A, AA, AAA). Most Australian organisations target Level AA, which means meeting all Level A and AA criteria, 55 in total. Each criterion below has a plain-English explanation, a typical failure example, who it affects, and the ExceedAbility tools and services that address it. No signup, no paywall.

Where do you fit in?

Jump to the tools, services and persona paths that match how you'll use these criteria.

Designer

I'm reviewing a design

Inclusive flows, accessible visual systems, focus states.

Open the designer path →
Developer

I'm in a code review

Semantic HTML, keyboard support, ARIA only when needed.

Open the developer path →
Audit

I'm preparing for an audit

Independent WCAG 2.2 audits with severity ratings and remediation guidance.

See Audit and Compliance →
Remediation

I have findings to fix

Web and document remediation at consistent quality and predictable turnaround.

See remediation services →
Level
Principle
1.1.1

Non-text Content

Level A Perceivable Since WCAG 2.0
Plain English
Every image, icon, chart or other non-text element must have a text alternative that describes its purpose, so people who cannot see it (or whose tools cannot render it) still get the meaning.
Typical failure
Images uploaded to a CMS with no alt attribute, alt="image", alt="picture123.jpg", or decorative graphics that screen readers announce as "graphic, graphic, graphic" because alt="" was never set.
Affects
1.2.1

Audio-only and Video-only (Prerecorded)

Level A Perceivable Since WCAG 2.0
Plain English
Provide a transcript for audio-only content like podcasts, and provide either an audio track or a full text description for video-only content like silent demos or animations. People who cannot hear or cannot see still need to access the information.
Typical failure
A podcast episode published with no transcript. A silent product walkthrough video showing only screen recordings with no companion description. An audio-only interview with no written version available for download.
1.2.2

Captions (Prerecorded)

Level A Perceivable Since WCAG 2.0
Plain English
Synchronised captions must be provided for prerecorded video with audio. Captions let people who are deaf or hard of hearing follow dialogue, identify speakers, and pick up important non-speech sounds like alarms or laughter.
Typical failure
A homepage hero video that auto-plays with no captions. Captions that are present but only contain auto-generated speech-to-text with no speaker labels or sound effects. Burnt-in captions that disappear when the user resizes or zooms the video.
1.2.3

Audio Description or Media Alternative (Prerecorded)

Level A Perceivable Since WCAG 2.0
Plain English
Prerecorded video with synchronised audio must include either an audio description that narrates what is happening visually, or a full text alternative that conveys the same information. People who cannot see the video still need the visual content.
Typical failure
A safety training video where on-screen text and visual demonstrations are critical to the message but are never described aloud or in a transcript. A product explainer where the narrator says "as you can see here" without describing what is on screen.
Affects
1.2.4

Captions (Live)

Level AA Perceivable Since WCAG 2.0
Plain English
Live audio in synchronised media, such as live-streamed presentations, town halls or broadcasts, must include captions in real time so deaf and hard-of-hearing audiences can follow the event as it happens.
Typical failure
A live executive webcast streamed on YouTube with no live caption track enabled. A state-government public briefing that relies only on automatic platform captions when an event of that significance warrants human captioners.
1.2.5

Audio Description (Prerecorded)

Level AA Perceivable Since WCAG 2.0
Plain English
Prerecorded video with audio must include an audio description track that narrates the important visual information not already conveyed by the dialogue, so people who cannot see the video do not miss key content.
Typical failure
A campaign video where the speaker silently gestures to graphs and on-screen statistics with no descriptive narration. A product demonstration that relies on visual-only cues, such as a colour changing or a cursor moving, with no audio description.
Affects
1.2.6

Sign Language (Prerecorded)

Level AAA Perceivable Since WCAG 2.0
Plain English
Sign-language interpretation must be provided for prerecorded audio in synchronised media. For an Australian audience that usually means Auslan, so that people whose first language is a sign language can access the content directly rather than via written captions.
Typical failure
A government public-information video that offers captions but no Auslan interpreter overlay. A health alert from a public body with no signed version, leaving Deaf-community first-language signers reliant on a second language.
1.2.7

Extended Audio Description (Prerecorded)

Level AAA Perceivable Since WCAG 2.0
Plain English
When dialogue pauses are too short to fit a standard audio description, an extended version must be provided. The video pauses briefly so a longer description can be spoken before playback resumes, then continues.
Typical failure
A dense documentary or training video where the voiceover runs almost continuously, leaving no gaps for description, and no extended-description version is offered. Audio description tracks that race through detail unintelligibly because the producer refused to add pauses.
Affects
1.2.8

Media Alternative (Prerecorded)

Level AAA Perceivable Since WCAG 2.0
Plain English
A full alternative for time-based media must be provided alongside any prerecorded synchronised media. Typically this is a written transcript that includes both dialogue and a description of the visual content, formatted so people can read, search, translate or print it.
Typical failure
A training video with captions but no companion transcript. A multimedia case study where the only way to consume the content is to sit through the video, with no readable version available to people using refreshable Braille displays or those who simply prefer reading.
1.2.9

Audio-only (Live)

Level AAA Perceivable Since WCAG 2.0
Plain English
An alternative must be provided for live audio-only content such as live podcasts or radio streamed on the web. In practice this means a real-time text feed or live caption service so deaf and hard-of-hearing audiences can follow the broadcast as it happens.
Typical failure
A live audio-only stream of a panel discussion or radio programme with no live transcript or captioning service. Live audio chats inside a product, such as a spaces-style room, with no live-text alternative for participants.
1.3.1

Info and Relationships

Level A Perceivable Since WCAG 2.0
Plain English
The structure and relationships in content, such as headings, lists, tables, form labels and grouped fields, must be expressed in the underlying code, not just shown visually. Assistive technologies depend on the markup to convey what the eye sees in the layout.
Typical failure
Section headings styled with bold and a larger font but coded as ordinary paragraphs, so screen-reader users cannot list or jump between sections. A table built from div elements with grid CSS that loses its row and column semantics. A required-field marker shown only by a red asterisk that is not connected to the field by aria-required or a programmatic label.
Affects
1.3.2

Meaningful Sequence

Level A Perceivable Since WCAG 2.0
Plain English
When the meaning of content depends on the order it is read in, that order must also exist in the underlying code. The DOM order, not just the visual position, must make sense when content is read aloud or navigated step by step.
Typical failure
A multi-column layout reordered with CSS flexbox or grid so that screen-reader users hear content in an order that no longer makes sense. A pricing comparison table that flows left to right visually but is coded so columns are read out of sequence. Floated sidebars that interrupt the main reading flow.
Affects
1.3.3

Sensory Characteristics

Level A Perceivable Since WCAG 2.0
Plain English
Instructions for understanding or operating content must not rely on a single sensory cue such as shape, colour, size, position or sound. "Click the green button on the right" fails for people who cannot see colour or position. Always pair the cue with text the user can identify.
Typical failure
A form that tells the user to "click the round button at the top right". A help message that says "press the icon shaped like a cog". An audio instruction to "select the option that follows the chime". A wizard step labelled only "the one in blue".
1.3.4

Orientation

Level AA Perceivable Since WCAG 2.0
Plain English
Content must not lock to a single screen orientation such as portrait or landscape unless that orientation is genuinely essential. People who mount a tablet on a wheelchair or use a fixed-position kiosk should be able to use the content however the device is held.
Typical failure
A mobile app or progressive web app that shows a "please rotate your device" screen when the user holds it in portrait. A booking flow that forces landscape on a tablet locked in a stand. A video player that auto-locks orientation and overrides the operating-system rotation lock.
1.3.5

Identify Input Purpose

Level AA Perceivable Since WCAG 2.0
Plain English
For form fields that collect information about the user, the purpose must be programmatically identifiable, usually via the HTML autocomplete attribute. Browsers, password managers and assistive tools can then label, autofill or personalise the field consistently.
Typical failure
A checkout where the card number, expiry and cardholder name fields carry no autocomplete attributes, blocking browser autofill and password-manager assistance. A signup form with field names like "field_3" and "field_4" instead of email and given-name. Address fields that never declare which one is postcode, suburb or country.
1.3.6

Identify Purpose

Level AAA Perceivable Since WCAG 2.0
Plain English
The purpose of user-interface components, icons and regions must be programmatically identifiable. That lets browsers, assistive technologies and personalisation extensions substitute simpler icons, swap in a preferred symbol set, hide non-essential content, or otherwise adapt the interface for the user.
Typical failure
A custom widget set where every button relies on a bespoke icon with no ARIA role or accessible name. A navigation built from divs without landmark roles, blocking tools that try to simplify or restyle the interface for users with cognitive disabilities. Decorative regions marked up the same way as primary content.
Affects
1.4.1

Use of Color

Level A Perceivable Since WCAG 2.0
Plain English
Colour must not be the only way information, an action, a state, or a distinction is conveyed. Pair colour with text, an icon, a pattern, or a shape so people who cannot see colour can still understand the message.
Typical failure
A form where required fields are shown only by being highlighted in red. A chart whose data lines are distinguished only by colour with no labels, patterns or shapes. Pricing tables where the recommended option is identified only by a coloured background.
Affects
1.4.2

Audio Control

Level A Perceivable Since WCAG 2.0
Plain English
If audio plays automatically for more than 3 seconds, there must be a way to pause, stop, or mute it independently of the system volume. Background audio interferes with screen reader speech and is a distraction many people cannot ignore.
Typical failure
A homepage background video with audio that auto-plays with no visible control. A music or game site that starts a track on page load without a pause or mute button. Auto-playing ad audio inside an article.
1.4.3

Contrast (Minimum)

Level AA Perceivable Since WCAG 2.0
Plain English
Text and images of text must have a contrast ratio of at least 4.5:1 against their background (3:1 for large text). This lets people with low vision, colour-vision differences or older screens still read your content.
Typical failure
Light grey body text (#999) on white; pale brand-colour buttons with white labels; placeholder text in form fields rendered at 30% opacity.
Affects
1.4.4

Resize text

Level AA Perceivable Since WCAG 2.0
Plain English
Text must be able to be resized up to 200% without loss of content or functionality, and without the user needing assistive technology. Many people with low vision zoom heavily to read.
Typical failure
A page that breaks its layout, hides content, or overlaps elements when the browser zoom is set to 200%. Form labels that disappear off-screen at higher zoom. Fixed pixel font sizes that ignore the user's default text size setting.
Affects
1.4.5

Images of Text

Level AA Perceivable Since WCAG 2.0
Plain English
Real HTML text should be used in preference to images of text. Real text scales, can be selected and copied, can be translated, can be styled by the user, and can be read aloud by screen readers. Images of text cannot.
Typical failure
A marketing banner where the headline copy is part of the JPG. A PDF whose pages are scanned images rather than actual text. Pull-quotes rendered as graphics. Pricing tables saved as images for design control.
Affects
1.4.6

Contrast (Enhanced)

Level AAA Perceivable Since WCAG 2.0
Plain English
At AAA, text and images of text must have a contrast ratio of at least 7:1 against their background (4.5:1 for large text). This is the strict version of 1.4.3, useful when serving users with more pronounced vision loss or when the content will be read in difficult lighting.
Typical failure
Any pale brand colour used for body text. Most sites that meet AA contrast still fall short of AAA. Light grey on white reading surfaces in long-form articles.
Affects
1.4.7

Low or No Background Audio

Level AAA Perceivable Since WCAG 2.0
Plain English
For pre-recorded audio-only content that contains speech, background sounds should be at least 20 decibels quieter than the speech, or be absent altogether. Otherwise people who are hard of hearing cannot make out the words.
Typical failure
A podcast intro where music plays loudly under the host's voice. A government video announcement with a busy musical bed. A radio-style ad where sound effects mask the spoken offer.
1.4.8

Visual Presentation

Level AAA Perceivable Since WCAG 2.0
Plain English
Blocks of text need formatting that supports reading: user-selectable foreground and background colours, line length under 80 characters, no full justification, line spacing of at least 1.5, paragraph spacing of at least 1.5 times line height, and resizing without horizontal scrolling.
Typical failure
A justified-text page with tight line height and long lines. PDF reports with no reflow option. Pages that force a colour scheme the user cannot override. Marketing pages with very wide line lengths on desktop.
Affects
1.4.9

Images of Text (No Exception)

Level AAA Perceivable Since WCAG 2.0
Plain English
At AAA the only allowed uses of text in images are logos, branded text, and cases where the specific visual presentation is essential to the meaning. The flexibility allowed at 1.4.5 is removed.
Typical failure
Decorative quote graphics where the quote itself is part of the image. Hero banners that use image-rendered headlines. Infographic statistics where the numbers are baked into the image rather than overlaid as HTML.
Affects
1.4.10

Reflow

Level AA Perceivable Since WCAG 2.1
Plain English
Content must reflow into a single column at 400% zoom, or at a viewport width of 320 CSS pixels, without requiring the user to scroll in two directions. This supports phone users and people who magnify the screen heavily.
Typical failure
A pricing comparison table that requires horizontal scrolling on a phone. A fixed-width page that exposes side-scrolling at 400% zoom. Sticky elements that cover viewport content at narrow widths. Multi-column layouts that never collapse to one column.
1.4.11

Non-text Contrast

Level AA Perceivable Since WCAG 2.1
Plain English
User interface components (button borders, form-field outlines, focus indicators, toggle states) and meaningful graphical objects must have at least 3:1 contrast against adjacent colours. Without it, people with low vision cannot find or distinguish them.
Typical failure
An unfilled form field with a 1px light grey border on white. A toggle switch where on and off look almost identical. Pale icons used as the only indicator of an action. Custom radio buttons whose selected state has no contrast difference.
Affects
1.4.12

Text Spacing

Level AA Perceivable Since WCAG 2.1
Plain English
When users override line height, paragraph spacing, letter spacing, and word spacing through their own stylesheet or a browser tool, no content or functionality may be lost. Layouts cannot assume specific text dimensions.
Typical failure
Fixed-height buttons that clip the label when users increase line height. Cards that overlap each other when paragraph spacing is increased. Tight horizontal layouts that overflow when letter-spacing changes. Text inside icons that breaks at a different word spacing.
Affects
1.4.13

Content on Hover or Focus

Level AA Perceivable Since WCAG 2.1
Plain English
When extra content appears on hover or keyboard focus (tooltips, dropdowns, definitions), it must be dismissable without moving pointer or focus, hoverable so the user can move into it, and persistent until dismissed, the user moves away, or the information is no longer valid.
Typical failure
A tooltip that disappears the moment the mouse moves toward it, making the content unreadable. Tooltips that obscure the field a user is trying to fill in. Focus-triggered popovers with no way to close them other than tabbing away. Custom dropdowns that close before the user can click the menu items.
2.1.1

Keyboard

Level A Operable Since WCAG 2.0
Plain English
Everything a user can do with a mouse must also be possible using only a keyboard. Many people with physical, visual or temporary mobility issues navigate exclusively by keyboard, switch device or voice control that maps to keyboard input.
Typical failure
Custom dropdown menus that only open on hover; modal dialogs you can open by clicking but cannot close without the mouse; drag-and-drop interfaces with no keyboard equivalent.
Affects
2.1.2

No Keyboard Trap

Level A Operable Since WCAG 2.0
Plain English
If keyboard focus can move into a component, it must be able to move out using just the keyboard. People who navigate by keyboard, or use assistive technology that simulates a keyboard, must never get stuck inside a modal, embed, widget or media player.
Typical failure
A video player or embedded PDF where pressing Tab keeps cycling inside the embed and the user cannot return to the rest of the page. A modal dialog that traps focus inside its own controls with no visible close button or keyboard exit. A date picker that captures arrow keys and never returns focus to the form.
2.1.4

Character Key Shortcuts

Level A Operable Since WCAG 2.1
Plain English
If a site implements keyboard shortcuts using single letter, punctuation or symbol keys, the user must be able to turn them off, remap them, or have them only fire when a modifier key is held. Otherwise speech-input users and people who type with one finger can trigger them by accident.
Typical failure
A web app that maps "j" to "next item" and "k" to "previous item" with no setting to disable it. A productivity tool whose single-letter shortcuts fire while the user is dictating into a different field. A help system that hijacks the slash key globally with no off switch.
2.1.3

Keyboard (No Exception)

Level AAA Operable Since WCAG 2.0
Plain English
All functionality must be operable through a keyboard interface with no exception. This is the strict form of 2.1.1, which allowed exceptions for path-dependent input such as freehand drawing.
Typical failure
A drawing or signature canvas that accepts only mouse or touch input, with no keyboard equivalent at any difficulty. A handwriting input that ignores the keyboard entirely. A custom 3D model viewer that requires drag gestures.
2.2.1

Timing Adjustable

Level A Operable Since WCAG 2.0
Plain English
When content imposes a time limit, the user must be able to turn it off, adjust it, or extend it at least ten times before it expires. The exceptions are real-time events, essential time limits, and very long limits over 20 hours.
Typical failure
A government form that ends its session after 10 minutes with no warning and no extension. A test or assessment with a hard countdown and no documented accommodation path. A payment screen that drops the session after a fixed window with no option to extend.
2.2.2

Pause, Stop, Hide

Level A Operable Since WCAG 2.0
Plain English
Moving, blinking, scrolling or auto-updating content that lasts more than five seconds must offer a way to pause, stop or hide it. Auto-updating content must also let the user pause, stop or control its update frequency.
Typical failure
A homepage carousel that rotates every few seconds with no pause control. A live-tile dashboard that refreshes every two seconds with no way to slow it down. An animated advertising banner running continuously alongside body copy.
2.2.3

No Timing

Level AAA Operable Since WCAG 2.0
Plain English
Timing is not an essential part of the activity in the content, except for non-interactive synchronised media and real-time events. People can take as long as they need without losing their place.
Typical failure
A learning module that locks each screen for a fixed minimum or maximum reading time. A self-service kiosk that times out the instructions screen even though the user is still working on the same step. A captioning exercise that forces a specific pace.
2.2.4

Interruptions

Level AAA Operable Since WCAG 2.0
Plain English
Interruptions such as alerts, updates and pop-ups can be postponed or suppressed by the user, except for emergencies. Background activity should not steal the user's focus from the current task.
Typical failure
A web app that surfaces marketing prompts and "did you mean" overlays in the middle of a checkout. A dashboard that throws a system-notification toast across the cursor while the user is selecting an option. A chatbot widget that auto-expands every few minutes without a setting to silence it.
Affects
2.2.5

Re-authenticating

Level AAA Operable Since WCAG 2.0
Plain English
When an authenticated session expires, the user can continue the activity without losing data after re-authenticating. They return to where they were, with form input preserved.
Typical failure
A long benefits application that drops the user back to the start screen after a session timeout, losing every field they had completed. A booking flow that demands re-login mid-cart and empties the cart. A multi-step survey that loses partial answers on session expiry.
2.2.6

Timeouts

Level AAA Operable Since WCAG 2.1
Plain English
Users are warned in advance of how long they can be inactive before the session ends and data is lost, unless the data is preserved for at least 20 hours. The warning gives them a chance to extend the session or save their work.
Typical failure
A banking session that ends silently after 15 minutes with no warning, losing the user's draft transfer. A health-record portal that posts an unannounced "session ended" message with no save option. A form whose timeout is documented only in the terms of service.
2.3.1

Three Flashes or Below Threshold

Level A Operable Since WCAG 2.0
Plain English
Web pages must not contain anything that flashes more than three times in any one-second period, unless the flashing area meets specific size and luminance thresholds. Rapid flashing can trigger seizures in people with photosensitive epilepsy.
Typical failure
An animated promotional image with rapid white-to-red flashes that fill most of the viewport. A loading spinner that strobes faster than three times per second across a large area. A celebration animation triggered after a quiz answer that flashes the screen repeatedly.
Affects
2.3.2

Three Flashes

Level AAA Operable Since WCAG 2.0
Plain English
Web pages must not contain anything that flashes more than three times in any one-second period, with no exception. This is a stricter form of 2.3.1: the size and luminance exceptions do not apply.
Typical failure
Any content that flashes more than three times per second, including small areas of the screen that would have been permitted under 2.3.1. A gaming interface element that strobes regardless of its size. A status indicator that flashes rapidly for "urgent" alerts.
Affects
2.3.3

Animation from Interactions

Level AAA Operable Since WCAG 2.1
Plain English
Motion animation triggered by user interaction must be able to be disabled, unless the animation is essential to the function. People with vestibular conditions can experience nausea, dizziness or migraine from parallax scrolling, large transitions and sweeping camera moves.
Typical failure
A site with full-page parallax scroll effects that cannot be turned off. A product gallery whose zoom uses an aggressive scaling animation with no way to disable it. A dashboard that animates every state change with no respect for the prefers-reduced-motion system setting.
2.4.1

Bypass Blocks

Level A Operable Since WCAG 2.0
Plain English
Users must be able to skip past blocks of repeated content like the site-wide navigation. The most common solution is a "Skip to main content" link that appears as the first focusable item on every page.
Typical failure
A site with no skip link, so keyboard users must Tab through dozens of nav items before reaching the page content. A skip link pointing to a missing or hidden target. Skip links shown only on hover that never appear when receiving keyboard focus.
2.4.2

Page Titled

Level A Operable Since WCAG 2.0
Plain English
Every page must have a title element that describes its topic or purpose. The title appears in the browser tab, in screen-reader page-load announcements, in search-engine results and in the user's bookmarks.
Typical failure
A single-page application that never updates document.title between views, so every screen announces the same title. Generic titles like "Home" or "Untitled" across many pages. Titles that lead with the brand and only mention the page topic at the end, where it gets truncated in tab strips.
Affects
2.4.3

Focus Order

Level A Operable Since WCAG 2.0
Plain English
When users navigate through content with the keyboard, focus must move in an order that preserves meaning and operability. The Tab sequence should match the visual reading order.
Typical failure
A form where the submit button receives focus before all required fields. A modal that opens but leaves focus behind on the page underneath. Positive tabindex values that pull focus to unexpected places in the document order.
2.4.4

Link Purpose (In Context)

Level A Operable Since WCAG 2.0
Plain English
The purpose of every link must be clear from the link text, optionally combined with its surrounding context such as the sentence, list item, paragraph, table cell or heading it sits in. "Click here" links fail this test unless the context fully explains where they go.
Typical failure
A list of articles where every link says "Read more" with no programmatic way to distinguish them in a screen-reader link list. An icon-only link with no accessible name. A button whose only label is a chevron.
Affects
2.4.5

Multiple Ways

Level AA Operable Since WCAG 2.0
Plain English
There must be more than one way to locate a page within a set, unless the page is a step in a process. Common combinations are site search plus a navigation menu, or a sitemap plus a related-links section.
Typical failure
A documentation site offering only a left-hand tree navigation with no search. A government portal whose sitemap link is broken and whose primary navigation requires hover-only menus that a keyboard user cannot operate.
2.4.6

Headings and Labels

Level AA Operable Since WCAG 2.0
Plain English
Headings and form labels must describe the topic or purpose. Vague headings like "More information" or labels like "Field" fail this test, because they give the user no idea what the section or input is about.
Typical failure
A page where every section heading reads "Information". Form fields labelled "Field 1", "Field 2", "Field 3". Tabs labelled "One", "Two", "Three" with no indication of what content sits inside each.
Affects
2.4.7

Focus Visible

Level AA Operable Since WCAG 2.0
Plain English
When something on the page receives keyboard focus, there must be a clear visual indicator showing which element is focused. Without it, keyboard users have no way to track where they are.
Typical failure
CSS that strips the default browser focus ring (outline: none) without providing a replacement; designer-supplied focus styles that meet the brand palette but disappear against busy backgrounds.
2.4.11

Focus Not Obscured (Minimum)

Level AA Operable Since WCAG 2.2
Plain English
When a component receives keyboard focus, it must not be entirely hidden by something the author has added, such as a sticky banner, cookie bar, chat widget or fixed footer. At least part of the focused control must remain visible.
Typical failure
A sticky bottom-of-screen cookie banner that covers form inputs as the user Tabs through them. A floating chat widget that overlaps the focused button so the user cannot tell what is selected. A persistent header that hides the focused control when the page scrolls.
2.4.8

Location

Level AAA Operable Since WCAG 2.0
Plain English
The user can find out where they are within a set of related pages. Common solutions are a breadcrumb, an "in this section" indicator in the navigation, or a visible step indicator in a multi-step flow.
Typical failure
A deep documentation page with no breadcrumb and no indication of which navigation branch the page belongs to. A multi-page checkout with no progress indicator. A sub-site whose pages do not mark themselves as current in the global navigation.
Affects
2.4.9

Link Purpose (Link Only)

Level AAA Operable Since WCAG 2.0
Plain English
The purpose of every link must be clear from the link text alone, with no need for surrounding context. This is the strict form of 2.4.4.
Typical failure
A list of links each labelled "Read more". A table of attachments where every link reads "Download". Buttons sharing the same label across rows that act on different items.
Affects
2.4.10

Section Headings

Level AAA Operable Since WCAG 2.0
Plain English
Where content is organised into sections, those sections must be introduced by headings. Long pages benefit from heading-level navigation that lets screen-reader users jump straight to the section they want.
Typical failure
A long whitepaper presented as a wall of paragraphs with no headings beyond the page title. A FAQ page where every question is rendered as bold paragraph text rather than a real heading. A policy page that uses font-size alone to suggest section divisions.
Affects
2.4.12

Focus Not Obscured (Enhanced)

Level AAA Operable Since WCAG 2.2
Plain English
When a component receives keyboard focus, no part of the focus indicator is hidden by something the author has added. Stricter than 2.4.11, which allows partial obscuration.
Typical failure
A sticky element that partially overlaps the focus ring of any focused control. An author-added overlay that clips even one pixel of the focus indicator. A floating help bubble that crosses the edge of focused controls.
2.4.13

Focus Appearance

Level AAA Operable Since WCAG 2.2
Plain English
The keyboard focus indicator must be at least as large as a 2-pixel solid outline around the focused control, with a contrast ratio of at least 3 to 1 against the unfocused state. People scanning the screen at a distance, or with low vision, can then still see where focus is.
Typical failure
A site that removes the browser default outline and replaces it with a subtle background tint that does not meet the 3-to-1 contrast ratio. A focus ring that is only one pixel thick. A focus style that disappears against certain element backgrounds.
Affects
2.5.1

Pointer Gestures

Level A Operable Since WCAG 2.1
Plain English
All functionality that uses multi-point or path-based gestures, such as pinch-zoom, swipe or two-finger rotate, must also be operable with a single pointer without a path-based gesture, unless the gesture is essential to the function.
Typical failure
A map widget where the only way to zoom is pinch-zoom, with no plus or minus buttons. A photo viewer where rotation requires a two-finger gesture. A signature pad that demands a specific drawing path with no keyboard or single-tap alternative.
2.5.2

Pointer Cancellation

Level A Operable Since WCAG 2.1
Plain English
For functionality operated with a single pointer, the action must trigger on the up-event, not the down-event, so users can move off the target before releasing. This prevents accidental activation.
Typical failure
A button that fires on mousedown rather than mouseup, leaving no way to abort once the user realises they have targeted the wrong control. A canvas tool that draws or deletes on the first touch with no undo. A custom slider that commits its value on touchstart.
2.5.3

Label in Name

Level A Operable Since WCAG 2.1
Plain English
For controls labelled with both visible text and a programmatic accessible name, the visible text must be included in the accessible name. Speech-input users can then activate controls by saying what they see on screen.
Typical failure
A Submit button whose visible text is "Submit application" but whose aria-label is "Send form". A search button labelled "Search" visually but coded as aria-label="Find content". An icon button with no visible text but a long aria-label that bears no relationship to the surrounding context.
2.5.4

Motion Actuation

Level A Operable Since WCAG 2.1
Plain English
Functions that can be triggered by device motion (shake, tilt) or user motion (waving at a camera) must also be operable through standard UI controls, and the user must be able to disable motion actuation to prevent accidental triggering.
Typical failure
A shake-to-undo gesture in a mobile web app with no equivalent undo button. A camera-based gesture control with no toggle for users with tremor or limited mobility. A drawing tool that erases when the device is shaken, with no way to switch the behaviour off.
2.5.5

Target Size (Enhanced)

Level AAA Operable Since WCAG 2.1
Plain English
Pointer-input targets such as buttons and links must be at least 44 by 44 CSS pixels. Exceptions exist for controls inline in a sentence of text, controls whose size is set by the user agent, or where a particular size is essential.
Typical failure
A row of small icon buttons in a toolbar each only 24 pixels tall. Pagination links sized at 28 pixels. A close button rendered as a 16-pixel cross in the corner of a modal. Action buttons in a data table cell sized to match the row height of 32 pixels.
2.5.6

Concurrent Input Mechanisms

Level AAA Operable Since WCAG 2.1
Plain English
Web content does not restrict the use of input modalities available on a platform. Users can choose to use a keyboard, a touchscreen, a mouse, a stylus or an assistive technology, or switch between them, without losing functionality.
Typical failure
A web app that disables touch input the moment a mouse is detected, locking out a hybrid laptop-tablet user. A site that prevents keyboard input on a touchscreen device so users with an external keyboard cannot type. An interface that requires a particular pointing device.
2.5.7

Dragging Movements

Level AA Operable Since WCAG 2.2
Plain English
Any functionality that uses a dragging movement must also be operable through a single pointer without dragging, unless dragging is essential. A common alternative is click-to-select followed by click-to-place, or plus and minus buttons.
Typical failure
A kanban board where the only way to move a card between columns is drag-and-drop. A slider whose value can only be changed by dragging the thumb, with no plus or minus buttons or text input. A range picker that requires dragging both ends.
2.5.8

Target Size (Minimum)

Level AA Operable Since WCAG 2.2
Plain English
Pointer-input targets must be at least 24 by 24 CSS pixels, with exceptions for inline text links and where surrounding spacing or user-agent defaults already satisfy the requirement. This is the AA version of the older 2.5.5 (which sets the bar at 44 pixels).
Typical failure
Small icon-only buttons in a navigation bar each only 20 pixels square. Tightly packed pagination controls with no spacing between them. A row of social-share buttons sized at 18 pixels in a sidebar.
3.1.1

Language of Page

Level A Understandable Since WCAG 2.0
Plain English
The default human language of the page must be set programmatically, usually with the lang attribute on the html element. Screen readers use this to pronounce content correctly.
Typical failure
A page with no lang attribute, so screen readers default to the user's system language and read English content with French phonetics. A multilingual site whose Australian-English pages still declare lang="en-GB" inherited from a template.
Affects
3.1.2

Language of Parts

Level AA Understandable Since WCAG 2.0
Plain English
Where a passage of text on a page is in a different language from the page default, that passage must be marked up with its own lang attribute. This lets screen readers switch pronunciation for the foreign-language content.
Typical failure
A page in English that quotes a sentence in Arabic with no lang markup, so the screen reader mangles it as garbled English. Indigenous-language place names embedded in English copy with no lang declarations. Foreign-language quotations in a research article with no markup.
Affects
3.1.3

Unusual Words

Level AAA Understandable Since WCAG 2.0
Plain English
Provide a mechanism for identifying specific definitions of words or phrases used in an unusual or restricted way, such as idioms or jargon. Links to a glossary, inline definitions or hover-disclosed tooltips are common solutions.
Typical failure
A medical patient-information page peppered with technical terms with no glossary or inline definitions. A government policy page using industry acronyms with no definitions. A legal document full of jargon and Latin phrases.
Affects
3.1.4

Abbreviations

Level AAA Understandable Since WCAG 2.0
Plain English
A mechanism is available for identifying the expanded form or meaning of every abbreviation. Inline expansion on first use, abbr elements with title attributes, or a linked glossary all satisfy this.
Typical failure
A standards document that uses dozens of three-letter acronyms (WCAG, ATAG, UAAG, ARIA) with no expansion on first use. A report referring to "DSP funding for NDIS plans" with no clarification of either acronym.
Affects
3.1.5

Reading Level

Level AAA Understandable Since WCAG 2.0
Plain English
When text requires reading ability above the lower secondary education level after removing proper names and titles, supplemental content or a simplified version that does not require that level must be available.
Typical failure
A government services page written at university reading level with no plain-language version or summary. Health information for the general public written at professional medical reading level. Banking terms and conditions presented only in their legal form.
Affects
3.1.6

Pronunciation

Level AAA Understandable Since WCAG 2.0
Plain English
A mechanism is available for identifying specific pronunciations of words where the meaning is ambiguous without knowing the pronunciation, such as heteronyms.
Typical failure
An article that uses words like "read", "lead" or "wind" in contexts where the screen-reader pronunciation flips the meaning, with no ruby annotation, audio or phonetic spelling provided.
Affects
3.2.1

On Focus

Level A Understandable Since WCAG 2.0
Plain English
When any component receives focus, it must not initiate a change of context such as a new page load, a window opening, or focus moving elsewhere. Focus should never be a trigger for unexpected behaviour.
Typical failure
A dropdown that auto-submits to a new page the moment it receives focus. A link that opens a new window on focus rather than on activation. Mega-menus that open and steal focus on tab-hover instead of on click.
3.2.2

On Input

Level A Understandable Since WCAG 2.0
Plain English
Changing the setting of any user-interface component must not automatically cause a change of context, unless the user has been advised of the behaviour before using the component.
Typical failure
A select element that auto-submits the form on change, navigating the user away without warning. A radio group that triggers immediate page navigation on selection. A checkbox that submits without a confirm step.
3.2.3

Consistent Navigation

Level AA Understandable Since WCAG 2.0
Plain English
Navigational mechanisms that are repeated on multiple pages within a set occur in the same relative order each time, unless the user has chosen to change it.
Typical failure
A site where the primary navigation is in the header on the home page, in a sidebar on the contact page, and at the bottom of the page on the about page. Footers whose link order shuffles between sections.
Affects
3.2.4

Consistent Identification

Level AA Understandable Since WCAG 2.0
Plain English
Components with the same functionality across a set of pages must be identified consistently. A magnifying-glass icon meaning "search" on one page should not mean "zoom" on another.
Typical failure
A site where the same icon is labelled "Save" in one workflow and "Bookmark" in another. Inconsistent button styling where primary actions look secondary in some flows. Different terms used for the same concept across the same site.
Affects
3.2.5

Change on Request

Level AAA Understandable Since WCAG 2.0
Plain English
Changes of context, including new windows, focus moves and form submissions, happen only on explicit user request. The user can also disable such changes.
Typical failure
A site that auto-opens external links in new tabs with no warning. A help system that pops modal dialogs whenever the user pauses on a page. Auto-refresh on a long-form page that interrupts the user mid-read.
3.2.6

Consistent Help

Level A Understandable Since WCAG 2.2
Plain English
When help mechanisms such as contact details, a chat link, a help menu or self-service options are available across a set of pages, they appear in the same relative order each time, unless the user changes it.
Typical failure
A site whose phone number appears in the header on the home page, in the footer on the products page, and inside an accordion on the contact page. Help links moved between releases with no consistent placement.
Affects
3.3.1

Error Identification

Level A Understandable Since WCAG 2.0
Plain English
When an input error is detected automatically, the item in error must be identified and the error must be described to the user in text. A colour alone or a beep is not enough.
Typical failure
A form submission that fails with a generic "Error: please correct fields" message and no indication of which fields are wrong. Inline errors shown only via a red border with no message. Status messages flashed onscreen too briefly to read.
Affects
3.3.2

Labels or Instructions

Level A Understandable Since WCAG 2.0
Plain English
Form fields that need user input must have visible labels or instructions explaining what is expected. Placeholder text alone is not a label. It vanishes as soon as the user starts typing.
Typical failure
Search boxes labelled only with a magnifying-glass icon; checkout forms using placeholder text in lieu of labels; required-field markers shown only by red asterisks with no legend.
Affects
3.3.3

Error Suggestion

Level AA Understandable Since WCAG 2.0
Plain English
When an input error is detected and a correction is known, the suggestion must be provided to the user, unless that would jeopardise the security or purpose of the content.
Typical failure
A form that says "Invalid postcode" but does not indicate the expected format. A username field that rejects spaces without explaining why. A credit-card field that returns "Card number incorrect" without indicating which characters are out.
Affects
3.3.4

Error Prevention (Legal, Financial, Data)

Level AA Understandable Since WCAG 2.0
Plain English
For pages that cause legal commitments, financial transactions, modifications to user data, or test submissions, at least one of the following is true: submissions are reversible, the user can check and correct entries before submitting, or a confirmation step is required.
Typical failure
A donation form that charges immediately on submit with no confirmation screen. A delete-account button that removes the account on first click. A statutory-declaration form with no review-and-confirm step.
3.3.5

Help

Level AAA Understandable Since WCAG 2.0
Plain English
Context-sensitive help must be available for forms, fields and processes where the user is required to enter information.
Typical failure
A tax form with no field-level help text and no tooltips explaining what information is being requested. A booking flow with no FAQ or contextual guidance for users unfamiliar with the process.
Affects
3.3.6

Error Prevention (All)

Level AAA Understandable Since WCAG 2.0
Plain English
For all pages that require the user to submit information, submissions must be reversible, the user must be able to check and correct entries before submitting, or a confirmation step must be required. Stricter than 3.3.4, which applies only to legal, financial and data-modification pages.
Typical failure
Any form that submits irreversibly without review or confirmation, including newsletter signups, account changes and preference updates. A search-filter panel that auto-submits irreversibly on each change.
3.3.7

Redundant Entry

Level A Understandable Since WCAG 2.2
Plain English
Information previously entered by, or provided to, the user that is required to be entered again in the same process must be either auto-populated or available for the user to select. Exceptions: re-entry is essential, the information is required for security, or the previous information is no longer valid.
Typical failure
A multi-step application form that asks the user to retype their address on every page. A checkout that requests the email address again on each step. A test that requires the user to re-enter their name to start each section.
3.3.8

Accessible Authentication (Minimum)

Level AA Understandable Since WCAG 2.2
Plain English
A cognitive function test, such as remembering a password or solving a puzzle, must not be required for any step in an authentication process, unless an alternative method is available that does not rely on cognitive function, or there is a mechanism to assist the user.
Typical failure
A login that requires the user to retype a captcha character sequence with no copy-paste support. A password-only login that blocks the autocomplete attribute used by password managers. A security question requiring recall of a memorised pet name.
3.3.9

Accessible Authentication (Enhanced)

Level AAA Understandable Since WCAG 2.2
Plain English
A cognitive function test must not be required for any step in an authentication process, full stop. Removes the "alternative method" exception that 3.3.8 allows at AA.
Typical failure
Any authentication that requires recalling, retyping or solving puzzles, including captcha or password-only login. Two-factor codes the user must memorise and re-enter from another device with no copy-paste support.
4.1.2

Name, Role, Value

Level A Robust Since WCAG 2.0
Plain English
For every user-interface component, including form controls, links and components built from scripts, the name and role can be programmatically determined, states and properties can be programmatically set, and assistive technologies are notified of any changes.
Typical failure
A custom-built dropdown that looks like a select element but has no role="combobox" or aria-expanded. A toggle switch with no role and no aria-checked. A modal coded entirely with div elements and click handlers, with no role="dialog" or aria-modal.
4.1.3

Status Messages

Level AA Robust Since WCAG 2.1
Plain English
Status messages such as "form saved", "added to cart" or "3 results found" can be programmatically determined through role or properties, so assistive technologies can announce them without moving focus.
Typical failure
A "form saved" toast that appears visually but is never announced to a screen reader because it has no role="status" or aria-live region. A cart-update message rendered into the DOM with no live-region wrapper. An inline validation count that updates silently.
Affects

Apply this to your project

Pick the path that matches where you are. We work across audits, remediation, training and long-term capability uplift, with free tools to support each step.

Common questions about WCAG 2.2

Plain answers to the questions buyers and delivery teams ask most often when applying these criteria.

Which WCAG conformance level should we target?

Level AA is the de facto standard required by the Australian Digital Service Standard and most international accessibility legislation. AA means meeting all 30 Level A and 25 Level AA criteria, 55 in total. Level AAA is aspirational; not all content can practically meet it. See Audit and Compliance for how we scope and deliver Level AA audits.

What's the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 (October 2023) adds 9 new success criteria to WCAG 2.1, focused mainly on motor disabilities and cognitive accessibility - notably 2.4.11 Focus Not Obscured, 2.4.12 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size and 3.3.7 Redundant Entry. See WCAG 2.2 in the glossary.

How do we apply these criteria to documents (PDFs, Word, PowerPoint)?

Documents need the same WCAG conformance as websites, plus PDF/UA (ISO 14289-1) for tagged PDF structure. Our Document Remediation service delivers tagged source files and PDF/UA-compliant outputs. The free Document Accessibility Tool walks you through the most common issues.

How do we track progress against WCAG over time?

Use the 90-second Maturity Self-Assessment as a baseline, then re-run quarterly. Pair it with an annual independent audit and CI-integrated automated checks to catch regressions. Organisational Uplift covers the full multi-year programme.

How do the criteria differ between websites, native apps and documents?

The criteria themselves are the same - the testing techniques and assistive technologies differ. Use the WCAG Criteria Search to filter by disability, principle and focus area; pair with our screen reader comparison guide for selecting the right testing targets.

How do we know which criteria apply to specific user groups?

Each criterion above lists who it Affects (Visual, Auditory, Cognitive, Physical or Speech) - click any badge to open the matching disability-types primer. For personas and specific access needs, our Accessibility Navigator tool filters every page in the catalogue by role and access need.