WCAG and POUR

Perceivable · Operable · Understandable · Robust

Accessibility rests on four principles — Perceivable, Operable, Understandable, Robust. Here’s what each means and the success criteria every team should know.

Origin

The Web Content Accessibility Guidelines are produced by the World Wide Web Consortium’s Web Accessibility Initiative, launched in 1997 with Tim Berners-Lee’s declaration that the power of the web is in its universality.

WCAG 1.0 arrived in 1999; 2.0 (2008) reorganized everything under the four POUR principles and became an ISO standard and the legal benchmark in much of the world. Successive versions — 2.1, 2.2 — extended coverage to mobile, low vision, and cognitive needs.

The Guidelines

Content must be Perceivable, Operable, Understandable, and Robust. POUR is the durable core: every specific success criterion is one of these four promises made concrete.

Coined by
W3C Web Accessibility Initiative
Source
WCAG 2.x specifications
In practice
Test against POUR, not just checkboxes

The Four Principles

Principle 1 01 / 10

Perceivable

Information and UI components must be presented in ways users can perceive — through sight, sound, or touch. If users can’t sense it, they can’t use it.

Guidelines
1.1 – 1.4
Sense covered
Sight · Hearing · Touch
Failure mode
User can’t detect content
Principle 2 02 / 10

Operable

UI components and navigation must be operable. If something requires a mouse with pixel-perfect aim or a steady hand, large portions of users are locked out.

Guidelines
2.1 – 2.5
Input methods
Keyboard · Touch · Switch
Failure mode
User can’t interact
Principle 3 03 / 10

Understandable

Information and the operation of the UI must be understandable. Predictable behavior and plain language matter as much as visual design.

Guidelines
3.1 – 3.3
Reading level
Lower-secondary recommended
Failure mode
User confused or misled
Principle 4 04 / 10

Robust

Content must be robust enough to be reliably interpreted by user agents — including assistive technologies. Today’s accessible page must still be accessible to tomorrow’s screen readers and devices.

Guideline
4.1
Targets
Screen readers · Voice · Future
Failure mode
AT can’t parse markup

Key Success Criteria

SC 1.4.3 05 / 10

Color Contrast (1.4.3)

Text against its background must reach 4.5:1 for normal text or 3:1 for large text (18pt+, or 14pt+ bold). Anything below makes copy unreadable for low-vision users.

Ratio · Normal
4.5 : 1 (AA) · 7 : 1 (AAA)
Ratio · Large
3 : 1 (AA) · 4.5 : 1 (AAA)
Tools
WebAIM Contrast Checker
SC 1.1.1 06 / 10

Text Alternatives (1.1.1)

Every non-text element needs a text alternative that conveys the same meaning. Decorative images use empty alt; informative images describe the content.

Required on
<img> · SVG · icon fonts
Decorative
alt=“” hides from screen reader
Avoid
“image of …” prefix
SC 2.1.1 07 / 10

Keyboard Accessible (2.1.1)

Every interactive element must be reachable and operable using a keyboard. No mouse-only menus, no drag-and-drop without a fallback, no hover-only reveal of critical info.

Test method
Unplug your mouse
Watch for
div onclick · custom widgets
Order
Visual ≡ DOM ≡ tab order
SC 2.4.7 08 / 10

Focus Visible (2.4.7)

Keyboard focus must always be visible. Removing the default outline without providing a clearer replacement strands keyboard users — they literally cannot see where they are.

Default
Browser-blue outline · do not strip
Custom ring
3 px · 2 px offset · ≥3:1 contrast
Property
:focus-visible (not :focus)
SC 2.5.5 09 / 10

Touch Target Size (2.5.5)

Pointer targets must be at least 24×24 CSS pixels (AA, WCAG 2.2) — 44×44 for AAA. Tiny tap targets make mobile sites useless for anyone with low precision or large fingers.

AA
24 × 24 CSS px
AAA
44 × 44 CSS px
Spacing
Adjacent targets ≥ 8 px apart
SC 4.1.2 10 / 10

Name, Role, Value (4.1.2)

Every UI component must expose its name, role, and current state to assistive technology. Use the right element for the right job — <button> for actions, <a href> for navigation, <label> for inputs. ARIA only when native HTML can’t express it.

Name
Accessible text label
Role
What kind of element
Value
Current state / value

Accessibility in the Age of AI

AI is becoming both a way to generate accessibility metadata at scale and the assistive layer itself — neither replaces human review.

✦ AI Era

AI-Generated Alt Text & Captions

Vision and speech models can describe images and transcribe audio at scale. But the output needs review — a confident, wrong caption is worse than none at all.

Generates
Alt text · captions · labels
Use when
Volume is too high for manual
Watch for
Plausible but wrong output
✦ AI Era

AI as the New Assistive Layer

Screen readers, live captions, and “explain this page” are becoming AI features. Ship clean semantics so the model has accurate structure to work from.

Becomes
AI-powered AT
Design for
Clean roles & semantics
Watch for
Garbage-in → garbage-out
Further Reading