WCAG 2.2 Success Criteria

Non-text Content

Non-text content such as images, icons, and diagrams needs a text alternative that serves the same purpose. It lets text-based assistive technologies, like screen readers and braille displays, convey the same information, while purely decorative elements should instead be hidden from assistive technology. For cases like CAPTCHAs or tests where a full alternative would defeat the purpose, a short identifying description is enough.

Audio-only and Video-only (Prerecorded)

Provide a text alternative, such as a transcript, that conveys the same content as prerecorded audio-only material. For video-only content, either a text alternative or a narrated audio track works. This requirement doesn't apply when the audio or video is itself clearly labeled as an alternative for text.

Captions (Prerecorded)

Provide captions for all prerecorded audio in synchronized video, covering not just dialogue but speaker identification and important sound effects too. This lets people who are deaf or hard of hearing follow the content without relying on sound; audio-only or video-only content isn't covered here.

Audio Description or Media Alternative (Prerecorded)

For prerecorded video, either add audio description that explains visual-only information -- on-screen text, actions, and so on -- during natural pauses in dialogue, or provide a full text alternative describing everything seen and heard. Either option ensures blind or low-vision users don't miss information conveyed only visually.

Captions (Live)

Live audio in synchronized media -- breaking news, live streams, and the like -- needs real-time captions just as prerecorded content does. Some delay is unavoidable, but the goal is that viewers who are deaf or hard of hearing aren't left out of live broadcasts.

Audio Description (Prerecorded)

Prerecorded video must include audio description that explains visual-only information during pauses in dialogue. Unlike 1.2.3, a full text alternative can't substitute for this -- it's a stricter AA requirement. Video where the soundtrack alone already conveys the visual content, such as a talking-head interview, doesn't need extra description.

Sign Language (Prerecorded)

Provide a sign language interpretation video for all prerecorded audio content in synchronized media. For viewers whose first language is a signed language, this can be easier to follow than reading captions in a written language. It's a Level AAA criterion, the strictest tier, so it's rarely mandated as a legal minimum.

Extended Audio Description (Prerecorded)

When the pauses in dialogue aren't long enough to fully describe the visuals, pause the video as needed to insert more detailed extended audio description. This matters for content dense with visual information, like instructional videos, where 1.2.5's standard audio description can't fit everything in. It's a Level AAA criterion that goes further than 1.2.5.

Media Alternative (Prerecorded)

Provide a full text alternative describing everything that can be seen and heard, for all prerecorded synchronized media and video-only content. Delivering it as text means it can also be read via a braille display, reaching users who are deaf-blind. Where 1.2.3 offered a media alternative as one option among others, this AAA criterion makes it mandatory.

Audio-only (Live)

Provide a text alternative, such as real-time captions, conveying the content of live radio or audio-only live streams. Unlike 1.2.4, which covers live video with audio, this Level AAA criterion targets audio-only live content specifically.

Info and Relationships

Structure and relationships conveyed visually -- headings, lists, table associations, label-input pairings -- must be made programmatically determinable through HTML markup or ARIA. Screen reader users can't see the visual layout, so structure expressed only through color or spacing goes unnoticed. A classic failure is text styled to look like a heading with color or bold weight but marked up as a plain paragraph.

Meaningful Sequence

Even when CSS layout, such as multi-column formatting or positioning, changes the visual order, the correct, meaning-preserving reading order must still be programmatically determinable. Screen readers and keyboard navigation follow DOM order, so reordering content visually with CSS alone -- without matching the DOM -- can leave the sequence nonsensical.

Sensory Characteristics

Don't describe how to operate something using sensory characteristics alone -- shape, color, position, or sound -- like "the green button in the top right." Users with color vision deficiencies or visual impairments may not perceive those cues at all. Using color or shape is fine as long as a text label or other identifying cue is given alongside it.

Orientation

Don't lock display or operation to a single screen orientation, whether portrait or landscape. Users who mount their device -- on a wheelchair, for example -- may not be able to rotate it. An exception applies when a specific orientation is essential to the function itself, such as a piano keyboard app or check-scanning.

