WCAG 2.2 Success Criteria Checklist 2026: All 78 Criteria

Requires: All non-text content (images, charts, icons, CAPTCHA) has a text alternative that serves an equivalent purpose.

Common failure: Images without alt text; icon buttons without aria-label; decorative images with alt text instead of empty alt (alt='').

Implementation tip: For decorative images use alt=''. For informative images describe the content. For functional images (buttons) describe the action.

Requires: Pre-recorded audio-only: text transcript provided. Pre-recorded video-only: text transcript or audio description provided.

Common failure: Podcast episode without a transcript; silent explainer video without audio description.

Implementation tip: A full text transcript satisfies this criterion for audio-only content. For video-only, describe all visually conveyed information.

Requires: Captions provided for all pre-recorded audio content in synchronized media (video with audio).

Common failure: YouTube videos embedded without captions enabled; auto-generated captions not corrected.

Implementation tip: Auto-captions must be reviewed and corrected — inaccurate captions may not meet this criterion. Use SRT files for accurate captions.

Requires: Audio description OR a text alternative is provided for pre-recorded synchronized media.

Common failure: Marketing videos where important visual information (product demonstrations, on-screen text) is not described in the audio track.

Implementation tip: If the audio already fully describes the visuals, no audio description is needed. Only required when video conveys info not in the audio.

Requires: Captions provided for all live audio content in synchronized media.

Common failure: Live webinars, town halls, or streams without real-time captions.

Implementation tip: CART (Communication Access Realtime Translation) services or tools like Otter.ai Live provide real-time captions for live events.

Requires: Audio description provided for all pre-recorded video content in synchronized media.

Common failure: Tutorial or demonstration videos where screen content is shown but not described in the narration.

Implementation tip: If audio already describes visuals (many how-to videos do this naturally), you're likely already conformant. Test by listening with eyes closed.

Requires: Sign language interpretation for all pre-recorded audio content in synchronized media.

Common failure: Video content without an embedded sign language interpreter.

Implementation tip: Picture-in-picture sign language overlay is the standard implementation. Most applicable for services targeting Deaf communities.

Requires: Where audio description pauses are insufficient, extended audio description (pause + describe + resume) is provided.

Common failure: Dense visual demonstrations where natural audio gaps are too short to describe all visual content.

Implementation tip: This applies when the video must literally pause to allow full audio description of complex visuals.

Requires: Full text alternative provided for all pre-recorded synchronized media.

Common failure: Video content without a full script/transcript that includes both audio and visual descriptions.

Implementation tip: A well-structured transcript serving as a complete text alternative (not just a transcript of audio) satisfies this.

Requires: Text alternative equivalent for live audio-only content.

Common failure: Live radio broadcasts embedded on a website without live captioning or alternative.

Implementation tip: Most relevant for live audio streaming services. CART captioning services satisfy this requirement.

Requires: Information, structure, and relationships conveyed through presentation can be programmatically determined.

Common failure: Using bold/color for required fields instead of aria-required; visual table formatting without semantic table elements.

Implementation tip: Use semantic HTML: <table> for data, <nav> for navigation, <fieldset>/<legend> for form groups, headings for page structure.

Requires: Reading sequence can be programmatically determined when it affects meaning.

Common failure: CSS-positioned content where DOM order doesn't match visual order; floating layouts where reading order is ambiguous.

Implementation tip: Ensure the DOM order matches the logical reading order. Screen readers read the DOM, not the visual layout.

Requires: Instructions don't rely solely on sensory characteristics (shape, color, size, visual location, orientation, sound).

Common failure: 'Click the green button to proceed'; 'See the form on the right'; 'Click the round icon'.

Implementation tip: Always pair sensory references with text labels: 'Click the green Submit button' or better just 'Click Submit'.

Requires: Content doesn't restrict orientation to portrait or landscape unless a specific orientation is essential.

Common failure: Banking app login locked to portrait mode; forms that only work in one orientation.

Implementation tip: Remove CSS or JS that forces orientation. Wheelchairs often fix device orientation — users need to use the orientation available to them.

Requires: Input fields collecting user information have autocomplete attributes that identify their purpose.

Common failure: Login, registration, and payment forms missing autocomplete='email', autocomplete='name', autocomplete='cc-number' etc.

