Learn WCAG 2.1: a plain-English primer

Written for website owners who just received an automated accessibility audit, or who want to understand what their team is being asked to fix.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is the international standard for making websites usable by people with disabilities. The standard is maintained by the World Wide Web Consortium (W3C), the same body that maintains HTML and CSS.

The version your audit tests against is WCAG 2.1, published in 2018. A newer version (WCAG 2.2) was published in 2023 and adds 9 new success criteria; it does not remove or contradict anything in 2.1. WCAG 2.1 is the version most legal frameworks (in the US, the European Union, Canada, Australia, and elsewhere) currently reference.

WCAG defines about 78 testable rules called success criteria. Your audit tests the 50 of them that are at Level A and Level AA, which together represent the standard most legal requirements expect.

Why accessibility matters

Roughly 1 in 5 adults lives with a disability that can affect how they use the web. That includes people with low vision, blindness, deafness, motor impairments, and cognitive differences. An accessible site means more of them can become customers, members, students, or readers without friction.

Beyond the human case, there is a legal case. Multiple jurisdictions explicitly reference WCAG as the conformance bar:

• United States: the Americans with Disabilities Act (ADA) Title III applies to commercial websites; courts and the Department of Justice routinely cite WCAG 2.1 Level AA as the operative standard.
• European Union: the European Accessibility Act, in force since June 2025, requires WCAG-aligned accessibility for digital products and services sold into the EU market.
• Canada: the Accessible Canada Act and provincial laws (such as the Accessibility for Ontarians with Disabilities Act) reference WCAG as well.

There is also a usability case that has nothing to do with disability: many WCAG techniques (semantic markup, keyboard support, sensible color contrast, alt text on images) make sites work better on mobile, on flaky connections, and for search engines.

The 4 WCAG principles

WCAG groups its success criteria under 4 high-level principles, often abbreviated POUR: Perceivable, Operable, Understandable, Robust. Every criterion lives under exactly one principle.

Level A, AA, and AAA

Each WCAG success criterion is assigned one of three conformance levels:

Your audit reports against Level A and Level AA combined. Level A failures are usually the most urgent because they block the most users.

How to read your audit

The audit report has two main views.

Issues by WCAG criterion

Use this view when you want to fix a class of problem everywhere it appears. For example, if your report shows criterion 1.1.1 Non-text Content with 40 affected elements across 5 pages, that means the same kind of issue (missing alt text on images) is showing up in many places, and you can probably fix it with one change to a template or component.

Issues by page

Use this view when you want to fix one page at a time, for example if you are about to launch a new product page and want to clean it up specifically.

What to fix first

A reasonable order of attack:

1. Critical impact + high element count first. These are usually missing form labels, missing button names, missing image alts, or low color contrast: simple to fix, high payoff.
2. Serious impact + appears on every page. Often a navigation, header, or footer issue. One fix to the layout template propagates everywhere.
3. Anything blocking checkout, sign-up, or other revenue-critical paths. Even a moderate-impact issue here is more urgent than a critical issue on a buried marketing page.

The LLM prompt feature

Each violation in the report includes a copy-paste prompt you can paste into Claude or ChatGPT. The prompt gives the model the violation, the offending HTML, and the WCAG criterion, then asks it to ask you which web framework you use before producing fix code. This means you do not need to manually translate generic accessibility advice into your stack; the model does it. The model will also explain the change and suggest how to verify it.

What axe-core catches and what it misses

Your audit uses an open-source rule engine called axe-core. axe-core is the industry standard for automated accessibility testing, and it is honest about its limits: it catches roughly 30 to 40 percent of WCAG issues automatically. The remaining 60 to 70 percent need a human.

Things axe catches well

• Missing alt attributes on images
• Insufficient color contrast (most cases)
• Form fields without labels
• Buttons and links without accessible names
• Invalid or misused ARIA attributes
• Missing language declarations
• Markup mistakes that break assistive technology, such as duplicate IDs or nested interactive controls

Things axe cannot catch

