You have probably been told your site needs to meet WCAG 2.1 AA. Maybe a client mentioned it in a brief. Maybe legal sent over a scary email about the European Accessibility Act. Maybe you actually tried reading the official W3C specification and gave up somewhere around "programmatically determined." Here is the thing most guides get wrong: they either dumb down the criteria into useless one-liners, or they copy-paste the spec language that nobody outside the W3C working group actually understands. Neither approach helps you write better code on Monday morning. This guide takes a different approach. We go through all 50 WCAG 2.1 Level A and AA success criteria, organized by the four POUR principles (Perceivable, Operable, Understandable, Robust). For each criterion, you get a plain-English explanation of what it actually means, a concrete pass/fail test you can run, and real code examples showing the right and wrong way to handle it. A quick note on scope: WCAG 2.1 AA includes everything from Level A plus the Level AA criteria. We cover both because you cannot claim AA conformance without meeting Level A first. If you have already handled the basics and want to jump straight to the AA additions, look for the "(AA)" marker next to each heading. Want to check how your site scores right now? Run a [free accessibility scan](/) before diving in. It takes about 30 seconds and will flag the most common violations from this checklist automatically.
How This Checklist Works
WCAG organizes its guidelines under four principles, often abbreviated POUR:
**Perceivable** means users must be able to perceive the information. If someone cannot see, the content needs a text alternative. If someone cannot hear, video needs captions.
**Operable** means users must be able to operate the interface. Everything that works with a mouse must work with a keyboard. Users need enough time. Nothing should cause seizures.
**Understandable** means users must be able to understand both the content and how the interface works. Text must be readable. Pages must behave predictably. Users need help avoiding and correcting mistakes.
**Robust** means content must be robust enough for different user agents and assistive technologies to interpret it reliably. In practice, this mostly comes down to valid, semantic HTML and proper ARIA usage.
For each success criterion below, we provide: - The official WCAG reference number (e.g., 1.1.1) - Whether it is Level A or Level AA - A plain-English explanation - A pass/fail check - Code examples where applicable
Let us get into it.
Principle 1: Perceivable
Perceivable criteria ensure that all users can access the information on your page, regardless of which senses they use. This is the largest group of criteria, and the one where most sites fail hardest. Missing alt text, unlabeled images, auto-playing video without captions, these are the bread-and-butter accessibility violations that scanners catch by the thousands every day.
1.1.1 Non-text Content (A)
Every non-text element, images, icons, charts, CAPTCHAs, needs a text alternative that serves the same purpose. Decorative images get an empty alt attribute so screen readers skip them. **Pass/Fail Check:** Visit your page with images disabled. Can you still understand all the content? If an image conveys information that disappears without it, you have a failure. **Good:** `
`
`
`
**Bad:**
``
``
``
The most common mistake I see is lazy alt text. Writing alt="logo" on your company logo is technically present, but it should say something like alt="Acme Corp home" if it links to the homepage. The alt text describes the function, not just the object.
1.2.1 Audio-only and Video-only (A)
Pre-recorded audio-only content needs a text transcript. Pre-recorded video-only content (no audio track) needs either a text alternative or an audio description.
**Pass/Fail Check:** Can a deaf user get all information from your audio content via text? Can a blind user get all information from your silent video via audio or text?
This comes up most often with podcast embeds and background product videos. That hero video showing your office with no narration? It either needs a text description of what it shows, or it needs to be marked as purely decorative.
1.2.2 Captions for Pre-recorded Audio (A)
All pre-recorded video with audio must have synchronized captions. Auto-generated captions from YouTube count only if you have reviewed and corrected them, which nobody does, so treat auto-captions as a starting point, not a solution. **Pass/Fail Check:** Watch your video with sound off, captions on. Does every spoken word appear? Are speaker changes identified? Are meaningful sounds (applause, music cues, phone ringing) described? **Good:** `` Remember that captions differ from subtitles. Captions include non-speech audio ("[door slams]", "[upbeat music]"), while subtitles only translate dialogue. WCAG requires captions.1.2.3 Audio Description or Media Alternative (A)
Pre-recorded video needs an audio description or a full text transcript. Audio descriptions narrate the visual information that is not conveyed through the existing audio track, things like on-screen text, scene changes, or actions that are not described in dialogue.
**Pass/Fail Check:** Can a blind user follow your video entirely through the audio track? If important visual content is not described in the existing audio, you need an audio description track or a text alternative.
For most web content, providing a detailed text transcript below the video is the simplest compliant approach. Audio descriptions are more relevant for narrative video content like training courses or storytelling.
1.2.4 Captions for Live Audio (AA)
Live video with audio (webinars, live streams, virtual events) must have real-time captions. This is an AA requirement, so if you are targeting AA conformance and you host live events, you need a plan.
**Pass/Fail Check:** During your last live stream, were captions available in real-time? Were they accurate enough to follow?
Options range from professional CART (Communication Access Realtime Translation) captioners to AI-powered solutions like Otter.ai or the built-in captioning in Zoom and Teams. AI captions have gotten surprisingly good, but they still struggle with technical jargon, accents, and multiple speakers.
1.2.5 Audio Description for Pre-recorded Video (AA)
This is the AA version of 1.2.3. At Level A, you could provide either audio description or a text alternative. At Level AA, you specifically need audio description for pre-recorded video content where the existing audio track does not convey all visual information.
**Pass/Fail Check:** Play your video with your eyes closed. If you miss key information, such as on-screen demonstrations, text overlays, or visual transitions that change meaning, you need audio description.
Practical tip: the easiest way to avoid needing audio descriptions is to describe everything verbally during the original recording. If the presenter says "as you can see on screen, the revenue chart shows an 18% increase" instead of just "as you can see on screen," you have already solved the problem.
1.3.1 Info and Relationships (A)
Information, structure, and relationships conveyed visually must also be conveyed programmatically. If something looks like a heading, it must be marked up as a heading. If a visual layout creates groups, the HTML structure must reflect those groups. **Pass/Fail Check:** Disable CSS and look at your page. Does the structure still make sense? Are headings, lists, tables, and form groups apparent from the markup alone? **Good:** `| Region | Revenue |
|---|---|
| Europe | $1.2M |
1.3.2 Meaningful Sequence (A)
When the order of content matters, the reading order in the DOM must match the visual order. This trips up developers who use CSS Grid or Flexbox to reorder elements visually while leaving the source order jumbled. **Pass/Fail Check:** Tab through your page. Does the focus order match what a sighted user would expect? Read the page with a screen reader. Does the content flow logically? **Bad pattern:** `1.3.3 Sensory Characteristics (A)
Instructions must not rely solely on shape, color, size, visual location, orientation, or sound. Saying "click the red button" or "the information in the right column" fails this criterion because a blind user cannot identify those cues.
**Pass/Fail Check:** Read your instructions aloud without looking at the page. Can someone follow them?
**Bad:** "Click the green button to continue." **Good:** "Click the 'Submit Order' button (green) to continue."
**Bad:** "Required fields are shown in red." **Good:** "Required fields are marked with an asterisk (*) and shown in red."
1.3.4 Orientation (AA) - New in WCAG 2.1
Content must not restrict its view and operation to a single display orientation (portrait or landscape) unless a specific orientation is essential. A banking check deposit that requires landscape for scanning is acceptable. A blog that breaks in landscape is not.
**Pass/Fail Check:** Rotate your device. Does everything still work in both orientations?
**Code fix:** `/* Bad - forces portrait */` `@media (orientation: landscape) { .container { display: none; } }`
`/* Good - adapts to both */` `@media (orientation: landscape) { .container { flex-direction: row; } }` `@media (orientation: portrait) { .container { flex-direction: column; } }`
This criterion was added in WCAG 2.1 specifically for mobile users who mount their devices in fixed orientations due to motor disabilities.
1.3.5 Identify Input Purpose (AA) - New in WCAG 2.1
Input fields that collect personal information must have an autocomplete attribute that identifies the purpose. This helps password managers, autofill, and assistive technologies fill in forms correctly. **Pass/Fail Check:** Do your form fields for name, email, address, phone, and credit card have appropriate autocomplete values? **Good:** `` `` `` `` **Bad:** `` `` The full list of valid autocomplete values is in the HTML spec. The most common ones: given-name, family-name, email, tel, street-address, postal-code, country-name, cc-number, cc-exp, cc-csc.1.4.1 Use of Color (A)
Color must not be the only way to convey information, indicate an action, prompt a response, or distinguish a visual element. Links in body text that are only distinguished by color need an additional indicator like an underline.
**Pass/Fail Check:** View your page in grayscale (most OS have an accessibility filter for this). Can you still identify all interactive elements, error states, and required fields?
**Common failures:** - Form errors indicated only by turning the field border red - Links in text that have no underline and only differ by color - Charts using only color to distinguish data series - Status indicators (green = good, red = bad) with no text label
Fix these by adding a secondary indicator: underlines for links, icons or text for errors, patterns or labels for charts.
1.4.2 Audio Control (A)
If audio plays automatically for more than 3 seconds, users must be able to pause, stop, or control the volume independently from the system volume.
**Pass/Fail Check:** Load your page. Does audio start playing? If so, is there a visible control to stop it within the first 3 seconds?
Best practice: do not auto-play audio at all. It interferes with screen readers, annoys users, and violates most people's expectations. If you must have background audio, start it muted and let users opt in.
1.4.3 Contrast Minimum (AA)
Text and images of text must have a contrast ratio of at least 4.5:1 against the background. Large text (18pt / 24px regular, or 14pt / 18.66px bold) gets a relaxed ratio of 3:1.
**Pass/Fail Check:** Use a contrast checker tool or [scan your site](/) for contrast issues. Check text on colored backgrounds, text over images, placeholder text, and disabled states.
**Common failures:** - Light gray text on white (#999 on #fff = 2.85:1, fails) - White text on a light background image without overlay - Placeholder text in inputs (often light gray)
**Quick reference for safe combinations:** - #595959 on #ffffff = 7:1 (passes AAA) - #767676 on #ffffff = 4.54:1 (barely passes AA) - #999999 on #ffffff = 2.85:1 (fails AA)
That gray placeholder text you love? It almost certainly fails. Use #767676 as your absolute minimum for text on white.
1.4.4 Resize Text (AA)
Text must be resizable up to 200% without loss of content or functionality. Users who zoom their browser to 200% should still be able to read everything and use all features.
**Pass/Fail Check:** Set your browser zoom to 200%. Can you still read all text, access all controls, and complete all tasks? Does any content get clipped or overlap?
**Common failures:** - Fixed-height containers that clip text when it wraps: `height: 40px; overflow: hidden;` - Absolute positioning that causes overlaps at larger sizes - Using viewport units (vw) for font sizes without a minimum
**Good:** `font-size: clamp(1rem, 2vw, 1.5rem);` `min-height: 40px; /* not height: 40px */`
Use relative units (rem, em) for font sizes and min-height instead of fixed height for containers.
1.4.5 Images of Text (AA)
Do not use images to display text if the same visual presentation can be achieved with actual text. Logos are exempt.
**Pass/Fail Check:** Can you select and copy all the text on your page? If a user zooms in, does the text stay sharp? If something looks like text but is actually an image, it likely fails.
**Common failures:** - Header banners with text baked into a JPEG - Infographics with no text alternative - Stylized navigation items as images
With modern CSS (custom fonts, gradients, text-shadow, clip-path), there is almost no reason to use images of text in 2026. If your designer hands you a mockup with text in an image, push back and implement it in CSS.
1.4.10 Reflow (AA) - New in WCAG 2.1
Content must reflow to fit a 320 CSS pixel wide viewport without requiring horizontal scrolling. In practice, this means your site must work at 1280px width zoomed to 400%, which results in a 320px equivalent.
**Pass/Fail Check:** Resize your browser to 320px wide. Is there horizontal scrolling for any content other than data tables, maps, or images that require two-dimensional layout?
**Common failures:** - Fixed-width layouts wider than 320px - Side-by-side elements that do not stack on narrow viewports - Horizontal navigation that does not collapse to a hamburger menu - Code blocks without horizontal scroll
`/* Good - responsive container */` `max-width: 100%; overflow-x: auto; /* for code blocks/tables only */`
This criterion was added in WCAG 2.1 because many low-vision users zoom their browsers rather than using screen magnifiers. If your responsive design already works on mobile, you are probably fine. If you have been skipping mobile optimization, this is your wake-up call.
1.4.11 Non-text Contrast (AA) - New in WCAG 2.1
User interface components (buttons, form fields, focus indicators) and meaningful graphics must have a contrast ratio of at least 3:1 against adjacent colors.
**Pass/Fail Check:** Can you see the boundaries of all form fields, buttons, and interactive controls? Can you see focus indicators? Can you distinguish chart elements?
**Common failures:** - Light gray input borders on white (#ccc on #fff = 1.6:1, fails) - Custom checkboxes with low-contrast borders - Icon-only buttons where the icon has poor contrast - Focus outlines that are nearly invisible
**Good:** `input { border: 2px solid #767676; } /* 4.54:1 on white */` `button:focus { outline: 3px solid #005fcc; } /* high contrast focus */`
This is one of the most commonly failed AA criteria because designers love subtle, thin, light-gray borders. Push back on those designs. A form field nobody can see is a form nobody can fill out.
1.4.12 Text Spacing (AA) - New in WCAG 2.1
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.
**Pass/Fail Check:** Apply these CSS overrides via a browser extension or bookmarklet and check that no text gets cut off:
`* { line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important; } p { margin-bottom: 2em !important; }`
**Common failures:** - Fixed-height containers that clip text when spacing increases - Overlapping elements when line height grows - Cards or buttons where text overflows its container
The fix is the same as for 1.4.4: use flexible containers with min-height instead of fixed height, and avoid overflow: hidden on text containers.
1.4.13 Content on Hover or Focus (AA) - New in WCAG 2.1
When hovering or focusing on an element triggers additional content (tooltips, dropdowns, popovers), that content must be: dismissible without moving hover or focus (usually Escape key), hoverable itself (the user can move the mouse onto the tooltip), and persistent until dismissed or the trigger is removed. **Pass/Fail Check:** Hover over a tooltip. Can you move your mouse onto the tooltip text? Press Escape, does the tooltip close? Does the tooltip stay visible long enough to read? **Good:** `Principle 2: Operable
Operable criteria ensure users can navigate and interact with your site using various input methods. If a keyboard user cannot reach a button, or a user with motor impairments cannot click a tiny target, your interface is not operable. These criteria often get overlooked because developers test with mice, not keyboards.
2.1.1 Keyboard (A)
All functionality must be operable through a keyboard interface. Every click handler, every drag interaction, every custom widget, it all needs to work with keyboard alone. **Pass/Fail Check:** Unplug your mouse (or stop touching your trackpad). Can you navigate to and activate every interactive element using only Tab, Shift+Tab, Enter, Space, and arrow keys? **Common failures:** - Click handlers on div or span elements without keyboard support - Drag-and-drop without keyboard alternative - Custom dropdowns that only work with mouse - Hover-only interactions with no focus equivalent **Good:** `` **Bad:** `2.1.2 No Keyboard Trap (A)
If a keyboard user can navigate into a component, they must be able to navigate out. The classic failure is a modal dialog where Tab cycles through the modal but you cannot close it with Escape or navigate away.
**Pass/Fail Check:** Tab into every interactive component on your page. Can you always Tab out? Can you close modals with Escape? Can you exit embedded content like iframes?
**Common failures:** - Modal dialogs without Escape to close - Embedded videos or maps that trap focus - WYSIWYG editors that capture Tab for indentation - Auto-complete dropdowns that trap keyboard focus
For modals, implement focus trapping correctly: keep Tab cycling within the modal, but always allow Escape to close it and return focus to the trigger element.
2.1.4 Character Key Shortcuts (A) - New in WCAG 2.1
If you implement keyboard shortcuts using single character keys (letters, numbers, punctuation), users must be able to turn them off, remap them, or they should only be active when the relevant component has focus.
**Pass/Fail Check:** Does your app use single-key shortcuts (like "k" to play/pause or "j" to scroll)? If yes, can users disable them or remap them?
This criterion exists because speech recognition users may accidentally trigger shortcuts by speaking. If your shortcuts require a modifier key (Ctrl+K, Alt+J), you are already compliant. Single-key shortcuts are the problem.
**Good:** `Ctrl+K` to open search **Bad:** `K` to open search (without option to disable)
2.2.1 Timing Adjustable (A)
If your page has a time limit, users must be able to turn it off, adjust it, or extend it. The user must be warned at least 20 seconds before time expires and given a simple action to extend it.
**Pass/Fail Check:** Does your site have session timeouts, auto-advancing carousels, or timed quizzes? Can users pause, extend, or disable the timing?
**Common failures:** - Session timeouts without warning or extension option - Auto-rotating carousels (these fail multiple criteria) - Forms that expire after a fixed time with no warning
Exceptions exist for real-time events (auctions, live sessions) and situations where the time limit is essential (a timed test where timing is being measured).
2.2.2 Pause, Stop, Hide (A)
Moving, blinking, scrolling, or auto-updating content that starts automatically must have a mechanism to pause, stop, or hide it. This includes carousels, marquees, animated backgrounds, and auto-refreshing feeds. **Pass/Fail Check:** Is anything moving on your page without user action? Can the user stop it? Auto-advancing carousels, animated backgrounds, and scrolling tickers all need pause controls. **Good:** `2.3.1 Three Flashes or Below Threshold (A)
Nothing on the page should flash more than three times per second. Flashing content can trigger seizures in people with photosensitive epilepsy.
**Pass/Fail Check:** Does any element on your page flash or blink rapidly? Does any video content contain strobe effects?
This is a safety criterion, not just a usability preference. Violating this can literally cause physical harm. If you have any animated content, ensure it stays under three flashes per second. Be especially careful with video content and GIF animations.
2.4.1 Bypass Blocks (A)
Provide a mechanism to skip past repeated content blocks. The most common implementation is a "skip to main content" link. **Pass/Fail Check:** Press Tab on your page. Is the first focusable element a "Skip to content" link? Does it work, does it actually move focus to the main content? **Good:** `` ` Skip to main content` ` ` `2.4.2 Page Titled (A)
Every page needs a descriptive title tag that describes its topic or purpose. **Pass/Fail Check:** Look at your browser tabs. Can you tell which page is which from the titles alone? Are they unique and descriptive? **Bad:** `2.4.3 Focus Order (A)
When navigating sequentially with a keyboard, focus order must be logical and intuitive. Focus should move top-to-bottom, left-to-right (in LTR languages), matching the visual layout.
**Pass/Fail Check:** Tab through your entire page. Does focus move in a logical sequence? Does it ever jump unexpectedly to a different section?
**Common failures:** - Using tabindex values greater than 0 (this overrides natural order) - CSS Grid or Flexbox reordering without matching DOM order - Dynamic content inserted in illogical DOM positions
**Rule:** Never use tabindex with a positive value. Use tabindex="0" to make elements focusable in natural DOM order, or tabindex="-1" to make elements programmatically focusable but not in the tab sequence.
2.4.4 Link Purpose (In Context) (A)
Every link's purpose must be determinable from the link text itself, or from the link text combined with its surrounding context (paragraph, list item, table cell, or heading). **Pass/Fail Check:** Read just the link text for each link on the page. Can you tell where each one goes? If your page has three "Click here" links going to different places, it fails. **Bad:** `To learn more about our pricing, click here.
` **Good:** `` Screen reader users often navigate by listing all links on a page. A list of "click here", "read more", "click here", "learn more" is useless. Each link should make sense out of context.2.4.5 Multiple Ways (AA)
Users must have more than one way to find a page within your site. This typically means providing at least two of: navigation menu, site search, sitemap, table of contents, or links from related pages.
**Pass/Fail Check:** Can users find your page via at least two different methods? Navigation plus search usually covers this.
Most sites pass this just by having a navigation menu and a sitemap. If you also have a search function, you are well covered.
2.4.6 Headings and Labels (AA)
Headings and labels must describe the topic or purpose of the content they introduce. This does not require that you have headings, but if you use them, they must be descriptive.
**Pass/Fail Check:** Read just the headings on your page (you can use the heading outline in a browser extension). Do they tell a coherent story about the page content?
**Bad headings:** "Section 1", "Details", "More Info" **Good headings:** "Shipping Options", "Return Policy Details", "Customer Reviews"
Same for form labels. "Field 1" is not a label. "Email address" is.
2.4.7 Focus Visible (AA)
Keyboard focus indicators must be visible. When a user tabs to an element, they must be able to see where focus is.
**Pass/Fail Check:** Tab through your page. Can you always see which element currently has focus? Is the focus indicator easy to spot?
**The cardinal sin of web development:** `*:focus { outline: none; }`
Do not do this. Ever. If you do not like the default focus outline, replace it with something better, do not remove it.
**Good:** `:focus-visible { outline: 3px solid #005fcc; outline-offset: 2px; }`
The :focus-visible selector is supported in all modern browsers and only shows the focus ring for keyboard navigation, not mouse clicks. Use it instead of removing focus styles entirely.
2.5.1 Pointer Gestures (A) - New in WCAG 2.1
Functionality that requires multipoint or path-based gestures (pinch-zoom, multi-finger swipe, drawing a shape) must also be operable with a single pointer action like a click or tap.
**Pass/Fail Check:** Can every function that uses a multi-finger gesture also be done with a single tap or click? For a map, can you zoom with buttons in addition to pinch-zoom?
This criterion protects users who cannot perform complex gestures due to motor impairments, or who use alternative pointing devices like head pointers or eye tracking.
2.5.2 Pointer Cancellation (A) - New in WCAG 2.1
For functionality triggered by a single pointer, at least one must be true: the action fires on the up-event (mouseup/pointerup), the action can be aborted or undone, or the down-event reverses the up-event.
**Pass/Fail Check:** Press the mouse button on a button, then drag away before releasing. Does the action fire? It should not. Actions should fire on click (which is an up-event), not on mousedown.
Native HTML buttons handle this correctly. Custom JavaScript interactions sometimes fire on mousedown for perceived performance. Resist that temptation.
2.5.3 Label in Name (A) - New in WCAG 2.1
When a component has a visible text label, the accessible name must contain that visible text. This matters for speech recognition users who say "click Submit" and expect the button labeled "Submit" to activate. **Pass/Fail Check:** For each control with visible text, does the accessible name include that text? **Bad:** `` A speech user sees "Submit" and says "click Submit", but the accessible name is "Send form data to server" so the command fails. **Good:** `` Or if you must add extra context: `` The visible text "Submit" appears within the accessible name "Submit contact form", so speech commands work.2.5.4 Motion Actuation (A) - New in WCAG 2.1
Functionality triggered by device motion (tilting, shaking) must also have a UI alternative, and users must be able to disable motion responses.
**Pass/Fail Check:** Does your site use any device motion? Shake to undo, tilt to scroll, etc.? Is there a button alternative for each?
This is rare in web content but common in mobile web apps. If you use the DeviceMotion or DeviceOrientation APIs, ensure there is always an on-screen alternative.
Principle 3: Understandable
Understandable criteria ensure that content is readable and the interface behaves in predictable ways. These criteria often get dismissed as "common sense" but they catch real problems: forms that submit when you change a dropdown, error messages that appear nowhere near the field they reference, and pages with no language declaration that confuse screen readers.
3.1.1 Language of Page (A)
The default human language of each page must be programmatically determinable. In HTML, this means a lang attribute on the html element. **Pass/Fail Check:** View your page source. Does the html tag have a lang attribute? Is it the correct language code? **Good:** `` or `` or `` **Bad:** `` (no lang attribute) This is one of the easiest criteria to meet and one of the most commonly missed. Screen readers use this to select the correct pronunciation engine. Without it, a French screen reader might try to pronounce English text with French phonetics.3.1.2 Language of Parts (AA)
When text appears in a different language than the page default, it must be marked with a lang attribute. This helps screen readers switch pronunciation. **Pass/Fail Check:** Does your English page contain any French, German, Spanish, or other foreign-language text? Is it wrapped in an element with the appropriate lang attribute? **Good:** `The French word bonjour means hello.
` Exceptions: proper names, technical terms that have become part of the language (like "rendezvous" in English), and borrowed phrases that are widely understood.3.2.1 On Focus (A)
When a component receives focus, it must not trigger an automatic change of context. That means no automatic form submissions, no page navigation, and no new windows just because a user tabbed to an element.
**Pass/Fail Check:** Tab through every interactive element. Does anything unexpected happen just because an element received focus? Does a new window open? Does the page navigate away?
This comes up with auto-submit search fields and forms where tabbing to a certain field triggers AJAX updates that change the page structure.
3.2.2 On Input (A)
Changing a form input should not automatically trigger a change of context unless the user has been told about the behavior beforehand. A dropdown that navigates to a new page when you select an option violates this criterion. **Pass/Fail Check:** Change each form input on your page. Does anything unexpected happen? Does selecting a dropdown option submit the form or navigate away? **Bad:** `` **Good:** `` `` Always pair a select element with a submit button unless the user has been warned about auto-submit behavior.3.2.3 Consistent Navigation (AA)
Navigation menus that appear on multiple pages must be in the same relative order on each page. You can add or remove items, but the order of common items must not change.
**Pass/Fail Check:** Visit three different pages on your site. Is the navigation in the same order? Are common elements (logo, search, menu) in the same position?
This seems obvious but gets violated when sites have different templates for different sections, or when a CMS allows different menus per page category.
3.2.4 Consistent Identification (AA)
Components that have the same functionality must be identified consistently. If you use a magnifying glass icon for search on one page, use the same icon everywhere. If you call it "Search" in the header and "Find" in the footer, that is inconsistent.
**Pass/Fail Check:** Look at common components across your site. Is the search always labeled the same? Is the cart icon always the same? Do similar actions have similar labels?
This helps users build a mental model of your site. Consistency reduces cognitive load for everyone, but it is especially important for users with cognitive disabilities.
3.3.1 Error Identification (A)
When an input error is detected, the error must be identified and described to the user in text. It is not enough to turn a field border red; you need a text message explaining what went wrong. **Pass/Fail Check:** Submit a form with incorrect data. Are errors identified in text? Does each error message explain what is wrong? Can a screen reader user find and understand the errors? **Good:** `` `` `Please enter a valid email address (e.g., [email protected])` **Bad:** `` The aria-invalid attribute tells assistive technology the field has an error. The aria-describedby links the error message to the field. The role="alert" ensures the error is announced when it appears.3.3.2 Labels or Instructions (A)
Form fields and interactive controls must have labels or instructions. Every input needs an associated label element or an aria-label/aria-labelledby attribute. **Pass/Fail Check:** Click on a form label. Does focus move to the associated input? For every input, is there a visible label or instruction? **Good:** `` `` **Bad:** `` Placeholder text is NOT a label. It disappears when the user starts typing, leaving them with no idea what the field is for. Always use a visible label in addition to any placeholder text.3.3.3 Error Suggestion (AA)
When an input error is detected and suggestions are known, they must be provided to the user (unless doing so would compromise security).
**Pass/Fail Check:** Submit incorrect data. Does the error message tell you how to fix it, not just what is wrong?
**Bad:** "Invalid date" **Good:** "Invalid date. Please use the format YYYY-MM-DD (e.g., 2026-03-01)"
**Bad:** "Invalid email" **Good:** "Did you mean [email protected]? The email address must include an @ sign and a domain."
The key difference between 3.3.1 (error identification) and 3.3.3 (error suggestion) is that identification says "this is wrong" and suggestion says "try this instead."
3.3.4 Error Prevention for Legal, Financial, and Data (AA)
For forms that create legal commitments, financial transactions, or modify/delete user data, at least one of: submissions are reversible, data is checked and the user can correct it, or a confirmation step is provided before final submission.
**Pass/Fail Check:** For purchase forms, account deletion, or legal agreements, can users review before submitting? Can they undo the action? Is there a confirmation step?
**Good pattern:** 1. User fills out order form 2. Review page shows all details: "You are ordering X for $Y. Shipping to Z." 3. User confirms or goes back to edit 4. Order processes
This protects everyone from mistakes, not just users with disabilities. But it is especially important for users with cognitive or motor disabilities who may make input errors more frequently.
Principle 4: Robust
Robust criteria ensure that content works reliably with current and future user agents, including assistive technologies. In practice, this comes down to writing valid HTML and using ARIA correctly. There are only two criteria here at Levels A and AA, but they are foundational. Get these wrong and assistive technologies cannot make sense of your page at all.
4.1.1 Parsing (A) - Deprecated in WCAG 2.2 but still in 2.1
In HTML, elements must have complete start and end tags, must be nested correctly, must not have duplicate attributes, and all IDs must be unique. This criterion was deprecated in WCAG 2.2 because browsers now handle parsing errors gracefully, but it remains in WCAG 2.1.
**Pass/Fail Check:** Run your HTML through the W3C HTML Validator (validator.w3.org). Fix any parsing errors.
**Common failures:** - Duplicate ID attributes (especially common with CMS-generated content) - Unclosed tags or incorrect nesting - Elements missing required child elements (like ul without li)
Even though browsers are forgiving with malformed HTML, assistive technologies can be less so. Clean, valid HTML is always a good practice.
4.1.2 Name, Role, Value (A)
For all user interface components, the name, role, and value must be programmatically determinable, and changes to these must be communicated to assistive technologies. **Pass/Fail Check:** For each interactive element, can a screen reader announce what it is (role), what it is called (name), and what its current state is (value/state)? **Good:** `` `` When the menu opens, JavaScript updates aria-expanded to "true" and removes hidden from the menu. The screen reader announces the state change. **Bad:** `4.1.3 Status Messages (AA) - New in WCAG 2.1
Status messages that provide information about success, errors, progress, or results must be programmatically determinable without receiving focus. In practice, this means using ARIA live regions. **Pass/Fail Check:** When your page shows a success message, error notification, or "3 results found" message, is it announced by screen readers without the user having to navigate to it? **Good:** `Testing Your WCAG 2.1 AA Compliance
Going through this checklist manually takes time, and even experienced developers miss things. Here is a practical testing workflow that balances thoroughness with efficiency:
**Step 1: Automated scanning.** Run your site through an [automated accessibility scanner](/) to catch the low-hanging fruit. Automated tools typically find 30-40% of WCAG issues, including missing alt text, contrast failures, missing form labels, and structural problems. Start here to identify the obvious issues.
**Step 2: Keyboard testing.** Unplug your mouse and navigate your entire site using only the keyboard. This catches focus order issues, keyboard traps, missing focus indicators, and non-functional interactive elements. Budget 15-20 minutes per major page template.
**Step 3: Screen reader testing.** Test with at least one screen reader. NVDA is free on Windows, VoiceOver is built into macOS and iOS. Navigate your key user flows (finding content, filling forms, completing transactions) and note where the experience breaks down.
**Step 4: Visual review.** Check contrast ratios, text resizing to 200%, content reflow at 320px, and text spacing overrides. Most of the Perceivable criteria need visual verification.
**Step 5: Manual code review.** Check ARIA usage, landmark structure, heading hierarchy, and language attributes. Browser DevTools accessibility panels help here.
Do not try to test everything at once. Prioritize your most important pages and user flows first, then expand coverage over time.
Want a head start? Our [free accessibility scan](/) covers steps 1 and 4 automatically and gives you a prioritized list of issues to fix. It is not a substitute for the full workflow, but it gets you 40% of the way there in 30 seconds.
Common WCAG 2.1 AA Failures by Category
After scanning thousands of websites, certain failures appear over and over. Here are the most frequent ones, grouped by how hard they are to fix:
**Easy fixes (under 30 minutes):** - Missing lang attribute on html element (3.1.1) - Missing alt text on images (1.1.1) - Missing form labels (3.3.2) - Missing page titles or generic titles (2.4.2) - Missing skip navigation link (2.4.1) - Missing autocomplete attributes on personal data fields (1.3.5)
**Medium fixes (1-4 hours):** - Color contrast failures across the site (1.4.3) - Focus indicators removed or invisible (2.4.7) - Non-text contrast on UI components (1.4.11) - Missing or unhelpful error messages (3.3.1, 3.3.3) - Meaningful sequence broken by CSS reordering (1.3.2)
**Hard fixes (days to weeks):** - Custom widgets not keyboard accessible (2.1.1) - Missing ARIA states and properties on dynamic content (4.1.2) - Live region implementation for status messages (4.1.3) - Video captions and audio descriptions (1.2.2, 1.2.5) - Complete reflow at 320px viewport (1.4.10)
Start with the easy fixes. They cover the highest-impact, lowest-effort improvements that affect the most users. Then work through the medium fixes systematically. Schedule the hard fixes across sprints with dedicated accessibility stories.
If you are working through remediation based on a [site audit](/blog/accessibility-audit-guide), cross-reference the audit findings with this checklist to ensure nothing gets missed.
WCAG 2.1 vs 2.2: What Changed
WCAG 2.2, published in October 2023, added 9 new success criteria on top of WCAG 2.1. If you are wondering whether to target 2.1 AA or 2.2 AA, here is the short version: most regulations currently reference WCAG 2.1, but 2.2 is becoming the recommendation.
The new criteria in WCAG 2.2 cover focus appearance (better focus indicators), dragging movements (alternatives to drag-and-drop), target size (minimum 24x24px click targets), consistent help (help mechanisms in the same location), and redundant entry (not asking users for the same information twice).
We have a [detailed comparison of WCAG 2.1 vs 2.2](/blog/wcag-2-2-vs-2-1-differences) if you want the full breakdown.
For now, if you meet WCAG 2.1 AA as outlined in this checklist, you are compliant with current legal requirements in the EU (EAA references EN 301 549, which maps to WCAG 2.1) and the US (ADA case law typically references WCAG 2.1 AA). Meeting 2.2 AA on top of that gives you extra protection and better usability, but 2.1 AA is your compliance baseline.
How WCAG 2.1 AA Maps to the European Accessibility Act
If you are in Europe or serve European customers, you have probably heard about the European Accessibility Act (EAA), which took effect in June 2025. The EAA does not directly reference WCAG, but the harmonized standard it uses, EN 301 549, maps closely to WCAG 2.1 AA.
In practical terms: meeting WCAG 2.1 AA gets you most of the way to EAA compliance. EN 301 549 adds some requirements around documentation, support services, and non-web ICT that WCAG does not cover, but for your website, WCAG 2.1 AA is the technical standard to meet.
The EAA carries real penalties. Unlike the US where accessibility lawsuits are primarily private litigation, EU member states can impose administrative fines and even pull non-compliant products from the market. Check our guide on [EAA fines and penalties by country](/blog/eaa-fines-penalties-by-country) for specifics.
Do not wait until you receive a complaint. Proactive compliance is significantly cheaper than reactive remediation under regulatory pressure. Use this checklist, [scan your site](/), and start fixing issues now.
Printable WCAG 2.1 AA Quick-Reference Checklist
Here is a condensed reference you can print or save. For each criterion, check pass or fail during your audit:
**Perceivable:** 1.1.1 All images have meaningful alt text (or empty alt for decorative) - A 1.2.1 Audio-only has transcript, video-only has text/audio alternative - A 1.2.2 Pre-recorded video has captions - A 1.2.3 Pre-recorded video has audio description or text alternative - A 1.2.4 Live video has real-time captions - AA 1.2.5 Pre-recorded video has audio description - AA 1.3.1 Structure conveyed visually is also in markup (headings, lists, tables) - A 1.3.2 Reading order in DOM matches visual order - A 1.3.3 Instructions do not rely solely on sensory characteristics - A 1.3.4 Content works in both portrait and landscape orientation - AA 1.3.5 Form fields for personal data have autocomplete attributes - AA 1.4.1 Color is not the only way to convey information - A 1.4.2 Auto-playing audio can be paused or stopped - A 1.4.3 Text has minimum 4.5:1 contrast ratio (3:1 for large text) - AA 1.4.4 Text resizable to 200% without loss of content - AA 1.4.5 Real text used instead of images of text - AA 1.4.10 Content reflows at 320px width without horizontal scrolling - AA 1.4.11 UI components and graphics have 3:1 contrast ratio - AA 1.4.12 Content works with overridden text spacing - AA 1.4.13 Hover/focus content is dismissible, hoverable, and persistent - AA
**Operable:** 2.1.1 All functionality accessible via keyboard - A 2.1.2 No keyboard traps - A 2.1.4 Single-key shortcuts can be disabled or remapped - A 2.2.1 Time limits can be adjusted or extended - A 2.2.2 Moving/auto-updating content can be paused - A 2.3.1 No content flashes more than 3 times per second - A 2.4.1 Skip navigation link provided - A 2.4.2 Pages have descriptive titles - A 2.4.3 Focus order is logical - A 2.4.4 Link purpose clear from link text or context - A 2.4.5 Multiple ways to find pages (nav + search or sitemap) - AA 2.4.6 Headings and labels are descriptive - AA 2.4.7 Focus indicator is visible - AA 2.5.1 Multi-point gestures have single-pointer alternative - A 2.5.2 Actions fire on up-event, not down-event - A 2.5.3 Accessible name contains visible label text - A 2.5.4 Motion-triggered functions have UI alternative - A
**Understandable:** 3.1.1 Page language declared in HTML - A 3.1.2 Language changes within content are marked - AA 3.2.1 No context change on focus - A 3.2.2 No context change on input without warning - A 3.2.3 Navigation is consistent across pages - AA 3.2.4 Similar components identified consistently - AA 3.3.1 Errors identified in text - A 3.3.2 Form fields have labels or instructions - A 3.3.3 Error messages suggest corrections - AA 3.3.4 Legal/financial submissions are reversible or confirmable - AA
**Robust:** 4.1.1 HTML is valid (no duplicate IDs, proper nesting) - A 4.1.2 Custom components have name, role, and value - A 4.1.3 Status messages use ARIA live regions - AA
Next Steps: From Checklist to Compliance
You have the checklist. Now what?
First, get a baseline. [Scan your site](/) to see where you stand right now. An automated scan will not catch everything on this list, but it will flag the most common failures and give you a starting point.
Second, prioritize ruthlessly. You probably will not fix all 50 criteria in one sprint. Focus on the issues that affect the most users first: missing alt text, broken keyboard navigation, insufficient contrast, missing form labels. These four categories account for the majority of real-world accessibility barriers.
Third, integrate accessibility into your workflow. Do not treat this checklist as a one-time audit. Add accessibility checks to your code review process, your QA checklist, and your design system. The cheapest accessibility fix is the one you prevent from shipping in the first place.
Fourth, test with real users. All the automated scanning and manual testing in the world cannot replace feedback from people who actually use assistive technology daily. Include people with disabilities in your user testing, or at minimum, partner with an accessibility consultant who works with disabled testers.
WCAG 2.1 AA is not the ceiling, it is the floor. It represents the minimum standard for making your web content usable by people with disabilities. But meeting the standard is genuinely achievable, and this checklist gives you a concrete path to get there.
Ready to start? [Run your free scan](/) and see exactly where your site stands against these 50 criteria.