POUR stands for Perceivable, Operable, Understandable, and Robust — the four principles that organize every requirement in the Web Content Accessibility Guidelines (WCAG). Each principle answers a plain question about your website: can people take in your content, use your controls, follow what is happening, and trust the site to work with their technology? Every individual WCAG rule, from color contrast to form labels, sits under one of these four headings, which makes the WCAG POUR principles the fastest way for a non-technical decision maker to understand what accessibility actually asks of a site.
Why should a business owner care about the WCAG POUR principles?
WCAG 2.2 — the current version of the standard, published by the W3C in October 2023 — contains dozens of testable success criteria. Nobody expects an owner to memorize them, and you should not have to. The four principles are the executive summary: once you understand them, every finding your developers or auditors raise will slot into a category you recognize.
There is also a legal reason to care. WCAG Level AA is the benchmark courts, settlement agreements, and regulators consistently reference, and litigation keeps climbing — more than 5,000 digital-accessibility lawsuits were filed in 2025 alone. The failures those suits cite are not exotic. WebAIM's 2025 analysis found detectable WCAG failures on 94.8% of the top one million homepages, and the most common types — low-contrast text, missing image alt text, missing form labels, and empty links or buttons — map directly onto the four principles below.
What does "Perceivable" mean in practice?
Perceivable means every visitor can take in your content through at least one working sense. Over 1 in 4 U.S. adults live with a disability, and many browse in ways you may never have watched: with a screen reader speaking the page aloud, with text enlarged far beyond your design mockups, or with color perception that flattens a carefully chosen palette.
The heavy hitters under this principle:
- Alt text on images. A screen reader cannot describe a photo unless your code does. Writing useful alt text is one of the cheapest accessibility wins available.
- Color contrast. WCAG requires a 4.5:1 contrast ratio for normal text and 3:1 for large text. Low-contrast text is the single most common failure on the web.
- Captions on video. Prerecorded video needs captions even at Level A, WCAG's minimum conformance level. Live content requires them at Level AA.
What does "Operable" mean in practice?
Operable means everyone can actually work your interface — open menus, submit forms, dismiss pop-ups — regardless of how they physically interact with a device. Plenty of users never touch a mouse: people with motor disabilities, screen-reader users, and keyboard power users alike.
The core tests:
- Full keyboard access. Every action a mouse can perform must be reachable with Tab, Enter, and the arrow keys, with a visible focus indicator showing where you are. You can run a basic keyboard navigation test yourself in about five minutes.
- No keyboard traps. A pop-up you can tab into but never out of fails this principle outright.
- Reasonable target sizes. WCAG 2.2 added a minimum target size of 24×24 CSS pixels, so tiny tap targets stop punishing users with limited dexterity.
- Time and motion. Auto-advancing carousels, aggressive session timeouts, and drag-only interactions all create operability failures.
What does "Understandable" mean in practice?
Understandable means visitors can follow both your content and your interface's behavior. A site can be technically perceivable and operable and still leave people stranded because it behaves unpredictably or explains nothing when something goes wrong.
On a real site, that means:
- Labeled form fields. Every input needs a programmatic label, and error messages must say what went wrong and how to fix it. "Invalid input" helps no one.
- Predictable behavior. Navigation stays where visitors expect it, and focusing a form field never fires off a surprise page change.
- Plain language. Clear writing is an accessibility feature for people with cognitive disabilities — and for every other customer skimming on a phone.
WCAG 2.2 also strengthened this principle with Accessible Authentication: logins can no longer depend solely on memorizing or transcribing information, so password managers and paste must work.
What does "Robust" mean in practice?
Robust means your code is clean enough for assistive technologies to interpret reliably — today and as browsers and screen readers evolve. It is the least visible principle, and the one most often broken by modern JavaScript-heavy sites.
The classic failure is a generic container styled to look like a button. A sighted mouse user clicks it and nothing seems wrong. A screen reader announces nothing — no name, no role, no hint that the element is interactive — so for that user, the "button" does not exist. Robust code uses real HTML elements (actual buttons, links, and headings) or correctly applied ARIA attributes, so every component exposes its name, role, and state to assistive technology.
How do you check your site against the POUR principles?
Start with an automated scan, but understand its limits: automated tools can detect only roughly a third of WCAG success criteria. A scanner will reliably flag missing alt text and low contrast; it cannot judge whether your alt text is meaningful, whether keyboard focus order makes sense, or whether your error messages are understandable. Those calls require a human.
Be equally skeptical of anything promising instant results. No tool, widget, or overlay can make a site conform to WCAG — the FTC's $1 million action against overlay vendor accessiBe, announced in January 2025, targeted exactly that kind of claim. To be clear, the problem is the compliance claim, not the preference button: a user-facing contrast or text-size widget on a site that is already accessible at the code level is a courtesy, and ADA Fail's own site runs one. Our breakdown of why overlay widgets fail covers the difference in detail.
A sensible sequence: run a scanner for the mechanical failures, do the five-minute keyboard test yourself, then get expert eyes on the rest. ADA Fail's free accessibility audit pairs an automated scan with human review against WCAG 2.2 AA, organized by these same four principles, so you can see where your site actually stands.
Frequently asked questions
Is meeting the POUR principles the same as being ADA compliant?
Not automatically. The ADA does not publish a technical web standard for private businesses; WCAG is the de facto benchmark that courts and settlements reference, and Level AA is the target nearly everyone means. POUR is the organizing framework inside WCAG — conformance is assessed against the individual success criteria under each principle, and full-conformance conclusions require expert human testing, not a scan score alone.
Which POUR principle do websites fail most often?
Perceivable, by a wide margin. WebAIM's 2025 study of the top one million homepages found low-contrast text and missing image alt text to be the most common detectable failures — both Perceivable problems — with missing form labels and empty links or buttons close behind. The encouraging news is that these are also among the cheapest issues to fix.
Will the POUR principles change in WCAG 3.0?
Not any time soon, and not in a way you need to plan around. WCAG 3.0 is an early draft, years away from being a requirement anywhere. WCAG 2.2 — a W3C Recommendation since October 5, 2023 — is the current standard, and its structure of four principles and three conformance levels is what regulators and courts reference today. Work you do against POUR now is not effort you will throw away.
Want to know how your site measures up, principle by principle? Request a free WCAG 2.2 audit from ADA Fail — we will show you which failures your site has, which ones matter most, and exactly what fixing them takes.