• Whether an alt attribute, even when present, actually describes the image meaningfully (alt="image" is technically present but useless)
• Whether link text like "click here" makes sense in context
• Whether form error messages are actually clear enough for a non-technical user
• Whether the heading hierarchy reflects the logical structure of the content
• Whether a custom widget actually works with a screen reader, not just whether it has the right ARIA attributes
• Whether the focus order matches the visual reading order in complex layouts

For these, you need the manual testing described in the next section.

Manual testing you should still do

After working through the violations in your audit, do at least these manual checks:

1. Tab through every page using only the keyboard. Confirm every interactive element is reachable, focus is always visible, and you can never get stuck on an element with no way out.
2. Listen to your site with a screen reader. On macOS or iOS, turn on VoiceOver (Command + F5 on Mac). On Windows, NVDA is free. On both platforms, listen to your home page top to bottom and confirm what is announced makes sense.
3. Zoom your text to 200 percent. Use your browser's zoom (Command-plus or Control-plus). Confirm no content is lost or hidden, and that nothing requires horizontal scrolling on a normal-width window.
4. Audit color combinations the scanner could not test. Use the WebAIM Contrast Checker on any color pair the scanner flagged as "incomplete" or that you used in custom graphics.
5. Check images that look meaningful. For each image with non-empty alt text, ask: does the alt text describe what the image actually shows in a way that makes sense in context, or is it a generic filler?
6. Check forms. Submit them with bad data on purpose and confirm the error messages tell the user what to do, not just what is wrong.

Glossary: all 50 WCAG 2.1 Level A and AA criteria

Every criterion your audit can flag is listed here, grouped by principle. Each links to the official W3C explanation. The plain-English description is what the criterion requires; for examples and edge cases, follow the W3C link.

1. Perceivable

1.1 Text Alternatives

• 1.1.1 Non-text Content Level A
  Provide a text alternative for every non-text element (images, audio, video, charts, icons) so assistive technology can announce it. Decorative images use empty alt.
  Who is affected: Blind and low-vision users who rely on a screen reader cannot tell what an image is showing if it has no text alternative. People on slow or unreliable connections also lose information when images fail to load.
  Read on W3C

1.2 Time-based Media

• 1.2.1 Audio-only and Video-only (Prerecorded) Level A
  For prerecorded audio-only content provide a transcript. For prerecorded video-only content provide either a transcript or an audio description.
  Who is affected: Deaf and hard-of-hearing users cannot perceive audio-only content without a transcript. Blind users cannot perceive video-only content, for example a silent product demo, without a description or transcript.
  Read on W3C
• 1.2.2 Captions (Prerecorded) Level A
  Provide synchronized captions for all prerecorded audio in video content.
  Who is affected: Deaf and hard-of-hearing users cannot follow video without captions. People watching in noisy environments and people learning the language of the video also rely on captions.
  Read on W3C
• 1.2.3 Audio Description or Media Alternative (Prerecorded) Level A
  For prerecorded video provide either an audio description of the visual content or a full media alternative covering both audio and visuals.
  Who is affected: Blind and low-vision users miss what is happening on screen during dialogue gaps in a video unless an audio description or full text alternative is provided.
  Read on W3C
• 1.2.4 Captions (Live) Level AA
  Provide synchronized captions for all live audio content in video.
  Who is affected: Deaf and hard-of-hearing users cannot follow live broadcasts such as webinars, town halls, or live announcements without captions delivered in real time.
  Read on W3C
• 1.2.5 Audio Description (Prerecorded) Level AA
  Provide audio description for all prerecorded video content.
  Who is affected: Blind and low-vision users miss visual context, including gestures, on-screen text, and scenery that carries meaning, without an audio description track.
  Read on W3C

1.3 Adaptable

• 1.3.1 Info and Relationships Level A
  Use semantic HTML (headings, lists, tables, form labels, landmarks) so structure and relationships in the visual layout are programmatically determinable.
  Who is affected: Screen reader users rely on real headings, lists, tables, form labels, and landmarks to navigate. Without those, the page sounds like a wall of unstructured text. Voice-control users also depend on programmatic structure to target elements.
  Read on W3C
• 1.3.2 Meaningful Sequence Level A
  When the order of content matters, the reading order in the source must match the visual order, so screen readers and keyboard users encounter content in the intended sequence.
  Who is affected: Screen reader users hear content in source order. If the source order does not match the visual reading order, the page becomes nonsensical when read aloud.
  Read on W3C
