Frontend / Accessibility / 01_wcag_and_pour.md

WCAG and the POUR Principles

Updated 4 min read source
On this page6
  1. TL;DR
  2. In depth
  3. Gotchas / edge cases
  4. What a senior is expected to say
  5. Cross-references
  6. Further reading

WCAG and the POUR Principles

TL;DR

WCAG (Web Content Accessibility Guidelines) is the standard. It’s organized under four principles — POUR: Perceivable, Operable, Understandable, Robust — with testable success criteria at three conformance levels: A (minimum), AA (the legal/industry target), AAA (enhanced, rarely required wholesale). Aim for WCAG 2.1/2.2 AA. Most of AA is achieved by semantic HTML, sufficient contrast, keyboard operability, labels, and focus management — not by sprinkling ARIA.

In depth

What does POUR stand for?

Principle Means Examples of criteria
Perceivable users can perceive the content text alternatives for images, captions, color contrast, content not conveyed by color alone
Operable users can operate the UI full keyboard access, no keyboard traps, enough time, no seizure-inducing flashing, skip links
Understandable content and operation are clear readable text, predictable behavior, input labels and error help
Robust works with current and future assistive tech valid markup, correct name/role/value for custom widgets

What are the conformance levels and which do you target?

A (essential), AA (addresses major barriers — the standard target), AAA (highest, often impractical for an entire site). Target AA. Laws and policies almost universally reference WCAG 2.x AA: the US ADA (and Section 508), the EU’s EN 301 549 / European Accessibility Act, the UK Equality Act. “We meet WCAG 2.2 AA” is the answer interviewers want, not “AAA everywhere.”

Name a few high-impact AA criteria you actively check.

  • 1.4.3 Contrast (Minimum) — 4.5:1 for normal text, 3:1 for large text and UI components/graphics.
  • 1.1.1 Non-text Content — meaningful images have alt text; decorative images have empty alt="".
  • 2.1.1 Keyboard — everything operable by keyboard; 2.1.2 no keyboard trap.
  • 2.4.7 Focus Visible — a visible focus indicator (don’t outline: none without a replacement).
  • 2.4.3 Focus Order — focus order is logical and matches reading order.
  • 1.3.1 Info and Relationships — structure (headings, labels, lists) is in the markup, not just visual.
  • 4.1.2 Name, Role, Value — custom controls expose correct accessible name/role/state.
  • 2.5.5 / 2.5.8 Target Size — interactive targets large enough (24×24 CSS px min in 2.2).

Two of those have a one-line fix that is routinely got wrong:

css 
/* 2.4.7 — never remove the indicator without replacing it. */
:focus-visible {
  outline: 3px solid var(--focus);
  outline-offset: 2px;
}

/* 2.5.8 — hit area without changing the visual size. */
.icon-button { position: relative; }
.icon-button::after {
  content: ""; position: absolute; inset: -8px;   /* 24x24 min */
}

:focus-visible rather than :focus is the detail: it shows the ring for keyboard users and not on mouse click, which is what makes designers accept it instead of asking for outline: none.

html 
<!-- 1.1.1 — the alt depends on the job the image does. -->
<!-- meaningful -->
<img src="chart.png" alt="Revenue rose 40% in Q3">

<!-- decorative: skip me -->
<img src="swirl.svg" alt="">

<!-- it is a link, so name the destination -->
<img src="logo.svg" alt="Acme">

alt="" is not the same as omitting alt — the empty attribute tells a screen reader to skip the image, while a missing one makes it read the filename.

What’s new in WCAG 2.2 vs 2.1?

2.2 (2023) added criteria like Focus Not Obscured, Target Size (Minimum) 24×24px, Dragging Movements (provide a non-drag alternative), Consistent Help, and Accessible Authentication (don’t force a cognitive test like solving puzzles or retyping passwords). One 2.1 criterion (4.1.1 Parsing) was removed as obsolete. 2.1 itself added mobile/touch, low-vision, and cognitive criteria over 2.0.

Legally it’s frequently required (ADA litigation in the US, EAA from 2025 in the EU). Practically: ~15–20% of people have a disability; accessible sites also help temporary impairments (broken arm, bright sunlight), aging users, and SEO (semantic structure). It overlaps with general quality — keyboard support and clear labels help everyone.

What can automated tools verify, and what can’t they?

Automated checkers (axe, Lighthouse) reliably catch roughly 30–40% of WCAG issues — missing alt, low contrast, missing labels, invalid ARIA. They cannot judge whether alt text is meaningful, whether focus order makes sense, whether a custom widget is usable by keyboard, or whether content is understandable. Those need manual keyboard + screen-reader testing. See Testing Accessibility.

Gotchas / edge cases

  • AAA is per-criterion, not a realistic site-wide goal — e.g., AAA contrast is 7:1, AAA requires sign-language for video. Claim AA; meet specific AAA criteria where feasible.
  • “Accessible” isn’t a one-time audit — it regresses with every feature; bake checks into CI and code review.
  • Contrast applies to UI components too (2.1+), not just text — icon buttons and input borders need 3:1.
  • Overlay widgets (“accessibility plugins”) that claim instant compliance are widely criticized and don’t substitute for real fixes; some have been the subject of lawsuits.
  • Color alone can’t convey meaning (error = red only fails) — pair with text/icon.

What a senior is expected to say 4

  • “WCAG under POUR — Perceivable, Operable, Understandable, Robust — and I target 2.2 AA, which is what the ADA/EAA effectively require.”
  • “Most of AA comes free from semantic HTML, contrast, keyboard support, labels, and visible focus — not from ARIA.”
  • “Automated tools catch ~a third of issues; the rest needs manual keyboard and screen-reader testing.”
  • “It’s continuous — I gate it in CI and review, not as a one-off audit.”

Cross-references

Further reading