WCAG 2.2 success criteria list: all 86, explained in plain English
WCAG 2.2 has 86 success criteria: 31 at Level A, 24 at Level AA and 31 at Level AAA, organized under 4 principles and 13 guidelines. Nine are new in 2.2, and 4.1.1 Parsing was removed. Laws that name a level usually require AA, often of WCAG 2.0 or 2.1 rather than 2.2.
Published . Last reviewed .
Every success criterion below is listed in the order of the WCAG 2.2 Recommendation, with its exact number, name and level as W3C publishes them. The one-sentence summaries are ours, written to be read quickly; where the wording matters, the W3C text and its Understanding page are the authority, and each row links to both. To filter the criteria by level, use the W3C Quick Reference.
WCAG 2.2 at a glance
The Web Content Accessibility Guidelines (WCAG) are published by the W3C. WCAG 2.2 became a W3C Recommendation on October 5, 2023, and an update was published on December 12, 2024, according to W3C's WCAG overview. The same page states that WCAG 2.2 is also an ISO standard, ISO/IEC 40500:2025, which matches the October 2023 version.
The document has three layers that matter for conformance. Four principles (perceivable, operable, understandable, robust) sit at the top. Under them are 13 guidelines, which W3C describes as goals and says are not themselves testable. Under the guidelines are the success criteria: the testable requirements, each assigned a level. This page has one section per principle, one heading per guideline and one table per guideline.
| Level | Criteria at this level | Criteria a page must meet at this level |
|---|---|---|
| A | 31 | All 31 Level A criteria |
| AA | 24 | All Level A and AA criteria: 55 in total |
| AAA | 31 | All 86 criteria |
Levels are cumulative, and meeting the criteria is not the whole test. Conformance also requires the whole page and every page in a process to meet the criteria, with technology used in accessibility-supported ways that do not interfere with the rest of the page, and a page may instead offer a conforming alternate version (WCAG 2.2 section 5.2, conformance requirements). W3C also advises against requiring Level AAA as a general policy for entire sites, because some content cannot meet every AAA criterion.
The 55 Level A and AA criteria at a glance
Most laws and policies that name a level ask for AA, which means every criterion in both lists below. Each name links to its row in the tables further down.
Level A (31 criteria):
- 1.1.1 Non-text Content
- 1.2.1 Audio-only and Video-only (Prerecorded)
- 1.2.2 Captions (Prerecorded)
- 1.2.3 Audio Description or Media Alternative (Prerecorded)
- 1.3.1 Info and Relationships
- 1.3.2 Meaningful Sequence
- 1.3.3 Sensory Characteristics
- 1.4.1 Use of Color
- 1.4.2 Audio Control
- 2.1.1 Keyboard
- 2.1.2 No Keyboard Trap
- 2.1.4 Character Key Shortcuts
- 2.2.1 Timing Adjustable
- 2.2.2 Pause, Stop, Hide
- 2.3.1 Three Flashes or Below Threshold
- 2.4.1 Bypass Blocks
- 2.4.2 Page Titled
- 2.4.3 Focus Order
- 2.4.4 Link Purpose (In Context)
- 2.5.1 Pointer Gestures
- 2.5.2 Pointer Cancellation
- 2.5.3 Label in Name
- 2.5.4 Motion Actuation
- 3.1.1 Language of Page
- 3.2.1 On Focus
- 3.2.2 On Input
- 3.2.6 Consistent Help
- 3.3.1 Error Identification
- 3.3.2 Labels or Instructions
- 3.3.7 Redundant Entry
- 4.1.2 Name, Role, Value
Level AA (24 criteria):
- 1.2.4 Captions (Live)
- 1.2.5 Audio Description (Prerecorded)
- 1.3.4 Orientation
- 1.3.5 Identify Input Purpose
- 1.4.3 Contrast (Minimum)
- 1.4.4 Resize Text
- 1.4.5 Images of Text
- 1.4.10 Reflow
- 1.4.11 Non-text Contrast
- 1.4.12 Text Spacing
- 1.4.13 Content on Hover or Focus
- 2.4.5 Multiple Ways
- 2.4.6 Headings and Labels
- 2.4.7 Focus Visible
- 2.4.11 Focus Not Obscured (Minimum)
- 2.5.7 Dragging Movements
- 2.5.8 Target Size (Minimum)
- 3.1.2 Language of Parts
- 3.2.3 Consistent Navigation
- 3.2.4 Consistent Identification
- 3.3.3 Error Suggestion
- 3.3.4 Error Prevention (Legal, Financial, Data)
- 3.3.8 Accessible Authentication (Minimum)
- 4.1.3 Status Messages
Which level do laws require?
Where a law or regulation names a WCAG level, it is usually AA, but often of an older version than 2.2. A few examples from primary sources:
- The US ADA Title II rule for state and local governments requires WCAG 2.1 Level AA, with compliance dates of April 26, 2027 and April 26, 2028 depending on population size (ADA.gov fact sheet; see our ADA Title II deadline guide).
- US Section 508, for federal agencies, references WCAG 2.0 Level A and AA (US Access Board ICT standards).
- In the EU, EN 301 549 v3.2.1 is the referenced standard and is aligned to WCAG 2.1 Level AA. Version 4.1.1, aligned to WCAG 2.2, was published on September 2, 2026 but is not yet cited in the EU Official Journal (AccessibleEU). See EN 301 549 explained and our European Accessibility Act guide.
- Ontario's AODA requires WCAG 2.0 Level AA, excluding 1.2.4 and 1.2.5 (Ontario government guidance).
- UK government guidance for public sector websites names WCAG 2.2 Level AA (GOV.UK).
Meeting WCAG 2.2 also meets 2.1 and 2.0, with one caveat: W3C notes that authors required by policy to conform to WCAG 2.0 or 2.1 may still need to test and report 4.1.1 Parsing, which 2.2 removed (WCAG 2.2, comparison with 2.1). This is general information, not legal advice. For the full picture by country, see web accessibility laws worldwide, which WCAG version the law requires, the laws for the United States, the European Union, the United Kingdom and Canada, ADA website compliance for businesses, or answer a few questions in which accessibility laws apply to you.
What changed in WCAG 2.2
WCAG 2.2 added nine success criteria (W3C: What's new in WCAG 2.2). Each is marked "New in 2.2" in the tables below:
- 2.4.11 Focus Not Obscured (Minimum) (Level AA)
- 2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
- 2.4.13 Focus Appearance (Level AAA)
- 2.5.7 Dragging Movements (Level AA)
- 2.5.8 Target Size (Minimum) (Level AA)
- 3.2.6 Consistent Help (Level A)
- 3.3.7 Redundant Entry (Level A)
- 3.3.8 Accessible Authentication (Minimum) (Level AA)
- 3.3.9 Accessible Authentication (Enhanced) (Level AAA)
It also removed one: 4.1.1 Parsing, now marked obsolete and removed. It stays in the list below, explained once, because many older policies and audit reports still refer to it. The arithmetic follows: WCAG 2.1 has 78 success criteria (30 at Level A, 20 at AA and 28 at AAA, counted from the W3C Recommendation and including 4.1.1), and 78 plus 9 new, minus 4.1.1, gives the 86 in WCAG 2.2. New criteria were added at the end of their guideline so that existing numbers did not change. The order within a guideline says nothing about level; only the level shown for each criterion does. Our guide to what's new in WCAG 2.2 covers the nine in more depth.
How we rated "can software test it?"
The testability column is GotAlt's own assessment, made criterion by criterion from what each requirement asks for and from what rule-based and AI checks can and cannot see. It is not part of WCAG, and other testers may place some criteria differently. We use three categories, and the removed 4.1.1 row is marked Not applicable:
- Automated: the requirement is a measurable property of the code or the rendered page, so software can decide pass or fail for most content. A person still reviews the edge cases a tool reports.
- Partly automated: software can find some real failures, such as a missing label or a missing title, but cannot confirm a pass, because meeting the criterion depends on meaning, context or behavior.
- Manual: a person has to judge the content or operate the page. Tools can at most point to where to look.
By this assessment, 3 of the 86 criteria are automated, 32 are partly automated and 51 are manual. Measured another way, Karl Groves found that an automated tool "can definitively test for approximately 25-29% of best practices for WCAG 2.0" and "cannot test for approximately 40%" (Karl Groves, Automated lies, with one line of code). That figure counts best practices for WCAG 2.0, not 2.2 criteria, so the two are not directly comparable. Our methodology page lists every rule GotAlt runs and what it cannot detect, why rule scanners miss issues explains the gap, and our editorial policy sets out how pages like this are sourced and reviewed.
Where a GotAlt tool helps with a criterion, the row names it. A tool that helps is not a pass: every one of them checks part of a criterion, and the row says which part.
The 86 criteria by principle and guideline
Principle 1: Perceivable
People can perceive the information and the interface, whichever senses they rely on. W3C text: Principle 1 in WCAG 2.2.
Guideline 1.1 Text Alternatives
Give anything that is not text a text alternative, so it can become speech, braille, large print or simpler language. Understanding Guideline 1.1
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 1.1.1 Non-text Content | A | Every image, icon, chart or other non-text item has a text alternative that does the same job, and purely decorative images are hidden from assistive technology. GotAlt: alt text checker, alt text generator, deep audit, accessibility bookmarklet, the free scan, and the PDF checker for figures in PDFs. See also our alt text guide. | Partly automated. Software finds missing alt text; only a person, or a model that looks at the image, can say whether the words match the picture. | Understanding 1.1.1 |
Guideline 1.2 Time-based Media
Offer alternatives for audio and video. Understanding Guideline 1.2
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Recorded audio-only content has a transcript, and recorded video with no sound has a transcript or an audio track that gives the same information, unless the media is itself an alternative for text on the page. | Manual. A tool cannot tell what a recording contains or whether an alternative matches it. | Understanding 1.2.1 |
| 1.2.2 Captions (Prerecorded) | A | Recorded video with sound has captions for the speech and other important sounds, unless the media is itself an alternative for text on the page. | Partly automated. Software can flag a video element with no caption track; a person must check that captions exist in the player and are accurate. | Understanding 1.2.2 |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Recorded video has audio description of important visual content, or a full text alternative. | Manual. Deciding what visual information needs describing is a judgment. | Understanding 1.2.3 |
| 1.2.4 Captions (Live) | AA | Live video with sound carries captions in real time. | Manual. Live captions can only be checked while the stream is running. | Understanding 1.2.4 |
| 1.2.5 Audio Description (Prerecorded) | AA | Recorded video has audio description of important visual content. At this level a text alternative alone is not enough. | Manual. Deciding what visual information needs describing is a judgment. | Understanding 1.2.5 |
| 1.2.6 Sign Language (Prerecorded) | AAA | Recorded audio in video has sign language interpretation. | Manual. A person has to confirm the interpretation is there and covers the content. | Understanding 1.2.6 |
| 1.2.7 Extended Audio Description (Prerecorded) | AAA | Where natural pauses are too short for description, the video pauses so a longer description can play. | Manual. Needs a person to watch the video with its description. | Understanding 1.2.7 |
| 1.2.8 Media Alternative (Prerecorded) | AAA | Recorded video, with or without sound, has a full text alternative, similar to a screenplay. | Manual. A tool cannot judge whether a text version is complete. | Understanding 1.2.8 |
| 1.2.9 Audio-only (Live) | AAA | Live audio-only content, such as a live radio stream, has a text alternative that gives the same information. | Manual. Only checkable during the live event. | Understanding 1.2.9 |
Guideline 1.3 Adaptable
Build content so it can be presented in other ways, such as a simpler layout, without losing information or structure. Understanding Guideline 1.3
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 1.3.1 Info and Relationships | A | Structure shown visually, such as headings, lists, tables and form labels, is also in the code, so assistive technology can pass it on. GotAlt: heading checker, accessibility bookmarklet, the free scan, and the PDF checker for tags, headings and tables in PDFs. | Partly automated. Software catches missing labels, broken table markup and heading problems such as skipped levels (a best practice, not a 1.3.1 failure on its own); whether all visual structure is coded needs a person. | Understanding 1.3.1 |
| 1.3.2 Meaningful Sequence | A | When order changes the meaning, the reading order in the code matches the order that makes sense. | Manual. Comparing the visual order with the code order needs a judgment about meaning. | Understanding 1.3.2 |
| 1.3.3 Sensory Characteristics | A | Instructions do not rely only on shape, color, size, position, orientation or sound, for example "press the round button". | Manual. A person has to read instructions in context. | Understanding 1.3.3 |
| 1.3.4 Orientation | AA | Content works in both portrait and landscape, unless one orientation is essential. | Partly automated. Software can find code that locks the orientation; whether the lock is essential is a judgment. | Understanding 1.3.4 |
| 1.3.5 Identify Input Purpose | AA | Form fields that collect information about the user, such as name, email or address, declare that purpose in code (usually the autocomplete attribute). | Partly automated. Software can check that autocomplete values are valid; deciding which fields collect personal data needs a person. | Understanding 1.3.5 |
| 1.3.6 Identify Purpose | AAA | In markup, the purpose of interface components, icons and page regions can be determined by software, so content can be adapted to the user. | Partly automated. Software can check that landmark regions exist; full coverage of components and icons needs a person. | Understanding 1.3.6 |
Guideline 1.4 Distinguishable
Make content easy to see and hear, including separating it clearly from its background. Understanding Guideline 1.4
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 1.4.1 Use of Color | A | Color is never the only way information is shown, such as a required field or an error marked only in red. | Partly automated. Software can flag links told apart from text by color alone; other uses of color need a person to interpret. | Understanding 1.4.1 |
| 1.4.2 Audio Control | A | Audio that plays automatically for more than 3 seconds can be paused or stopped, or its volume set separately from the system volume. GotAlt: the free scan flags autoplaying audio and video. | Partly automated. Software can find media set to autoplay; whether a working control exists needs a check. | Understanding 1.4.2 |
| 1.4.3 Contrast (Minimum) | AA | Text has a contrast ratio of at least 4.5:1 against its background, or 3:1 for large text. Logos, decoration and inactive controls are exempt. GotAlt: contrast checker for a color pair, image contrast checker for text on images, and the accessibility bookmarklet for text on a live page. | Automated. The ratio is a calculation; text over images, gradients or video still needs a person to judge. | Understanding 1.4.3 |
| 1.4.4 Resize Text | AA | Text can be enlarged to 200 percent without assistive technology and without losing content or function. Captions and images of text are excepted. GotAlt: the free scan flags zoom disabled in the viewport meta tag. | Partly automated. Software can flag zoom disabled in the viewport tag; spotting clipped or overlapping text at 200 percent needs a person. | Understanding 1.4.4 |
| 1.4.5 Images of Text | AA | Real text is used instead of pictures of text, unless the picture can be customized by the user or the exact look is essential, as in a logo. | Manual. Finding text inside images and judging whether it could be real text needs a person. | Understanding 1.4.5 |
| 1.4.6 Contrast (Enhanced) | AAA | Text has a contrast ratio of at least 7:1 against its background, or 4.5:1 for large text, with the same exemptions as 1.4.3. GotAlt: contrast checker and image contrast checker. | Automated. The ratio is a calculation; text over images, gradients or video still needs a person to judge. | Understanding 1.4.6 |
| 1.4.7 Low or No Background Audio | AAA | Recorded audio-only content that is mainly speech (not a CAPTCHA, audio logo or singing) has no background sound, a way to turn it off, or background sound at least 20 decibels quieter than the speech, apart from occasional sounds of a second or two. | Manual. Needs listening or audio analysis of each recording. | Understanding 1.4.7 |
| 1.4.8 Visual Presentation | AAA | For blocks of text, users can choose colors, and there is a way to get lines of no more than 80 characters, no justified text, wider spacing, and 200 percent text without horizontal scrolling. | Partly automated. Software can measure line length and justified text; the parts users control need a person to check. | Understanding 1.4.8 |
| 1.4.9 Images of Text (No Exception) | AAA | Pictures of text are used only for decoration or where the exact look is essential. | Manual. Finding text inside images and judging whether it is essential needs a person. | Understanding 1.4.9 |
| 1.4.10 Reflow | AA | Content fits a screen 320 CSS pixels wide (about 400 percent zoom on a 1280 pixel window), or 256 CSS pixels tall for content that scrolls sideways, without scrolling in two directions, except content such as maps, diagrams, video and data tables. | Partly automated. Software can detect sideways scrolling at that width; whether content or function is lost needs a person. | Understanding 1.4.10 |
| 1.4.11 Non-text Contrast | AA | The visual parts needed to identify controls and their states, and the parts of graphics needed to understand them, have at least 3:1 contrast against neighboring colors. GotAlt: contrast checker for a color pair. | Partly automated. The ratio is measurable, but deciding which pixels identify a control or carry meaning needs judgment. | Understanding 1.4.11 |
| 1.4.12 Text Spacing | AA | Nothing is cut off or overlaps when users increase line height, paragraph, letter and word spacing to the amounts WCAG sets. | Partly automated. A tool can apply the spacing; spotting lost or overlapping content still needs a person to look. | Understanding 1.4.12 |
| 1.4.13 Content on Hover or Focus | AA | Tooltips and pop-ups that appear on hover or focus can be dismissed without moving away, can be hovered over themselves, and stay visible until the user moves away or dismisses them. | Manual. Needs a person to trigger each pop-up with a mouse and a keyboard. | Understanding 1.4.13 |
Principle 2: Operable
People can operate the interface and move around it, whichever input they use. W3C text: Principle 2 in WCAG 2.2.
Guideline 2.1 Keyboard Accessible
Everything works from a keyboard. Understanding Guideline 2.1
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 2.1.1 Keyboard | A | Everything can be done with a keyboard alone, without precise timing, unless the function depends on the path of movement, such as freehand drawing. | Partly automated. Software can flag some controls that cannot take keyboard focus; confirming everything works needs a person with a keyboard. | Understanding 2.1.1 |
| 2.1.2 No Keyboard Trap | A | Keyboard focus never gets stuck inside a component; if leaving needs anything beyond standard keys, users are told how. | Manual. A trap only shows when someone tabs through the page. | Understanding 2.1.2 |
| 2.1.3 Keyboard (No Exception) | AAA | Everything can be done with a keyboard, with no exception for path-based input. | Partly automated. Software can flag some controls that cannot take keyboard focus; confirming everything works needs a person with a keyboard. | Understanding 2.1.3 |
| 2.1.4 Character Key Shortcuts | A | Single-key shortcuts (a letter, number, punctuation or symbol key) can be turned off, remapped to include a key such as Ctrl or Alt, or only work when their control has focus. | Manual. Shortcuts are found by testing the page or reading its scripts. | Understanding 2.1.4 |
Guideline 2.2 Enough Time
Give people enough time to read and use content. Understanding Guideline 2.2
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 2.2.1 Timing Adjustable | A | Users can turn off, adjust or extend time limits, with exceptions for real-time events, essential limits and limits longer than 20 hours. GotAlt: the free scan flags a timed meta refresh. | Partly automated. Software can flag a timed page refresh; other time limits live in scripts and need testing. | Understanding 2.2.1 |
| 2.2.2 Pause, Stop, Hide | A | Moving, blinking, scrolling or auto-updating content that starts on its own and runs alongside other content can be paused, stopped or hidden or, for auto-updating content, the update frequency controlled. For motion, this applies when it lasts more than five seconds. | Partly automated. Software can flag a few known patterns; most motion comes from scripts and needs a person to watch. | Understanding 2.2.2 |
| 2.2.3 No Timing | AAA | Timing is not an essential part of any activity, except non-interactive media and real-time events. | Manual. Needs a person to work through each task. | Understanding 2.2.3 |
| 2.2.4 Interruptions | AAA | Users can postpone or turn off interruptions, such as updates, except in an emergency. | Manual. Needs a person to use the page over time. | Understanding 2.2.4 |
| 2.2.5 Re-authenticating | AAA | When a signed-in session expires, users can sign in again and carry on without losing data. | Manual. Needs a person to let a session expire and sign back in. | Understanding 2.2.5 |
| 2.2.6 Timeouts | AAA | Users are warned how long they can be inactive before data is lost, unless the data is kept for more than 20 hours. | Manual. Depends on server behavior a page scan cannot see. | Understanding 2.2.6 |
Guideline 2.3 Seizures and Physical Reactions
Avoid content known to cause seizures or physical reactions. Understanding Guideline 2.3
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 2.3.1 Three Flashes or Below Threshold | A | Nothing flashes more than three times in any one second, unless the flashing is below the general flash and red flash thresholds. | Partly automated. Video analysis software can measure flashes; someone still has to find and run every animation and video. | Understanding 2.3.1 |
| 2.3.2 Three Flashes | AAA | Nothing flashes more than three times in any one second, with no threshold exception. | Partly automated. Video analysis software can count flashes; someone still has to find and run every animation and video. | Understanding 2.3.2 |
| 2.3.3 Animation from Interactions | AAA | Motion animation triggered by interaction, such as parallax effects on scroll, can be turned off unless it is essential. | Manual. Needs a person to interact with the page and judge what is essential. | Understanding 2.3.3 |
Guideline 2.4 Navigable
Help people navigate, find content and know where they are. Understanding Guideline 2.4
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 2.4.1 Bypass Blocks | A | There is a way to skip blocks repeated across pages, such as a skip link, landmark regions or headings. | Partly automated. Software can find skip links, landmarks and headings; whether they actually work needs a check. | Understanding 2.4.1 |
| 2.4.2 Page Titled | A | Each page has a title that describes its topic or purpose. GotAlt: the free scan and the accessibility bookmarklet flag a missing title; the PDF checker checks PDF titles. | Partly automated. A missing title is detectable; whether it describes the page is a judgment. | Understanding 2.4.2 |
| 2.4.3 Focus Order | A | When people move through a page with the keyboard, focus follows an order that keeps the meaning and operation intact. GotAlt: the free scan flags positive tabindex values. | Partly automated. Software can flag positive tabindex values; the order itself needs a person to tab through. | Understanding 2.4.3 |
| 2.4.4 Link Purpose (In Context) | A | The purpose of each link is clear from its text, or from its text together with its programmatically related context, such as the sentence or list item around it. GotAlt: link text checker, accessibility bookmarklet, deep audit and the free scan. | Partly automated. Software finds empty links and generic text such as "click here"; judging whether the context makes the purpose clear needs a reader. | Understanding 2.4.4 |
| 2.4.5 Multiple Ways | AA | There is more than one way to find a page in a site, such as navigation, search or a site map, except for pages that are a step in a process. | Manual. Requires looking across the whole site. | Understanding 2.4.5 |
| 2.4.6 Headings and Labels | AA | Headings and labels describe the topic or purpose of what they introduce. This does not require headings to exist; it sets a bar for the ones that do. GotAlt: the heading checker lists every heading for review, and the deep audit reads headings and link text and flags weak ones. | Manual. Whether the words describe the content is a judgment. | Understanding 2.4.6 |
| 2.4.7 Focus Visible | AA | Keyboard users can see which element has focus. | Partly automated. Software can flag CSS that removes the focus outline; whether a visible indicator remains needs a person to tab through. | Understanding 2.4.7 |
| 2.4.8 Location | AAA | Users can tell where they are within a set of pages, for example from breadcrumbs or a highlighted menu item. | Manual. Requires a person to judge across pages. | Understanding 2.4.8 |
| 2.4.9 Link Purpose (Link Only) | AAA | The purpose of each link can be identified from the link text alone, through a mechanism if needed, except where it would be ambiguous to everyone. GotAlt: link text checker. | Partly automated. Software finds empty and generic link text; whether the text alone is clear needs a reader. | Understanding 2.4.9 |
| 2.4.10 Section Headings | AAA | Long content is broken into sections, each with its own heading. | Manual. Whether content is divided into sensible sections is a judgment. | Understanding 2.4.10 |
| 2.4.11 Focus Not Obscured (Minimum) New in 2.2 |
AA | When an element receives keyboard focus, it is not entirely hidden by content the site added, such as a sticky header, cookie banner or chat panel. | Manual. Depends on layout, scroll position and overlays at the moment of focus. | Understanding 2.4.11 |
| 2.4.12 Focus Not Obscured (Enhanced) New in 2.2 |
AAA | When an element receives keyboard focus, no part of it is hidden by content the site added. | Manual. Depends on layout, scroll position and overlays at the moment of focus. | Understanding 2.4.12 |
| 2.4.13 Focus Appearance New in 2.2 |
AAA | A visible focus indicator has an area at least as large as a 2 CSS pixel thick perimeter of the unfocused element, and at least 3:1 contrast between its focused and unfocused states, unless the browser's own, unmodified focus indicator is used. | Partly automated. Size and contrast can be measured in a rendered page, but each focus state has to be triggered first. | Understanding 2.4.13 |
Guideline 2.5 Input Modalities
Make functions easy to operate with inputs other than a keyboard, such as touch and pointer. Understanding Guideline 2.5
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 2.5.1 Pointer Gestures | A | Anything operated with multi-finger or path-based gestures, such as a pinch or a swipe along a path, also works with a single pointer without a path, unless the gesture is essential. | Manual. Needs a person to find gestures and try the alternative. | Understanding 2.5.1 |
| 2.5.2 Pointer Cancellation | A | Accidental taps and clicks can be canceled: the action does not fire on press down, or it fires on release and can be aborted or undone, or releasing reverses the press, unless firing on press is essential. | Manual. Needs a person to test how each control responds to press and release. | Understanding 2.5.2 |
| 2.5.3 Label in Name | A | A control's accessible name includes the text of its visible label, so speech-input users can say what they see. | Partly automated. Software can compare visible text with the accessible name; labels drawn as images and edge cases need a person. | Understanding 2.5.3 |
| 2.5.4 Motion Actuation | A | Features triggered by shaking or tilting the device also work through on-screen controls, and the motion response can be turned off. | Manual. Needs a person with a device to find and test motion features. | Understanding 2.5.4 |
| 2.5.5 Target Size (Enhanced) | AAA | Pointer targets are at least 44 by 44 CSS pixels, with exceptions for targets in text, equivalent larger controls, browser-controlled targets and essential presentation. | Partly automated. Sizes are measurable in a rendered page; the exceptions need judgment. | Understanding 2.5.5 |
| 2.5.6 Concurrent Input Mechanisms | AAA | Content does not restrict which input methods a user can switch between, such as touch, mouse or keyboard, except for essential, security or user-setting reasons. | Manual. Needs a person to try each input method. | Understanding 2.5.6 |
| 2.5.7 Dragging Movements New in 2.2 |
AA | Anything done by dragging can also be done with a single pointer without dragging, such as tapping or clicking, unless dragging is essential. | Manual. Needs a person to find drag interactions and try the alternative. | Understanding 2.5.7 |
| 2.5.8 Target Size (Minimum) New in 2.2 |
AA | Pointer targets are at least 24 by 24 CSS pixels, or spaced so that 24 CSS pixel circles centered on small targets do not overlap another target or each other, with exceptions for equivalent controls, targets in text, browser-controlled and essential targets. | Partly automated. Sizes and spacing are measurable in a rendered page; the exceptions need judgment. | Understanding 2.5.8 |
Principle 3: Understandable
People can understand both the information and how the interface works. W3C text: Principle 3 in WCAG 2.2.
Guideline 3.1 Readable
Make text readable and understandable. Understanding Guideline 3.1
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 3.1.1 Language of Page | A | The main language of each page is declared in code, for example a lang attribute on the html element. GotAlt: the free scan, the accessibility bookmarklet, and the PDF checker for PDF language. | Automated. A missing or invalid language attribute is detectable; a quick look confirms it matches the text. | Understanding 3.1.1 |
| 3.1.2 Language of Parts | AA | Passages in a different language from the rest of the page are marked with their own language, apart from proper names, technical terms and borrowed words. | Partly automated. Software can validate language codes; finding unmarked foreign passages needs a reader. | Understanding 3.1.2 |
| 3.1.3 Unusual Words | AAA | There is a way to find definitions of jargon, idioms and words used in an unusual or restricted way. | Manual. Requires a reader to spot unusual usage. | Understanding 3.1.3 |
| 3.1.4 Abbreviations | AAA | There is a way to find the expanded form or meaning of abbreviations. | Manual. Requires a reader to spot abbreviations and check for expansions. | Understanding 3.1.4 |
| 3.1.5 Reading Level | AAA | When text needs reading ability beyond lower secondary education, supplemental content or a simpler version is available. | Manual. Readability formulas give a rough signal; the decision needs a person. | Understanding 3.1.5 |
| 3.1.6 Pronunciation | AAA | There is a way to find the pronunciation of words whose meaning is unclear without it. | Manual. Requires a reader to spot ambiguous words. | Understanding 3.1.6 |
Guideline 3.2 Predictable
Make pages look and behave in predictable ways. Understanding Guideline 3.2
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 3.2.1 On Focus | A | Moving focus onto an element does not trigger a change of context, such as opening a new window or submitting a form. | Manual. Needs a person to move focus through the page. | Understanding 3.2.1 |
| 3.2.2 On Input | A | Changing a setting, such as choosing an option from a drop-down, does not cause a change of context unless users were told beforehand. | Manual. Needs a person to operate each control. | Understanding 3.2.2 |
| 3.2.3 Consistent Navigation | AA | Navigation repeated across pages appears in the same relative order each time, unless the user changes it. | Manual. Requires comparing pages across the site. | Understanding 3.2.3 |
| 3.2.4 Consistent Identification | AA | Components that do the same thing are identified the same way across pages, such as a search button labeled the same everywhere. | Manual. Requires comparing components across the site. | Understanding 3.2.4 |
| 3.2.5 Change on Request | AAA | Changes of context happen only when the user asks for them, or there is a way to turn them off. | Manual. Needs a person to operate the page. | Understanding 3.2.5 |
| 3.2.6 Consistent Help New in 2.2 |
A | If help such as contact details, a contact form or chat, or a self-help page is repeated across pages, it appears in the same relative order each time. | Manual. Requires comparing pages across the site. | Understanding 3.2.6 |
Guideline 3.3 Input Assistance
Help people avoid mistakes and correct them. Understanding Guideline 3.3
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 3.3.1 Error Identification | A | When a form detects a mistake automatically, it says in text which field is wrong and what the problem is. | Manual. Needs a person to submit forms with mistakes and read the messages. | Understanding 3.3.1 |
| 3.3.2 Labels or Instructions | A | Fields and controls that need user input have labels or instructions. GotAlt: the free scan and the accessibility bookmarklet flag unlabeled fields; the PDF checker checks PDF form fields. | Partly automated. Software finds fields with no label; whether the label or instructions are enough needs a person. | Understanding 3.3.2 |
| 3.3.3 Error Suggestion | AA | When an input error is detected and a correction is known, the suggestion is shown to the user, unless that would undermine security or the purpose of the content. | Manual. Needs a person to submit forms with mistakes and judge the suggestions. | Understanding 3.3.3 |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | For submissions with legal or financial consequences, that change or delete stored data, or that submit test answers, users can reverse, check or confirm before finalizing. | Manual. Needs a person to walk through each such process. | Understanding 3.3.4 |
| 3.3.5 Help | AAA | Help relevant to the current task is available. | Manual. Whether help fits the context is a judgment. | Understanding 3.3.5 |
| 3.3.6 Error Prevention (All) | AAA | Any submission of information can be reversed, checked or confirmed before it is final. | Manual. Needs a person to walk through each form. | Understanding 3.3.6 |
| 3.3.7 Redundant Entry New in 2.2 |
A | Information already entered or provided in the same process is filled in or offered for selection rather than typed again, unless re-entry is essential, needed for security, or the earlier entry is no longer valid. | Manual. Needs a person to walk through each multi-step process. | Understanding 3.3.7 |
| 3.3.8 Accessible Authentication (Minimum) New in 2.2 |
AA | Signing in does not require a cognitive function test, such as remembering a password or solving a puzzle, unless there is an alternative, help such as allowing password managers and paste, or the test is recognizing objects or the user's own content. | Manual. Needs a person to walk through the sign-in process. | Understanding 3.3.8 |
| 3.3.9 Accessible Authentication (Enhanced) New in 2.2 |
AAA | The same as 3.3.8, without the exceptions for recognizing objects or the user's own content. | Manual. Needs a person to walk through the sign-in process. | Understanding 3.3.9 |
Principle 4: Robust
Content works reliably with a wide range of browsers and assistive technologies, now and later. W3C text: Principle 4 in WCAG 2.2.
Guideline 4.1 Compatible
Work with current and future browsers and assistive technologies. Understanding Guideline 4.1
| Success criterion | Level | What it means | Can software test it? | W3C guidance |
|---|---|---|---|---|
| 4.1.1 Parsing (Obsolete and removed) | Removed | Removed. It covered markup errors that assistive technology once tripped over when reading HTML directly. W3C states that this no longer happens, so the criterion has no remaining use. Sites held to WCAG 2.0 or 2.1 by a policy may still need to test and report it. GotAlt: the free scan still lists duplicate id attributes under 4.1.1; see what we check. | Not applicable. Not a WCAG 2.2 requirement. | Understanding 4.1.1 |
| 4.1.2 Name, Role, Value | A | Every interface component, including custom controls built with scripts, exposes its name and role to assistive technology; settable states and values can be set, and changes are announced. GotAlt: the free scan flags links, buttons and frames with no name, and hidden elements that can still take focus. | Partly automated. Software finds controls with no accessible name and invalid ARIA; whether custom widgets behave correctly needs testing with assistive technology. | Understanding 4.1.2 |
| 4.1.3 Status Messages | AA | Status messages, such as "added to cart" or a search result count, are announced by assistive technology without moving focus. | Manual. Needs a person to trigger each message and listen with a screen reader. | Understanding 4.1.3 |
Where to start
Most sites are measured against Level A and AA, so start with those rows and leave AAA for content where it makes sense. Run the free scan to find the failures software can see, then work through the manual rows with a keyboard and a screen reader. Our WCAG 2.2 checklist turns the most common A and AA failures into a working list, and if you sell on Shopify, our Shopify accessibility guide covers the alt text problems specific to stores. When you publish an accessibility statement, the statement generator gives you a plain-text draft to review. If you have received a legal letter, read our guide to accessibility demand letters first.
An overlay widget does not make a site meet these criteria. The FTC's final order against accessiBe, issued April 21, 2025 with a $1,000,000 payment, concerned its claims that the product would make websites meet WCAG (FTC press release). Our overlays comparison covers the rest.
What this page is not
This page is general information about a technical standard, not legal advice, and not a conformance test. The summaries simplify the W3C text, so check the linked W3C pages before relying on any detail. No automated tool, GotAlt included, can tell you that a site meets WCAG 2.2: a large share of the criteria need a person.
WCAG 2.2 success criteria: common questions
How many success criteria are in WCAG 2.2?
86: 31 at Level A, 24 at Level AA and 31 at Level AAA. Level AA conformance means meeting all 55 Level A and AA criteria. The W3C document still shows 4.1.1 Parsing, marked obsolete and removed, but it is not a requirement and is not in the count.
Which success criteria are new in WCAG 2.2?
Nine: 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum) and 3.3.9 Accessible Authentication (Enhanced). Two are Level A, four are Level AA and three are Level AAA.
Which WCAG level do I need to meet?
Where a law or regulation names a level, it is usually AA, though often of WCAG 2.0 or 2.1 rather than 2.2. The US ADA Title II rule, for example, requires WCAG 2.1 Level AA. W3C advises against requiring AAA as a general policy for whole sites. This is general information, not legal advice; the rule that applies to you depends on where you operate and who you serve.
If my site meets WCAG 2.2, does it also meet WCAG 2.1 and 2.0?
W3C says that sites conforming to WCAG 2.2 are intended to conform to 2.0 and 2.1 as well, because 2.2 keeps the earlier criteria. The one exception is 4.1.1 Parsing: it was removed in 2.2, so a policy that still cites 2.0 or 2.1 may require you to test and report it.
Can an automated tool test every WCAG 2.2 success criterion?
No. In our assessment on this page, 3 criteria are automated, 32 are partly automated and 51 need a person. Karl Groves put it this way for WCAG 2.0: an automated tool "can definitively test for approximately 25-29% of best practices" and "cannot test for approximately 40%". Automated checks are a fast first pass, not a verdict.
Is WCAG 3.0 replacing WCAG 2.2?
No. WCAG 3.0 is a W3C Working Draft, and W3C says it will not supersede WCAG 2 and that WCAG 2 will not be deprecated until several years after WCAG 3 is finished (W3C WCAG 3 introduction). No law references WCAG 3, so WCAG 2.2 and the earlier 2.x versions are the ones that matter today.
Find the failures software can see
The free scan runs 16 rule-based checks mapped to WCAG success criteria and cites the criterion for every issue it finds. The manual rows above are still yours to check.
Scan my site for free See a real report first