POUR: The Four Pillars of Web Accessibility

WHY IT EXISTS: The Web Content Accessibility Guidelines (WCAG) are extensive and complex. The POUR principles were created to organize these guidelines into a simple, memorable framework. Instead of memorizing hundreds of rules, developers can group them into four fundamental human needs, making it easier to build inclusive products from the start.

THE MENTAL MODEL: Think of POUR as a user-centric checklist for your entire product. It shifts the focus from technical compliance to four core questions about the user experience. Can they perceive it with their senses? Can they operate it with their tools? Can they understand it? And will it work reliably with their technology, now and in the future?

HOW IT WORKS: POUR is an acronym for the four principles of accessibility. PERCEIVABLE: Information and UI components must be presentable to users in ways they can perceive. This means providing text alternatives for images (for screen readers), captions for videos (for hearing impairments), and ensuring content is distinguishable (e.g., not relying on color alone to convey information). OPERABLE: Users must be able to operate the interface. The interface cannot require an interaction that a user cannot perform. This includes full keyboard accessibility, giving users enough time to use content, and avoiding content that could cause seizures. UNDERSTANDABLE: Information and the operation of the user interface must be understandable. This involves making text readable, making web pages appear and operate in predictable ways, and helping users avoid and correct mistakes with clear error messages and instructions. ROBUST: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. This primarily means using clean, standard-compliant code (like valid HTML) so that screen readers and other tools can parse it correctly.

WHEN TO USE IT: Use POUR as the guiding framework for all UI/UX design and development, from initial wireframes to final code reviews. It is the foundation for any accessibility audit and for building products that comply with legal and ethical standards.

WHEN NOT TO USE IT: POUR is a set of principles, not a replacement for the specific WCAG success criteria. Do not use it as a literal, exhaustive checklist and assume you are fully compliant. It is a high-level guide; you must still test against the detailed guidelines that fall under each principle. It's the map, not the territory.

ONE CANONICAL EXAMPLE: Consider a simple form 'Submit' button. PERCEIVABLE: It must have sufficient color contrast against its background. For a non-sighted user, its existence is perceived via a screen reader announcing its text label. OPERABLE: It must be focusable and activatable using the Enter or Space key, not just a mouse click. Its clickable target area should be large enough for users with motor impairments. UNDERSTANDABLE: The label 'Submit' clearly communicates its function. Its placement at the end of a form is predictable. ROBUST: The HTML <button>Submit</button> has a clear name ('Submit') and role ('button') that assistive technologies can reliably interpret and announce to the user.