Frontend / Accessibility / 01_wcag_and_pour.md

WCAG and the POUR Principles

Updated 4 interview angles 5 min read source
On this page10
  1. What does POUR stand for?
  2. What are the conformance levels and which do you target?
  3. Name a few high-impact AA criteria you actively check.
  4. What’s new in WCAG 2.2 vs 2.1?
  5. Why is accessibility a legal and business concern, not just “nice to have”?
  6. What can automated tools verify, and what can’t they?
  7. Gotchas
  8. Related
  9. Further reading
  10. Interview angle

WCAG and the POUR Principles

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.

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 one-line fixes

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

  • 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.

Further reading

Interview angle 4

  • “What standard do you target, and why that one?” - WCAG 2.2 level AA, organised under POUR: perceivable, operable, understandable, robust. AA is the level regulation effectively requires - the ADA in the US and the European Accessibility Act both land there - so it is a compliance floor as well as a quality one.
  • “How much of AA is actually about ARIA?” - very little. Most of it falls out of semantic HTML, sufficient colour contrast, everything reachable by keyboard, labelled form controls and a visible focus indicator. Teams that reach for ARIA first usually have not done those.
  • “How much can you automate?” - roughly a third of the issues. Automated tools catch contrast, missing labels, invalid ARIA and structural problems; they cannot tell you whether the focus order makes sense, whether an announcement is meaningful, or whether the flow is usable by keyboard.
  • “How do you keep it from regressing?” - gate it in CI and in review, the same as any other quality attribute. A one-off audit produces a report and a codebase that drifts back within two quarters, because nothing stops the next <div onClick> from landing.