POUR Principles & the WCAG Framework

The full lesson

Accessibility without a framework is just a list of fixes you apply after the product ships. WCAG — the Web Content Accessibility Guidelines — gives that work a spine. It organizes every criterion, from color contrast to keyboard focus, from caption timing to session timeout, around four core principles.

Understanding those principles separates practitioners who can reason about accessibility from those who can only copy-paste criteria.

WCAG 2.2 is the current standard as of 2026. It introduced four new criteria, removed one outdated criterion, and remains the legal baseline in the EU (EAA, EN 301 549), the US (Section 508, ADA), and most other jurisdictions. WCAG 3.0 is in draft but has not been adopted — treat it as a useful signal, not a target.

What POUR Actually Is

POUR is the acronym for the four principles at the very top of WCAG’s structure. Every success criterion — all 78 of them in WCAG 2.2 — belongs to exactly one of these four buckets.

These principles are not just filing categories. They expose the failure mode.

A contrast failure is a Perceivable problem: the information exists, but the user cannot detect it. A missing keyboard handler is an Operable problem: the user understands the interface but cannot act on it. Confusing these leads to wrong fixes — for example, adding ARIA labels to something a user literally cannot see.

The Three-Tier Structure: Principles, Guidelines, Success Criteria

Below the four principles sit 13 guidelines. These give stable, aspirational direction. Below those sit success criteria — testable, pass/fail statements. Each criterion gets a conformance level:

• Level A — the minimum floor. Failures here are typically blocking for some users.
• Level AA — the widely adopted legal and commercial baseline. When someone says “WCAG compliant,” they almost always mean this level.
• Level AAA — enhanced and aspirational in specific contexts (for example, transcripts for all pre-recorded audio). Most organizations do not claim full AAA.

A conformance claim requires every page to meet every criterion at the claimed level, with no exceptions. If even one page fails a single Level A criterion, the entire site cannot claim Level A conformance. This is often misunderstood during audit conversations.

What Changed in WCAG 2.2

WCAG 2.2 added four success criteria and removed one. Knowing the additions is table-stakes in any modern accessibility conversation.

New in 2.2:

• 2.4.11 Focus Not Obscured (Minimum, AA) — the focused element must not be entirely hidden by sticky headers, cookie banners, or chat widgets. Being partially obscured is acceptable at AA; being fully visible is required at AAA (2.4.12).
• 2.4.12 Focus Not Obscured (Enhanced, AAA) — the focused component must be fully visible, not just partially.
• 2.5.7 Dragging Movements (AA) — any functionality that uses drag-and-drop must also have a single-pointer (tap or click) alternative. This covers custom sliders, sortable lists, and map interactions.
• 2.5.8 Target Size (Minimum, AA) — interactive targets must be at least 24x24 CSS pixels, or have enough spacing so that the 24x24 area does not overlap adjacent targets. This is a minimum floor, not the 44x44 recommendation from Apple and Google’s HIG guidelines.
• 3.2.6 Consistent Help (A) — if a help mechanism (chat, phone number, FAQ link) appears on multiple pages, it must appear in the same relative position on each page.
• 3.3.7 Redundant Entry (A) — information a user already provided in a session must not be asked for again unless it is essential (like a password confirmation field). Pre-filling known data satisfies this criterion.
• 3.3.8 Accessible Authentication (Minimum, AA) — authentication steps cannot require cognitive function tests such as puzzles, memorizing codes, or transcribing distorted text, unless an alternative is provided. Standard CAPTCHA fails this criterion without an audio or other alternative.

Removed in 2.2:

• 4.1.1 Parsing — this criterion required well-formed HTML with unique IDs. Modern browsers handle malformed HTML gracefully enough that the criterion was generating false positives without protecting users. It is now obsolete. Remove it from your checklists.

How to Apply POUR in Practice

Understanding the principle behind a criterion changes how you fix it — and how you prevent regressions.

Perceivable: Information must reach the user’s senses

The most common Perceivable failures are low contrast and missing text alternatives. But Perceivable also covers:

• Reflow (1.4.10): content must not require horizontal scrolling at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport). Test this at every major release, not just on the initial build.
• Text spacing (1.4.12): layout cannot break when line height, letter spacing, and word spacing are overridden by the user. Use relative units (em or rem) for all spacing — never px.
• Contrast: WCAG 2.2 AA requires a ratio of 4.5:1 for normal text and 3:1 for large text (18pt or larger, or 14pt bold and larger) and UI components. The Advanced Perceptual Contrast Algorithm (APCA) offers a more perceptually accurate lens — useful for evaluating edge cases — but it is not part of any adopted WCAG version. Do not apply APCA ratios as if they were WCAG requirements.