Implementation tip: Add appropriate autocomplete values from the WCAG input purposes list. This also improves UX for everyone by enabling browser autofill.

Requires: The purpose of UI components, icons, and regions can be programmatically determined.

Common failure: Icon-only buttons without accessible names; regions without landmarks or labels.

Implementation tip: Use ARIA landmarks (main, nav, aside), aria-label on ambiguous regions, and aria-label or visible text on icon buttons.

Requires: Color is not the only visual means of conveying information, indicating an action, or distinguishing a visual element.

Common failure: Required form fields indicated by red color only; charts distinguishing data series by color alone.

Implementation tip: Pair color coding with patterns, icons, labels, or other visual cues. 8% of males have color vision deficiency.

Requires: Mechanism to pause, stop, or control volume of audio that plays automatically for more than 3 seconds.

Common failure: Background music or video narration that starts on page load with no visible controls.

Implementation tip: Do not autoplay audio. If you must, provide immediate, visible, keyboard-accessible controls to pause or stop it.

Requires: Text has contrast ratio of at least 4.5:1 (3:1 for large text — 18pt or 14pt bold). Decorative text exempt.

Common failure: Gray text on white (#767676 on white = 4.48:1, fails); light blue links on white backgrounds.

Implementation tip: Use WebAIM Contrast Checker. Minimum passing: #595959 on white for normal text. Bootstrap's default gray-600 (#6c757d) fails AA.

Requires: Text can be resized up to 200% without loss of content or functionality.

Common failure: Fixed pixel font sizes in overflow:hidden containers; text that overlaps or disappears at 200% zoom.

Implementation tip: Use relative units (rem, em) for font sizes and test at 200% browser zoom. Content should reflow, not overflow.

Requires: If same visual presentation can be achieved with text, text is used instead of images of text.

Common failure: Screenshots of code used as content; styled headings or pull quotes delivered as JPEGs.

Implementation tip: CSS can achieve nearly any visual text style. Use real text with CSS styling; reserve image-text for logos and essential brand elements.

Requires: Text has contrast ratio of at least 7:1 (4.5:1 for large text).

Common failure: Normal-contrast text that passes AA (4.5:1) but falls below the enhanced 7:1 threshold.

Implementation tip: Target #222222 or #000000 on white for enhanced contrast. Worth implementing on high-stakes content (legal, medical, financial).

Requires: Pre-recorded speech audio has no background sound, or background sounds are 20dB lower than foreground speech.

Common failure: Video narration with prominent background music competing with the speaker's voice.

Implementation tip: Relevant for video and audio production. Most applicable for accessibility-focused content and educational platforms.

Requires: Users can select foreground/background colors; line width max 80 chars; text not fully justified; 1.5 line spacing minimum; text resizable without assistive technology.

Common failure: Fully justified text; very wide text columns (120+ characters); fixed line heights that can't be overridden.

Implementation tip: Implement a reading mode or user preferences panel to satisfy this without restricting default design.

Requires: Images of text used only for decoration or where a specific presentation is essential (logotypes).

Common failure: Any styled text delivered as an image that could technically be achieved with HTML/CSS.

Implementation tip: Essentially a stricter version of 1.4.5 with no exceptions beyond pure decoration and logotypes.

Requires: Content can be presented without loss of information at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport) without horizontal scrolling.

Common failure: Tables, code blocks, and data displays that require horizontal scrolling at mobile widths.

Implementation tip: Use CSS Grid/Flexbox with responsive breakpoints. Data tables can remain scrollable if they're in their own scrollable container.

Requires: UI components and graphical objects have contrast ratio of at least 3:1 against adjacent colors.

Common failure: Light gray checkbox borders on white; low-contrast button outlines; chart lines that blend with background.

Implementation tip: Check all form controls (inputs, checkboxes, radio buttons), buttons (especially outline/ghost variants), and data visualizations.

Requires: No loss of content when text spacing is overridden: line-height ≥1.5, letter-spacing ≥0.12em, word-spacing ≥0.16em, paragraph spacing ≥2em.

Common failure: Fixed-height containers with overflow:hidden that clip text when spacing increases.

Implementation tip: Test with the bookmarklet at www.html5accessibility.com/tests/tsbookmarklet.html — it applies the test overrides automatically.

