POUR stands for Perceivable, Operable, Understandable, and Robust. These are the four principles the Web Content Accessibility Guidelines (WCAG) are built on. Every WCAG success criterion sits under one of them.

The principles organize the requirements. They aren’t requirements themselves. WCAG 2.1 and 2.2 group their testable success criteria into 13 guidelines, and those guidelines sit under the four principles. When a law or policy points to WCAG 2.1 Level AA, the success criteria are what teams test against.

This guide explains what each principle covers, how enterprise teams use POUR to route accessibility work, and where Section 504 fits.

What the POUR principles mean

Each principle describes a condition content has to meet before people can use it. If content fails any one of them, some users can’t use it at all. It doesn’t matter how polished the rest of the page is.

Perceivable: See it and hear it

Perceivable means users can take in information and interface components through their senses. Nothing can be invisible to all of a user’s senses.

Four guidelines sit under this principle: text alternatives (1.1), time-based media (1.2), adaptable content (1.3), and distinguishable content (1.4).

In practice, you can’t rely on color alone to tell a story. Informative images need text alternatives. Purely decorative images should be coded so assistive technologies skip them. Video needs captions for those who can’t hear. It also needs audio descriptions for those who can’t see the screen. Text needs enough contrast against its background: 4.5:1 for normal-size text at Level AA.

A common failure: a chart that uses red and green lines with no labels. Users who can’t tell the colors apart lose the data. Respecting the light, dark, and forced-colors modes users choose goes a step further.

Operable: Navigate with ease

Operable means users can work every control and move through all the content, whatever input they use.

Five guidelines sit here: keyboard accessible (2.1), enough time (2.2), seizures and physical reactions (2.3), navigable (2.4), and input modalities (2.5, added in WCAG 2.1).

Many people don’t use a mouse. They might use a keyboard, a switch device, or voice commands. Your site’s menus and forms must work with these tools. Keyboard focus should move in a logical order and stay visible.

Time limits are allowed, but users must be able to turn them off, adjust them, or extend them, with a few exceptions. A session that times out mid-form with no warning fails this test.

A common failure: a pop-up window a keyboard user can’t exit. They’re stuck in a keyboard trap.

Understandable: Easy to follow

Understandable means users can make sense of both the information and how the interface works.

Three guidelines sit here: readable (3.1), predictable (3.2), and input assistance (3.3).

Your content shouldn’t be a puzzle. At Level AA, the page declares its language. Navigation stays in the same place on every page. Nothing changes unexpectedly when a user moves focus. Every form field has a clear, text-based label. When input goes wrong, the error message says what went wrong and, where possible, how to fix it.

Plain language helps everyone. WCAG treats reading level as a Level AAA criterion, though, so it’s good practice rather than an AA requirement.

A common failure: a form error that just says “Invalid entry.”

Robust: Works with a variety of tools

Robust means content can be interpreted reliably by a wide range of user agents. That includes browsers and assistive technologies such as screen readers.

One guideline sits here: compatible (4.1). Its core requirement is that every interface component exposes its name, role, and value in code (4.1.2). A screen reader can only announce a control correctly if the code says what it is.

That’s why semantic HTML matters. Use the right tags for the right job. For instance, don’t use a div tag when you need a button tag. Prefer native HTML elements, and add ARIA only where native HTML can’t describe a custom component. Incorrect ARIA can make things worse.

A common failure: a custom toggle built from div tags that a screen reader announces as plain text.

POUR at a glance

The four POUR principles, their WCAG 2.1 guidelines, example success criteria, and the team that usually owns them
Principle Guidelines Example success criteria (level) Typical failure Usual owner
Perceivable 1.1 Text alternatives, 1.2 Time-based media, 1.3 Adaptable, 1.4 Distinguishable Non-text content (1.1.1, A); Captions, prerecorded (1.2.2, A); Contrast, minimum (1.4.3, AA) Informative images with no text alternative Content and design
Operable 2.1 Keyboard accessible, 2.2 Enough time, 2.3 Seizures and physical reactions, 2.4 Navigable, 2.5 Input modalities Keyboard (2.1.1, A); No keyboard trap (2.1.2, A); Focus visible (2.4.7, AA) A modal a keyboard user can’t close Engineering and design
Understandable 3.1 Readable, 3.2 Predictable, 3.3 Input assistance Language of page (3.1.1, A); Consistent navigation (3.2.3, AA); Error identification (3.3.1, A) Vague form error messages Content and engineering
Robust 4.1 Compatible Name, role, value (4.1.2, A); Status messages (4.1.3, AA) Custom controls with no accessible name or role Engineering

