Every Web Content Accessibility Guidelines 2.1 Level AA success criterion — explained in plain English with practical guidance for developers and designers.
Scan Your Site Free →The Web Content Accessibility Guidelines (WCAG) 2.1 are the international standard for web accessibility, published by the W3C. Level AA is the benchmark required for ADA compliance, Section 508, and most international laws — including the ADA Title II deadline for U.S. government-adjacent websites.
WCAG 2.1 AA builds on Level A with 17 additional criteria, covering areas like color contrast, text resizing, focus visibility, and captions for live audio. Failing to meet these criteria exposes your organization to legal risk and locks out millions of users.
Use this checklist as a reference during development, QA, or legal review. Click any criterion to expand its explanation and actionable guidance. Then scan your site free to see exactly which criteria your pages pass or fail.
Information and UI components must be presentable to users in ways they can perceive.
All non-text content (images, icons, charts, audio controls) must have a text alternative that serves the equivalent purpose. Decorative images use empty alt="". Complex images (charts, graphs) need extended descriptions.
<img> needs an alt attribute. If the image conveys information, describe it. If it's purely decorative, use alt="". Never omit the attribute entirely.Prerecorded audio-only content must have a text transcript. Prerecorded video-only content must have either an audio description or a text alternative.
Captions are required for all prerecorded audio content in synchronized media (video + audio). Auto-generated captions alone do not meet this requirement unless they are accurate.
.vtt) or SRT caption files with your <video> element's <track kind="captions">.Prerecorded video with audio must have an audio description or a full text alternative that describes the visual content conveyed.
Live audio content in synchronized media must have real-time captions. This applies to live webinars, streams, and broadcasts.
Audio descriptions must be provided for all prerecorded video content in synchronized media. This is in addition to 1.2.3 — at AA, a text alternative is not sufficient; an actual audio description track is required.
<track kind="descriptions"> or provide an alternate version with descriptions baked into the audio.Information, structure, and relationships conveyed through presentation must also be available programmatically (via HTML semantics or ARIA). A heading that looks bold shouldn't just be a <span style="font-weight:bold"> — it needs to be an <h1>–<h6>.
<nav>, <main>, <header>, <table> with <th scope>, <label> for form fields.When the sequence of content affects meaning, the correct reading order must be determinable from the source code — not just from the visual layout. CSS positioning shouldn't reorder logical reading flow.
Instructions must not rely solely on sensory characteristics like shape, color, size, visual location, or sound. "Click the green button" or "see the diagram on the right" are not accessible instructions.
Content must not restrict its view and operation to a single display orientation (portrait or landscape) unless the specific orientation is essential for the content (e.g., a piano app).
For form inputs that collect personal information, the purpose can be programmatically determined using HTML autocomplete attributes. This enables assistive technologies to present custom labels and icons.
autocomplete values like name, email, tel, street-address to relevant input fields.Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Error states, required fields, and links must have additional indicators.
If audio plays automatically for more than 3 seconds, users must be able to pause/stop it or control the volume independently of the system volume.
Text and images of text must have a contrast ratio of at least 4.5:1 against their background. Large text (18pt / 14pt bold) requires 3:1. Decorative text and logotypes are exempt.
Text must be resizable up to 200% without assistive technology and without loss of content or functionality. Pages that break layout or truncate content when browser zoom is set to 200% fail this criterion.
rem, em) for font sizes. Test at 200% browser zoom. Fixed-height containers with overflow:hidden are a common culprit.If the same visual presentation can be achieved with real text, images of text must not be used — except for logotypes and situations where a particular visual presentation is essential.
Content must reflow to a single column when the viewport is narrowed to 320 CSS pixels without requiring horizontal scrolling (except for content that inherently requires two-dimensional layout, like maps or data tables).
max-width containers. Avoid fixed-width layouts.UI components (buttons, inputs, checkboxes, focus indicators) and meaningful graphical objects must have a 3:1 contrast ratio against adjacent colors.
No content or functionality is lost when users override: line height to 1.5×, letter spacing to 0.12em, word spacing to 0.16em, and spacing after paragraphs to 2em.
Content that appears on hover or keyboard focus (tooltips, dropdowns) must be: (1) dismissible without moving focus, (2) hoverable over the appearing content, and (3) persistent until dismissed.
UI components and navigation must be operable.
All functionality must be operable via keyboard. No keyboard traps. Custom interactive widgets (carousels, date pickers, custom dropdowns) must implement keyboard interaction patterns.
If keyboard focus moves to a component, focus can be moved away using standard key presses (Tab, Esc). If non-standard keys are needed, users must be advised.
If single-character keyboard shortcuts are implemented, users must be able to turn them off, remap them to a non-character key, or activate them only when a UI component is focused.
When time limits are set, users must be able to: turn off the limit, adjust it (at least 10× default), or be warned and given at least 20 seconds to extend it.
Moving, blinking, scrolling, or auto-updating content that lasts over 5 seconds must have controls to pause, stop, or hide it.
Pages must not contain anything that flashes more than three times per second, unless the flash is below the general flash and red flash thresholds. Flashing content can trigger photosensitive seizures.
prefers-reduced-motion to disable animations for sensitive users. Test with the PEAT tool.A mechanism must be available to bypass blocks of content that are repeated on multiple pages (e.g., navigation menus). This is typically a "Skip to main content" link.
<a class="skip-link" href="#main">Skip to main content</a>. Show it on focus.Web pages must have titles that describe the topic or purpose. Each page in a multi-page site should have a unique, descriptive title.
"Page Name — Site Name". Avoid generic titles like "Home" or "Page 1". Update titles on client-side navigation in SPAs.If a web page can be navigated sequentially, the focus order must preserve meaning and operability. Tab order should follow the logical reading order of the page.
tabindex values (they break natural DOM order). Use tabindex="0" to include elements and tabindex="-1" to exclude them from tab order.The purpose of each link must be determinable from the link text alone or from the link text plus its programmatically determined context (surrounding sentence, list item, table cell, or heading).
aria-label or visually-hidden text to differentiate repeated "Read more" links.More than one way must be available to locate a web page within a set of pages (except where the page is a step in a process). Examples: site map, search, navigation menu, related links.
Headings and labels must describe the topic or purpose. Vague headings like "More" or "Click Here" and unlabeled form fields are failures.
<label> or an aria-label. Headings should clearly describe the following section content.Any keyboard-operable interface must have a visible focus indicator. Removing the default browser focus outline without a custom replacement is a failure.
outline: none without replacing it. Use :focus-visible to show focus rings only for keyboard users while hiding them for mouse clicks.All functionality that uses multi-point or path-based gestures (pinch-to-zoom, swipe) must also be operable with a single pointer (tap or click), unless the gesture is essential.
For single-pointer operations, at least one of: no down-event trigger, abort/undo available, up-event reversal, or the down-event trigger is essential.
mouseup/touchend, not mousedown/touchstart. This lets users cancel by moving the pointer away before releasing.For UI components with visible text labels, the accessible name must contain the visible label text. This enables voice control users to activate controls by saying the visible label.
aria-label="Send form", a voice user saying "Click Submit" won't be able to activate it. The accessible name must include the visible text.Functionality triggered by device motion (shaking, tilting) must also be operable via UI components, and users must be able to disable the motion response.
Information and the operation of the UI must be understandable.
The default human language of each web page must be programmatically determinable. Screen readers use this to select the correct speech engine and pronunciation rules.
<html lang="en"> (or the appropriate language code). Missing lang is one of the most common and easily-fixed failures.When content on a page switches language (a French quote on an English page), that passage must have a lang attribute identifying the language change.
<blockquote lang="fr">…</blockquote>. Proper nouns, technical terms, and common foreign words that have been adopted into the language are exempt.When a UI component receives focus, it must not initiate a change of context. Tabbing to a dropdown should not automatically submit a form or navigate to a new page.
onFocus handlers that trigger navigation or major UI changes. Context changes should require explicit user action (Enter, click).Changing the setting of a UI component must not automatically cause a change of context unless the user has been advised beforehand. Selecting a value in a <select> should not immediately navigate away.
onChange on select elements to navigate. Instead, add a "Go" button. Or warn users: "Selecting a country will reload the page."Navigation mechanisms that appear on multiple pages must occur in the same relative order each time, unless a change is initiated by the user.
Components with the same functionality across a set of pages must be consistently identified. A search field called "Search" on one page and "Find" on another violates this criterion.
If an input error is automatically detected, the item in error must be identified and the error described to the user in text. Red border alone is not sufficient.
aria-describedby to link error messages to the input. Announce errors with aria-live="polite" or by moving focus to the first error.Labels or instructions must be provided when content requires user input. Format hints like "MM/DD/YYYY" or required field indicators must be present before submission.
placeholder as supplemental, not as a label — placeholders disappear when typing begins.If an input error is detected and suggestions for correction are known, those suggestions must be provided to the user — unless doing so would jeopardize security.
For pages that cause legal commitments, financial transactions, or data submissions, at least one of the following must be true: reversible, checked for errors, or confirmable before submission.
Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies.
HTML must have complete start and end tags, elements nested according to spec, no duplicate attributes, and unique IDs. Malformed HTML causes AT to fail silently.
id attributes and improperly nested elements are common sources of AT failures.All UI components must have accessible names, roles, and values that can be programmatically determined and set. Custom widgets built from <div> elements without ARIA are the most common failure.
<button>, <input>, <select>). For custom widgets, apply role, aria-label/aria-labelledby, and state attributes (aria-expanded, aria-checked).Status messages (success notifications, errors, loading indicators, search result counts) must be programmatically determinable through role or properties so they can be announced by AT without receiving focus.
aria-live="polite" for non-urgent status messages and role="alert" (or aria-live="assertive") for errors. Toast notifications, form submission confirmations, and cart update counts all need live regions.