Requires: Content appearing on hover/focus must be dismissible (Escape), hoverable (pointer can move over it), and persistent (stays until dismissed or no longer relevant).

Common failure: Tooltips that disappear when cursor moves slightly; tooltips that can't be dismissed with Escape; tooltips that close immediately on hover.

Implementation tip: Custom tooltips and dropdowns must remain visible while the pointer is over them and must be dismissible with Escape without moving focus.

Requires: All functionality available via keyboard unless input requires specific path (drawing, freehand).

Common failure: Drag-and-drop sorting with no keyboard alternative; custom date pickers with no keyboard navigation.

Implementation tip: Test every interactive element: links, buttons, form fields, dropdowns, modals, date pickers. Everything must work with Tab, Enter, Space, arrows.

Requires: Keyboard focus is not trapped in a component unless the user is informed and can navigate out (Escape).

Common failure: Modal dialogs that don't release focus; embedded media players that capture Tab.

Implementation tip: Modal dialogs should trap focus intentionally (while open) but release on Escape. Focus should never be permanently stuck.

Requires: All functionality available via keyboard with no exceptions whatsoever.

Common failure: Paths that rely on analog motion (drawing with mouse curves) where alternative keyboard interface is genuinely not possible.

Implementation tip: Stricter version of 2.1.1 — removes the exception for path-dependent input.

Requires: Single-character keyboard shortcuts can be turned off, remapped, or only active on focus.

Common failure: Keyboard shortcuts using single letters that conflict with screen reader shortcuts.

Implementation tip: If you implement keyboard shortcuts (S for search, N for next), provide a way to disable or remap them. Affects users who use voice input.

Requires: Time limits can be turned off, adjusted, or extended (20 seconds minimum warning with extension).

Common failure: Session timeouts without advance warning; shopping carts that expire without extension option.

Implementation tip: Warn users before timeout (at least 20 seconds in advance), allow extension. Exceptions: real-time events, essential timing.

Requires: Moving, blinking, scrolling, or auto-updating content can be paused, stopped, or hidden.

Common failure: Auto-advancing carousels with no pause button; news tickers; background animations without controls.

Implementation tip: Provide pause controls for all auto-playing content. Users with ADHD, cognitive disabilities, and vestibular conditions are most affected.

Requires: Timing is not an essential part of any event or activity, except real-time events.

Common failure: Any timed assessments or interactions where the timer can't be disabled.

Implementation tip: For testing platforms and applications where timing constraints can reasonably be removed, AAA compliance is achievable.

Requires: Interruptions (emergency updates, chat notifications) can be postponed or suppressed.

Common failure: Unexpected notification banners, live chat pop-ins, or alerts that can't be delayed.

Implementation tip: Emergency alerts are exempt. Otherwise provide a 'do not disturb' or notification deferral mechanism.

Requires: When authenticated session expires, user can continue without losing data after re-authenticating.

Common failure: Forms that lose all entered data when session expires, requiring restart.

Implementation tip: Save form state server-side before session expires so users can re-authenticate and continue.

Requires: Users warned of any data loss due to inactivity before it occurs.

Common failure: Forms or applications that lose data after inactivity without prior warning.

Implementation tip: New in WCAG 2.2. Show warnings well in advance of any inactivity-triggered data loss.

Requires: No content flashes more than 3 times per second, OR the flash is below the general flash and red flash thresholds.

Common failure: Strobe effects in hero videos; animated GIFs with fast cycling; video game-style flash effects.

Implementation tip: Test with PEAT (Photosensitive Epilepsy Analysis Tool). When in doubt, remove the flash — photosensitive seizures are life-threatening.

Requires: No content flashes more than 3 times per second — no exceptions for threshold compliance.

Common failure: Any content flashing 3+ times per second, even if below standard threshold.

Implementation tip: Simply don't flash content at or above 3 times per second.

Requires: Motion animation triggered by interaction can be disabled unless essential.

Common failure: Parallax scroll effects, page transition animations, and decorative motion that can't be disabled.

Implementation tip: New in WCAG 2.2. Respect prefers-reduced-motion CSS media query to disable non-essential animations.

Requires: Mechanism to bypass blocks of content repeated on multiple pages (skip navigation links, ARIA landmarks).

