POUR: The Four Principles of Web Accessibility

POUR stands for Perceivable, Operable, Understandable, and Robust — the four principles that organize every rule in the Web Content Accessibility Guidelines. Each WCAG success criterion belongs to one of them, so POUR is the simplest way to understand what makes a website accessible to people with disabilities.

Where POUR comes from

The POUR principles are the top layer of WCAG, published by the World Wide Web Consortium’s Web Accessibility Initiative (W3C/WAI). The structure is a pyramid:

You don’t need to memorize all of this. When courts, the DOJ, or a demand letter reference accessibility, they’re almost always pointing at WCAG 2.1 AA — which means meeting every Level A and AA criterion across all four principles. The same framework underpins ADA Title III expectations and Section 508 for federal contractors.

Below, each principle gets a plain-language definition and concrete examples of what passing and failing look like.

1. Perceivable

Perceivable means users can take in the information on your page through at least one of their senses. If content is delivered in only one way — say, sight — anyone who can’t use that sense is locked out.

This is where the most common — and most litigated — barriers live. A blind user relies on a screen reader (NVDA, JAWS, or VoiceOver) to convert your page to speech or braille; a user with low vision needs sufficient color contrast.

Real examples:

• Alt text on images so a screen reader can describe them. A product photo with no description is invisible to a blind shopper. (See our alt text best practices.)
• Color contrast of at least 4.5:1 for normal text, so low-vision users can read it. Light-gray text on white is the classic failure — covered in our color contrast guide.
• Captions on video and transcripts on audio for deaf and hard-of-hearing users.
• Don’t rely on color alone to convey meaning (e.g., “fields in red are required” leaves out colorblind users).
• Text that resizes to 200% without breaking the layout.

If a user literally cannot get the information, no amount of clever interaction design helps. Perceivable comes first for a reason.

2. Operable

Operable means users can actually navigate and interact with your site — clicking, typing, submitting forms — regardless of the input device they use. Many people don’t use a mouse at all.

The benchmark test here is simple: can you operate your entire site with the keyboard only? People with motor disabilities, screen-reader users, and those using switch devices all depend on keyboard navigation.

Real examples:

• Full keyboard access — every link, button, menu, and form control reachable and usable with Tab, Enter, and arrow keys, with no keyboard traps.
• Visible focus indicators so keyboard users can see where they are on the page.
• Skip-to-content links and clear heading structure and landmarks so users aren’t forced to tab through hundreds of items.
• Enough time to read and use content — auto-advancing carousels and aggressive session timeouts fail here.
• No content that flashes more than three times per second (a seizure risk).
• Descriptive link text — “Read our pricing,” not “click here.”

A beautiful site that only works with a mouse fails Operable on day one. This is one of the most frequently cited categories in ADA web complaints.

3. Understandable

Understandable means people can comprehend both your content and how your interface behaves. Information should be readable, and the site should act in predictable ways.

This principle protects everyone, but especially users with cognitive disabilities, learning differences, or limited literacy — and anyone moving fast or under stress.

Real examples:

• Clear, plain language instead of jargon, with a defined page language (lang="en") so screen readers pronounce words correctly.
• Predictable behavior — navigation appears in the same place on every page; nothing changes context unexpectedly when a user focuses a field.
• Helpful form design — visible labels, clear instructions, and error messages that explain how to fix the problem, not just “invalid input.” See our accessible forms guide.
• Consistent identification — the same icon or button means the same thing everywhere.

If users can’t predict what your site will do, they make mistakes and abandon tasks. Understandable is about removing that friction.

4. Robust

Robust means your content works reliably across browsers, devices, and — critically — assistive technologies, both now and as those tools evolve. This is the most technical of the four principles.

Robustness is mostly about clean, standards-compliant code. Screen readers and other assistive technology read your HTML’s structure and the accessibility information you expose to them. Broken or invented markup breaks the bridge.

Real examples:

• Valid, well-formed HTML with properly nested, non-duplicated elements so assistive tech can parse the page.
• Correct ARIA — accessible names, roles, and states for custom components like modals, tabs, and menus. Misused ARIA is worse than none; see our ARIA labels and roles guide.
• Native HTML elements (<button>, <input>, <nav>) wherever possible, because they come with accessibility built in.
• Status messages announced to screen readers without stealing focus (e.g., “Item added to cart”).

Robust is why a checkbox built from a styled <div> so often fails: it looks right but reports nothing useful to a screen reader.

How the POUR principles connect to ADA compliance

There’s no separate “ADA code” for websites. U.S. courts, the DOJ, and most settlement agreements treat WCAG 2.1 AA as the practical standard — and WCAG is built entirely on POUR. So when you make a page Perceivable, Operable, Understandable, and Robust at Level A and AA, you’re doing the work that defends against an ADA website lawsuit.

This is also why accessibility overlays don’t work. A widget injected on top of your page can’t rebuild broken HTML, can’t add genuine keyboard operability, and can’t give a screen reader the structure it needs. The underlying code still fails POUR — which is exactly why overlays keep showing up in lawsuits rather than preventing them. (More on why overlays don’t ensure compliance.)

This page explains accessibility standards, not legal requirements — it isn’t legal advice. For your specific exposure, consult a qualified attorney.

Putting POUR into practice

You can’t fix what you can’t see. Automated tools flag obvious Perceivable issues like missing alt text, but Operable, Understandable, and Robust problems almost always require a human testing with a keyboard and a screen reader. That’s the gap a real accessibility audit fills — every finding mapped to its principle and success criterion, with a remediation plan to match.

Curbcut audits and remediates by hand — no overlay, no shortcut. We fix the code so your site genuinely satisfies all four POUR principles, then document it. Want to know where you stand? Start with a free accessibility scan or have us audit your site against WCAG 2.1 AA.