Building a POUR Website: the 4 Principles of Accessibility

The Web Content Accessibility Guidelines (WCAG) — currently WCAG 2.2, published October 5, 2023 — are organized around four foundational principles. Together they spell out as POUR: Perceivable, Operable, Understandable, Robust. If a website fails any one of these, users with disabilities will run into barriers. Build for all four, and your site works for the broadest possible audience — including the roughly 1 in 4 US adults living with some form of disability (CDC, 2023).

POUR isn’t just a mnemonic. The 50+ specific success criteria in WCAG 2.2 Level AA all map to one of these four principles, and the principles themselves are referenced by virtually every major accessibility law in the world: the US ADA, the DOJ’s April 2024 Title II Final Rule (with deadlines extended by the April 20, 2026 Interim Final Rule to April 26, 2027 / April 26, 2028), the European Accessibility Act (enforced since June 28, 2025), Canada’s Accessible Canada Act, Section 508, and dozens of national implementations. Get POUR right and you’re meeting nearly every legal accessibility requirement on the planet.

The 4 principles of accessibility

1. Perceivable

Users must be able to perceive the information and interface — through sight, sound, or touch. Content can’t be invisible to one or more of the user’s senses, and the interface should adapt to whatever sensory channel the user relies on. Perceivable also means content is parseable by assistive technologies (screen readers, braille displays, captioning systems) and by automated agents like search engine crawlers.

Practical implementations:

• Text alternatives for non-text content (WCAG 1.1.1). Every meaningful image needs alt text. Decorative images use empty alt="" so screen readers skip them. Complex images (charts, infographics) need short alt text plus a longer description in surrounding context. Sound effects need text labels for what they communicate.
• Captions and transcripts for time-based media (WCAG 1.2.x). Captions for pre-recorded video with audio (1.2.2 Level A); captions for live video (1.2.4 Level AA); audio descriptions where visual content adds meaning not in the audio (1.2.5 Level AA); transcripts for audio-only content. The modern web standard for closed captions is WebVTT; the older SMIL format is still permitted but rarely used in new content.
• Adaptable content (WCAG 1.3.x). Reading order in source code matches visual order. Content adapts to user preferences for layout, color, and presentation. Information conveyed by formatting (bold for emphasis, color for status) is also conveyed in another way.
• Distinguishable content (WCAG 1.4.x). Sufficient color contrast: 4.5:1 for normal text, 3:1 for large text (1.4.3 Level AA). UI components and graphical objects have 3:1 contrast (1.4.11 Non-text Contrast). Color is never the only signal for information (1.4.1 Use of Color). Text resizes to 200% without loss of functionality (1.4.4); content reflows at 400% zoom on a 320-pixel viewport (1.4.10 Reflow).

2. Operable

Users must be able to operate the interface. Every function — navigation, forms, controls, menus — has to work via the input methods users actually have. For most users, that means keyboard, mouse, touch, voice, or assistive devices like switch access, eye-tracking, and screen reader keyboard combinations.

Practical implementations:

• Keyboard accessibility (WCAG 2.1.x). Every interactive element reachable and operable via keyboard alone — Tab, Shift+Tab, Enter, Space, Arrow keys, Esc. No keyboard traps (2.1.2). Custom keyboard shortcuts can be turned off or remapped (2.1.4).
• Adequate time (WCAG 2.2.x). Session timeouts can be extended or disabled (2.2.1). Moving, blinking, or auto-updating content can be paused, stopped, or hidden (2.2.2).
• No seizure-triggering content (WCAG 2.3.1). Nothing flashes more than three times per second within general flash thresholds. Respect the CSS prefers-reduced-motion media feature for users who opt out of animation.
• Navigable structure (WCAG 2.4.x). Skip links to main content (2.4.1 Bypass Blocks). Descriptive page titles (2.4.2). Logical focus order (2.4.3). Link text describing destination (2.4.4). Multiple ways to find pages (2.4.5). Descriptive headings and labels (2.4.6). Visible focus indicator (2.4.7). WCAG 2.2 added 2.4.11 Focus Not Obscured — the focused element can’t be hidden behind sticky headers, cookie banners, or other persistent overlays.
• Input modalities (WCAG 2.5.x). All functionality usable with single-pointer input (2.5.1 Pointer Gestures — no required pinch/swipe gestures without alternative). Cancel-able pointer activations (2.5.2). Visible labels match accessible names (2.5.3). Motion-based input has alternatives (2.5.4). WCAG 2.2 added 2.5.8 Target Size (Minimum) — interactive targets must be at least 24×24 CSS pixels (with limited exceptions).

