You opened an accessibility audit, or a vendor’s slide deck, and saw the word POUR written in capitals across the top. Four headings followed, each with a list of numbered items beneath it. The numbers are where the detail lives, but the four headings are the part worth understanding first, because they explain why each requirement exists.
The POUR principles are the four ideas the whole of WCAG is built on. This post takes each one in turn, shows what it looks like on an ordinary business website, and gives you a few quick checks you can run yourself in a couple of minutes. It is not a tour of individual criteria; our guide to the WCAG 2.2 AA criteria does that.
Where the POUR principles come from
WCAG groups its success criteria under four principles. In order, content must be perceivable, operable, understandable and robust, the last meaning it is built on code that browsers and assistive technology can read reliably. Take the first letter of each and you get POUR.
The principles are not tested directly. Nobody fails “Operable” as a whole. They are a way of organizing the guidelines and criteria so that people can see the purpose behind them. If you want the wider background on how the standard is put together, our plain-language WCAG overview covers it.
For a business owner, the useful thing about POUR is that it turns into four simple questions about any page:
- Can everyone take in what is here?
- Can everyone use the controls?
- Can everyone make sense of it?
- Will it work with the tools people actually use to browse?
P: Perceivable
Perceivable means people can take in the content through at least one of their senses. If something is only available as an image, someone who is blind misses it. If it is only available as sound, someone who is deaf misses it. If the text is pale gray on white, someone with low vision might miss it too.
What it looks like on a real site
- A restaurant’s menu uploaded as a photo of the printed menu, with no text version.
- A promotional video with no captions, where the offer is only spoken.
- A “Book now” button where the words are white on a pale yellow brand color.
- An infographic about your services where the actual information is baked into the image.
Quick checks
- Look at your three most important images. If each one disappeared, would the page still say what it needs to say? If not, the image needs good alt text; the steps for writing and entering alt text in WordPress are in a separate post.
- Play your main video with the sound off. Can you still follow it?
- Read your body text and button labels in bright daylight on a phone. If you squint, so will your customers. Our guide to contrast ratios and brand colors explains how to measure it properly.
O: Operable
Operable means people can actually use the interface: every link, button, menu and form. Not everyone uses a mouse. Some people use only a keyboard, some use switch devices, voice control or a screen reader, and many people on phones have a shaky thumb on a crowded bus. Operable also covers time and motion. People need enough time to finish, and nothing on the page should flicker fast enough to risk a seizure.
What it looks like on a real site
- A dropdown menu that only opens when you hover a mouse over it.
- A popup with no way to close it from the keyboard, so you are stuck.
- A slider that rotates every three seconds with no pause button.
- Tiny social icons in the footer that are almost impossible to tap accurately.
- A session timeout on a long application form that wipes everything without warning.
Quick checks
- Slide the mouse out of reach and work down the page with the Tab key. Does every link and button get its turn? Is your position on the page always visible? Can you open the menu and close any popup with Escape? Our post on testing your site with only a keyboard turns this into a proper method.
- Watch the home page for ten seconds. Does anything move on its own? Is there a visible way to stop it?
- On a phone, try tapping each footer icon with your thumb. Do you ever hit the wrong one?
U: Understandable
Understandable means people can make sense of the content and predict how the interface behaves. This principle helps everyone, but it matters most for people with cognitive or learning disabilities, visitors whose first language is not English, and anyone who is tired, stressed or in a hurry. That last group includes most of your customers at some point.
What it looks like on a real site
- A contact form whose field names are gray hints inside the boxes that disappear once typing begins.
- An error message that says “Invalid input” without saying which field or what is wrong.
- Navigation that changes order from page to page.
- A dropdown that jumps you to a new page as soon as you pick an option, before you press anything.
- Service descriptions packed with jargon and internal abbreviations.
Quick checks
- Submit your contact form with every field empty. Do the error messages say clearly what to fix, in words and not just in red?
- Click through four or five pages. Do the menu, the search and the phone number stay in the same place?
- Read your top service page out loud. Would a new customer understand every term on first read?
R: Robust
Robust is about the code underneath the page. Content has to be built in a way that browsers, screen readers, voice control software and other assistive technology can interpret reliably, today and as those tools change. This is the most technical of the four, and it is the one owners cannot see by looking at the screen.
The core idea is that every control should tell assistive technology three things: what it is (a button, a checkbox, a link), what it is called (“Add to cart”), and what state it is in (checked, expanded, selected). Standard HTML elements do this automatically. Custom components built from plain boxes and scripts often do not.
What it looks like on a real site
- An icon-only search button with no text name, which a screen reader announces as just “button.”
- An accordion on an FAQ page that opens visually but never tells a screen reader whether it is open or closed.
- A “Message sent” confirmation that appears on screen but is never announced.
- A page builder widget that uses clickable boxes instead of real buttons.
Quick checks
This principle is hard to check without a screen reader, but you can get a feel for it. Turn on VoiceOver on a Mac or iPhone, or install the free NVDA screen reader on Windows, and move through your main menu and your contact form. Listen for controls announced with no name, or a run of “button, button, link” with nothing to tell them apart. If you hear that, the code needs attention.
Using POUR to sort what you find
POUR is also a handy way to organize your own notes. When you or a colleague find something wrong, file it under the principle it affects:
| Principle | Question to ask | Typical fix owner |
|---|---|---|
| Perceivable | Can people see or hear this? | Content editor, designer |
| Operable | Can people use this with their device? | Developer, theme or plugin |
| Understandable | Will people know what this means and what will happen? | Content editor, designer |
| Robust | Will assistive technology read this correctly? | Developer |
The “fix owner” column is rough, but it helps. Perceivable and understandable issues are often fixed in the editor by whoever writes the content: alt text, captions, clearer labels, plainer wording. Operable and code issues usually need a developer to change the theme, swap a plugin or rewrite a component. Knowing which is which tells you how much of the work you can start on this afternoon.
A single problem can touch more than one principle. A carousel with tiny unlabeled arrows that rotates on its own is hard to perceive, hard to operate and silent to screen readers. Those are the components worth fixing first, because one change removes several barriers at once.
If you are trying to understand how this fits with the legal and practical side for a US business, the hub page on accessibility services for US businesses sets out the audit, fix and monitor approach. For video specifically, our post on captioning website videos is a good next step.
Frequently asked questions
What does POUR stand for in accessibility?
POUR is the shorthand for the four principles behind WCAG: perceivable, operable, understandable and robust. Content must be possible to take in, possible to use and possible to make sense of, and it must be coded so that browsers and assistive technology can interpret it reliably. Every success criterion sits under one of the four.
Is one principle more important than the others?
No. A barrier under any of the four can stop someone completely. A form that cannot be perceived, cannot be operated, cannot be understood or is not announced by a screen reader fails the person using it just the same. The principles organize the requirements; they are not ranked.
Why is the fourth principle called Robust?
In WCAG, robust has nothing to do with security or server uptime. It means content is built so that a wide range of browsers and assistive technologies, including future versions, can interpret it. In practice that comes down to standard markup and controls that expose their name, role and state.
Do the POUR principles apply to PDFs and documents?
Yes. The same four ideas apply to any content you publish, including PDFs, Word files and slide decks. A scanned PDF with no real text fails the first principle immediately, and an untagged document often fails the fourth because screen readers cannot work out its structure.
Our WCAG accessibility audit works through a site principle by principle and criterion by criterion, with evidence for each finding and a suggested fix order. Even if you never get in touch, the quick checks above will show you a lot.
Next in this series: WCAG Color Contrast: Ratios, Tools and Brand Fixes
