WCAG, demystified
The web's accessibility rulebook, in plain English.
Every craft has its rulebook. Cooking has food-safety codes. Plumbing has building regs. The web has WCAG — the Web Content Accessibility Guidelines. Most accessibility laws around the world (the EU's EAA, the US ADA in practice, Canada's ACA, the UK Equality Act) point at WCAG and say: "do this."
Don't be scared by the spec PDF. The shape is small once you see it.
What WCAG is
WCAG is published by the W3C (the same standards body behind HTML and CSS). It's a list of testable success criteria — concrete things you can check and either pass or fail. The latest stable version most teams target is WCAG 2.2, released in 2023. WCAG 3 is in draft and will eventually replace it, but it's years away from being legally referenced.
The full spec organizes everything two ways: by principle (POUR) and by level (A / AA / AAA). Think of the principles as buckets and the levels as priorities. Every success criterion lives in one bucket and at one level.
POUR — the four principles
The whole spec rests on four principles, abbreviated POUR:
- Perceivable — users must be able to sense the content. Images need text alternatives. Videos need captions. Color isn't the only signal. Anything you can see, a screen reader can hear.
- Operable — users must be able to use the interface. Everything works on a keyboard. Targets are big enough. Nothing flashes fast enough to trigger seizures. Time limits don't trap people.
- Understandable — the content and behavior must make sense. Text is clear. Forms label their fields. Error messages explain what went wrong. The interface doesn't change unpredictably.
- Robust — the code must be solid enough that today's tools and tomorrow's tools can both parse it. Valid HTML. Correct roles, names, and states. Nothing held together with hopes and div soup.
If you ever can't remember a specific WCAG number, you can almost always argue your case from POUR. "This image has no alt text, so it's not perceivable" is a perfectly valid framing.
Levels A, AA, AAA
Each rule lives at one of three conformance levels:
- A — the bare minimum. If you fail level A, your site has serious accessibility blockers — like videos without captions or pages that aren't keyboard-reachable.
- AA — the practical industry standard. Most laws and contracts require AA. This is the level you should aim for.
- AAA — the highest level. Some criteria here are very strict (sign-language interpretation, 7:1 contrast). You don't have to hit AAA across a whole site; it's often impossible. Cherry-pick what fits.
A useful analogy: think of A as "does the building have a door," AA as "does the building meet code," and AAA as "the building wins design awards." Aim for code.
When a contract or RFP says "WCAG-compliant," they almost certainly mean WCAG 2.1 or 2.2 at level AA. If it just says "compliant," ask which version and which level.
What AA actually requires
The whole AA list is around fifty success criteria. You don't need to memorize them — but here's what they boil down to in real terms:
- Text alternatives: every meaningful image, icon, and chart has a textual equivalent (
alt,aria-label, captions). - Captions and transcripts: prerecorded video has captions; audio-only content has a transcript.
- Color contrast: at least 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold), 3:1 for UI components and graphics.
- Don't rely on color alone: red asterisks aren't enough; pair color with text or shape.
- Keyboard access: every interactive thing is reachable and usable with the keyboard — no traps, no mouse-only interactions.
- Visible focus: when something has keyboard focus, you can clearly see where you are.
- Skip to main content: a way to bypass repeated navigation.
- Headings, labels, landmarks: pages have proper heading order, form fields have visible labels, regions are marked up (
<main>,<nav>,<aside>). - Resize and reflow: text can be enlarged to 200% without loss; content reflows at 320 CSS pixels wide without horizontal scroll.
- Errors are clear: form errors explain what's wrong and how to fix it.
- Language is set:
<html lang="en">(or whatever) so screen readers use the right pronunciation. - No keyboard traps: focus can always move out of any component.
- Time limits are flexible: warn users, let them extend.
If you do those things, you're in AA territory for the vast majority of pages.
Using WCAG day to day
You don't open the WCAG spec like a novel. In practice teams use it like a checklist or a referee:
- During design, run a quick contrast check (tools like the WebAIM contrast checker live in browsers and Figma).
- During build, lean on semantic HTML first (lesson 4). It buys you most of AA before you write any ARIA.
- During review, run an automated tool like axe DevTools or Lighthouse. They catch maybe 30–40% of issues — useful, never sufficient.
- During QA, do a manual keyboard pass (lesson 6) and a screen-reader spot check.
When you find something tricky, search "WCAG 2.2 [topic]" — the W3C Understanding documents are the real teacher. They explain why each criterion exists, often with examples.
You've got the rulebook. Next we'll see why the first line of defense against most WCAG failures is also the easiest one — semantic HTML.