3. Understandable

Information and interface must be understandable — readable, predictable, and forgiving. Users should be able to read the content, predict how the interface behaves, and recover easily when something goes wrong.

Practical implementations:

• Readable (WCAG 3.1.x). Identify the page’s primary language with lang attribute on the HTML element (3.1.1). Identify language changes within content (3.1.2). For unusual words, abbreviations, or jargon, provide definitions on first use or link to a glossary (3.1.3, 3.1.4). Plain language helps users with cognitive disabilities, non-native speakers, and everyone scanning quickly. Aim for an 8th–10th-grade reading level for general audiences.
• Predictable (WCAG 3.2.x). Components don’t change context unexpectedly when they receive focus (3.2.1) or input (3.2.2). Navigation appears consistently across pages (3.2.3). Components that perform the same function look alike across the site (3.2.4). Changes of context only happen at user request (3.2.5). WCAG 2.2 added 3.2.6 Consistent Help — help mechanisms (contact info, human help) must appear in the same relative position on every page that has them.
• Input assistance (WCAG 3.3.x). Form fields have programmatic labels (3.3.2). Errors are identified clearly with text describing the problem and how to fix it (3.3.1, 3.3.3). For legal, financial, and data-modifying transactions, errors are reversible, checked for accuracy, or confirmed before submission (3.3.4). WCAG 2.2 added 3.3.7 Redundant Entry — information previously entered in the same session must not require re-entry; auto-fill or carry-forward is required. WCAG 2.2 added 3.3.8 Accessible Authentication — login flows can’t require a cognitive test that assistive technology can’t pass; password managers, biometrics, and similar alternatives must work.

4. Robust

Content must be robust enough to work with current and future assistive technologies — and with whatever new technologies emerge over time. The robust principle is the smallest in WCAG 2.2 (just two success criteria) but the most foundational: it’s the requirement that your code parses cleanly and exposes its semantics so that screen readers, voice control, switch access, and AI agents can all interact with it.

Practical implementations:

• Compatible (WCAG 4.1.x). Use semantic HTML — real <button>, <a>, <form>, <label>, <nav>, <main>, <article>, headings in correct hierarchy. Custom widgets need correct ARIA roles, states, and properties so screen readers know what they are and how to interact with them (4.1.2 Name, Role, Value). Status messages get announced via aria-live or appropriate role (4.1.3).
• Use ARIA sparingly and correctly. Native HTML semantics are stronger than ARIA — incorrect ARIA is worse than no ARIA. The W3C’s First Rule of ARIA: don’t use ARIA when a native HTML element exists that does the same job.
• Test with multiple assistive technologies. Different screen readers (NVDA, JAWS, VoiceOver, TalkBack) interpret markup differently. Robust content works across all of them.
• Future-proof with standards. Modern frameworks (Next.js, Nuxt, Astro, SvelteKit, Remix) have strong accessibility primitives built in. Use them. Avoid client-side-only rendering for content that needs to be assistive-tech-accessible at first paint.

How POUR maps to WCAG conformance levels

WCAG defines three conformance levels:

• Level A — minimum conformance. Many criteria are foundational requirements like keyboard accessibility, alt text, captions, and navigable structure.
• Level AA — the standard target referenced by virtually every major accessibility law. Includes everything in Level A plus contrast requirements, reflow at 400% zoom, target size minimums, accessible authentication, and consistent help.
• Level AAA — enhanced conformance. Includes sign language interpretation, audio descriptions for all video, very strict contrast (7:1), and similar high-touch requirements. Aspirational for most sites.

Each WCAG success criterion is assigned to one level. Building to Level AA means meeting all Level A and Level AA criteria across all four POUR principles. WCAG 2.2 AA is the practical target for compliance with the DOJ Title II Rule, the EAA, EN 301 549, ACA, and most other current frameworks.

Common POUR mistakes

• Perceivable failures: missing alt text on content images, color-only signaling (red for errors with no icon or text), insufficient contrast, hard-coded colors that break in Forced Colors Mode, video without captions.
• Operable failures: hover-only menus that don’t work via keyboard, click handlers without keyboard equivalent, focus indicators removed by CSS, sticky headers that obscure focused elements (WCAG 2.2 specifically targets this), tap targets smaller than 24×24 CSS pixels.
• Understandable failures: form errors that don’t explain how to fix them, navigation that changes between pages, CAPTCHA that screen readers can’t solve, unannounced timeouts, jargon without definitions.
• Robust failures: <div>-based buttons without proper ARIA, missing form labels, custom widgets that don’t expose state to screen readers, dynamic content updates without aria-live, client-side-only rendering of critical content.