Common failure: No 'Skip to main content' link; no ARIA landmark regions (main, nav, header).

Implementation tip: Add a visually-hidden skip link as the first focusable element. Or use ARIA landmarks — screen reader users can jump between regions.

Requires: Pages have titles that describe topic or purpose.

Common failure: All pages sharing the same title; blank or placeholder <title> elements.

Implementation tip: Format: 'Page Topic — Site Name'. Unique, descriptive page titles are also critical for SEO.

Requires: Focus order preserves meaning and operability.

Common failure: Tab order jumping erratically due to tabindex misuse; modals that don't move focus to the dialog.

Implementation tip: Avoid positive tabindex values — they override natural DOM order. Use tabindex='0' to make custom elements focusable.

Requires: Link purpose can be determined from the link text alone or with context (surrounding paragraph, list, table).

Common failure: 'Click here', 'Read more', 'Learn more' links with no surrounding context differentiation.

Implementation tip: Write descriptive link text ('Read the WCAG 2.2 checklist') or use aria-label/aria-labelledby to add context programmatically.

Requires: More than one way to locate a page within a set of pages (site search, sitemap, navigation).

Common failure: Single-navigation sites with no search, sitemap, or alternative navigation path.

Implementation tip: Site search satisfies this. A sitemap page satisfies this. Navigation menu + any of the above satisfies this.

Requires: Headings and labels are descriptive.

Common failure: Generic headings ('Section 1', 'More Info'); form labels ('Field 1:', 'Input:').

Implementation tip: Every heading should tell you what the section is about; every form label should tell you what information is expected.

Requires: Keyboard focus indicator is visible.

Common failure: outline:none or outline:0 in CSS without a custom focus replacement; links with no visible focus state.

Implementation tip: NEVER remove focus outlines without replacing them. WCAG 2.2 AA adds 2.4.11 (Focus Not Obscured) requiring focus not to be fully covered by sticky headers.

Requires: Information about user's location within a set of pages is available (breadcrumbs, highlighted nav item).

Common failure: Deep content pages with no breadcrumbs or highlighted navigation state.

Implementation tip: Breadcrumbs are the simplest implementation. Also satisfies SEO structured data requirements.

Requires: Link purpose can be determined from link text alone (stricter than 2.4.4 which allows context).

Common failure: 'View details' links even when surrounded by context that identifies the product.

Implementation tip: Stricter than AA's 2.4.4. Requires every link to be unambiguous without context. Consider aria-label for cards with identical 'View' links.

Requires: Section headings are used to organize content.

Common failure: Long-form content without any heading structure; pages using visual separators instead of semantic headings.

Implementation tip: Use H2 for major sections, H3 for subsections. Heading structure serves both screen readers and SEO.

Requires: Focused component is not entirely hidden by author-created content (sticky headers, cookie banners).

Common failure: Sticky header that completely covers a focused input as user tabs down the page.

Implementation tip: New in WCAG 2.2. Use scroll-padding-top on the document to offset scroll position by sticky header height.

Requires: Focused component is not obscured by any author-created content (even partially).

Common failure: Focused elements partially covered by sticky header or overlay.

Implementation tip: New in WCAG 2.2. The AA version (2.4.11) only prohibits complete hiding; this prohibits any obstruction.

Requires: Focus indicator has minimum area (perimeter × 2px) and minimum contrast ratio of 3:1.

Common failure: Thin single-pixel focus outlines with insufficient contrast against adjacent colors.

Implementation tip: New in WCAG 2.2. A 2px solid outline around the element generally passes. Use a contrasting color (white or black works well).

Requires: All multipoint or path-based gestures have single-pointer alternatives.

Common failure: Pinch-to-zoom map controls without +/- buttons; swipe-only carousels without arrow buttons.

Implementation tip: Every gesture needs a single-tap/click alternative. Don't rely solely on swipe, pinch, or multi-finger gestures.

Requires: For single-pointer operations, the down event is not used to execute functions (or up-event can abort/undo).

Common failure: Dangerous actions triggered on mousedown (before mouseup); drag-and-drop with no undo.

Implementation tip: Trigger actions on mouseup/click (not mousedown). This allows users to cancel by moving the pointer away before release.

Requires: For UI components with visible text labels, the accessible name includes the visible text label.

