WCAG 2.2 Guide

Non-text Content A

Every image, icon, chart, and non-text element needs a text alternative that serves the same purpose. Use descriptive alt attributes on images, label icons with aria-label, and provide text descriptions for complex graphics like charts or infographics. Decorative images should use alt="" or role="presentation" so screen readers skip them.

Audio-only and Video-only (Prerecorded) A

For prerecorded audio-only content (like a podcast), provide a text transcript. For prerecorded video-only content (like a silent animation), provide either a transcript or an audio track that describes what's shown.

Captions (Prerecorded) A

All prerecorded video with audio must have synchronized captions. Auto-generated captions are a starting point but must be reviewed and corrected for accuracy. Captions should include speaker identification and relevant sound effects.

Audio Description or Media Alternative (Prerecorded) A

Prerecorded video content needs either an audio description track that narrates important visual information, or a full text alternative (such as a screenplay-style transcript) that describes both the dialogue and the visual content.

Captions (Live) AA

Live video with audio (webinars, live streams) must have real-time captions. Use a professional captioning service or a high-quality live captioning tool. Ensure captions appear with minimal delay and reasonable accuracy.

Audio Description (Prerecorded) AA

Provide audio descriptions for all prerecorded video content. Unlike 1.2.3 which allows a text alternative, this criterion specifically requires an audio description track that narrates key visual information during natural pauses in dialogue.

Info and Relationships A

Use semantic HTML to convey structure and relationships. Headings should use <h1>-<h6> tags (not just bold text), lists should use <ul>/<ol>, tables should use <th> for headers, and form inputs must be associated with <label> elements. Screen readers rely on this structure to help users navigate and understand content.

Meaningful Sequence A

The DOM order of your content should match the visual reading order. Avoid using CSS to rearrange content in a way that makes the underlying source order confusing. When content is read linearly (by a screen reader or with styles disabled), it should still make sense.

Sensory Characteristics A

Instructions for understanding and operating content must not rely solely on sensory characteristics like shape, color, size, visual location, or sound. For example, do not say "click the round button" or "see the item in red." Instead, reference elements by their label or text content.

Orientation AA

Content must not be locked to a single display orientation (portrait or landscape) unless a specific orientation is essential for the content to function. Users who mount their devices in a fixed position need content that adapts to their device orientation.

Identify Input Purpose AA

Form fields that collect common personal information (name, email, phone, address, etc.) should use the appropriate autocomplete attribute values. This lets browsers and assistive technologies auto-fill fields and present them with recognizable icons or labels, which is especially helpful for users with cognitive disabilities.

Use of Color A

Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. For example, error states should use an icon or text label in addition to red coloring. Links in body text need an underline or other non-color indicator in addition to a different color.

Audio Control A

If any audio plays automatically for more than 3 seconds, provide a mechanism to pause or stop it, or to control the volume independently from the system volume. Auto-playing audio interferes with screen reader output and is disorienting for many users.

Contrast (Minimum) AA

Normal text (under 18pt, or under 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) requires at least 3:1. Use a contrast checking tool to verify your color combinations. This applies to both light and dark themes.

Resize Text AA

Text must be resizable up to 200% without assistive technology, and without loss of content or functionality. Use relative units (rem, em, %) for font sizes rather than fixed px values. Test your layout at browser zoom levels of 150% and 200%.

Images of Text AA

Use real text instead of images of text wherever possible. Real text can be resized, recolored, and read by screen readers. Exceptions exist for logos and cases where a specific visual presentation is essential.

Reflow AA

Content must reflow to a single column at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport) without requiring horizontal scrolling. Exceptions include data tables, toolbars, and content where two-dimensional layout is essential. Use responsive CSS and avoid fixed-width containers.

Non-text Contrast AA

User interface components (buttons, form inputs, focus indicators) and meaningful graphical objects (icons, chart segments) must have a contrast ratio of at least 3:1 against adjacent colors. This ensures that interactive elements and informational graphics are visible to users with low vision.

Text Spacing AA

Content must remain readable and functional when users override text spacing to: line height 1.5x the font size, paragraph spacing 2x the font size, letter spacing 0.12x the font size, and word spacing 0.16x the font size. Avoid fixed-height containers that clip text when spacing changes. Test with a text spacing bookmarklet.

Content on Hover or Focus AA

Additional content triggered by hover or keyboard focus (tooltips, dropdowns, popovers) must be: dismissible without moving hover or focus (usually via Escape), hoverable so the user can move the pointer over the new content without it disappearing, and persistent until the user dismisses it or it is no longer relevant.

Keyboard A

All functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes. Use native interactive HTML elements (<button>, <a>, <input>) which are keyboard-accessible by default. If you build custom widgets, implement appropriate keyboard patterns from the WAI-ARIA Authoring Practices.

No Keyboard Trap A

If keyboard focus can be moved to a component, it must be possible to move focus away from that component using only the keyboard. Modal dialogs should trap focus intentionally but must always provide a keyboard-accessible close mechanism. Test by tabbing through your entire page and verifying you can always move forward and backward.

