WCAG 2.2 — POUR Principles

The 4 foundational principles of web accessibility — Perceivable, Operable, Understandable, Robust — and the 13 guidelines that make them actionable.

Try the WCAG principles

The Web Content Accessibility Guidelines (WCAG) are the global standard for accessible digital products, maintained by the W3C Web Accessibility Initiative. WCAG 2.2 was ratified in October 2023 and is the version referenced by the European Accessibility Act, which becomes mandatory for in-scope products in the EU on June 28, 2025.

The full WCAG 2.2 spec contains 78 testable success criteria across three conformance levels (A, AA, AAA). Most teams target WCAG 2.2 AA, which is the legal requirement in most jurisdictions. The 4 principles and 13 guidelines below are the conceptual scaffold that holds those criteria together.

Use POUR as a structured lens for accessibility review: walk a page through Perceivable, then Operable, then Understandable, then Robust. Most accessibility issues fall under just two or three guidelines on a typical website, and naming the principle makes the fix easier to scope.

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. Anything a sighted, hearing user gets from the page must have an equivalent for users on assistive technology — captions for video, alt text for images, labels for icons, semantic structure for screen readers.

1.1 Text Alternatives

Provide text alternatives for any non-text content so it can be changed into other forms people need — large print, braille, speech, symbols, or simpler language. Decorative images can have empty alt; meaningful images need descriptive alt; complex images may need a longer description.

1.2 Time-based Media

Provide alternatives for time-based media — captions for video, transcripts for audio, audio descriptions for video where visual information is essential. Live media has its own criteria, including live captions for prerecorded synchronized media at AA.

1.3 Adaptable

Create content that can be presented in different ways without losing information or structure. Use semantic HTML (headings, lists, landmarks) so screen readers can navigate it; don't rely on visual position alone to communicate relationships; support both portrait and landscape orientation.

1.4 Distinguishable

Make it easier for users to see and hear content. Maintain a 4.5:1 contrast ratio for normal text (3:1 for large), don't use color as the only way to convey meaning, allow text resizing up to 200% without loss of functionality, and avoid auto-playing audio.

2. Operable

User interface components and navigation must be operable. Every action available with a mouse must also work with a keyboard, with sufficient time to complete it, without triggering seizures, and with clear navigation cues for users who can't see the layout.

2.1 Keyboard Accessible

All functionality must be available from a keyboard. There should be no keyboard traps where focus enters a component but can't leave it. Visible focus indicators are required so keyboard users can see where they are.

2.2 Enough Time

Provide users enough time to read and use content. If there's a time limit, allow users to turn it off, adjust it, or extend it — except where the limit is essential (a real-time auction, for example). Avoid moving, blinking, or auto-updating content that can't be paused.

2.3 Seizures and Physical Reactions

Don't design content in ways that are known to cause seizures or physical reactions. Avoid flashing more than three times per second above certain thresholds. Respect the user's reduced-motion preference for animations.

2.4 Navigable

Provide ways to help users navigate, find content, and determine where they are. Skip links, descriptive page titles, meaningful link text, multiple ways to reach a page, and consistent focus order all support navigability.

2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard. Touch targets should be at least 24×24 CSS pixels at AA (44×44 at AAA), drag operations should have a single-pointer alternative, and gesture-based actions should be undoable.

3. Understandable

Information and the operation of the user interface must be understandable. Use clear language, predictable patterns, and proactive error handling so users can figure out what's happening and what to do next.

3.1 Readable

Make text content readable and understandable. Declare the page language so screen readers pronounce content correctly. Define unusual words, abbreviations, and idioms; aim for content that doesn't require more than a lower secondary education reading level.

3.2 Predictable

Make web pages appear and operate in predictable ways. Don't change context on focus or input without warning, keep navigation consistent across pages, and use consistent labels for components that do the same thing. New in WCAG 2.2: provide a consistent help mechanism across the site.

3.3 Input Assistance

Help users avoid and correct mistakes. Identify required fields and errors clearly, provide suggestions for fixes, and require confirmation for legal or financial actions. New in WCAG 2.2: don't require users to re-enter information they've already provided in the same session, and don't rely on cognitive function tests like puzzles for authentication.

4. Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. As technologies and assistive tools evolve, content should remain accessible.

4.1 Compatible

Maximize compatibility with current and future user agents, including assistive technologies. Use valid markup with correct nesting, expose name/role/value for all UI components programmatically (typically via ARIA when native HTML can't), and provide status messages that screen readers can announce without taking focus.

5. Conformance

Conformance is the formal framework that defines what it means for a page or product to "meet WCAG." The four POUR principles describe how to design accessibly; conformance defines how to claim — and how to verify — that you've actually done so. It covers the conformance level you're targeting, the requirements that must be met for any claim to be valid, and the way claims are documented.

5.1 Conformance Levels

WCAG defines three levels of conformance: A (minimum), AA (industry standard, the legal target in most jurisdictions), and AAA (highest, not recommended as a blanket policy because not all content can meet it). Most teams aim for WCAG 2.2 AA — that's what the European Accessibility Act, Section 508, and most national laws reference.

5.2 Conformance Requirements

A page conforms only if all five requirements are met: it satisfies every Success Criterion at the chosen level, conformance applies to full pages (not partial), it covers complete processes end-to-end (e.g. checkout from cart to confirmation), it uses only accessibility-supported ways of using technologies, and any inaccessible content does not interfere with the rest of the page.

5.3 Conformance Claims

Conformance claims are optional, but if you make one it must include the date, the WCAG version and conformance level, the technologies relied on, and a precise list of the pages or processes covered. Partial-conformance statements exist for cases where third-party or user-generated content can't be fully controlled.

Learn more