Accessibility 101: What POUR Means and Why It Matters
POUR is the acronym for the four foundational principles of WCAG (Web Content Accessibility Guidelines). Every accessibility success…
Accessibility 101: What POUR Means and Why It Matters
POUR is the acronym for the four foundational principles of WCAG (Web Content Accessibility Guidelines). Every accessibility success criterion in WCAG falls under one of these four principles.
P — Perceivable
Users must be able to perceive the information being presented — it can’t be invisible to all of their senses.
What it covers
- Text alternatives for non-text content (alt text for images, labels for icons)
- Captions and transcripts for audio and video
- Content that can be presented in different ways without losing meaning (responsive layouts, reflow)
- Content that’s easy to see and hear (sufficient color contrast, no audio that auto-plays loudly)
Common failures
- Images with no alt text or with
alt="image" - Videos without captions
- Information conveyed only by color (e.g., red text = error, with no icon or label)
- Low color contrast (gray text on white)
- Text inside images instead of real text
- Content that breaks when zoomed to 200% or reflowed
Example success criteria
- 1.1.1 Non-text Content (A)
- 1.2.2 Captions (A)
- 1.4.3 Contrast Minimum (AA)
- 1.4.10 Reflow (AA)
- 1.4.11 Non-text Contrast (AA)
O — Operable
Users must be able to operate the interface — it can’t require interaction they can’t perform.
What it covers
- All functionality available via keyboard
- Users have enough time to read and use content
- No content that flashes in ways that cause seizures
- Users can navigate, find content, and know where they are
- Input modalities beyond just keyboard and mouse (touch, voice)
Common failures
- Dropdowns, modals, or custom widgets that don’t work with keyboard
- Focus traps where you can’t escape with the keyboard
- Auto-advancing carousels with no pause button
- Session timeouts with no warning or extension option
- Flashing content (more than 3 flashes per second can trigger seizures)
- Missing skip links to bypass repeated navigation
- Tiny touch targets on mobile
- No visible focus indicator
Example success criteria
- 2.1.1 Keyboard (A)
- 2.1.2 No Keyboard Trap (A)
- 2.2.1 Timing Adjustable (A)
- 2.3.1 Three Flashes or Below (A)
- 2.4.3 Focus Order (A)
- 2.4.7 Focus Visible (AA)
- 2.5.5 Target Size (AAA in 2.1, became 2.5.8 AA in 2.2 at 24x24px)
U — Understandable
Users must be able to understand both the content and how the interface works.
What it covers
- Text is readable and understandable
- Content appears and operates in predictable ways
- Users are helped to avoid and correct mistakes
Common failures
- Page language not set in HTML (
<html lang="en">) - Jargon, idioms, or complex language without explanation
- Form fields without labels
- Errors without clear messages or guidance on how to fix them
- Navigation that changes order between pages
- Things that change unexpectedly on focus or input (e.g., a form submits when you tab into a field, a dropdown opens a new page on selection)
- Unclear or missing instructions
Example success criteria
- 3.1.1 Language of Page (A)
- 3.2.1 On Focus (A) — focus alone doesn’t trigger a context change
- 3.2.2 On Input (A) — changing a field value alone doesn’t trigger a context change
- 3.3.1 Error Identification (A)
- 3.3.2 Labels or Instructions (A)
- 3.3.3 Error Suggestion (AA)
- 3.3.7 Redundant Entry (A, new in 2.2)
R — Robust
Content must be robust enough to work reliably with current and future assistive technologies.
What it covers
- Valid, well-formed markup
- Correct use of semantic HTML and ARIA
- Status messages that can be programmatically detected
Common failures
- Using
<div onclick>for buttons instead of<button> - Invalid ARIA (role that doesn’t exist, required attributes missing)
- Custom widgets that don’t expose their name, role, and state to assistive tech
- Status messages (like “item added to cart”) that aren’t announced because they’re not in a live region
- Duplicate IDs that confuse screen readers
Example success criteria
- 4.1.2 Name, Role, Value (A) — every UI component must have these programmatically determinable
- 4.1.3 Status Messages (AA)
(Note: 4.1.1 Parsing was removed in WCAG 2.2 because modern browsers handle malformed HTML well enough.)
Quick mental model
When auditing or designing, walk through POUR as questions:
- Perceivable — Can users sense the content? (See it, hear it, feel it)
- Operable — Can users interact with it? (Keyboard, touch, voice)
- Understandable — Can users comprehend it? (Content + interactions)
- Robust — Can assistive tech parse it? (Now and in the future)
If any answer is “no” for any user, you have an accessibility issue.
Why POUR matters in practice
POUR isn’t just a memorization aid — it shapes how you should think about accessibility reviews:
- A blind user mostly cares about Perceivable (do alt texts exist, is structure semantic) and Robust (does my screen reader understand it)
- A keyboard-only user (motor impairment, power user, broken trackpad) mostly cares about Operable
- A user with cognitive differences cares heavily about Understandable (clear language, predictable patterns, error help)
- A user with low vision cares about Perceivable (contrast, zoom, reflow) and Operable (focus visibility, target size)
메타데이터
- post_id
- 143f398bab34
- slug
- accessibility-101-what-pour-means-and-why-it-matters-143f398bab34
- url
- https://medium.com/@shweta.shrivastava/accessibility-101-what-pour-means-and-why-it-matters-143f398bab34
- canonical_url
- https://medium.com/@shweta.shrivastava/accessibility-101-what-pour-means-and-why-it-matters-143f398bab34
- author_url
- https://medium.com/@shweta.shrivastava
- status
- ok
- fetched_at
- 2026-06-25 07:00:49