Common failure: Button with visible text 'Submit' but aria-label='Send form' — voice control users saying 'Submit' won't work.

Implementation tip: The aria-label or accessible name must contain the visible text. Voice control users activate controls by speaking the visible label.

Requires: Functionality using device motion (shaking, tilting) has UI alternative and can be disabled.

Common failure: Shake-to-undo feature with no UI equivalent; tilt-to-navigate without keyboard/button alternative.

Implementation tip: Provide UI buttons for every device motion feature. Allow disabling in settings.

Requires: Interactive target size is at least 44×44 CSS pixels.

Common failure: Small icon buttons (24×24px); closely-spaced navigation links with insufficient tap area.

Implementation tip: 44px is Apple's HIG and Android's recommendation. Use padding to increase tap area without changing visual size.

Requires: Web content does not restrict use of input modalities (keyboard, pointer, touch, voice).

Common failure: Applications that disable touch input when keyboard is connected; forms that only accept mouse input.

Implementation tip: Don't detect and restrict input method. Allow users to switch between mouse, keyboard, and touch freely.

Requires: All functionality using dragging has a single-pointer alternative (unless dragging is essential).

Common failure: Kanban boards with drag-only column assignment; sortable lists with no alternative to drag.

Implementation tip: New in WCAG 2.2. Add click/button alternatives for all drag actions. Essential dragging (e.g., drawing apps) is exempt.

Requires: Interactive target size is at least 24×24 CSS pixels, with exceptions for inline text links.

Common failure: Tiny icon buttons (16×16px); close buttons on modals that are too small to tap accurately.

Implementation tip: New in WCAG 2.2. Minimum 24px target size. Note: spacing offsets can satisfy this — a 16px target with 4px spacing on all sides passes.

Requires: Default human language of each page can be programmatically determined.

Common failure: Missing lang attribute on <html> element; incorrect lang attribute (lang='en' on a French page).

Implementation tip: Set lang='en' (or appropriate code) on the <html> element. This tells screen readers how to pronounce content.

Requires: Language of each passage or phrase can be programmatically determined when different from page language.

Common failure: Spanish paragraphs on an English page without lang='es' on the containing element.

Implementation tip: Add lang attribute to any element containing content in a language different from the page's default.

Requires: Mechanism available to identify definitions of unusual words and jargon.

Common failure: Technical documentation or legal content using specialized terminology with no glossary.

Implementation tip: Add a glossary page, inline definitions, or tooltip definitions for industry-specific terms.

Requires: Mechanism to identify expanded form of abbreviations.

Common failure: WCAG, ADA, ARIA used without expansion on first use or a glossary.

Implementation tip: Use <abbr title='expanded form'>ABBR</abbr> or define on first use: 'Web Content Accessibility Guidelines (WCAG)'.

Requires: Content readable at lower secondary education level, or simplified version available.

Common failure: Legal or medical content that's only available in advanced professional language.

Implementation tip: Provide a plain language summary alongside technical content. Tools like Hemingway App can help assess reading level.

Requires: Mechanism to identify pronunciation of words where meaning is ambiguous without pronunciation.

Common failure: Ambiguous words that change meaning based on pronunciation (rare in English, common in Japanese/Chinese).

Implementation tip: Most applicable for East Asian languages. Use ruby annotations or pronunciation guides.

Requires: Receiving focus does not initiate a context change.

Common failure: Form field that auto-submits when it receives focus; select menu that navigates immediately on focus.

Implementation tip: Focus should not trigger navigation, form submission, or content changes. Only user-initiated actions should change context.

Requires: Changing a UI component setting does not automatically cause a context change unless user is informed in advance.

Common failure: Radio button selection that immediately navigates to a new page; checkbox that immediately submits a form.

Implementation tip: Changes of context should require a separate user action (button click). If auto-change is needed, warn the user first.

Requires: Navigation components repeated on multiple pages appear in the same relative order each time.

Common failure: Navigation menu reordering between sections; breadcrumbs appearing in different locations on different pages.

Implementation tip: Navigation should be in the same position and order across all pages. Users build mental models based on consistency.

Requires: Components with the same functionality within a set of pages are identified consistently.

Common failure: Search button labeled 'Go' on some pages and 'Search' on others; same icon button with different labels.