Identify Input Purpose

Input fields that collect user information -- name, address, birthday, and so on -- should have their purpose made programmatically determinable, typically via the autocomplete attribute, so browsers can offer autofill or icon-based support. This applies only to the fixed list of input purposes defined by WCAG. It also reduces the burden of retyping the same information for users with cognitive or memory-related disabilities.

Identify Purpose

Make the purpose of UI components, icons, and page regions (such as navigation) programmatically determinable -- for example via landmarks or appropriate elements and attributes. When purpose is identifiable, tools can substitute familiar symbols or simplified presentations, and even aid translation. This AAA criterion applies only to content implemented in a markup language.

Use of Color

Do not rely on color alone to convey information, indicate an action, or distinguish a visual element -- marking form errors in red only, for example, excludes users with color vision deficiencies. Combine color with another cue such as text or an icon; using color itself is not the problem.

Audio Control

If audio starts playing automatically and lasts more than 3 seconds, provide either a way to pause or stop it, or a way to adjust its volume independently of the system volume. Auto-playing audio can drown out screen reader speech, so letting users silence it quickly matters.

Contrast (Minimum)

Maintain a contrast ratio of at least 4.5:1 between text and its background, or 3:1 for large text (18pt or larger, or 14pt bold or larger). Purely decorative text, logos or brand names, and inactive UI components are exempt from this requirement.

Resize Text

Ensure text can be resized up to 200% using only browser features, without assistive technology, and without losing content or functionality. This lets low-vision users rely on browser zoom alone; captions and images of text are excluded.

Images of Text

Present text as real text rather than an image of text wherever the technology allows it. Exceptions apply when the image is user-customizable (font, size, color) or when the exact visual presentation is essential, such as a logo. Real text supports resizing, recoloring, and screen readers far better than a picture of text.

Contrast (Enhanced)

Maintain a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text (18pt or larger, or 14pt bold or larger). This is a stricter AAA-level version of 1.4.3, with the same exceptions for decorative text, logos, and inactive components.

Low or No Background Audio

For prerecorded audio that is primarily speech -- excluding CAPTCHAs, sound logos, or musical expression -- ensure there is no background sound, that it can be turned off, or that it is at least 20dB quieter than the speech. A 20dB gap means the background is roughly a quarter as loud as the foreground.

Visual Presentation

For blocks of text, let users switch to a presentation with selectable foreground/background colors, a line width of no more than about 80 characters (40 for full-width text), no full justification, line spacing at least 1.5x the font size with paragraph spacing at least 1.5x that, and no horizontal scrolling when zoomed to 200%. This doesn't need to be the default appearance.

Images of Text (No Exception)

Do not use images of text at all, except for purely decorative purposes or cases where the exact visual presentation is essential to the information, such as a logo. Unlike the AA-level 1.4.5, being user-customizable is not accepted as an exception here -- this is the stricter AAA version.

Reflow

Ensure content remains usable without needing to scroll in two dimensions down to a width of 320 CSS pixels for vertically scrolling content, or a height of 256 CSS pixels for horizontally scrolling content -- equivalent to a 1280x1024 viewport zoomed to 400%. Content where a two-dimensional layout is essential, such as maps or data tables, is exempt.

Non-text Contrast

Ensure visual elements needed for operation or understanding -- button borders, form controls, and icons indicating state such as focus or hover -- have at least a 3:1 contrast ratio against adjacent colors. Inactive components, unmodified browser-default styling, and graphics whose specific appearance is essential (such as a photo) are exempt.

Text Spacing

Ensure that even when users set line height to at least 1.5x the font size, paragraph spacing to at least 2x, letter spacing to at least 0.12x, and word spacing to at least 0.16x, no text is clipped or lost and no functionality breaks. A given value doesn't apply where the corresponding property doesn't exist for a language or script.

Content on Hover or Focus

