WCAG Guidelines — The Essentials for Testers

WCAG — the Web Content Accessibility Guidelines — is the international standard for digital accessibility. It is a long, technical document, and every word is voted on by hundreds of contributors. Most testers will never read it cover to cover. You do not need to. What you need is a working mental model of its structure, the conformance level your team should aim for, and the small set of criteria that account for the bulk of real bugs. This lesson gives you exactly that.

The four POUR principles

WCAG is organised around four principles, summarised by the acronym POUR:

• Perceivable. Users must be able to sense the content. If it is purely visual, it must have a text alternative for users who cannot see. If it is audio, captions for users who cannot hear.
• Operable. Users must be able to interact with the content. Every action available to a mouse user must also work via keyboard, voice, or assistive device.
• Understandable. Users must be able to comprehend the content and the interface. Predictable navigation, clear labels, sensible language.
• Robust. The content must work across browsers, screen readers, and assistive technologies, now and as those tools evolve.

These four words frame every accessibility check you will ever run. If you can articulate which of the four a problem violates, you have already done most of the work of triaging it.

Conformance levels: A, AA, AAA

WCAG ranks each criterion at one of three conformance levels:

• Level A — the absolute minimum. Failing Level A makes content essentially unusable for some group of users. Examples: every image must have a text alternative; pages must work without a mouse.
• Level AA — the standard target for most public-facing organisations and the level most accessibility laws (including the EAA and ADA case law) reference. Adds requirements like a 4.5:1 contrast ratio and resize-to-200%-without-loss-of-content.
• Level AAA — the highest tier. Includes stringent rules like 7:1 contrast, sign-language interpretation for video, and reading-level limits. AAA across an entire site is rarely practical; specific high-stakes flows (government services, health portals) sometimes target it for individual screens.

For 95% of teams the right answer is "WCAG 2.1 (or 2.2) Level AA." That is the level your manual testing should benchmark against unless you have a specific reason to aim higher or lower.

The criteria you actually need to know

WCAG 2.1 Level AA contains 50 specific success criteria. You do not memorise all of them. You learn the ones that catch most real bugs and you let tools handle the rest.

A short tour of the highest-impact criteria — the ones that account for most accessibility bugs caught in production:

• Text alternatives for images. Every informative image needs alt; decorative images need alt="" so screen readers skip them. The single most violated WCAG criterion in the wild.
• Colour contrast ratio. Body text needs 4.5:1; large text (18pt+, or 14pt bold+) needs 3:1. Light grey on white is the most common failure.
• Keyboard accessibility. Every interactive element must be reachable and operable from the keyboard. Test it by unplugging the mouse.
• Visible focus indicator. When you tab to an element, it must be visually obvious which element has focus. Hidden default focus ring without a replacement is the usual failure.
• Form labels. Every input needs a programmatically-associated <label>. Placeholders are not labels — screen readers may skip them entirely.
• Heading hierarchy. Exactly one <h1>; no skipped levels (<h1> directly to <h3> breaks screen-reader navigation patterns that rely on level order).
• Name, role, value. Every custom widget (a div "button," a custom dropdown, a tab strip) must expose its name, role, and current value to assistive tech. This is what ARIA attributes exist for.

Memorise these seven. They cover most WCAG bugs you will actually encounter.

When to use tools — and when not to

Automated accessibility checkers like axe DevTools, Lighthouse, and WAVE can scan a page in seconds and flag a respectable share of issues — typically 30–40% of all WCAG failures. They are excellent for the criteria they cover well: contrast, missing alt text, missing labels, invalid markup. The rest — keyboard traps, ambiguous link text, focus order problems, dynamic-content announcement issues — require human testing with real keyboards and real screen readers.

The right workflow is to run an automated scanner first to clear the easy 30–40%, then perform the manual checks in the next lesson on what is left. The two methods complement each other; neither alone is sufficient.

The accessibility testing cheat sheet on qa.codes is a good companion reference once you start testing in earnest.

⚠️ Common mistakes

• Treating WCAG as a checklist of 50 things to memorise. Memorise the seven high-impact criteria; let tools handle the rest. Mastery of seven beats vague awareness of fifty.
• Aiming for AAA across the whole product. AAA is appropriate for specific high-stakes flows, not as a blanket target. Aim AA across the product and AAA where the stakes (e.g., a health-record viewer) genuinely warrant it.
• Trusting automated scanners alone. A green Lighthouse score does not mean accessible. The criteria automated tools cannot test reliably (keyboard traps, ambiguous labels, focus order) are exactly the ones that block real users from completing real tasks.

🎯 Practice task

Spend 25 minutes anchoring WCAG to a real product.

1. Pick a public website with a clear primary action — a sign-up flow, a checkout, a content-discovery page.
2. Run axe DevTools or Lighthouse against it. Note how many issues are flagged and which WCAG criteria they map to.
3. For each of the seven high-impact criteria above, manually inspect the page (no tool) and decide whether it passes, fails, or is partial. Write a one-line justification for each.
4. Compare your manual list to the automated output. Which issues did the tool catch? Which did you catch that the tool missed? The gaps you find will line up with the manual checks covered in the next lesson.