• 1.3.3 Sensory Characteristics Level A
  Do not rely on shape, color, size, location, or sound alone to convey information. Pair sensory cues with text or labels (for example, do not say 'click the round button on the right' alone).
  Who is affected: Blind and low-vision users cannot perceive instructions that depend on shape, color, size, or screen position alone, for example 'click the round green button on the right'.
  Read on W3C
• 1.3.4 Orientation Level AA
  Content does not lock to a single orientation, portrait or landscape, unless the orientation is essential to the function.
  Who is affected: Wheelchair users with mounted devices and people who hold a phone in a fixed orientation cannot rotate the device, so locking content to a single orientation blocks them.
  Read on W3C
• 1.3.5 Identify Input Purpose Level AA
  Form fields collecting common user information such as name, email, phone, address use autocomplete attributes so browsers and assistive tech can autofill correctly.
  Who is affected: People with cognitive disabilities, motor impairments, and attention disorders depend on browser autofill and password managers to complete forms with less effort. Missing autocomplete attributes turn a 30-second checkout into a 5-minute one.
  Read on W3C

1.4 Distinguishable

• 1.4.1 Use of Color Level A
  Color is not the only means of conveying information. If you flag required fields in red, also include text or an icon.
  Who is affected: About 8 percent of men and 0.5 percent of women have some form of color-blindness. If color is the only signal, for example red text alone marking required fields, they miss the information entirely.
  Read on W3C
• 1.4.2 Audio Control Level A
  If audio plays automatically for more than 3 seconds, provide a way to pause, stop, or control the volume independently of the system volume.
  Who is affected: Screen reader users cannot hear their reader over auto-playing audio. People with cognitive disabilities, anxiety, and people in shared or quiet environments are also affected.
  Read on W3C
• 1.4.3 Contrast (Minimum) Level AA
  Text has a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) only needs 3:1.
  Who is affected: Low-vision users (the largest disability category, including most adults over 60) and anyone using a phone outdoors in bright light cannot read low-contrast text. This is the single most common WCAG failure on the web.
  Read on W3C
• 1.4.4 Resize text Level AA
  Text can be resized up to 200 percent without loss of content or functionality. No horizontal scrolling, no text overlap.
  Who is affected: Low-vision users zoom their browser to 150, 200, or even 400 percent to read comfortably. If text breaks, overlaps, or scrolls horizontally at 200 percent, those users are blocked.
  Read on W3C
• 1.4.5 Images of Text Level AA
  Use real text instead of images of text, except for logos and decorative cases.
  Who is affected: Screen reader users cannot read text baked into an image. Low-vision users cannot apply their custom font size or color settings to text inside images. Translation tools cannot translate them.
  Read on W3C
• 1.4.10 Reflow Level AA
  Content reflows without horizontal scrolling at 320 CSS pixels wide, the mobile equivalent of 400 percent zoom on desktop.
  Who is affected: Mobile users on small phones, low-vision users zoomed to 400 percent, and people using screen magnifiers all need content that wraps without horizontal scrolling. Two-direction scrolling makes long-form content unusable.
  Read on W3C
• 1.4.11 Non-text Contrast Level AA
  User interface components (buttons, form borders, focus rings) and meaningful graphics have a contrast ratio of at least 3:1 against adjacent colors.
  Who is affected: Low-vision users cannot tell where a button ends and the page background begins if the button border has weak contrast against the page. They miss interactive controls entirely.
  Read on W3C
• 1.4.12 Text Spacing Level AA
  When users apply increased line-height, paragraph spacing, letter-spacing, or word-spacing within specified ranges, no content or functionality is lost.
  Who is affected: Users with dyslexia and certain visual processing differences increase line height and letter spacing through user stylesheets to make text readable. If your CSS forces the original spacing, those users can no longer override it.
  Read on W3C
• 1.4.13 Content on Hover or Focus Level AA
  Tooltips, popovers, and similar content triggered by hover or focus can be dismissed, hovered over without disappearing, and remain visible until the user moves away.
  Who is affected: Low-vision users using screen magnifiers need time to move the magnifier across a tooltip or popover before it disappears. People with motor tremors who slip off a hover target also depend on persistent hover content.
  Read on W3C

