POUR Accessibility Principles: Understanding Perceivable, Operable, Understandable and Robust

What are the POUR Accessibility Principles?

POUR Accessibility Principles summarise how content should behave so people with disabilities can use it. POUR stands for Perceivable, Operable, Understandable and Robust. These four headings form the foundation of the Web Content Accessibility Guidelines, including WCAG 2.1 and WCAG 2.2.

Why POUR matters

POUR is a decision framework. It helps teams find where a web page fails users and what kind of fix it needs. Each principle maps to specific WCAG success criteria. That makes testing and reporting clearer.

Perceivable: make content available to the senses

Perceivable means users must be able to sense the information. If content relies only on sight or hearing, provide alternatives.

Key requirements

• Text alternatives for non-text content such as images. (WCAG 1.1.1)
• Captions or transcripts for audio and video. (WCAG 1.2.x)
• Good contrast and resizable text. (WCAG 1.4.x)
• Content must be adaptable so it works when structure changes. (WCAG 1.3.1)

Operable: users can interact with controls and navigation

Operable means people can use the interface. That includes moving focus, activating controls and avoiding traps.

Key requirements

• Full keyboard access for all interactive elements. (WCAG 2.1.1)
• Visible focus state when tabbing. (WCAG 2.4.7)
• Enough time to complete tasks or a way to pause timeouts. (WCAG 2.2.x)
• Avoid keyboard traps and ensure predictable navigation.

Understandable: content and controls are clear

Understandable means the user can read, predict and complete tasks. Avoid confusing language and unpredictable behaviour.

Key requirements

• Specify the language of the page and parts of content. (WCAG 3.1.1)
• Labels and instructions for form fields. (WCAG 3.3.2)
• Clear error messages and suggestions to fix input mistakes. (WCAG 3.3.x)

Robust: content works with current and future tools

Robust means content must be parseable by user agents and assistive technologies. Use valid markup and expose names, roles and values.

Key requirements

• Use semantic HTML so assistive tech can interpret elements. (WCAG 4.1.1)
• Ensure accessible names, roles and values for widgets. (WCAG 4.1.2)
• Avoid relying on unsupported ARIA patterns.

POUR mapped to WCAG: quick reference

POUR principle	Example WCAG success criteria	Practical example
Perceivable	1.1.1, 1.2.x, 1.4.3, 1.3.1	Alt text on images; captions on videos; 4.5:1 text contrast for large text
Operable	2.1.1, 2.4.7, 2.2.x	Keyboard focus, skip links, pause controls for timed content
Understandable	3.1.1, 3.3.1, 3.3.2	Page language declared, clear form labels, helpful error messages
Robust	4.1.1, 4.1.2	Valid HTML, ARIA name and role used correctly

Common mistakes teams make under each principle

• Perceivable: decorative images given meaningful alt text or important images left without alt text.
• Operable: custom controls built without keyboard support or focus styles removed by CSS.
• Understandable: jargon in labels or error messages that offer no fix steps.
• Robust: incorrect ARIA attributes that conflict with native HTML roles.

Practical step-by-step: fix an inaccessible form (real-world)

This example follows POUR and shows common fixes for a form where screen reader users and keyboard users struggle.

1. Perceivable: add readable labels and link labels to fields with the label element. Provide descriptive alt on illustrative images and a transcript for any video help content.
2. Operable: ensure every control is reachable by keyboard. Add a logical tab order and keep focus visible. Avoid relying only on mouse events.
3. Understandable: place inline instructions near the field. Use aria-describedby for extra guidance. Show clear error text and focus the first invalid field after submission.
4. Robust: use semantic input types, for example type=“email” and type=“tel”. Expose the name and role for custom widgets using WAI-ARIA correctly. Validate HTML so assistive tech can parse it.

A simple prioritisation framework for POUR issues

Use impact and frequency to set priorities. Score each issue from 1 to 5. Multiply the two scores to get a priority score. Fix high scores first.

Issue	Impact (1-5)	Frequency (1-5)	Priority score
Missing form labels	5	5	25
Low contrast headings	3	4	12
Non-functional keyboard for custom dropdown	4	3	12

POUR checklist you can use now

• Declare page language and section languages where needed.
• Provide alt text for meaningful images and empty alt for decorative images.
• Ensure captions or transcripts for pre-recorded media.
• Make every interactive element keyboard operable and show focus.
• Use clear labels, instructions and error messages with suggestions.
• Validate HTML and use ARIA only to fill gaps left by native HTML.
• Test with a screen reader and keyboard only.

Tools for testing against POUR

Automated tools find many issues, but manual checks are essential.

• Browser dev tools with Lighthouse for quick audits
• axe and WAVE for automated rule checks
• NVDA, VoiceOver and other screen readers for manual testing
• Keyboard-only testing and colour contrast checkers

How to report accessibility work using POUR

Group findings by principle so developers know the type of failure and the kind of remedy. Include the WCAG success criterion reference, reproduction steps, a suggested fix and a priority score. That makes tickets actionable.

Next steps for teams

Start with high priority issues that block core tasks. Add tests for POUR principles to your QA checklist. Then include accessibility in design reviews and sprint planning. Small, repeated improvements reduce long term cost and make the site usable for more people.

Further reading

See the WCAG documentation for the authoritative list of success criteria and levels. Also review WAI-ARIA guidance when adding roles and properties.