POUR in Accessibility

What is POUR in accessibility?

POUR stands for Perceivable, Operable, Understandable and Robust, the four principles that organise the Web Content Accessibility Guidelines. Every WCAG success criterion sits under one of them, so POUR is a quick way to ask what is going wrong when someone cannot use a page. See WCAG for the full standard.

WCAG 2.2 has four principles and 13 guidelines. The principles are the top level, the guidelines say what to achieve, and the success criteria are the testable rules.

The four POUR principles

Perceivable

Information and interface components must be presentable in ways users can perceive. That covers text alternatives for images, captions for audio and video, content that keeps its meaning when its layout changes, and enough contrast and distinguishable colour. Guidelines 1.1 to 1.4. See accessible images.

Operable

Components and navigation must be operable. Everything has to work from a keyboard, users need enough time, nothing should flash in a way that can trigger seizures, pages need clear ways to navigate, and controls must work with more than a precise mouse click. Guidelines 2.1 to 2.5.

Understandable

Content and interface behavior must be understandable. The page language is set, navigation behaves predictably, and forms label their fields and explain errors in text. Guidelines 3.1 to 3.3. See accessible forms.

Robust

Content must be robust enough for browsers and assistive technologies to interpret reliably. In practice that means controls expose a name, role and state that a screen reader can read, using native HTML first and ARIA where HTML has no equivalent. Guideline 4.1, the only one under this principle.

Example: one login form, four failures

• Perceivable: the logo image has no alt text, so a screen reader announces a file name.
• Operable: the "Sign in" button is a styled div that only responds to a mouse click, so keyboard users cannot submit.
• Understandable: a failed login shows "Invalid input" without saying which field is wrong.
• Robust: a custom language dropdown built from unlabelled div elements exposes no role or name to assistive technology.

How to use POUR

• Triage audit findings. Tag each issue with its principle to see whether your problems cluster, for example mostly Operable issues from custom widgets.
• Structure reports. An Accessibility Conformance Report follows the same principles, criterion by criterion.
• Review designs early. Ask the four questions before building: can it be perceived, operated, understood and interpreted by assistive technology?

Common mistakes

• Treating POUR as a four-item checklist. It is a way to group the criteria, not a substitute for testing them.
• Reading a perfect Lighthouse score as "done". Automated checks cover only part of WCAG and leave checks like tab order and trapped focus to a person. See the roundup of accessibility testing tools.
• Reducing Robust to "valid HTML". Robust is about names, roles and states that assistive technology can use. WCAG 2.2 removed the old 4.1.1 Parsing criterion.

To keep an eye on the automated part over time, LoadFocus page speed monitoring runs scheduled Lighthouse audits and records the Accessibility category alongside Performance, so a drop after a release is visible. It is a regression alarm, not a conformance check.

FAQ: POUR

What does POUR stand for?

Perceivable, Operable, Understandable and Robust.

Who defined the POUR principles?

They are the four principles of WCAG, published by the W3C Web Accessibility Initiative.

Is POUR the same as WCAG?

No. POUR is the top level of WCAG's structure. Beneath it sit the guidelines and the success criteria at levels A, AA and AAA that you actually test against.

Does a perfect automated score mean a site meets POUR?

No. Automated tools check only part of the success criteria. Keyboard use, focus handling and the clarity of error messages need manual testing.