WCAG & 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.

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.

Principle 1 · WCAG 1.x
Text alternatives for non-text
Captions for audio & video
Adaptable, semantic structure
Distinguishable: color + contrast
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.

Principle 2 · WCAG 2.x
Keyboard accessible
Enough time to complete tasks
No seizure-inducing flashes
Navigable: skip links, headings
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.

Principle 3 · WCAG 3.x
Readable language, clear copy
Predictable: consistent patterns
Input assistance: clear errors
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.

Principle 4 · WCAG 4.x
<button aria-label="Close">
<nav role="navigation">
<main>…</main>
<label for="email">…</label>
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.

AA · 4.5:1 minimum
7.8 : 1 ✓
7.6 : 1 ✓
5.2 : 1 ✓
2.1 : 1 ✗
PASSES PASSES PASSES FAILS
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.

Three alt-text recipes
Informative
alt="Chart showing sales up 28% YoY"
Functional (link/button)
alt="Search products"
Decorative
alt=""
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.

Standard tab order
Tab→ next focusable element
Shift+Tab→ previous
Enter→ activate link / submit form
Space→ activate button · toggle checkbox
Esc→ close modal · cancel action
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.

With vs. without ring
Unfocused
Focused
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.

24 px AA · 44 px AAA Finger 16 px TOO SMALL 24 px AA 44 px AAA SIZE MATTERS — SEE FITTS'S LAW
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.

<div onclick="submit()">Go</div>
<button type="submit">Go</button>
<span>Email</span><input/>
<label for="em">Email</label>
<input id="em" type="email"/>
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