All WCAG 2.1 Success Criteria (A & AA)

To conform to WCAG 2.1 AA — the standard U.S. courts and the DOJ treat as the benchmark — your site must satisfy 50 success criteria: 30 at Level A and 20 at Level AA. This page lists every one, grouped under the four POUR principles, each linking to a full breakdown.

How WCAG 2.1 is structured

WCAG is organized as a pyramid. At the top sit the four POUR principles — Perceivable, Operable, Understandable, Robust. Under those sit 13 guidelines (broad goals like “Text Alternatives” or “Navigable”). And under the guidelines sit the success criteria — the specific, testable rules you actually pass or fail. WCAG 2.1, published by the W3C Web Accessibility Initiative (W3C/WAI) in 2018, contains 78 success criteria in total.

Each criterion carries a conformance level: A (essential — failing it blocks whole groups of users), AA (the practical standard for most organizations), or AAA (the strictest, rarely required across an entire site). The 28 AAA criteria are excluded from the AA target, which leaves the 50 Level A and AA criteria below. For more on what the tiers mean, see our guide to conformance levels A, AA, and AAA.

Two practical notes. First, WCAG 2.1 added 17 success criteria to the original 2008 WCAG 2.0 — mostly to address mobile, low vision, and cognitive needs (you’ll spot them in the 1.3.4–1.4.13 and 2.5.x ranges below). Second, when the DOJ issued its 2024 Title II rule for state and local government websites, it adopted WCAG 2.1 Level AA specifically — not the older 2.0 — confirming this exact list as the federal reference point (ADA.gov fact sheet).

A criterion that doesn’t apply to your content (for example, captions on a site with no video) is satisfied by default — but everything that does apply must pass.

Principle 1: Perceivable

Users must be able to take in your information through at least one sense. This principle holds the most-litigated barrier of all — missing alt text (1.1.1). It spans four guidelines: text alternatives, time-based media, adaptable structure, and distinguishable presentation.

• 1.1.1 Non-text Content (A) — Every image, icon, and control needs a text alternative a screen reader can read.
• 1.2.1 Audio-only and Video-only (Prerecorded) (A) — Provide a transcript for audio-only and an alternative for video-only media.
• 1.2.2 Captions (Prerecorded) (A) — Synchronized captions for all prerecorded video with sound.
• 1.2.3 Audio Description or Media Alternative (Prerecorded) (A) — Describe important visual information in prerecorded video.
• 1.2.4 Captions (Live) (AA) — Real-time captions for live audio in synchronized media.
• 1.2.5 Audio Description (Prerecorded) (AA) — A spoken audio description track for prerecorded video.
• 1.3.1 Info and Relationships (A) — Structure (headings, lists, tables, labels) must be coded, not just styled.
• 1.3.2 Meaningful Sequence (A) — Reading order in the code must make sense when CSS is stripped away.
• 1.3.3 Sensory Characteristics (A) — Don’t rely on shape, size, or position alone (“click the round button”).
• 1.3.4 Orientation (AA) — Don’t lock content to portrait or landscape unless essential.
• 1.3.5 Identify Input Purpose (AA) — Mark up common fields (name, email) so browsers can autofill them.
• 1.4.1 Use of Color (A) — Never use color as the only way to convey meaning. (See our color contrast guide.)
• 1.4.2 Audio Control (A) — Auto-playing audio over 3 seconds needs a pause or stop control.
• 1.4.3 Contrast (Minimum) (AA) — 4.5:1 contrast for normal text, 3:1 for large text.
• 1.4.4 Resize Text (AA) — Text must scale to 200% without loss of content or function.
• 1.4.5 Images of Text (AA) — Use real text instead of pictures of text wherever possible.
• 1.4.10 Reflow (AA) — Content reflows to a single column at 320px wide, no horizontal scroll.
• 1.4.11 Non-text Contrast (AA) — 3:1 contrast for buttons, form borders, and meaningful graphics.
• 1.4.12 Text Spacing (AA) — Content survives user-adjusted line height, letter, and word spacing.
• 1.4.13 Content on Hover or Focus (AA) — Tooltips and popovers must be dismissable, hoverable, and persistent.

Principle 2: Operable

Users must be able to navigate and operate your site with whatever input device they use — often a keyboard alone, never a mouse. This is the second most-cited category in web complaints. It covers keyboard access, timing, seizures, navigation, and pointer input.

