The Complete WCAG 2.2 Checklist

About This Checklist

This checklist covers all 56 Level A and Level AA success criteria in WCAG 2.2, the current Web Content Accessibility Guidelines recommendation from the World Wide Web Consortium (W3C). Each criterion is explained in plain English with a focus on what it means in practice.

The criteria are organized by the four POUR principles — Perceivable, Operable, Understandable, and Robust. Within each principle, Level A criteria (minimum requirements) are listed before Level AA criteria (the standard compliance target).

Use this checklist to understand your obligations, plan an audit, or verify that your website meets the standard most commonly referenced in accessibility laws and regulations.

Perceivable

Content and interface elements must be presentable in ways that users can detect through at least one of their senses.

Level A — Perceivable

1.1.1 Non-text Content — All images, icons, charts, and other non-text content must have text alternatives that convey the same information. Decorative images must have empty alt text (alt=""). Form inputs serving as images must describe the function. CAPTCHAs must provide alternative formats.

1.2.1 Audio-only and Video-only (Prerecorded) — Prerecorded audio-only content (such as a podcast) must have a text transcript. Prerecorded video-only content (such as a silent animation) must have either a text description or an audio track that describes the visual content.

1.2.2 Captions (Prerecorded) — All prerecorded video content that includes audio must have synchronized captions. Captions must include spoken dialogue, identify speakers, and describe meaningful sound effects.

1.2.3 Audio Description or Media Alternative (Prerecorded) — Prerecorded video must have either an audio description track that narrates important visual content not conveyed through the existing soundtrack, or a full text transcript that describes both the audio and visual content.

1.3.1 Info and Relationships — Information, structure, and relationships conveyed through visual presentation must be available programmatically. Use semantic HTML: proper headings (<h1> through <h6>), lists (<ul>, <ol>), tables (<table> with headers), form labels (<label>), and landmark regions (<nav>, <main>, <aside>).

1.3.2 Meaningful Sequence — The reading order of content must be programmatically determinable. The DOM order must match the intended visual reading sequence so that assistive technologies present content in a logical order.

1.3.3 Sensory Characteristics — Instructions for understanding or operating content must not rely solely on sensory characteristics such as shape, color, size, visual location, orientation, or sound. "Click the round button" or "see the red text above" fails this criterion without additional identifying information.

1.4.1 Use of Color — Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Supplement color with text labels, patterns, icons, or underlines.

1.4.2 Audio Control — If audio plays automatically for more than three seconds, users must be able to pause, stop, or control the volume independently from the system volume.

Level AA — Perceivable

1.2.4 Captions (Live) — Live audio content in synchronized media must have real-time captions. This applies to live streams, webinars, and live events with audio.

1.2.5 Audio Description (Prerecorded) — Prerecorded video content must have an audio description track. This is a stronger requirement than 1.2.3, which allowed a text alternative as an option.

1.3.4 Orientation — Content must not restrict its view or operation to a single display orientation (portrait or landscape) unless a specific orientation is essential, such as a piano keyboard app.

1.3.5 Identify Input Purpose — The purpose of form input fields that collect personal information (name, email, phone, address, etc.) must be programmatically determinable. Use the HTML autocomplete attribute with appropriate values so browsers and assistive technologies can auto-fill and present fields clearly.

1.4.3 Contrast (Minimum) — Text and images of text must have a contrast ratio of at least 4.5:1 against their background. Large text (18pt or 14pt bold and above) requires at least 3:1. Logos and incidental text in inactive components are exempt.

1.4.4 Resize Text — Text must be resizable up to 200 percent without assistive technology and without loss of content or functionality. Content should not require horizontal scrolling at 200 percent zoom on a standard viewport.

1.4.5 Images of Text — Use actual text rather than images of text wherever possible. Images of text are only acceptable when the specific visual presentation is essential (such as a logo) or when the image is customizable by the user.

1.4.10 Reflow — Content must reflow to fit within a viewport width of 320 CSS pixels (equivalent to 400 percent zoom on a 1280-pixel viewport) without requiring horizontal scrolling. Exceptions exist for content that requires two-dimensional layout, such as data tables, maps, and diagrams.

1.4.11 Non-text Contrast — User interface components (form field borders, buttons, toggle switches) and meaningful graphical objects (chart elements, icons that convey information) must have a contrast ratio of at least 3:1 against adjacent colors.

1.4.12 Text Spacing — Content must remain functional and visible when users override text spacing to the following minimums: line height 1.5 times font size, paragraph spacing 2 times font size, letter spacing 0.12 times font size, and word spacing 0.16 times font size.

1.4.13 Content on Hover or Focus — Content that appears on hover or focus (tooltips, dropdown menus, sub-menus) must be dismissible without moving hover or focus (typically via Escape), hoverable so the user can move the pointer over the new content without it disappearing, and persistent until the user deliberately dismisses it or it is no longer relevant.

