Map the POUR principles and WCAG 2.2 success criteria to concrete page fixes.
Why this matters
"Make it accessible" is too vague to build or test. The Web Content Accessibility Guidelines (WCAG), published by the W3C, turn it into testable requirements. Most accessibility laws and procurement rules point at WCAG, most audits report against it, and job descriptions for front-end and design roles name it. Learning to translate a WCAG criterion into a concrete page fix is a core skill.
How WCAG is organised
WCAG has four layers:
- Principles (POUR): content must be Perceivable, Operable, Understandable and Robust.
- Guidelines: 13 goals under the principles, such as 1.4 Distinguishable or 2.1 Keyboard Accessible.
- Success criteria: the testable rules, numbered like
1.4.3 Contrast (Minimum). Each has a level. - Techniques and Understanding documents: W3C's explanations of intent and known ways to pass or fail.
Levels are A (minimum), AA (the usual target) and AAA (enhanced, not expected site-wide). When a contract or law says "WCAG 2.2 AA", it means every A and AA criterion.
Versions. WCAG 2.0 (2008), 2.1 (2018) and 2.2 (October 2023) are backwards compatible: a page that meets 2.2 also meets 2.1 and 2.0, with one exception. 2.2 removed 4.1.1 Parsing as obsolete. WCAG 3 is a separate, early-stage draft and is not a current standard. Checked on 2026-10-23: see WCAG 2 Overview.
POUR mapped to fixes
| Principle | Ask yourself | Example criteria (level) | Typical fix |
|---|---|---|---|
| Perceivable | Can everyone get the information through at least one sense? | 1.1.1 Non-text Content (A), 1.2.2 Captions (A), 1.3.1 Info and Relationships (A), 1.4.1 Use of Color (A), 1.4.3 Contrast (AA), 1.4.10 Reflow (AA) | Alt text, captions, real headings and lists, text plus colour, 4.5:1 contrast, layouts that work at 320 CSS px wide |
| Operable | Can everyone use every control? | 2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), 2.4.1 Bypass Blocks (A), 2.4.3 Focus Order (A), 2.4.7 Focus Visible (AA), 2.5.8 Target Size (Minimum) (AA) | Native buttons, a skip link, logical tab order, visible focus styles, targets at least 24 by 24 CSS px |
| Understandable | Is it predictable and clear? | 3.1.1 Language of Page (A), 3.2.2 On Input (A), 3.3.1 Error Identification (A), 3.3.2 Labels or Instructions (A) | lang on <html>, no surprise navigation on change, text error messages, visible labels |
| Robust | Does it work with assistive technology? | 4.1.2 Name, Role, Value (A), 4.1.3 Status Messages (AA) | Native elements or correct ARIA, live regions for "Saved" messages |
Numbers worth memorising
- Contrast (1.4.3, AA): 4.5:1 for normal text; 3:1 for large text (at least 24 CSS px, or 18.66 px bold).
- Non-text contrast (1.4.11, AA): 3:1 for control borders, focus indicators and meaningful icons.
- Resize text (1.4.4, AA): text can be zoomed to 200 percent without losing content.
- Reflow (1.4.10, AA): no two-way scrolling at 320 CSS px wide (a 1280 px window at 400 percent zoom).
- Target size (2.5.8, AA, new in 2.2): pointer targets at least 24 by 24 CSS px, or enough spacing around smaller ones.
What WCAG 2.2 added
Nine new criteria, six of them at A or AA (What's New in WCAG 2.2):
- 2.4.11 Focus Not Obscured (Minimum), AA: a sticky header or cookie banner must not completely hide the focused element.
- 2.5.7 Dragging Movements, AA: anything done by dragging also works with single clicks (for example, arrow buttons on a sortable list).
- 2.5.8 Target Size (Minimum), AA.
- 3.2.6 Consistent Help, A: help links or contact details appear in the same place on each page.
- 3.3.7 Redundant Entry, A: do not make people retype information they already gave in the same process.
- 3.3.8 Accessible Authentication (Minimum), AA: no cognitive test such as remembering or transcribing a code to log in, unless there is an alternative; allow paste and password managers.
Worked example: auditing a sign-up form against POUR
A form has grey placeholder text instead of labels, a red border as the only error signal, a "Next" button made from a <div>, and a CAPTCHA that asks you to type distorted letters.
- Perceivable: placeholder-only fields fail 3.3.2 (and the light grey often fails 1.4.3). Red-only errors fail 1.4.1. Fix: visible
<label>elements and an error message in text. - Operable: the
<div>fails 2.1.1. Fix:<button>. - Understandable: "Invalid input" does not say what is wrong. Fix: "Enter an email address like name@example.com" (3.3.1, 3.3.3).
- Robust: the custom button has no role (4.1.2). The native button fixes it.
- 2.2 addition: the text CAPTCHA is a cognitive function test (3.3.8). Offer an alternative.
Write findings as criterion, location, problem and fix. That format is what audit reports and bug trackers expect.
The law, briefly
Many laws reference WCAG: the US Section 508 standards (WCAG 2.0 AA), the European standard EN 301 549 used by the European Accessibility Act (applying from June 2025), and courts and regulators under the ADA in the US. Requirements and versions differ by country and keep changing, so check the W3C's Web Accessibility Laws and Policies list rather than memorising them. Checked on 2026-10-23. You are not expected to give legal advice; you are expected to build to WCAG AA.
Common mistakes
- Treating AAA as the target for everything. Some AAA criteria cannot be met for all content. Target AA and use AAA where it is easy.
- Quoting a number without its criterion. Say "fails 1.4.3, measured 3.2:1", not "contrast is bad".
- Assuming automated tools prove conformance. They catch only a portion; many criteria need human judgement.
- Ignoring states. Hover, focus, error and disabled states all need to meet the rules too.
Quick recap
- POUR: Perceivable, Operable, Understandable, Robust.
- Levels A, AA, AAA; AA is the normal target. WCAG 2.2 is the current version.
- Key numbers: 4.5:1 and 3:1 contrast, 200 percent resize, 320 px reflow, 24 px targets.
- Bookmark the WCAG 2.2 Quick Reference and its Understanding pages.
Try it
Open the Do tab and map problems to POUR principles and success criteria.