• 2.1.1 Keyboard (A) — Every function works from the keyboard. (See keyboard navigation.)
• 2.1.2 No Keyboard Trap (A) — Keyboard focus can always move away from a component.
• 2.1.4 Character Key Shortcuts (A) — Single-key shortcuts must be remappable or turn-off-able.
• 2.2.1 Timing Adjustable (A) — Users can extend, adjust, or turn off time limits.
• 2.2.2 Pause, Stop, Hide (A) — Auto-moving carousels and animations need a pause control.
• 2.3.1 Three Flashes or Below Threshold (A) — Nothing flashes more than three times per second (seizure risk).
• 2.4.1 Bypass Blocks (A) — A “skip to content” link or landmarks to jump repeated navigation.
• 2.4.2 Page Titled (A) — Each page has a unique, descriptive <title>.
• 2.4.3 Focus Order (A) — Tab order follows a logical, meaningful sequence.
• 2.4.4 Link Purpose (In Context) (A) — Link text makes its destination clear (“View pricing,” not “click here”).
• 2.4.5 Multiple Ways (AA) — Offer more than one route to a page (menu, search, sitemap).
• 2.4.6 Headings and Labels (AA) — Headings and labels describe their topic or purpose. (See headings & landmarks.)
• 2.4.7 Focus Visible (AA) — Keyboard focus is always visibly indicated.
• 2.5.1 Pointer Gestures (A) — Multi-point or path gestures have a single-pointer alternative.
• 2.5.2 Pointer Cancellation (A) — Actions trigger on up-event, so a mis-tap can be aborted.
• 2.5.3 Label in Name (A) — A control’s accessible name includes its visible label text.
• 2.5.4 Motion Actuation (A) — Device-motion features (shake to undo) have a standard alternative.

Principle 3: Understandable

Users must be able to comprehend both your content and how your interface behaves. This principle protects users with cognitive disabilities, learning differences, and anyone working under stress. It spans three guidelines: readable, predictable, and input assistance.

• 3.1.1 Language of Page (A) — Set the page’s default language (lang="en") so screen readers pronounce it correctly.
• 3.1.2 Language of Parts (AA) — Mark passages that switch to another language.
• 3.2.1 On Focus (A) — Focusing an element must not trigger an unexpected change of context.
• 3.2.2 On Input (A) — Changing a field’s value must not auto-submit or jump unexpectedly.
• 3.2.3 Consistent Navigation (AA) — Navigation appears in the same relative order on every page.
• 3.2.4 Consistent Identification (AA) — The same component is labeled the same way site-wide.
• 3.3.1 Error Identification (A) — Input errors are clearly identified in text, not just color.
• 3.3.2 Labels or Instructions (A) — Form fields have visible labels and instructions. (See accessible forms.)
• 3.3.3 Error Suggestion (AA) — When you know how to fix an error, tell the user how.
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA) — Reversible, checkable, or confirmable submissions for high-stakes actions.

Principle 4: Robust

Your content must work reliably across browsers and — critically — assistive technologies, now and as those tools evolve. This is the most technical principle, and it’s where custom JavaScript components most often break. It has a single guideline, “Compatible,” with three criteria.

• 4.1.1 Parsing (A) — Well-formed markup: no duplicate IDs, properly nested elements. (Note: W3C deprecated this criterion in WCAG 2.2, but it still applies under the 2.1 standard.)
• 4.1.2 Name, Role, Value (A) — Custom controls expose a name, role, and state to assistive tech. (See ARIA labels and roles.)
• 4.1.3 Status Messages (AA) — Status updates (“Item added to cart”) are announced without stealing focus.

How these 50 criteria map to ADA risk

There is no separate ADA code for websites. U.S. courts, the DOJ, and most settlement agreements treat WCAG 2.1 AA — this exact list of 50 criteria — as the practical standard. The DOJ’s 2024 Title II rule made that explicit for state and local governments, requiring conformance with WCAG 2.1 AA by April 2026 for larger jurisdictions and 2027 for smaller ones. Private businesses under Title III face the same benchmark by court precedent, even without a formal regulation — which is why hundreds of web accessibility lawsuits are filed every year against companies whose sites fail criteria on this page.

A blunt reality: automated scanners catch only a fraction of these. Tools reliably flag a portion of 1.1.1, 1.4.3, and 4.1.1 failures, but criteria like 1.3.2 Meaningful Sequence, 2.4.3 Focus Order, 2.5.3 Label in Name, and 3.3.3 Error Suggestion require a human testing with a keyboard and a screen reader. This is also why accessibility overlays don’t work: a widget bolted onto your page can’t rebuild the broken HTML behind 4.1.2, can’t add genuine keyboard operability for 2.1.1, and can’t fix a reading order it never controlled. The underlying code still fails — which is why overlays keep appearing in lawsuits rather than preventing them.

This page explains accessibility standards, not legal requirements — it isn’t legal advice. For your specific exposure, consult a qualified attorney.

Turn the checklist into a fixed site

This list is your map; an audit is the territory. Curbcut tests every applicable criterion by hand — keyboard, screen reader, and code review — then remediates the failures manually, no overlay and no shortcut. Each finding comes back mapped to its exact success criterion with a fix, so you can see precisely where you stand against WCAG 2.1 AA.

Start with a free accessibility scan to surface the obvious failures, or have us audit your site against all 50 criteria for the complete picture — including the manual-only items a scanner will never catch.