Operable

Interface components and navigation must be usable by all users regardless of their input method.

Level A — Operable

2.1.1 Keyboard — All functionality must be operable through a keyboard interface. No interaction should require specific timing for keystrokes. This applies to all interactive elements: links, buttons, form controls, menus, sliders, and custom widgets.

2.1.2 No Keyboard Trap — If keyboard focus can move to a component, focus must be able to move away from that component using standard keyboard methods. If non-standard exit methods are required, users must be informed.

2.1.4 Character Key Shortcuts — If a keyboard shortcut uses only a single character key (letter, number, punctuation, or symbol), the user must be able to turn it off, remap it, or the shortcut must only be active when the relevant component has focus. This prevents accidental activation, especially for speech input users.

2.2.1 Timing Adjustable — If content has a time limit, users must be able to turn off, adjust, or extend the time limit. Exceptions exist for real-time events, essential time limits, and limits longer than 20 hours.

2.2.2 Pause, Stop, Hide — Moving, blinking, scrolling, or auto-updating content that starts automatically and lasts more than five seconds must have a mechanism for users to pause, stop, or hide it. This includes carousels, marquees, news tickers, and auto-refreshing content.

2.3.1 Three Flashes or Below Threshold — Content must not flash more than three times per second, unless the flash is below the general flash and red flash thresholds defined in WCAG. This protects users with photosensitive epilepsy.

2.4.1 Bypass Blocks — A mechanism must be provided to skip past blocks of content that are repeated across multiple pages, such as navigation menus and headers. Skip navigation links are the most common implementation.

2.4.2 Page Titled — Every web page must have a descriptive, informative title that describes its topic or purpose. Page titles appear in browser tabs, bookmarks, and search results, and are the first thing announced by screen readers.

2.4.3 Focus Order — When interactive elements can be navigated sequentially (via Tab key), the navigation order must be logical and intuitive, following the visual reading flow of the content.

2.4.4 Link Purpose (In Context) — The purpose of each link must be determinable from the link text alone, or from the link text combined with its programmatically determined context (such as the surrounding paragraph, list item, or table cell). Avoid generic link text like "click here" or "read more" without context.

2.5.1 Pointer Gestures — Functionality that requires multipoint or path-based gestures (pinch, swipe, drag along a path) must also be operable with a single-pointer action without a path-based gesture, unless the multipoint gesture is essential.

2.5.2 Pointer Cancellation — For functions operated by a single pointer, at least one of the following must be true: the down-event does not trigger the function; the function triggers on the up-event and can be aborted or undone; the up-event reverses any outcome of the down-event; or completing the function on the down-event is essential.

2.5.3 Label in Name — For components with visible text labels (buttons, links, form fields), the accessible name must include the visible text. If a button displays "Search," its accessible name must contain "Search" — not something completely different like "Find items."

2.5.4 Motion Actuation — Functionality triggered by device motion (shaking, tilting) must also be available through a conventional user interface, and motion actuation must be disableable to prevent accidental triggering.

Level AA — Operable

2.4.5 Multiple Ways — More than one way must be available to locate a web page within a set of pages. Examples include navigation menus, search functionality, site maps, and tables of contents.

2.4.6 Headings and Labels — Headings and labels must describe the topic or purpose of the content they introduce. "Section 1" or "Details" is far less helpful than "Shipping Information" or "Account Settings."

2.4.7 Focus Visible — Any keyboard-operable user interface must have a visible keyboard focus indicator. The focus indicator must be perceivable — never hidden by CSS outline: none without a visible replacement.

2.4.11 Focus Not Obscured (Minimum) — When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers, cookie banners, or fixed-position footers. The focused element must be at least partially visible.

2.4.12 Focus Not Obscured (Enhanced) — This AAA criterion was introduced in WCAG 2.2 but note that 2.4.11 at AA requires the focused component to be at least partially visible. Best practice is to ensure the focused component is fully visible.

2.4.13 Focus Appearance — This Level AAA criterion establishes minimum size and contrast requirements for focus indicators. While AAA, it provides useful design guidance: focus indicators should have an area of at least 2 CSS pixels around the perimeter and a contrast ratio of at least 3:1 between focused and unfocused states.

2.5.7 Dragging Movements — Any functionality that uses a dragging movement (drag-and-drop) must be operable by a single pointer without dragging. Provide an alternative such as click-to-select-then-click-to-place or use buttons to reorder items.

2.5.8 Target Size (Minimum) — Interactive targets must be at least 24 by 24 CSS pixels in size, with exceptions for inline targets within text, targets where the size is determined by the user agent, targets where a specific presentation is essential, and targets where an equivalent control of sufficient size exists elsewhere on the page.