Testing for POUR

Each principle responds to specific tests, and a layered testing approach catches the broadest range of issues:

• Perceivable: Run automated contrast checking (axe DevTools, WAVE, Lighthouse). Disable images and verify alt text appears. Disable CSS to check semantic structure. Test in Forced Colors Mode (Windows 11 Contrast themes or DevTools emulation).
• Operable: Unplug the mouse and verify every function works via keyboard. Test focus visibility throughout. Zoom to 200% and 400% and verify content remains usable.
• Understandable: Use a screen reader (NVDA, VoiceOver, TalkBack) on critical workflows. Try to break form validation with invalid input and check that errors are clear. Test with realistic users — including non-native speakers and users with cognitive disabilities where possible.
• Robust: Run automated WCAG validators in CI (axe, Pa11y, Lighthouse). Validate HTML markup. Test with multiple browsers and screen readers — output should be consistent.

Automated tools catch 30–50% of issues. Manual testing catches the rest. See our manual accessibility testing guide for the practical methods, and our website accessibility best practices for the broader implementation playbook.

Frequently asked questions

Why was POUR chosen as the framework?

The W3C’s Web Accessibility Initiative organized WCAG 2.0 (published December 2008) around the four POUR principles to provide a memorable, comprehensive structure that captures every major user-facing accessibility concern. The principles are intentionally broad — they apply across content types, technologies, and user needs — while the underlying success criteria are specific and testable. POUR has carried through unchanged into WCAG 2.1 (2018) and WCAG 2.2 (2023).

Are all four POUR principles equally important?

For compliance: yes — failing any one means failing WCAG conformance. For impact: it depends on the content. Pure-text sites lean heavily on Perceivable and Understandable. Highly interactive applications stress Operable. Systems with complex assistive-tech requirements (high-stakes regulated industries) emphasize Robust. Plan for all four, but apply effort proportionate to where your content lives.

What’s new in WCAG 2.2 vs 2.1?

Nine new success criteria, distributed across the principles: Focus Not Obscured (Minimum and Enhanced), Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, Accessible Authentication (Minimum and Enhanced). All additions, not changes — so meeting WCAG 2.2 AA automatically meets WCAG 2.1 AA. Note that one criterion from WCAG 2.1 (4.1.1 Parsing) was deprecated in 2.2 because modern HTML parsers handle malformed markup gracefully.

How do POUR and the legal frameworks map together?

Most accessibility laws don’t directly reference POUR — they reference WCAG (typically 2.0, 2.1, or 2.2 at Level AA). Since WCAG is organized around POUR, conforming to the legal target inherently satisfies all four principles. The DOJ Title II Rule references WCAG 2.1 AA; the EAA’s harmonized standard EN 301 549 references WCAG 2.1; Section 508 references WCAG 2.0; ACA’s CAN/ASC-EN 301 549 references WCAG 2.1.

Should we target Level AA or AAA?

Level AA is the practical compliance target — required by virtually every major law and achievable with reasonable engineering effort. Level AAA is aspirational for most sites; some AAA criteria (like 7:1 contrast or sign-language interpretation for all video) impose major design constraints. Target AA universally, then add AAA criteria where they fit your content type and user base — for example, sites serving users with low vision specifically might target the 7:1 contrast ratio.

Is POUR going away with WCAG 3.0?

WCAG 3.0 is in active development by the W3C. The early drafts use a different conformance model (outcome-based rather than success-criterion-based) and reorganize the underlying guidelines. Whether the four-principle POUR framing survives unchanged is uncertain. Either way, WCAG 3.0 is years from being the operative legal standard — for 2026 compliance decisions, WCAG 2.1 or 2.2 AA (and POUR) remain correct.

Bottom line

POUR is the conceptual core of web accessibility — a small set of principles that organize the entire WCAG framework and apply across every content type, technology, and user need. Build for Perceivable, Operable, Understandable, Robust from the start, target WCAG 2.2 Level AA, test with both automated and manual methods, and you’ll meet nearly every legal accessibility requirement worldwide while serving the 1-in-4 users with disabilities your site would otherwise exclude. POUR isn’t a checklist to satisfy — it’s the foundational thinking that makes all subsequent accessibility decisions easier.