Additional content that appears on hover or focus (e.g. tooltips) must be dismissible without moving the pointer (such as with Esc), hoverable so the pointer can move onto it without it disappearing, and persistent until the user dismisses it or moves away. Content controlled entirely by the user agent, such as a native title-attribute tooltip, is exempt.

Keyboard

Ensure all functionality is operable via keyboard alone, without requiring specific timing for individual keystrokes. Even custom, mouse-oriented widgets must be reachable with Tab and operable with Enter, Space, or arrow keys. The only exception is when the underlying function itself inherently requires path-based input, such as a freehand signature -- simply choosing handwriting as an input method doesn't qualify.

No Keyboard Trap

Ensure keyboard users can always move focus away from any component, including modals and custom widgets. Keyboard-only users have no alternative way out, so if a standard exit method like Escape isn't available, tell users explicitly how to leave.

Keyboard (No Exception)

Make every function operable via keyboard alone, with no exceptions. Unlike 2.1.1, this stricter AAA criterion does not exempt path-dependent or timing-sensitive interactions such as freehand drawing. Because of this strictness, it is rarely fully achievable and is one of the least commonly targeted AAA criteria.

Character Key Shortcuts

If you implement single-character keyboard shortcuts, let users turn them off, remap them to include a non-character key, or make them active only when the relevant element has focus. This prevents speech-input users from accidentally triggering a shortcut when a spoken word matches a letter key, and also protects users with limited dexterity who may hit keys unintentionally.

Timing Adjustable

If content imposes a time limit such as auto-logout, let users turn it off, adjust it to at least ten times the default, or extend it after a warning with at least twenty seconds to respond. This matters because users with cognitive or motor disabilities often need more time to read or complete input. Exceptions apply to real-time events, limits that are themselves essential (e.g. an auction), and limits longer than twenty hours.

Pause, Stop, Hide

Content that moves, blinks, or scrolls automatically for five seconds or more alongside other content -- such as a carousel -- must let users pause, stop, or hide it. Auto-updating content may instead let users adjust the update frequency. An exception applies when the motion is essential to the activity. This protects users who find ongoing motion distracting or hard to read around.

No Timing

Do not impose a time limit on interacting with content, except for non-interactive synchronized media (such as video) and real-time events. Unlike 2.2.1, which is satisfied by offering a way to turn off, adjust, or extend a limit, this stricter AAA criterion requires that no time limit exist at all.

Interruptions

Let users postpone or suppress interruptions such as notifications and pop-ups. Forcing attention away mid-task can make it hard for users with memory- or attention-related disabilities to return to what they were doing. Interruptions that require an immediate response, such as safety emergencies, are exempt.

Re-authenticating

When an authenticated session expires, let users re-authenticate and continue without losing the data they had already entered. Screen reader users and people with motor disabilities often need more time to fill in forms, so a security timeout that discards their work creates a serious disadvantage.

Timeouts

Warn users in advance about how much inactive time remains before data loss occurs. This helps users with memory- or attention-related disabilities avoid silently losing their input. The requirement does not apply when data is retained for at least twenty hours.

Three Flashes or Below Threshold

Do not include content that flashes more than three times per second, unless the flashes stay below the general and red flash thresholds. This prevents triggering photosensitive seizures, and the rule applies to any content on the page -- not just video, but also animations and flashing ads.

Three Flashes

Never include content that flashes more than three times per second, regardless of intensity or color -- a stricter AAA version of 2.3.1 with no threshold exception. It applies to all content on the page, whether video or animation.

Animation from Interactions

Allow users to disable motion animation that is triggered by interaction, such as parallax scrolling effects. Users with vestibular disorders can experience dizziness, nausea, or headaches from this kind of motion. The requirement does not apply when the animation itself is essential to the information being conveyed, such as in data visualizations.

Bypass Blocks

Provide a way to skip repeated blocks of content, such as navigation menus, and jump straight to the main content -- for example with a skip link, landmark regions, or a proper heading structure. Without this, keyboard and screen reader users must navigate through the same repeated menu on every single page before reaching the content they came for.

