The four WCAG principles are Perceivable, Operable, Understandable and Robust, remembered as POUR: people must be able to take in your content, work your controls, make sense of both, and use them with their own assistive technology. Each of the 13 guidelines, and every one of the 86 criteria in the current release, belongs to one of them.
The principles are not themselves testable. They are the reason each criterion exists, and they make a useful checklist when you review a design before any code is written.
Quick facts
The four principles
Perceivable, Operable, Understandable, Robust.
Memory aid
POUR, from the first letters.
Guidelines under them
13 in WCAG 2.2: 4, 5, 3 and 1.
Criteria per principle
29, 34, 21 and 2 in WCAG 2.2.
Testable?
No. You test the success criteria, not the principles.
WCAG POUR principles diagram
People often look for a WCAG POUR principles diagram. Here is the same information as a table, which screen readers can navigate and which you can copy into a slide.
| Principle | The question it asks | Guidelines in WCAG 2.2 | Criteria |
|---|---|---|---|
| Perceivable | Can every user take in the content with at least one sense? | 1.1 Text Alternatives, 1.2 Time-based Media, 1.3 Adaptable, 1.4 Distinguishable | 29 |
| Operable | Can every user work every control and move around? | 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures and Physical Reactions, 2.4 Navigable, 2.5 Input Modalities | 34 |
| Understandable | Can users follow the content and predict what the interface does? | 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance | 21 |
| Robust | Will it keep working with browsers and assistive technology? | 4.1 Compatible | 2 |
The counts add up to 86. Robust has only two criteria left in WCAG 2.2 because the parsing criterion was removed.
Perceivable: content people can take in
Perceivable means information cannot be invisible to all of a person's senses. A blind user needs text that a screen reader can speak; a Deaf user needs captions; a low vision user needs contrast and the freedom to zoom.
- Give images and icons a text alternative (non-text content).
- Code headings, lists, tables and labels so structure survives without the visuals (info and relationships).
- Keep text contrast at 4.5:1 or more and let content reflow at narrow widths (reflow).
- Never let color be the only clue (use of color).
Not perceivable: the icon has no text a screen reader can read.
<a href="/cart/"><img src="cart.svg"></a>Perceivable: the alt text names the destination.
<a href="/cart/"><img src="cart.svg" alt="Cart"></a>Operable: controls people can use
Operable means people can use every control with the input they have: keyboard, switch, voice, touch or mouse. It also covers time and motion, since some users need longer or cannot cope with flashing.
- Nothing needs a mouse, and focus never gets stuck (keyboard).
- Focus is visible and moves in a sensible order (focus visible, focus order).
- Links say where they lead (link purpose).
- Moving content can be paused (pause, stop, hide).
- Touch targets are big enough or spaced out (target size).
Understandable: no surprises
Understandable means the content reads clearly and the interface behaves the way people expect. Surprises are the enemy: a form that submits when you pick an option, or an error that just turns a border red.
- Set the page language so speech output uses the right voice.
- Keep navigation and naming consistent from page to page.
- Do not change context just because a value changed (on input).
- Label fields and explain formats (labels or instructions), and name errors in words (error identification).
Robust: code that assistive tech can read
Robust means your code tells browsers and assistive technology what each thing is, so it keeps working as tools change. In practice it now comes down to just a pair of criteria.
- Every control exposes a name, a role and its current state (name, role, value).
- Status updates are announced without stealing focus (status messages).
Not robust: a styled div gives no role or state to assistive technology.
<div class="toggle on">Dark mode</div>Robust: a native control with a role and a state built in.
<label><input type="checkbox" checked>
Dark mode</label>Using the WCAG principles in reviews
Because the principles are broad, they work well as review questions at each stage of a project.
| Stage | Question to ask | Principle |
|---|---|---|
| Wireframe | Could someone who cannot see this layout still get every piece of information? | Perceivable |
| Visual design | Do colors, focus styles and sizes work for low vision and touch users? | Perceivable and Operable |
| Content | Are headings, labels and errors written so a tired, rushed reader understands them? | Understandable |
| Build | Did we use native HTML elements, or did we rebuild a button from scratch? | Robust |
| Testing | Can a keyboard user and a screen reader user finish the task? | Operable and Robust |
If a design discussion stalls, ask which principle a choice affects. It moves the conversation from taste to user needs.
Where POUR fits in the standard
The POUR principles WCAG relies on first appeared with version 2.0 and has stayed unchanged in every later 2.x release. The only structural change is that 2.1 added a fifth guideline under Operable, 2.5 Input Modalities, for touch and pointer use. The W3C quick reference is organised by these principles, and our WCAG overview explains how principles, guidelines and criteria fit together. The WCAG 3.0 draft is reorganising the structure, covered on the WCAG 3.0 page.
Questions people ask
What does POUR stand for in WCAG?
POUR stands for Perceivable, Operable, Understandable and Robust. They are the four principles that group every WCAG guideline and success criterion.
Are the POUR principles requirements?
Not directly. You cannot pass or fail a principle. Conformance is measured on the success criteria beneath them, which are the testable part of WCAG.
Which principle has the most success criteria?
Operable, with 34 in WCAG 2.2, because it covers keyboard use, timing, seizures, navigation and pointer input. Perceivable follows with 29.
Why does Robust have so few criteria?
The parsing criterion, 4.1.1, was dropped from 2.2 for being outdated, which leaves 4.1.2 and 4.1.3. Robust is short, but those two criteria catch many failures in custom widgets.
Are the WCAG principles the same in every version?
Yes, the same four have been used since WCAG 2.0. Later versions added guidelines and criteria under them, but did not change the principles.