Implementation tip: Use consistent labels, icons, and accessible names for identical functions across your site.

Requires: Context changes are only initiated by user request, or mechanism to turn off such changes is available.

Common failure: Auto-advancing carousels; automatic page refreshes; pages that open new windows without user request.

Implementation tip: Stricter than 3.2.1/3.2.2. Changes of context must be explicitly triggered by the user.

Requires: Help mechanisms (human contact, self-help, automated contact) appear in the same relative location across pages.

Common failure: Help button in the header on most pages but in the footer on others; chat widget that appears inconsistently.

Implementation tip: New in WCAG 2.2. If you have a help mechanism, keep it in the same position on every page.

Requires: Input errors are automatically detected, and the item in error is identified and described to the user.

Common failure: Form submission that colors invalid fields red but provides no text description; error messages that aren't linked to fields.

Implementation tip: Describe the error in text (not just color), identify which field has the error, and link the error message to the field programmatically.

Requires: Labels or instructions provided when content requires user input.

Common failure: Forms with placeholder-only labels; fields with format requirements (phone, date) not communicated to the user.

Implementation tip: Visible labels are required. Placeholders disappear on input and are insufficient as labels. Show format examples (MM/DD/YYYY) persistently.

Requires: When input error is detected and suggestions are known, suggestions are provided to the user.

Common failure: Email validation that says 'Invalid format' without suggesting the expected format.

Implementation tip: Tell users what to fix: 'Email must include @ and a domain (e.g., name@example.com)'. Not required when suggestions would compromise security.

Requires: Submissions that cause legal commitments or financial transactions are reversible, verified, or confirmable.

Common failure: Purchase forms with no order review step; account deletion without confirmation.

Implementation tip: Add a review/confirm step for purchases, subscriptions, and account changes. Or allow reversal within a time window.

Requires: Context-sensitive help is available.

Common failure: Complex forms with no inline help text; technical fields with no explanation of expected values.

Implementation tip: Add help text (not tooltips — persistent text) next to complex fields. This benefits all users, not just those with disabilities.

Requires: Submissions are reversible, checked, or confirmable for all input, not just legal/financial.

Common failure: Any form submission that can't be reviewed before final submission or undone after.

Implementation tip: Extends 3.3.4 to all forms. Add confirmation steps or undo mechanisms for all user input.

Requires: Information previously entered is auto-populated or available for selection in the same process.

Common failure: Multi-step checkout forms that require billing and shipping address to be entered separately even when identical.

Implementation tip: New in WCAG 2.2. Auto-populate fields with previously entered values. 'Same as billing address' checkbox is a common solution.

Requires: Cognitive function test (solving puzzle, remembering image) not required for authentication unless alternative provided.

Common failure: Image-based CAPTCHA required to log in with no alternative; puzzle CAPTCHAs with no audio alternative.

Implementation tip: New in WCAG 2.2. Use email magic links, passkeys, or CAPTCHA alternatives. If using reCAPTCHA, ensure audio alternative works.

Requires: No cognitive function test at any step of authentication, without exception.

Common failure: Any CAPTCHA in the authentication flow, even with alternatives.

Implementation tip: New in WCAG 2.2. Eliminates all CAPTCHAs. Passkeys and email magic links satisfy this criterion.

Requires: Markup has no errors that affect accessibility (duplicate IDs, unclosed elements, invalid attributes).

Common failure: Duplicate id attributes on a page; invalid HTML that confuses AT.

Implementation tip: Validate HTML with W3C Markup Validator. Note: WCAG 2.2 has deprecated this criterion due to modern browser error correction.

Requires: All UI components have name, role, and (for state/properties) value that can be programmatically determined and set.

Common failure: Custom dropdown built from <div> elements without ARIA role, aria-expanded, aria-haspopup; icon buttons without accessible names.

Implementation tip: If you build custom components, add ARIA roles and properties that match native elements. Accessible Name computation is the most commonly failed rule in this criterion.

Requires: Status messages (form success, errors, cart updates) can be programmatically determined via role or property so AT users get the information without receiving focus.

Common failure: Success messages that appear visually but aren't in an ARIA live region; cart count updates not announced.

Implementation tip: Use role='status' (polite) or role='alert' (assertive) on dynamically updated regions. Don't move focus just to announce status.