Page Titled

Give each page a title that describes its topic or purpose, using the title element. Screen reader users hear the title announced first when a page loads, so it is often their first clue to the page's content, and it also helps everyone tell pages apart among many open browser tabs.

Focus Order

Ensure the focus order follows a logical sequence that preserves meaning and operability, including moving focus into a dialog when opened and back to the trigger when closed. This matters especially for screen reader users, who cannot see the whole page at once and rely on the focus order to make sense of it.

Link Purpose (In Context)

Ensure each link's purpose can be determined from its link text alone or together with programmatically associated context, such as the enclosing sentence or heading. Text like "click here" is acceptable if the surrounding context makes the destination clear, but visual proximity alone does not count as context.

Multiple Ways

Provide more than one way to find a given page within a site, such as site search, a sitemap, or navigation menus, since users search for content in different ways. Pages that are a step in a process or the result of one, where a single path is natural, are exempt.

Headings and Labels

Write headings and form labels that clearly describe their topic or purpose -- for example, "Shipping address details" rather than just "Details". Vague labels make it hard for screen reader users to quickly grasp what each section or field is for.

Focus Visible

Ensure the keyboard focus indicator is visible so users can see which element currently has focus; do not remove the focus ring. It only needs to be visible in at least one mode of operation, not necessarily in every mode.

Location

Let users know where they are within a set of pages, for example via a breadcrumb trail or a highlighted item in a site map. This helps prevent users from getting lost in large or deeply nested sites; it matters less for small, single-page sites.

Link Purpose (Link Only)

Make each link's purpose understandable from its link text alone, without relying on surrounding context. This is a stricter version of 2.4.4, ensuring links still make sense when read out of context, such as in a screen reader's links list -- except where the purpose would be ambiguous to any reader, disabled or not.

Section Headings

Organize content into sections using headings, so users can understand the page's structure and navigate it easily. This applies to sectioning long-form content; labeling UI components like buttons or tabs is covered separately by 4.1.2.

Focus Not Obscured (Minimum)

Ensure a keyboard-focused element is not entirely hidden behind author-created content such as sticky headers or dialogs. Overlaps caused by content the user opened themselves are exempt, as long as the element can be revealed again without moving focus.

Commentary available

Focus Not Obscured (Enhanced)

Ensure a keyboard-focused element is never obscured by author-created content such as sticky headers or dialogs -- not even partially. This is a stricter version of 2.4.11, which only requires that the element not be entirely hidden.

Focus Appearance

Make the keyboard focus indicator large enough (equivalent to at least a 2 CSS pixel border around the component) and high-contrast (at least 3:1 between the focused and unfocused states) so it is clearly visible -- a subtle color change on a thin outline is easy for low-vision users to miss. The default browser-drawn indicator is exempt if left unmodified.

Pointer Gestures

For functions operated by multi-point or path-based gestures like pinch-to-zoom or swipe, provide a single-pointer alternative such as zoom buttons or previous/next buttons, since tracing a precise path is hard for users with tremor or limited dexterity. Exempt when the path itself is essential, as with signature input.

Pointer Cancellation

Trigger actions on the up-event (when the pointer is released) rather than the down-event, so users can cancel an accidental press by moving away before releasing. Without this, a mis-tap is committed instantly, which is especially costly for users with limited motor control.

Label in Name

When a control has visible text (like a "Submit" button), make sure that text is included in its accessible name. This lets speech-input users operate controls by speaking the text they see on screen; putting the visible label at the start of the accessible name is best practice.

Motion Actuation

For functions triggered by shaking or tilting the device, provide a conventional UI alternative and let users disable the motion response, so people who mount their device or move it unintentionally are not tripped up by false triggers. Exempt where detecting movement is the essential purpose, as with a step counter.

Target Size (Enhanced)

Make interactive targets at least 44 by 44 CSS pixels -- a stricter AAA version of 2.5.8's 24x24 pixel minimum, intended to make targets easy to hit for users with tremor or larger fingers. Inline links within a sentence and unmodified user-agent-sized controls are exempt.