2. Operable

2.1 Keyboard Accessible

• 2.1.1 Keyboard Level A
  All functionality is operable with a keyboard alone, with no mouse required. Every interactive element is reachable and usable via Tab, Enter, Space, and arrow keys.
  Who is affected: Motor-impaired users who cannot operate a mouse, blind users who navigate by keyboard with their screen reader, and any user on a device where the mouse fails (a broken trackpad on a laptop, for example) all rely on full keyboard support.
  Read on W3C
• 2.1.2 No Keyboard Trap Level A
  Keyboard focus can move into and out of any component using only the keyboard. No element traps focus indefinitely.
  Who is affected: Any keyboard-only user (motor-impaired, blind, or just on a broken mouse) is stuck in place when focus enters a widget that does not let them tab back out.
  Read on W3C
• 2.1.4 Character Key Shortcuts Level A
  If a single-character keyboard shortcut exists, the user can turn it off, remap it, or restrict it to focused elements so accidental keystrokes do not trigger actions.
  Who is affected: Speech-input users who navigate the page by voice command can trigger single-character shortcuts accidentally just by speaking near the microphone. People with motor impairments who hit keys unintentionally have the same problem.
  Read on W3C

2.2 Enough Time

• 2.2.1 Timing Adjustable Level A
  For any time limit on user actions, allow the user to turn off, adjust, or extend the limit. Real-time exceptions like auctions are allowed.
  Who is affected: People with cognitive disabilities, older users, motor-impaired users, and people reading in a second language all need more than the default time to complete forms or read content. Hard time limits force them to fail.
  Read on W3C
• 2.2.2 Pause, Stop, Hide Level A
  For any moving, blinking, scrolling, or auto-updating content that lasts more than 5 seconds, provide a way to pause, stop, or hide it.
  Who is affected: People with attention disorders are pulled away by motion in their peripheral vision. People with vestibular disorders may feel dizzy or nauseated by auto-scrolling carousels and rolling banners.
  Read on W3C

2.3 Seizures and Physical Reactions

• 2.3.1 Three Flashes or Below Threshold Level A
  Content does not flash more than 3 times per second, to avoid triggering seizures.
  Who is affected: About 1 in 4000 people has photosensitive epilepsy. Flashing content in the wrong frequency range can trigger a seizure.
  Read on W3C

2.4 Navigable

• 2.4.1 Bypass Blocks Level A
  Provide a way to skip blocks of repeated content. A 'Skip to main content' link, ARIA landmarks, or proper heading structure all qualify.
  Who is affected: Screen reader users would otherwise listen to the same navigation menu, often 30 to 50 links, on every single page. Keyboard users would tab through it on every page. A skip link or a proper landmark structure cuts that out.
  Read on W3C
• 2.4.2 Page Titled Level A
  Every page has a descriptive title that identifies its topic or purpose.
  Who is affected: Screen reader users hear the page title announced first when the page loads, and rely on it to confirm where they are. People with cognitive disabilities and anyone with multiple tabs open also rely on titles to keep oriented.
  Read on W3C
• 2.4.3 Focus Order Level A
  When navigating with the keyboard, focus moves in an order that preserves meaning and matches the visual reading order.
  Who is affected: Keyboard users and screen reader users encounter elements in focus order. If focus jumps between distant parts of the page, the experience becomes incoherent.
  Read on W3C
• 2.4.4 Link Purpose (In Context) Level A
  The purpose of every link is clear from the link text alone or together with its surrounding context. Avoid generic 'click here' or 'read more'.
  Who is affected: Screen reader users frequently pull all links on a page into one flat list to scan. Out of that list, 'click here' and 'read more' tell them nothing about where each link goes.
  Read on W3C
• 2.4.5 Multiple Ways Level AA
  Users can find pages on the site by more than one means: search, sitemap, navigation menu, breadcrumbs, or similar.
  Who is affected: People with cognitive disabilities, people new to a site, and people who learn spatially rather than linearly all benefit from having more than one way to find a page, whether through search, a sitemap, navigation, or breadcrumbs.
  Read on W3C
