WCAG 2.2 Explained in Plain English: What Each Rule Actually Means

You keep seeing the acronym “WCAG” in emails from your legal team, in vendor contracts, or in that audit report you’ve been avoiding. You nod along in meetings, but privately you have no idea what any of it actually means. This is the article I wish someone had handed me the first time I heard the word “WCAG” — no jargon, no spec-speak, just plain English.

What Is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is a set of rules that describe how to make websites usable by people with disabilities — including people who are blind, deaf, have limited mobility, or have cognitive differences. Think of it as a building code, but for websites instead of buildings.

The 4 Principles: POUR

Every WCAG rule falls under one of four big ideas. The acronym is POUR.

Perceivable — People must be able to sense your content. If someone cannot see, they need another way to get the same information (like hearing it read aloud). If someone cannot hear, they need captions or a transcript.

Operable — People must be able to use your website. Not everyone uses a mouse. Some people navigate entirely with a keyboard, a switch device, or voice commands. Every button, link, and menu must work without a mouse.

Understandable — People must be able to comprehend your content and your interface. Labels should be clear, error messages should be helpful, and the site should behave predictably. No surprise pop-ups, no mystery icons.

Robust — Your website must work with the tools people rely on, including screen readers, magnifiers, and alternative browsers. This mostly means using proper HTML so those tools can interpret your pages correctly.

Levels A, AA, AAA — Which One You Actually Need

WCAG organizes its rules into three levels of strictness:

  • Level A is the bare minimum. Failing these means parts of your site are completely unusable for some people.
  • Level AA is the standard almost everyone aims for. It is what most laws reference, what most contracts require, and what courts expect. If someone says “WCAG compliant” without specifying a level, they almost certainly mean AA.
  • Level AAA is the gold standard. It is extremely thorough but also extremely difficult to achieve across an entire site. Almost no one requires it, and WCAG itself says it is not a realistic target for whole websites.

Bottom line: You need Level AA. That is your target. Everything below focuses on AA and A requirements.

The Reality: Almost Everyone Is Failing

Before we get to individual rules, here is some context. According to the WebAIM Million study, which tests the home pages of the top one million websites every year, 96.8% of home pages have detectable WCAG failures. The average page has 56.8 errors. These are not obscure sites — they are the most popular sites on the internet. Accessibility failures are the norm, not the exception, which means fixing even a few issues puts you ahead of nearly every competitor.

The 10 Most Common Issues — In Plain English

These are the problems that appear on the vast majority of failing websites. For each one, I will explain the rule, why it matters, how to spot the problem, and how to fix it — all without touching code.

1. Every Image Needs a Description

The rule: If an image conveys information, it needs a text alternative (often called “alt text”) that describes what the image shows.

Why it matters: A blind person visiting your online store hears their screen reader say “image” with no further detail. They have no idea if they are looking at a product photo, a sale banner, or a decorative squiggle. They cannot make a purchase decision without knowing what the image shows.

How to check it: Right-click any image on your site, select “Inspect” (or ask your web team to run a scan). If you see alt="" or no alt attribute at all on an image that communicates something, that is a failure.

How to fix it: Write a short, specific description for every meaningful image. “Red running shoe, side view, Nike Air Max” is great. “Image” or “photo” is useless. If the image is purely decorative (like a background pattern), it is fine to leave the description empty — but that decision should be intentional.

2. Text Must Have Enough Contrast Against Its Background

The rule: Regular text needs a contrast ratio of at least 4.5:1 against its background. Large text (roughly 18pt or bigger) needs at least 3:1.

Why it matters: Light grey text on a white background is hard to read for anyone, but for someone with low vision or color blindness, it can be completely invisible. Imagine a customer literally cannot read your prices or your “Add to Cart” button.

How to check it: Use a free tool like the WebAIM Contrast Checker (webaim.org/resources/contrastchecker). Enter your text color and background color. It will tell you instantly whether you pass or fail.

How to fix it: Darken your text or lighten your background until you hit the 4.5:1 ratio. Your designer may resist, but there are beautiful, modern designs that meet contrast requirements. Low contrast is a style choice, not a design necessity.

3. Every Form Field Needs a Visible Label

The rule: Input fields (name, email, password, search, etc.) must have a clear text label that is permanently visible and programmatically associated with the field.

Why it matters: Placeholder text (the grey text inside a field that disappears when you start typing) is not a label. Once a user starts typing, they may forget what the field was for. For screen reader users, an unlabeled field is a complete guessing game — they literally hear “edit text, blank” and have no idea what to type.

How to check it: Look at every form on your site. If the only indication of what a field is for is placeholder text inside the field, that is a failure. Every field should have a label above or beside it that stays visible at all times.

How to fix it: Add a visible text label next to each form field. “Email address,” “Your name,” “Search products.” Keep it simple and descriptive.

The rule: The text of a link should make sense on its own. A user should be able to understand where a link leads without reading the surrounding paragraph.

Why it matters: Screen reader users often pull up a list of all links on a page to navigate quickly. If every link says “click here” or “read more,” that list is useless — it is just “click here, click here, click here, click here” with no way to tell them apart.

How to check it: Read through your pages and look for links that say “click here,” “learn more,” “read more,” or “this.” If removing the surrounding sentence makes the link meaningless, it needs better text.

How to fix it: Replace vague link text with descriptive text. Instead of “To see our return policy, click here,” write “Read our return policy.” The link text itself should tell people what they will find.

5. The Site Must Be Fully Usable With a Keyboard Alone

The rule: Every interactive element — links, buttons, menus, forms, sliders, modals — must be reachable and operable using only the Tab, Enter, Escape, and arrow keys.