Concurrent Input Mechanisms

Do not restrict users to a single input mechanism, such as touch-only. Support whichever input methods -- keyboard, mouse, touch, etc. -- the platform provides, since users such as those with tremors or switch-device users may depend on a specific method to interact reliably. Restrictions are allowed when a function is inherently limited to one mechanism, when required for security, or when they reflect a user's own settings.

Dragging Movements

For drag-based operations such as moving a slider thumb, reordering items, or resizing a pane, provide a single-pointer alternative -- like a click or a button -- that does not require dragging. Users with tremors or those relying on switch devices often cannot hold and drag precisely. An exception applies when the drag path itself is essential to the function, such as freehand drawing.

Commentary available

Target Size (Minimum)

Ensure interactive targets are at least 24 by 24 CSS pixels, or leave enough spacing between adjacent targets so their offset areas don't overlap. This keeps targets reliably tappable for people with tremors or limited fine motor control. Inline text links, unmodified native browser controls, and targets with an equivalent larger alternative elsewhere on the page are exempt.

Commentary available

Language of Page

Declare the page's default language (e.g. lang="ja") on the html element so it can be determined programmatically. Screen readers rely on this to apply correct pronunciation and intonation; without it, content may be read in the wrong language or machine translation may degrade.

Language of Parts

Mark up any passage written in a different language (e.g. an English quote) with its own lang attribute. This lets a screen reader switch pronunciation rules for just that passage instead of misreading it in the surrounding language. Proper nouns, technical terms, words of undetermined language, and loanwords absorbed into the surrounding text are exempt.

Unusual Words

For idioms, jargon, or words used in an unusual sense, provide a way to look up their meaning -- a glossary, an inline definition, or a link to a dictionary. This helps a wide range of readers, including people with cognitive or learning disabilities and non-native speakers, follow content that would otherwise be hard to parse.

Abbreviations

For abbreviations -- including acronyms and initialisms -- provide a way to find the expanded form or meaning, such as the abbr element, a glossary, or spelling it out on first use. This lets readers who can't guess the meaning look it up through assistive technology or a dictionary-like mechanism. Abbreviations that have become ordinary words (e.g. "laser") are exempt.

Reading Level

When the body text -- excluding proper names and titles -- requires reading ability beyond lower-secondary education level, provide either supplementary content that clarifies it or a simplified, easier-to-read version. This gives people with cognitive or learning disabilities access to the same essential information.

Pronunciation

For words whose meaning depends on pronunciation (heteronyms, or kanji with multiple readings), provide a way to determine the correct pronunciation when context alone isn't enough. Ruby annotations, an audio reading, or a link to a pronunciation guide are typical ways to satisfy this.

On Focus

Simply moving focus to an element -- a form field, a button -- must not by itself trigger a change of context such as page navigation, a modal opening, or an automatic form submission. Keyboard and screen reader users tab through elements sequentially, so an unexpected change on focus alone easily disorients them.

On Input

Simply checking a box, typing into a field, or picking an option from a select box must not by itself trigger an unexpected change of context such as navigation or auto-submission. If such a change is going to happen, the user must be told about it in advance, before they interact with the control.

Consistent Navigation

Keep navigation mechanisms that repeat across multiple pages of a site, such as a header menu, in the same relative order every time they appear. This lets users predict where to find an item without relearning the layout on each page. Order changes the user makes themselves are exempt.

Consistent Identification

Use the same label, name, or icon for components that perform the same function across pages -- do not call a search button "search" on one page and "find" on another. This lets people with cognitive disabilities and screen reader users recognize a function quickly by its consistent name.

Change on Request

Changes of context -- opening a new window, auto-submitting, or auto-redirecting -- triggered by focus movement or input must occur only when the user explicitly requests them, or a way to stop such changes must be available. This matters most for screen reader users, who can't see the whole page at once and are more easily disoriented by unexpected changes.