• 2.4.6 Headings and Labels Level AA
  Headings and form labels describe the topic or purpose of their section or input clearly.
  Who is affected: Screen reader users navigate by jumping between headings to find the section they want. Vague headings such as 'More' or 'Information' offer no signal. Cognitive disability users also rely on clear labels.
  Read on W3C
• 2.4.7 Focus Visible Level AA
  When an element has keyboard focus, the focus indicator is visibly distinct. Default browser focus rings qualify; custom designs that hide the indicator fail.
  Who is affected: Keyboard users cannot tell where they are on the page if the focus indicator is suppressed or invisible. This is one of the highest-frustration accessibility failures because it affects every keyboard user, every action, on every page.
  Read on W3C

2.5 Input Modalities

• 2.5.1 Pointer Gestures Level A
  Any function that uses a multi-point or path-based gesture (pinch, swipe, drag) can also be operated with a single pointer such as a tap or click.
  Who is affected: People with motor tremors, hand pain, or limited dexterity often cannot perform a pinch, swipe, or drag. Single-pointer alternatives such as a tap, a click, or a button keep the function reachable.
  Read on W3C
• 2.5.2 Pointer Cancellation Level A
  Pressing down on a pointer does not by itself trigger an action. Users can move the pointer off the target before release to cancel.
  Who is affected: People with motor impairments who press the wrong button by mistake can move the pointer off the button before release to cancel the action. Triggering on press-down removes that safety net.
  Read on W3C
• 2.5.3 Label in Name Level A
  For interactive elements with visible text labels, the accessible name (what a screen reader announces) contains the visible text. Avoid a mismatch between aria-label and visible button text.
  Who is affected: Voice-input users speak the visible button text aloud, for example 'click Buy Now'. If the accessible name set in code does not contain the visible text, the voice command does not match and the action fails.
  Read on W3C
• 2.5.4 Motion Actuation Level A
  Any function triggered by device motion such as shake or tilt is also operable via standard UI controls, and motion-triggered actions can be disabled.
  Who is affected: People with motor impairments cannot reliably shake or tilt a device. Wheelchair-mounted devices cannot be moved at all. People whose phone has a broken accelerometer also lose the function.
  Read on W3C

3. Understandable

3.1 Readable

• 3.1.1 Language of Page Level A
  The default human language of the page is declared programmatically, for example with the html lang attribute, so screen readers use correct pronunciation.
  Who is affected: Screen readers use the page language to choose pronunciation rules; English vowels sound different than Spanish vowels. Without a declared language, the reader uses the user's default and mispronounces words. Translation tools also rely on the declared language.
  Read on W3C
• 3.1.2 Language of Parts Level AA
  Sections of a page in a different language from the page default declare their language programmatically, for example with a lang attribute on a span.
  Who is affected: Same problem as the page language but for sections of the page in a different language. A French quote in an otherwise English article needs its own language attribute or the screen reader pronounces it with English rules.
  Read on W3C

3.2 Predictable

• 3.2.1 On Focus Level A
  Receiving keyboard focus does not by itself cause a context change. No automatic page navigation, popup, or form submit fires on focus.
  Who is affected: Screen reader and keyboard users frequently move focus to read or operate an element. If focus alone causes a page navigation, popup, or form submit, they lose their place without warning.
  Read on W3C
• 3.2.2 On Input Level A
  Changing the value of a form field does not by itself cause a context change unless users are warned in advance.
  Who is affected: All users, especially screen reader and cognitive disability users, lose orientation when typing into a field unexpectedly navigates the page or submits the form.
  Read on W3C
• 3.2.3 Consistent Navigation Level AA
  Navigation menus and recurring components appear in the same relative order across pages.
  Who is affected: Cognitive disability users, older users, and screen reader users build a mental map of where the navigation lives on the page. Reordering it from page to page forces them to rebuild that map every time.
  Read on W3C
• 3.2.4 Consistent Identification Level AA
  Components with the same function are identified the same way across pages. A search icon is always labeled 'search', not sometimes 'find'.
  Who is affected: Cognitive disability users and screen reader users learn what an icon or label means by its appearance and accessible name. Identifying the same function differently on different pages forces them to relearn it.
  Read on W3C

