UX Encyclopedia

WCAG Essentials (2.2)

Primary source: W3C Web Content Accessibility Guidelines 2.2 (w3.org/TR/WCAG22) — the global standard, referenced directly or indirectly by law in most jurisdictions. Target AA conformance as the practical baseline.

Try it — lose your place. Click into the stage, then Tab through. With a visible indicator (WCAG 2.4.7) you always know where you are; with outline: none you are navigating blind. The readout below announces the focused control in both modes, so keyboard and screen-reader users are never actually stranded by this demo. If you must restyle focus, replace it — never remove it.
Focus indicator
Read the docs

Focus: nowhere yet — click the stage, then press Tab.

The four principles (POUR)

Perceivable · Operable · Understandable · Robust — every success criterion hangs off these.

The high-impact AA checklist (covers most real failures)

Perceivable

  • Text alternatives for images (1.1.1); decorative images marked so.
  • Captions for video (1.2.2); transcripts for audio.
  • Info/structure not conveyed by presentation alone; real headings, lists, and labels in markup (1.3.1); logical reading order (1.3.2).
  • Don't rely on color alone (1.4.1). Contrast: text 4.5:1, large text 3:1 (1.4.3); UI components & graphics 3:1 (1.4.11).
  • Text resizable to 200% (1.4.4); reflow at 320 px width without 2-D scrolling (1.4.10); survives user text-spacing overrides (1.4.12).

Operable

  • Everything works by keyboard (2.1.1), no traps (2.1.2); visible focus (2.4.7) that isn't obscured (2.4.11, new in 2.2).
  • Skip links / landmarks to bypass repeated blocks (2.4.1); page titles (2.4.2); focus order matches meaning (2.4.3); link text makes sense (2.4.4).
  • Timing adjustable (2.2.1); pause/stop moving content (2.2.2); no >3 flashes/sec (2.3.1).
  • Target size ≥24×24 CSS px (2.5.8, new in 2.2 — platform guidance of 44/48 exceeds this); gestures have single-pointer alternatives (2.5.1); dragging has non-drag alternative (2.5.7, new).

Understandable

  • Page language declared (3.1.1). Predictable: no context change on focus (3.2.1); consistent navigation & naming (3.2.3/3.2.4).
  • Errors identified in text (3.3.1); labels/instructions present (3.3.2); error suggestions (3.3.3); confirm/reverse for legal/financial (3.3.4); redundant entry avoided (3.3.7, new); accessible authentication — no cognitive test like transcription/puzzles as the only factor (3.3.8, new).