Understandable

Information and interface behavior must be comprehensible to users.

Level A — Understandable

3.1.1 Language of Page — The default human language of each web page must be programmatically determinable via the lang attribute on the <html> element. This ensures screen readers use the correct pronunciation rules.

3.2.1 On Focus — Receiving focus on any component must not trigger a change of context. Moving focus to a form field should not automatically submit the form, open a new window, or significantly change the page content.

3.2.2 On Input — Changing the setting of any user interface component must not automatically cause a change of context unless the user has been informed in advance. Selecting a radio button should not automatically navigate to a new page without warning.

3.3.1 Error Identification — When an input error is automatically detected, the item in error must be identified and the error described to the user in text. Error messages must be specific: "Please enter a valid email address" rather than "Error in field 3."

3.3.2 Labels or Instructions — Labels or instructions must be provided when content requires user input. Every form field must have a visible, descriptive label. Required fields must be identified. Expected formats ("MM/DD/YYYY") should be indicated.

Level AA — Understandable

3.1.2 Language of Parts — When content includes passages in a language different from the page's default language, the language of each passage must be programmatically determinable using the lang attribute on the containing element.

3.2.3 Consistent Navigation — Navigation mechanisms that are repeated across multiple pages must occur in the same relative order each time, unless the user initiates a change. The main navigation should not rearrange itself from page to page.

3.2.4 Consistent Identification — Components that have the same functionality across a set of pages must be identified consistently. If a search function is labeled "Search" on one page, it should not be labeled "Find" or "Look up" on another.

3.2.6 Consistent Help — If a web page contains help mechanisms (contact information, human contact, self-help options, or a chatbot), these mechanisms must appear in the same relative order across pages. Users should not have to hunt for help on each page.

3.3.3 Error Suggestion — When an input error is detected and suggestions for correction are known, the suggestions must be provided to the user (unless doing so would compromise security or the purpose of the content).

3.3.4 Error Prevention (Legal, Financial, Data) — For pages that cause legal commitments, financial transactions, or modification/deletion of user-controllable data, at least one of the following must be true: submissions are reversible, data is checked for errors and the user is given an opportunity to correct them, or a mechanism is available to review and confirm information before finalizing.

3.3.7 Redundant Entry — Information previously entered by or provided to the user that is required again in the same process must be auto-populated or available for the user to select, unless re-entering the information is essential for security or the previously entered information is no longer valid.

3.3.8 Accessible Authentication (Minimum) — If an authentication process requires a cognitive function test (such as remembering a password, solving a puzzle, or performing a calculation), at least one method must be available that does not require the cognitive function test, or the site must provide a mechanism to assist (such as copy-paste support for passwords, allowing password managers, or offering alternative authentication methods like passkeys or magic links). Recognizing objects or personal content the user provided is allowed.

Robust

Content must work reliably with current and future user agents, including assistive technologies.

Level A — Robust

4.1.2 Name, Role, Value — For all user interface components, the name, role, and state must be programmatically determinable. Native HTML elements (<button>, <input>, <a>) handle this automatically. Custom components must use appropriate ARIA roles, properties, and states. When component states change (expanded, checked, selected, disabled), those changes must be communicated to assistive technology.

4.1.3 Status Messages — Status messages that provide information to the user without receiving focus — such as "Item added to cart," "3 search results found," or "Form submitted successfully" — must be programmatically communicated to assistive technology using ARIA live regions (role="status", role="alert", or aria-live).

Note: WCAG 2.2 removed Success Criterion 4.1.1 (Parsing) that was present in earlier versions, as modern browsers and assistive technologies now handle HTML parsing errors consistently.

How to Use This Checklist

This checklist serves as a reference and planning tool, not a substitute for hands-on testing. For each criterion, consider whether it applies to your content and test with a combination of methods.

Automated tools can reliably check criteria related to alt text presence, color contrast ratios, language attributes, form labels, and valid ARIA usage. Use tools like axe, WAVE, or Lighthouse for efficient scanning.

Manual testing is essential for criteria that require human judgment: the quality and accuracy of alt text, the logical ordering of content, the helpfulness of error messages, the consistency of navigation, and the usability of custom interactive components.

Assistive technology testing provides the most authentic evaluation. Test with at least one screen reader (NVDA, JAWS, or VoiceOver), navigate entirely by keyboard, and verify that all information and functionality is available through these methods.

Prioritize remediation by impact and conformance level. Address Level A failures first — these represent the most severe barriers. Then address Level AA criteria to reach the conformance level most commonly referenced in laws and policies. Document your findings, track your progress, and retest after remediation to verify that fixes are effective and have not introduced new issues.