Operable: Users must be able to navigate and interact

Operable failures block entire flows for keyboard-only users, switch access users, and voice navigation users. Key areas:

• Full keyboard operability (2.1.1): every interactive element must be reachable and activatable by keyboard alone. No JavaScript handlers that only respond to mousedown.
• No keyboard trap (2.1.2): focus must be movable out of any component using standard keys. Modal dialogs require managed focus trapping using the inert attribute on background content — not tabindex hacks — so that Tab cycles only within the modal while it is open.
• Focus visible (2.4.7 at AA; 2.4.11 at AA in 2.2): the focused element must have a visible indicator. Setting outline: none without a custom replacement is a failure. Custom focus indicators must meet a 3:1 contrast ratio against adjacent colors.
• Timing adjustable (2.2.1): if a session expires, users must be warned and given 20 or more minutes to extend it. Do not auto-log out without a warning.

Understandable: Content and behavior must be predictable

Understandable failures often show up in forms. The criteria here require:

• Labels on every input (1.3.1 / 3.3.2): use visible, persistent labels placed above fields. Placeholder text is not a label — it disappears on focus, fails users with cognitive disabilities, and fails screen reader users when the field already has content. Floating labels are only marginally better; they hide the label on focus, which breaks cognitive continuity.
• Error identification (3.3.1): errors must identify the field in text (not color alone) and describe the specific problem. “Invalid input” fails. “Date must be in MM/DD/YYYY format” passes.
• Error suggestion (3.3.3, AA): when an error is detected and a fix is known, suggest the correction. “Email address is missing an @ symbol” is useful. “Email is invalid” is not.
• Consistent navigation (3.2.3): navigation components that repeat across pages must appear in the same order on each page.
• Redundant Entry (3.3.7, new in 2.2): if a user enters their shipping address, do not ask for it again on the billing page without offering a “same as shipping” option.

The Understandable principle maps directly to cognitive accessibility — the domain addressed by the W3C’s Cognitive Accessibility Task Force (COGA). Designing for COGA users, who may have differences in memory, attention, learning, or executive function, often means writing clearer labels and instructions. That clarity benefits every user.

Robust: Content must be interpreted correctly by assistive technology

Robust is the most technical of the four principles and the one designers most often hand off entirely to engineers. That is a mistake, because Robust failures start in component design.

• Name, Role, Value (4.1.2): every UI component must expose its accessible name, its role (button, checkbox, dialog), and its current state (expanded, checked, selected) to the accessibility tree. You do this through semantic HTML, or through ARIA when native semantics are not enough.
• Status Messages (4.1.3): messages that appear without moving focus — toast notifications, form submission confirmations, live search result counts — must be programmatically determinable via aria-live regions. This ensures screen reader users hear them without needing to shift focus.

A custom component (a dropdown, a date picker, a tag input) built from div and span elements without ARIA attributes will typically fail 4.1.2 for every state it can enter. The ARIA Authoring Practices Guide (APG) provides patterns for common components, but semantic HTML almost always produces more robust results with less maintenance burden.

Conformance vs. Accessibility

WCAG conformance is a legal and contractual concept. Actual accessibility is broader.

A product can pass every WCAG 2.2 AA criterion and still be painful to use with a screen reader, cognitively overwhelming, or inaccessible to users with less common disabilities. The criteria are a floor, not a ceiling.

The practical implication: pass/fail audits must be paired with qualitative usability testing with disabled users. An axe DevTools scan that finds zero violations is necessary but not sufficient. At minimum, test keyboard navigation manually, use a screen reader on primary user flows, and test at 200% browser zoom.

WCAG in the Modern Stack

A few intersections between WCAG requirements and current front-end practice are worth making explicit:

• Fluid typography with clamp() and rem units satisfies 1.4.4 (Resize Text) and 1.4.12 (Text Spacing), where px-fixed sizes fail at 200% zoom.
• prefers-reduced-motion media query is required by 2.3.3 (Animation from Interactions, AAA) and is considered a reasonable AA-level expectation by most accessibility practitioners, even though it sits at AAA in the spec.
• Design tokens using semantic names (for example, color.text.default or color.text.disabled) make contrast management tractable at scale — but only if the token values are validated against WCAG contrast ratios at build time. Raw primitive tokens like blue-500, with no semantic layer, offer no protection against contrast failures in dark mode or on colored backgrounds.
• View Transitions (CSS @view-transition) must respect prefers-reduced-motion. Full-page crossfade transitions can trigger vestibular symptoms for users with motion sensitivity.