Using POUR to run an accessibility program

On a large site, accessibility work stalls when everyone owns it and no one does. POUR gives teams a shared way to sort issues and send them to the people who can fix them.

Route issues by principle

Perceivable and Understandable issues often start in content and design: missing text alternatives, low contrast, vague labels. Operable and Robust issues usually start in templates and components. Sorting findings by principle tells you which team gets the ticket.

Start by adding POUR rules to your design system. Designers check contrast ratios and create clear focus states. Content creators add text alternatives and captions. Engineers build components on semantic HTML.

These steps shouldn’t be an afterthought. Accessible design should be part of the initial “Definition of Done” for every project.

Fix gaps at the source

To fix issues for good, use a clear remediation workflow.

  • Audit: Use automated tools to find easy errors such as missing labels.
  • Manual test: Have experts navigate with screen readers to find complex logic issues.
  • Fix: Update the master code or content templates, not just one page.
  • Verify: Retest to make sure the fix works and didn’t break anything else.

Test with tools and people

Automation is great for speed. But no tool can check every accessibility requirement on its own. Tools can’t tell if a video’s captions make sense or if a page’s reading order is logical. That’s where manual testing is needed.

  • Automated scans: Use these for quick, site-wide checks and to catch basic errors early.
  • Manual audits: Have experts test complex tasks with screen readers such as NVDA or JAWS.
  • User testing: Invite people with disabilities to use your site and provide feedback on their experience.

Governance holds it together. Each team should have an accessibility leader. Use a central standard to keep everyone aligned, and teach every new designer, developer, and content creator the four principles.

Where Section 504 fits

Section 504 of the Rehabilitation Act is a civil rights law. It bars disability discrimination in programs and activities that receive federal financial assistance, and in programs run by federal agencies. It doesn’t mention POUR, and the statute itself sets no web standard.

The technical standard comes from regulation. The U.S. Department of Health and Human Services (HHS) 2024 Section 504 rule adopts WCAG 2.1 Level AA for the web content and mobile apps of HHS funding recipients. An interim final rule in May 2026 extended the compliance dates by one year:

  • Recipients with 15 or more employees: May 11, 2027
  • Recipients with fewer than 15 employees: May 10, 2028

The extension covers only the WCAG 2.1 dates. Recipients’ other Section 504 obligations still apply, including making reasonable modifications to avoid discrimination.

Many organizations fall under more than one law. A public university, for example, may face Section 504 and ADA Title II at once. Section 504, the ADA, and Section 508 cover different organizations, and the overlap shapes your program. For what Section 504 requires on the web in detail, see the guide to Section 504 website compliance.

This content is for informational purposes only and does not constitute legal advice. WCAG is a technical standard; legal obligations vary by jurisdiction and context. Consult qualified counsel for legal guidance.

POUR principles FAQ

What does POUR stand for in accessibility?

Perceivable, Operable, Understandable, and Robust. The acronym names the four principles WCAG is organized around.

Are the POUR principles part of WCAG?

Yes. Every success criterion in WCAG 2.0, 2.1, and 2.2 falls under one of the four principles.

Are the POUR principles a legal requirement?

Not on their own. Laws and regulations point to WCAG success criteria at a stated level, such as WCAG 2.1 Level AA in the HHS Section 504 rule. The principles are how those criteria are organized.

What makes a site operable?

A site is operable when users can work every control and reach all content with the input they use, including a keyboard alone. Users also get enough time to finish tasks, aren’t exposed to flashing content that could trigger seizures, and can find their way around.

Which POUR principle covers captions and alt text?

Perceivable. Text alternatives (guideline 1.1) and captions (guideline 1.2) make non-text content available to users who can’t see or hear it.

Did WCAG 2.2 change the POUR principles?

No. WCAG 2.2 keeps the same four principles and 13 guidelines. It adds nine success criteria, such as focus not obscured and target size, and removes 4.1.1 Parsing.

Make accessibility a habit

Enterprises succeed when they move from one-off fixes to steady governance. POUR makes that practical: four principles every team can learn, mapped to criteria every team can test. Pair automated tools with regular manual checks and use clear checklists to hold teams accountable. This keeps your conformance from slipping as you add new content or features.