Consistent Help

When contact information, chat, FAQ links, or other help mechanisms appear on multiple pages, place them in the same relative order and position on each page. This lets people with cognitive disabilities or first-time visitors find help without hunting for it again on every page. Positions the user has customized themselves are exempt.

Commentary available

Error Identification

When an input error is automatically detected, identify the specific field and describe the error in text. Relying on color or an icon alone fails users who cannot perceive color differences or use a screen reader. Note that automatic error detection is not itself required -- this criterion only kicks in once a site chooses to detect errors.

Labels or Instructions

Every form control that asks for input needs a label or instruction telling users what is expected. Placeholder text disappears once typing starts and is not reliably announced by assistive technology, so it cannot substitute for a real label. When a field is required or expects a specific format (such as a four-digit year), state that explicitly too.

Error Suggestion

When an input error is automatically detected and the likely correction can be inferred, show a concrete suggestion -- for example, "Enter the date as YYYY-MM-DD". Where 3.3.1 only requires pointing out what's wrong, this criterion goes further and says how to fix it. Password fields and similar cases are exempt, since revealing the correct value would defeat the field's purpose.

Error Prevention (Legal, Financial, Data)

For actions with serious, hard-to-reverse consequences -- finalizing a contract or payment, deleting or changing user-controlled data, or submitting test answers -- offer at least one of three safeguards: the action can be undone, the input is automatically checked for errors, or the user can review and confirm before submitting. Only one of the three is required; a confirmation screen before final submission is the most common way to satisfy it.

Help

Provide help -- instructions or a way to contact support -- that is tied to the specific field or task the user is working on, so they don't have to abandon what they're doing to hunt for help elsewhere. A generic link to a site-wide FAQ page does not satisfy this on its own. This Level AAA criterion particularly benefits users with cognitive or learning disabilities.

Error Prevention (All)

Apply the same three safeguards as 3.3.4 -- reversible, automatically checked, or confirmed before submission -- to essentially any page that asks users to submit information. Unlike 3.3.4, this is not limited to legal, financial, or data-related actions; it also covers seemingly low-risk forms like comments or newsletter signups. This Level AAA criterion is optional, but it reduces the damage from accidental submissions site-wide.

Redundant Entry

Within the same multi-step process, information the user already entered should be auto-filled or offered as a selectable option, not typed again from scratch. The burden of re-entering the same data twice falls hardest on people with cognitive, memory, or motor impairments. Exceptions apply when re-entry is essential to the task (such as a password-confirmation field), required for security, or the earlier value is no longer valid.

Commentary available

Accessible Authentication (Minimum)

Do not make login or other authentication steps rely solely on a cognitive function test -- a task like memorizing a password or transcribing text from an image -- as the only way through. Avoid blocking paste (e.g. via onpaste) or otherwise interfering with password managers. At this Minimum level, object-recognition CAPTCHAs ("pick the photos with a car") and identifying content the user previously provided are still allowed as exceptions.

Commentary available

Accessible Authentication (Enhanced)

No step of an authentication process may require a cognitive function test -- memorization, calculation, or puzzle-solving. Unlike 3.3.8, this Enhanced level does not even allow the object-recognition CAPTCHA or personal-content exceptions. In practice, meeting this criterion means offering a genuinely cognition-free alternative, such as a passkey or biometric login.

Name, Role, Value

Every UI component must expose its name, role, and current state or value programmatically to assistive technology -- and any later change to that state or value must also be announced. Standard HTML elements like button and input already satisfy this natively, so the real work is adding the right ARIA attributes to custom widgets built from generic elements like div or span.

Status Messages

Convey status changes -- "Saved", "3 results found" -- to assistive technology without moving the user's focus, typically via a live region (aria-live, role="status", etc.). A common technique is to place the container in the DOM ahead of time and insert the message into it, since some browser/screen-reader combinations won't reliably announce text added to an element that appears at the same moment. Notifications that involve an actual change of context, such as a full page reload, fall outside this criterion.