Why it matters: People with motor disabilities, tremors, or paralysis may not be able to use a mouse. They rely entirely on keyboard navigation. If your dropdown menu only opens on mouse hover, or your modal has no way to close it with a keyboard, those users are locked out.

How to check it: Put your mouse in a drawer. Open your website and try to do everything — navigate, fill out forms, open menus, complete a purchase — using only your keyboard. Tab moves you forward, Shift+Tab moves you back, Enter activates things. If you get stuck anywhere, that is a failure.

How to fix it: Ask your web team to ensure all interactive elements are focusable and operable via keyboard. Avoid custom-built menus and widgets that bypass standard keyboard behavior. If you must use them, they need explicit keyboard support.

6. You Must Be Able to See Where the Keyboard Focus Is

The rule: When navigating with a keyboard, there must be a visible indicator showing which element is currently focused.

Why it matters: Imagine using your keyboard to tab through a page, but there is no highlight or outline showing where you are. You are pressing Tab into the void, hoping the next Enter press activates the right button. This is disorienting for sighted keyboard users and makes the site effectively unusable.

How to check it: Tab through your site. If you cannot clearly see which element is selected at all times — a visible outline, underline, or highlight — that is a failure.

How to fix it: Do not remove the browser’s default focus outline. Many designers remove it because they think the blue ring looks ugly. If a custom style replaces it, make sure the replacement is clearly visible. A 2px solid outline in a contrasting color works well.

7. Videos Need Captions

The rule: Pre-recorded video with audio must have synchronized captions. Live video should have captions too, where feasible.

Why it matters: A deaf customer is watching your product demo video. Without captions, they get visuals but miss all the spoken explanation — pricing, features, instructions, calls to action. Auto-generated captions from YouTube are a start, but they are often inaccurate, especially with names, technical terms, or accented speech.

How to check it: Play every video on your site. Turn the sound off. Turn on captions. Are captions available? Are they accurate? Do they include speaker identification when multiple people talk?

How to fix it: Add human-reviewed captions to all videos. Services like Rev or Otter provide affordable captioning. If you use auto-captions, at minimum review and correct them manually.

8. The Page Must Have a Logical Heading Structure

The rule: Pages must use headings (H1, H2, H3, etc.) in a logical, hierarchical order. There should be one H1 per page, sections under it use H2, sub-sections use H3, and so on.

Why it matters: Screen reader users navigate pages by jumping between headings, the same way sighted users scan a page by looking at bold section titles. If headings are skipped, used out of order, or missing entirely, the page structure is invisible to those users. It is like a book with no table of contents and no chapter titles.

How to check it: Install the free HeadingsMap browser extension. It will show you the heading structure of any page. If headings jump from H1 to H4, or if there is no H1, or if body text is styled to look like a heading but is not actually marked as one, those are failures.

How to fix it: Work with your content or web team to ensure headings follow a logical order. Heading level should reflect document structure, not font size preference. If you want big bold text that is not a section heading, use bold styling rather than a heading tag.

9. The Page Language Must Be Declared

The rule: Every page must specify what language it is written in (English, Spanish, Japanese, etc.) in the HTML.

Why it matters: Screen readers use the language declaration to choose the correct pronunciation engine. If your English page has no language set, a screen reader might default to whatever language the user’s device is set to, producing garbled or unintelligible speech. Imagine hearing your English content read with Japanese pronunciation rules.

How to check it: Ask your web team if the HTML tag includes a lang attribute. Or right-click, view page source, and check the very first <html tag. It should include something like lang="en" for English.

How to fix it: This is typically a one-line fix in your site’s template. Ask your web team to add the correct language code. It takes less than a minute.

10. Interactive Elements Must Have Accessible Names

The rule: Every button, link, and form control must have a name that assistive technology can read aloud. This is especially important for icon-only buttons (like a magnifying glass for search or a hamburger menu icon).

Why it matters: A screen reader user encounters a button. The button has no text, just an icon. The screen reader says “button” — nothing else. The user has no idea what the button does. Is it search? Is it delete? Is it submit? They might avoid pressing it entirely, or press it and trigger something unexpected.

How to check it: Look at every button on your site that uses an icon instead of text. If there is no visible text label next to the icon, check with your web team whether it has an accessible name behind the scenes.

How to fix it: Either add visible text next to the icon (best option) or ensure your web team adds an invisible text label that screen readers can announce. “Search,” “Open menu,” “Close dialog” — be specific.

A Quick Note on Checking Tools

You do not need to be a developer to run a basic accessibility check. These tools are free and work in your browser:

  • WAVE (wave.webaim.org) — Paste any URL and get a visual report of accessibility errors on that page. It highlights problems directly on the page so you can see exactly where they are.
  • axe DevTools — A browser extension that scans pages and explains each issue in plain language.
  • HeadingsMap — Shows you the heading structure of any page instantly.
  • WebAIM Contrast Checker — Tests whether your text and background colors meet contrast requirements.

None of these tools require you to write or understand code. They point to problems and explain them in terms anyone can follow.

What to Do Next

You do not have to fix everything at once. Start with the ten issues above — they account for the overwhelming majority of accessibility failures found in the wild. Run WAVE on your home page, your most-visited pages, and your checkout flow. Prioritize anything that blocks people from completing a task (buying, signing up, contacting you).

WCAG can feel like an overwhelming wall of rules, but at its core, it is asking one question: can everyone use your website? If you keep that question in mind and work through the issues above, you will be ahead of 96% of the internet. That is not an exaggeration — that is the data.

Accessibility is not a destination. It is something you maintain, like keeping your store’s entrance clear of obstacles. The good news is that the biggest improvements come from the simplest fixes, and you now know exactly what those fixes are.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.