The POUR principles of web accessibility for developers and designers
D
Devly Team
Sustainable & accessible Web Development
WCAG, the Web Content Accessibility Guidelines, can feel overwhelming. The current version (WCAG 2.2) has 13 guidelines and 86 success criteria across three conformance levels.
Most developers and designers never read them cover to cover. They don't need to. What they do need is a mental model, a way to think about accessibility that makes the specifics easier to understand and apply. That mental model is called POUR, the four foundational principles that every WCAG guideline sits underneath.
What POUR stands for
POUR is an acronym for the four principles that structure the entire WCAG standard:
Perceivable: users can perceive the content (through sight, hearing, or touch)
Operable: users can operate the interface (with keyboard, mouse, touch, or voice)
Understandable: users can understand the content and how to use the interface
Robust: the content works reliably across browsers, devices, and assistive technologies
Every WCAG guideline falls under one of these four principles. If your content fails on any one of them, a group of users is shut out, regardless of how well the other three are handled.
1. Perceivable: can users sense the content?
A website is perceivable when users can access its information through at least one of their senses. If content is only available visually, blind users can't access it. If it's only available as audio, deaf users can't access it.
What this covers in practice:
Text alternatives for images: Every meaningful image needs an alt attribute that describes what it shows. Decorative images get alt="" so screen readers skip them.
Captions and transcripts for media: Videos need captions for deaf users. Audio content needs transcripts.
Sufficient color contrast: Text needs at least a 4.5:1 contrast ratio against its background (3:1 for large text). Users with low vision or color blindness can't read low-contrast text.
Not relying on color alone: If a form error is indicated only by turning the field red, colorblind users won't see it. Add an icon, a text message, or a pattern.
Resizable text: Users must be able to zoom to 200% without losing content or functionality.
html
<!-- Meaningful image: describe what it shows --><img src="chart.png" alt="Bar chart showing 70% adoption increase from 2022 to 2024"><!-- Decorative image: empty alt so screen readers skip it --><img src="decorative-swirl.svg" alt="">
2. Operable: can users navigate and interact?
A website is operable when users can navigate and interact with it using whatever input method they rely on. Keyboard, voice, switch device, eye tracker, touch, or mouse... all must work.
What this covers in practice:
Full keyboard access: every interactive element: links, buttons, form fields, custom components... must be reachable and usable with Tab, Shift+Tab, Enter, and arrow keys. No mouse required.
Visible focus indicators: When a user tabs to an element, it must be visually obvious which element has focus.
Skip navigation links: A keyboard user shouldn't have to tab through 20 header links to reach the main content on every page. (We covered this in detail in our article on skip navigation.)
Enough time: If your interface has time limits (session timeouts, auto-logouts, countdown timers), users must be able to extend or disable them.
No seizure-inducing content: Flashing content above 3 times per second can trigger seizures in users with photosensitive epilepsy.
3. Understandable: can users make sense of what they see?
A website is understandable when users can read the content and predict how the interface will behave. This principle is about cognitive load: reducing confusion, preventing errors, and making the system's logic clear.
What this covers in practice:
Declare the page language: the <html lang="en"> attribute tells screen readers which language to use for pronunciation. Without it, a French page might be read aloud with an English accent.
Consistent navigation: If your main menu appears in a different order on different pages, users have to relearn it each time. Keep the structure consistent.
Predictable behaviour: Selecting an option in a dropdown shouldn't automatically submit a form. Users expect interactions to have obvious, expected results.
Clear error messages: When a form field is invalid, tell the user what went wrong and how to fix it. "Invalid input" is useless. "Email must contain an @ symbol" is actionable.
Labels on every form field.: A text input without a visible label is a guessing game for everyone, especially screen reader users.
4. Robust: does it work everywhere?
A website is robust when it works reliably across browsers, operating systems, devices, and assistive technologies, now and in the future. This principle is about building on solid foundations rather than fragile ones.
What this covers in practice:
Use semantic HTML: A <button> element is understood by every browser, screen reader, and voice control system on the planet. A <div> styled to look like a button is not.
Use ARIA only when HTML can't do the job: ARIA attributes (aria-label, role, aria-expanded, etc.) are powerful, but misused ARIA is a common source of accessibility failures. The first rule of ARIA is: don't use ARIA if native HTML already provides what you need.
The legal case for accessibility is clear: WCAG is referenced in the ADA (US), Section 508, the European Accessibility Act, and similar laws worldwide. But compliance is only part of the reason to care about POUR.
Accessibility benefits everyone: Captions help people in noisy environments or those who prefer reading to listening. Keyboard navigation benefits power users who work faster without a mouse. Clear error messages reduce frustration for every user, not just those with disabilities. High contrast improves readability in bright sunlight. POUR is a usability framework that happens to be essential for disabled users and valuable for everyone else.
It reduces support costs: Users who can understand error messages don't contact support. Users who can navigate your site without getting stuck don't abandon it.
It scales with your team: When accessibility is baked into your design system and component library, every new feature is accessible by default. Retrofitting accessibility after the fact is expensive. Building it in from the start is nearly free.
Whether you're just starting to think about sustainability and accessibility or you're ready to overhaul your entire stack, there's a place for you here.
No spam. Unsubscribe anytime. Join 300+ developers.