Character Key Shortcuts A

If your application uses single-character keyboard shortcuts (a letter, number, punctuation, or symbol key alone), you must provide a way to turn them off, remap them, or make them active only when the relevant component has focus. This prevents accidental activation by voice input users and people who inadvertently press keys.

Timing Adjustable A

If content has a time limit, users must be able to turn it off, adjust it, or extend it. Before a session times out, warn the user and give them at least 20 seconds to extend the time with a simple action. Exceptions include real-time events and situations where the time limit is essential (like an auction).

Pause, Stop, Hide A

For any moving, blinking, or scrolling content that starts automatically and lasts more than 5 seconds, provide a mechanism to pause, stop, or hide it. This includes carousels, animations, auto-updating news feeds, and progress indicators. The mechanism must be keyboard-accessible.

Three Flashes or Below Threshold A

Content must not flash more than three times per second, unless the flash is below the general flash and red flash thresholds. This is critical for preventing seizures in people with photosensitive epilepsy. Avoid flashing content entirely when possible; if necessary, keep flash areas small and test with seizure analysis tools.

Bypass Blocks A

Provide a mechanism to bypass blocks of content that are repeated on multiple pages. The most common solution is a "Skip to main content" link that is the first focusable element on the page. Using proper landmark regions (<nav>, <main>, <aside>) also helps screen reader users navigate directly to sections.

Page Titled A

Every page must have a descriptive <title> that identifies its topic or purpose. In single-page applications, update the document title on each route change. Titles should be unique across pages and follow a consistent pattern (e.g., "Page Name | Site Name").

Focus Order A

When content can be navigated sequentially by keyboard, the focus order must be logical and intuitive, generally matching the visual reading order. Avoid using positive tabindex values. Ensure that dynamically inserted content (modals, notifications) receives focus in a sensible sequence.

Link Purpose (In Context) A

The purpose of each link should be determinable from the link text alone, or from the link text combined with its programmatically determined context (such as a surrounding paragraph or list item). Avoid vague link text like "click here" or "read more." Instead, use descriptive text like "View the accessibility report for March."

Multiple Ways AA

Provide more than one way to locate a page within a set of pages. Common approaches include a site navigation menu, a site map, a search function, and a table of contents. This helps different users find content using the method that works best for them.

Headings and Labels AA

Headings and labels must describe the topic or purpose of the content they introduce. Use clear, concise headings that help users understand the structure of the page. Form labels should clearly describe what input is expected.

Focus Visible AA

Any keyboard-operable user interface must have a visible focus indicator. The default browser outline is acceptable, but custom focus styles are often better. Never use outline: none without providing an equally visible replacement. The focus indicator must be visible in both light and dark themes.

Focus Not Obscured (Minimum) AA

New in WCAG 2.2. When a component receives keyboard focus, it must not be entirely hidden by other content such as sticky headers, footers, cookie banners, or non-modal dialogs. The focused element must be at least partially visible. Audit your fixed-position elements and ensure they do not completely cover focused items behind them.

Focus Not Obscured (Enhanced) AAA

New in WCAG 2.2. The enhanced version requires that the focused component is not obscured at all. It must be fully visible, not just partially. While this is AAA, implementing it provides a significantly better keyboard experience and is recommended as a best practice.

Focus Appearance AAA

New in WCAG 2.2. The focus indicator must have sufficient size and contrast. Specifically, it should have an area of at least the perimeter of the element times 2 CSS pixels, and a contrast ratio of at least 3:1 between the focused and unfocused states. A solid 2px outline with good contrast typically satisfies this. While AAA, this is an excellent target for any serious accessibility effort.

Pointer Gestures A

Any functionality that uses multipoint or path-based gestures (like pinch-to-zoom, swiping, or drawing) must also be operable with a single-pointer action (like a single tap or click) unless the multipoint gesture is essential. Always provide button alternatives for swipe actions.

Pointer Cancellation A

For functionality triggered by single-pointer input, at least one of the following must be true: the down-event is not used to trigger the action, the action is triggered on the up-event and can be aborted or undone, or the up-event reverses the down-event. In practice, use click events (not mousedown) and allow users to cancel by moving the pointer away before releasing.

Label in Name A

When a UI component has a visible text label, its accessible name must include that visible text. Voice input users say what they see to activate controls. If the accessible name differs from the visible label, voice commands will not work. Ensure aria-label values match or contain the visible text.

Motion Actuation A

Functionality triggered by device motion (shaking, tilting) or user motion (detected by camera) must also be operable through a conventional user interface component, and users must be able to disable the motion-based trigger to prevent accidental activation.

Dragging Movements AA

New in WCAG 2.2. Any functionality that uses dragging (drag-and-drop) must provide a single-pointer alternative that does not require dragging. For example, a sortable list that supports drag-and-drop should also offer up/down buttons or a dropdown to set position. This benefits users with motor impairments who cannot perform sustained pointer movements.

Target Size (Minimum) AA

