The POUR Principles: The Foundation of Web Accessibility

Every requirement in WCAG is built on four foundational principles. If you understand these principles deeply, you can often identify accessibility issues intuitively, even without memorizing individual success criteria. These four principles — Perceivable, Operable, Understandable, and Robust — define the fundamental conditions that must be met for content to be accessible.

Perceivable: Users Must Be Able to Perceive the Content

The perceivable principle addresses the most fundamental accessibility requirement: information must be available to at least one of the user's senses. If a user cannot perceive content at all, no amount of good interaction design or clean code will make it usable.

This principle drives requirements for text alternatives to non-text content, captions and transcripts for audio and video, sufficient color contrast, the ability to resize text, and the separation of information from its visual presentation.

What this looks like in practice:

A promotional banner image that announces a seasonal sale needs alt text describing the promotion, because a blind user will not see the image. A training video needs captions, because a deaf user will not hear the narration. Body text on your website needs sufficient contrast against its background, because a user with low vision may not be able to read low-contrast text. A form that uses a red border to indicate errors also needs a text message, because a color-blind user may not perceive the red color.

Common failures:

Images without alt text. Videos without captions. Insufficient color contrast. Information conveyed only through color. Content that becomes inaccessible when zoomed to 200%. Placeholder text used as the only label for form fields.

Operable: Users Must Be Able to Operate the Interface

The operable principle ensures that users can interact with all interface components and navigate through all content, regardless of how they interact with their device. A beautiful, perceivable website is useless if a user cannot click, tap, or keyboard their way to the content they need.

This principle drives requirements for keyboard accessibility, sufficient time to interact with content, avoidance of content that could cause seizures, effective navigation mechanisms, and flexible input methods.

What this looks like in practice:

A dropdown menu that opens on hover must also open on keyboard focus and be navigable with arrow keys. A session timeout on a banking site must warn the user and allow them to extend the session. A slideshow that auto-advances must have pause controls. A search filter panel must be keyboard accessible so that users who cannot use a mouse can still filter results. Interactive elements must be large enough to be tapped without accidentally hitting adjacent controls.

Common failures:

Interactive elements that only respond to mouse clicks. Dropdown menus that are inaccessible by keyboard. Focus traps in modals or widgets. Missing skip links. Time limits without extension options. Content that flashes rapidly.

Understandable: Users Must Be Able to Understand Content and Interface

The understandable principle ensures that both the information presented and the way the interface operates are comprehensible to users. Content that is perceivable and operable but incomprehensible still fails the accessibility test.

This principle drives requirements for readable content, predictable interface behavior, and input assistance that helps users avoid and correct mistakes.

What this looks like in practice:

A page written in English has the lang="en" attribute so screen readers use the correct pronunciation. Navigation menus appear in the same location and order on every page. When a user makes an error in a form, the error is identified clearly and a suggestion for correction is provided. Users are warned before actions with significant consequences, such as submitting a payment or deleting data.

Common failures:

Missing language declarations. Inconsistent navigation between pages. Form validation that identifies errors without explaining them. Automatic context changes triggered by selecting an option or entering a field. Jargon-heavy content without explanations.

Robust: Content Must Work Across Technologies

The robust principle ensures that content is built on solid technical foundations that work reliably across different browsers, devices, and assistive technologies — both current and future.

This principle drives requirements for clean, standards-compliant markup, proper use of ARIA when native HTML is insufficient, and programmatic communication of component states and values to assistive technologies.

What this looks like in practice:

A custom dropdown widget uses proper ARIA roles, states, and properties so that a screen reader announces it as a combobox, communicates whether it is expanded or collapsed, and identifies the currently selected option. A live chat indicator uses an ARIA live region so screen readers announce new messages without the user needing to navigate to the chat window. Status messages like "Item added to cart" are announced to screen readers through appropriate roles.

Common failures:

Custom widgets that lack ARIA roles and states. Status messages that are only displayed visually but not announced to screen readers. Misuse of ARIA that conflicts with native HTML semantics. Content that works in one browser but fails in another due to non-standard code.

Applying POUR as a Design Principle

The POUR principles are not just categories for organizing success criteria — they are a thinking framework. When evaluating any piece of content or functionality, ask four questions: Can all users perceive it? Can all users operate it? Can all users understand it? Will it work across all relevant technologies? If the answer to any of these questions is no, you have identified an accessibility barrier.