3.3 Input Assistance

• 3.3.1 Error Identification Level A
  When the user makes an input error, the error is identified in text and the specific field with the error is described.
  Who is affected: Cognitive disability users, older users, screen reader users, and users typing in a second language all need explicit, in-text identification of which field has an error and what the error is. A red border alone tells them nothing.
  Read on W3C
• 3.3.2 Labels or Instructions Level A
  Form fields have visible labels or clear instructions describing the expected input.
  Who is affected: All users, but especially cognitive disability and screen reader users, need a visible label or clear instruction on each form field to know what to type. Placeholder-only forms fail this.
  Read on W3C
• 3.3.3 Error Suggestion Level AA
  When an input error is detected and a suggestion is known, the suggestion is provided to the user, unless doing so would compromise security.
  Who is affected: Cognitive disability users, users learning the language, and users with low literacy benefit from suggested corrections. Telling someone the answer is wrong without giving any hint about how to fix it leaves them stuck.
  Read on W3C
• 3.3.4 Error Prevention (Legal, Financial, Data) Level AA
  For pages that cause legal commitments, financial transactions, or data modification or deletion, the action is reversible, input is checked for errors, or the user confirms before submitting.
  Who is affected: All users, but especially cognitive disability and motor-impaired users, are at higher risk of submitting an incorrect form on legal, financial, or data-deletion pages. A confirmation step or reversal option prevents irreversible mistakes.
  Read on W3C

4. Robust

4.1 Compatible

• 4.1.1 Parsing Level A
  Markup is well-formed: no duplicate IDs, no unclosed tags, no invalid attributes. This criterion is obsolete in WCAG 2.2 because modern browsers handle malformed markup, but it remains in 2.1 AA scope.
  Who is affected: Older or non-mainstream assistive technology can fail to interpret malformed markup, leaving screen reader users unable to read the page. Modern browsers handle most parsing errors but assistive tech is more brittle.
  Read on W3C
• 4.1.2 Name, Role, Value Level A
  Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
  Who is affected: Screen reader users hear what an element is (button, checkbox, slider) and its current state (checked, expanded, disabled). Custom widgets that skip these annotations show up as 'group' or silence in the screen reader, blocking interaction. Voice-input users also depend on the role and name.
  Read on W3C
• 4.1.3 Status Messages Level AA
  Status messages such as success, error, or progress are announced by assistive tech without receiving focus, using ARIA live regions or appropriate roles.
  Who is affected: Screen reader users cannot see status messages such as 'added to cart', 'saved', or form-validation errors that appear visually without focus moving. Without an ARIA live region, those updates are silent to them.
  Read on W3C

More Learn articles

• The DOJ Title II web rule (April 2024) for SMBs: what it means and what to do. Covers who is covered, the 2026 and 2027 deadlines, the procurement-clause cascade, and what action SMBs should take.
• axe-core vs WAVE vs Lighthouse: which automated WCAG engine to trust. Side-by-side comparison of the three most-used automated accessibility engines, with guidance on which to pick for which job.
• WCAG 2.2 vs 2.1: when to upgrade and what's actually new. The 9 new success criteria, the one removed, and a practical SMB recommendation on whether to target 2.1 or 2.2 today.

Further reading and tools

Free official references

• WCAG 2.1 specification (W3C Recommendation): the canonical standard.
• Understanding WCAG 2.1 (W3C companion guide): plain-English explanations and examples for every criterion.
• WCAG 2.1 Quick Reference: filterable index of every criterion with technique links.
• ARIA Authoring Practices Guide: canonical patterns for accessible custom widgets (menus, tabs, modal dialogs, comboboxes).
• WebAIM: tutorials, the WebAIM Million annual benchmark report, and the contrast checker.

Free testing tools

• axe DevTools (Chrome and Firefox extension): same engine your audit uses, but runs in your browser interactively. Free tier covers the most common needs.
• WebAIM Contrast Checker: paste a foreground color and a background color, get the ratio.
• TPGi Color Contrast Analyser: desktop app, also free.
• Built-in screen readers: VoiceOver on macOS or iOS, Narrator on Windows, TalkBack on Android. NVDA is the free open-source option for Windows.