New in WCAG 2.2. Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing from other targets so that the total clickable area (including spacing) meets the minimum. Exceptions include inline links within text, targets whose size is determined by the user agent, and cases where the target's presentation is essential. This is more lenient than the AAA requirement of 44x44 pixels but still meaningful for motor accessibility.

Language of Page A

The default human language of each page must be programmatically determinable. Set the lang attribute on the <html> element (e.g., lang="en"). Screen readers use this to select the correct pronunciation rules, and translation tools use it to identify the source language.

Language of Parts AA

When content includes passages in a different language from the page default, mark those passages with the appropriate lang attribute. For example, a French phrase within an English page should be wrapped in <span lang="fr">. This ensures screen readers switch pronunciation rules correctly.

On Focus A

When a component receives focus, it must not trigger a change of context (such as automatically submitting a form, opening a new window, or navigating to another page). Focus should be predictable. Users should be able to tab through a page without unexpected things happening.

On Input A

Changing the setting of a user interface component (like selecting a radio button or typing in a field) must not automatically cause a change of context unless the user has been informed beforehand. Do not auto-submit forms when a dropdown selection changes or navigate away when a checkbox is toggled.

Consistent Navigation AA

Navigation mechanisms that appear on multiple pages within a site must appear in the same relative order each time. You can add or remove items, but do not rearrange the existing order. Consistent navigation helps users predict where to find things and builds spatial memory.

Consistent Identification AA

Components that have the same functionality across a set of pages must be identified consistently. If a search feature uses a magnifying glass icon labeled "Search" on one page, use the same icon and label everywhere. Consistent identification reduces cognitive load.

Consistent Help A

New in WCAG 2.2. If a page contains help mechanisms (such as contact information, a chat widget, a self-help FAQ link, or a help form), those mechanisms must appear in the same relative order on every page where they are present. This makes it easier for users with cognitive disabilities to find help when they need it. The help does not need to be on every page, but when present, its placement must be consistent.

Error Identification A

When an input error is automatically detected, the item in error must be identified, and the error described to the user in text. Do not rely solely on color to indicate errors. Use aria-invalid="true" on the field and associate the error message with the field using aria-describedby. Display error messages near the field, not only in a summary at the top of the form.

Labels or Instructions A

When content requires user input, provide labels or instructions. Every form field needs a visible label. If additional formatting or constraints apply (e.g., "Date format: MM/DD/YYYY" or "Password must be at least 8 characters"), state them clearly before or within the form field context.

Error Suggestion AA

When an input error is detected and suggestions for correction are known, provide the suggestion to the user (unless doing so would compromise security). For example, if a date field expects MM/DD/YYYY format and the user enters "March 15," suggest the correct format. Specific guidance helps all users, especially those with cognitive disabilities.

Error Prevention (Legal, Financial, Data) AA

For pages that cause legal commitments, financial transactions, or modify/delete user-controllable data, at least one of the following must be true: submissions are reversible, data is checked and the user gets a chance to correct errors, or a confirmation step is provided before final submission. Think of this as requiring a review step before consequential actions.

Redundant Entry A

New in WCAG 2.2. Information previously entered by or provided to the user that is required again in the same process must be either auto-populated or available for the user to select. Do not force users to re-type their email address, shipping address, or other information they already provided in a previous step. Exceptions exist for security purposes (re-entering a password) and when previously entered information is no longer valid.

Accessible Authentication (Minimum) AA

New in WCAG 2.2. Authentication processes must not require a cognitive function test (such as remembering a password, solving a puzzle, or performing calculations) unless at least one of the following is true: an alternative method is available, the user is assisted (e.g., copy-paste is allowed for passwords so password managers work), or the test involves object recognition or personal content. In practice, support password managers by not blocking paste in password fields, and offer alternatives like passkeys, SSO, or magic links.

Accessible Authentication (Enhanced) AAA

New in WCAG 2.2. The enhanced version removes the exceptions for object recognition and personal content. Authentication must not rely on any cognitive function test at all, unless an alternative or user assistance is provided. While AAA, this is the direction the industry is moving with passkeys and passwordless authentication.

Parsing A Removed in 2.2

This criterion required well-formed markup (no duplicate IDs, proper nesting, complete start/end tags). It was removed in WCAG 2.2 because modern browsers and assistive technologies handle parsing errors gracefully. However, valid HTML remains a best practice. Duplicate IDs still cause real problems for aria-describedby, aria-labelledby, and label/input associations. Continue writing valid markup even though this is no longer a formal requirement.

Name, Role, Value A

All user interface components must have an accessible name and role that can be programmatically determined, and states, properties, and values that can be programmatically set. Native HTML elements handle this automatically. For custom components, use appropriate ARIA roles (role="button", role="tab", etc.), states (aria-expanded, aria-checked), and ensure the accessible name is set via aria-label or aria-labelledby. Update ARIA states dynamically as the component state changes.

Status Messages AA

Status messages that provide information to the user without changing their context (like "Item added to cart," "3 results found," or "Form submitted successfully") must be programmatically determinable through role or properties so they can be announced by screen readers without receiving focus. Use role="status" for general status updates, role="alert" for urgent messages, or aria-live="polite" regions for dynamic content areas.