Robust

  • Valid, semantic markup; name/role/value exposed for custom widgets (4.1.2) — use native elements first; ARIA only per the WAI-ARIA Authoring Practices patterns ("no ARIA is better than bad ARIA" — W3C's own warning); status messages announced (4.1.3).
  • EU — European Accessibility Act (Directive 2019/882): applicable since June 28, 2025 to private-sector products and services sold in the EU — e-commerce, consumer banking, ebooks/e-readers, telecoms, transport ticketing, self-service terminals, and more. Transition rules: service contracts concluded before that date must comply by June 2027; pre-existing services have until June 28, 2030. Penalties and enforcement are per member state; enforcement activity began in 2025–26. Conformance is presumed via the harmonised standard EN 301 549.
  • EN 301 549 — in-force harmonised version is V3.2.1 (2021), which references WCAG 2.1 AA. A revision adopting WCAG 2.2 is in late-stage drafting at ETSI/CEN/CENELEC (expected to publish in 2026) but gains legal effect only once cited in the EU Official Journal. Build to 2.2 anyway — it's a superset.
  • US — ADA Title II: DOJ's April 2024 final rule requires WCAG 2.1 AA for state/local government web content and mobile apps. An April 2026 interim final rule extended compliance deadlines by one year: April 26, 2027 for entities serving ≥50,000 people; April 26, 2028 for smaller entities and special districts. Title III (private businesses) still has no web-specific regulation — courts apply the ADA case-by-case with WCAG as the de facto benchmark.
  • US — Section 508 (federal ICT): the 2017 refresh (in effect since Jan 2018) remains current and references WCAG 2.0 AA; no newer refresh has been finalized as of mid-2026. Agencies commonly test against newer WCAG versions in practice.
  • WCAG 3.0: still a W3C Working Draft (latest published March
    1. — outcome-based requirements and a graded scoring model (Bronze/Silver/Gold explored) instead of pass/fail; a final Recommendation is not expected before ~2028 and no law references it. Keep conforming to WCAG 2.x.

How to test (practical workflow)

  1. Automated pass — axe DevTools, Lighthouse, or WAVE on key templates. Fast, catches markup-level failures (contrast, missing alt, unlabeled fields), never sufficient alone (see coverage note below).
  2. Keyboard pass — Tab through every page: can you reach and operate everything? Is focus always visible and in a sensible order? No traps? Esc closes overlays? Skip link present? This one pass finds a large share of real-world blockers.
  3. Zoom & reflow — 200% text-only zoom (text must not clip); 400% page zoom or a 320 px viewport (content must reflow, no 2-D scrolling); apply text-spacing overrides (bookmarklets exist for 1.4.12).
  4. Contrast tooling — browser DevTools contrast inspector, TPGi's Colour Contrast Analyser (desktop, includes non-text UI), WebAIM's online contrast checker. Check states (hover, focus, disabled-ish).
  5. Screen reader smoke test — per platform: NVDA (free) + Chrome or Firefox on Windows, VoiceOver + Safari on macOS/iOS, TalkBack on Android; JAWS and NVDA trade the lead in WebAIM's user surveys, so Windows testing matters most. Smoke script: is the page title read? Navigate by headings and landmarks; operate every form control by its announced label; trigger dynamic changes and confirm they're announced.
  6. Human judgment items no tool can score: alt-text quality, sensible focus order, error-message usefulness, plain language.
  7. Include disabled users in usability testing — assistive-tech proficiency varies; only real users reveal real friction.

Coverage reality: automated tools detect only a subset of WCAG issues — commonly cited at ~30–40% of issue types; Deque's 2021 analysis of its own product data puts axe-detectable issues at ~57% by volume. Either way, manual testing is mandatory. The state of the web remains poor: WebAIM's 2026 "Million" audit found detectable WCAG 2 failures on 95.9% of the top million home pages (avg ~56 errors/page), led by low contrast, missing alt text, and missing form labels — the basics above.

Custom widgets (where most failures concentrate)

  • Use native HTML first (<button>, <select>, <dialog>, <details>). When you must build custom, follow the ARIA Authoring Practices Guide (APG) patterns (w3.org/WAI/ARIA/apg) — each has a tested keyboard map and required ARIA; don't invent your own behavior.
  • Modals/dialogs: focus moves into the dialog on open, stays trapped while open, returns to the trigger on close; Esc dismisses; background is inert. Native <dialog> with showModal() handles most of this.
  • Comboboxes/autocompletes: the hardest common widget — use the APG combobox pattern (arrow-key navigation, aria-expanded, aria-activedescendant, results count announced). Prefer a plain <select> or <datalist> when requirements allow.
  • Also covered by APG: tabs, accordions/disclosures, menus (navigation links are not role="menu"), tooltips, sliders, grids.

Documents & PDFs

  • WCAG applies to documents delivered on the web, not just pages. Prefer HTML. If PDF is unavoidable, it must be tagged (untagged PDFs are effectively unreadable by screen readers); the standard is PDF/UA (ISO 14289); check with the free PAC checker or Acrobat's tools. The EAA explicitly covers ebooks.

Accessibility statements & VPATs

  • EU: the Web Accessibility Directive and EAA require a published accessibility statement — conformance status, known limitations, and a feedback channel. W3C offers a statement generator (w3.org/WAI/planning/statements).
  • US/procurement: buyers request a VPAT (Voluntary Product Accessibility Template, from ITI) completed as an Accessibility Conformance Report (ACR); editions map to WCAG, Section 508, and EN 301
    1. An honest "Partially Supports" with remarks is worth more — and is legally safer — than inflated claims.

Sources

  • W3C — WCAG 2.2 (w3.org/TR/WCAG22); How to Meet WCAG (Quick Reference); WAI-ARIA Authoring Practices Guide (w3.org/WAI/ARIA/apg); WCAG 3.0 Working Draft & status (w3.org/WAI/standards-guidelines/wcag/wcag3-intro); Planning: accessibility statements.
  • EU — Directive 2019/882 (European Accessibility Act, EUR-Lex); European Commission digital-strategy pages on EN 301 549 harmonisation; ETSI EN 301 549 V3.2.1.
  • US — DOJ ADA Title II web rule (Federal Register, Apr 2024) and the Apr 2026 interim final rule extending compliance dates; ADA.gov; US Access Board — Revised 508 Standards (access-board.gov/ict).
  • Deque Systems — Automated Accessibility Coverage Report (~57% by issue volume, deque.com); WebAIM — "The WebAIM Million" 2026 audit and screen reader user surveys (webaim.org).
  • ITI — VPAT/ACR (itic.org); PDF/UA — ISO 14289.
↑↓ to navigate · Enter to open · Esc to close