How it is organised
WCAG is built on four principles, often shortened to POUR. Content must be perceivable, operable, understandable and robust. Under them sit testable criteria, each at one of three conformance levels: A, AA and AAA. Level AA is the usual target in policies and contracts. The versions in common use are 2.1 and 2.2.
What it asks for in practice
| Area | Example requirement |
|---|---|
| Colour contrast | Normal text needs a contrast ratio of at least 4.5:1 against its background at level AA |
| Keyboard | Every control works without a mouse, and the focus is always visible |
| Text alternatives | Meaningful images have a text description |
| Forms | Every field has a visible label, and errors say what went wrong and how to fix it |
| Language | The page declares its language, and Arabic pages declare right-to-left direction |
Accessibility belongs in design from the start. Colours, sizes and states are decided in the design system, and UI/UX design should test them before build. Automatic scanners catch only some issues, so manual checks with a keyboard and a screen reader are still needed.
Public-sector buyers often refer to WCAG in their requirements; see government for that context. This is awareness, not legal advice. Confirm your legal duties with qualified counsel.
An example
Imagine a government portal for renewing permits. A WCAG review might find grey text that fails the contrast ratio, a date picker that cannot be reached by keyboard and error messages shown only in red. Each is fixed in design and code, then retested. This is a hypothetical example, not our work.
Common mistakes
- Treating accessibility as a final-week audit instead of a design rule.
- Relying on an automatic scanner alone.
- Using colour as the only signal for errors or status.
- Assuming a legal requirement without checking it. Rules differ by country and sector.