The four WCAG principles (POUR) — a plain-English breakdown

Every success criterion in WCAG lives under one of four principles. They are easy to memorise — POUR — but harder to apply well. Here is what each one actually means, why it exists, and where people get it wrong.

Why principles matter more than criteria

The CPACC exam tests pattern recognition, not line-number recall. If you understand why each principle exists, you can reason about any criterion under it — even one you have never seen before. The principles are the mental model; the criteria are the details.

P — Perceivable

The rule: information and user-interface components must be presentable to users in ways they can perceive.

In plain terms: if a user cannot detect that something is there — because they cannot see it, hear it, or otherwise sense it — the content does not exist for them.

What this covers:

• Text alternatives — every non-text element (images, icons, charts) needs a text equivalent so screen readers and braille displays can convey it.
• Captions and audio descriptions — video content needs captions for users who are deaf, and audio descriptions for users who are blind.
• Adaptable content — the structure of a page (headings, lists, tables) must be programmatically determinable, not just visual. A sighted user sees a heading because it is large and bold; a screen reader user needs an actual <h2> tag.
• Distinguishable content — sufficient colour contrast, resizable text, and the ability to separate foreground from background.

Common failure: an icon button with no accessible name. Sighted users see a magnifying glass and know it means “search.” A screen reader announces — nothing. The button is imperceivable.

“If you deleted every colour and image from the page and the meaning survived, you are probably meeting Perceivable.”

O — Operable

The rule: user-interface components and navigation must be operable.

In plain terms: every action a user can take must be available through every input method — not just a mouse.

What this covers:

• Keyboard accessibility — all functionality must be reachable via the keyboard alone, with no keyboard traps.
• Enough time — users must be able to pause, stop, or extend time limits. Auto-playing carousels and session timeouts are the classic offenders.
• Seizure and motion safety — no content that flashes more than three times per second, and the ability to disable motion animations.
• Navigability — clear focus order, descriptive page titles, multiple ways to find content, and visible focus indicators.
• Input modalities (added in 2.1/2.2) — pointer gestures have simple alternatives, dragging has non-dragging alternatives, and target sizes are large enough.

Common failure: a dropdown menu that opens on mouse hover and has no keyboard equivalent. A user who navigates by keyboard or switch never reaches the menu items. The interface is inoperable.

U — Understandable

The rule: information and the operation of the user interface must be understandable.

In plain terms: the user must be able to comprehend the content and predict how the interface will behave.

What this covers:

• Readable text — the language of the page is programmatically set (so screen readers pronounce it correctly), and passages in a different language are marked up accordingly.
• Predictable behaviour — receiving focus or changing a setting does not trigger unexpected actions. Navigation is consistent across pages.
• Input assistance — errors are described in text, labels are associated with fields, and suggestions are provided when possible. The user is not left guessing what went wrong or what format is expected.

Common failure: a form that silently reloads the page when the user selects a country from a dropdown — without warning. The user expected to fill in more fields, but the page changed under them. The behaviour is unpredictable, therefore not understandable.

“Operable means you can use it. Understandable means you know how to use it.”

R — Robust

The rule: content must be robust enough that it can be reliably interpreted by a wide variety of user agents, including assistive technologies.

In plain terms: the code behind the interface must play nicely with the software that reads it — browsers, screen readers, magnifiers, voice-control tools.

What this covers:

• Parsing and validity (criterion 4.1.1 was retired in WCAG 2.2 — browser parsing is now reliable enough that markup errors rarely break assistive technology, but clean markup is still best practice).
• Name, role, value — all UI components must expose their name, role, and state to the accessibility API. Custom widgets built with <div> and JavaScript must use ARIA attributes to communicate what they are and what state they are in.
• Status messages — messages like “3 results found” or “item added to cart” must be announced to assistive technology without moving focus.

Common failure: a custom toggle built as a styled <div> with a click handler. It looks like a switch, but assistive technology sees a generic container. There is no role, no state, no label. The component is not robust.

How the principles relate to each other

Principle	Protects against	Typical audience impact
Perceivable	Content that is invisible to some senses	Blind, low-vision, deaf users
Operable	Interactions locked to one input method	Motor, mobility, keyboard-only users
Understandable	Confusing or unpredictable behaviour	Cognitive, learning, language differences
Robust	Broken assistive technology interoperability	All AT users, future-proofing

The principles are not silos — a single element can fail more than one. An unlabelled custom checkbox fails both Perceivable (no name) and Robust (no role/state). But thinking in principles helps you diagnose why something fails, which matters more than memorising which criterion it violates.

What the CPACC exam expects

You should be able to:

1. Name and define all four principles from memory.
2. Sort an accessibility problem into the correct principle — “a missing alt text is a Perceivable issue, not an Operable one.”
3. Explain the difference between Operable and Understandable — the most commonly confused pair.
4. Recognise that Robust is about the technology layer, not the user-facing experience.

The flashcards on this platform drill exactly this kind of classification. If you can consistently sort problems into the right principle under time pressure, you are well prepared.