Blog
WCAG is built on four principles: POUR.
Perceivable, operable, understandable and robust, explained in plain language through the 86 success criteria.
WCAG has four principles: perceivable, operable, understandable and robust.
Together they spell POUR.
Each of the 86 success criteria in WCAG 2.2 falls under one of these four, spread across thirteen guidelines.
That split is not theory, it is a way to work out where a problem sits and who fixes it.
A video without subtitles is a perceivable issue and belongs with the editorial team.
A dropdown that will not open with the keyboard is an operable issue and belongs in the theme.
Perceivable: does the information get through?
Perceivable means every bit of information can be picked up, even when one of your channels drops out.
In practice: text alternatives for images (success criterion 1.1.1), captions on video (1.2.2), a contrast ratio of at least 4.5 to 1 between normal text and its background (1.4.3), and a page that stays readable at 400 percent zoom without horizontal scrolling (1.4.10).
\n
What goes wrong in practice:
\n
- \n
- Alt text such as "image" or "logo-final-2", or an empty alt on a photo that does carry information.
- Light grey text on white: it crept in during the design phase and was never measured afterwards.
- Colour as the only signal, such as a status shown only by a coloured dot (1.4.1).
\n
\n
\n
Operable: does everything work without a mouse?
Operable means every function works with the keyboard, not only with a mouse or touch.
That is success criterion 2.1.1, and custom components trip over it most often.
It also covers a visible focus indicator (2.4.7), a focus that does not disappear behind a sticky header (2.4.11, new in WCAG 2.2), and click targets of at least 24 by 24 pixels (2.5.8, also new).
\n
- \n
- A div with a click handler instead of a button, so it is unreachable with tab and enter.
- A modal that lets focus wander off, or that will not close with escape.
- A focus ring that got removed because it did not fit the design.
\n
\n
\n
Understandable: does the visitor know what is happening?
Understandable is about predictability and language, not just about writing simply.
The principle calls for a correctly set page language (3.1.1), labels on form fields (3.3.2), an error message that says how to fix it (3.3.3), and navigation that sits in the same place everywhere (3.2.3).
WCAG 2.2 added accessible authentication (3.3.8): a login must not be a memory or puzzle test without an alternative.
- \n
- A placeholder as the only label, which disappears the moment you start typing.
- An error message at the top with no reference to the field that is wrong.
- A page whose declared language tag does not match its content, so a screen reader reads the text with the wrong pronunciation.
\n
\n
\n
Robust: does the technology understand it too?
Robust is the smallest principle and the most technical one: two success criteria, covering name, role and value (4.1.2) and status messages (4.1.3).
Assistive software needs to read out what an element is, what state it is in, and what just changed.
Success criterion 4.1.1 on parsing was dropped in WCAG 2.2, because modern browsers now handle broken HTML on their own.
- \n
- A hand-built tab component without roles and states, so a screen reader hears a row of loose links.
- A message or filter result that appears visually but is never announced.
- ARIA layered over correct HTML, which breaks more than it fixes.
\n
\n
\n
This is why I treat accessibility as code work rather than a plug-in: an overlay that promises the fix in one line of JavaScript does not touch the semantics of your components.
How it does work properly is on my page about digital accessibility.
Level A, AA and AAA: what is the difference?
The three levels are not three types of accessibility, they are three thresholds within the same set of criteria.
They are cumulative: AA means you meet all the A criteria plus the AA criteria, AAA means all of them together.
\n
| Level | Criteria in WCAG 2.2 | What it means |
|---|---|---|
| A | 31 | The baseline. Without it your site is unusable for part of your visitors. |
| AA | 24 more, 55 in total | The level that European standards and legislation refer to. |
| AAA | 31 more, 86 in total | Additional, and not achievable for all content. |
The difference shows up clearly in contrast: AA asks for 4.5 to 1 on normal text (1.4.3), AAA asks for 7 to 1 (1.4.6).
Other AAA criteria call for a sign language version alongside recorded video (1.2.6), text pitched at lower secondary reading level (3.1.5), or click targets of 44 by 44 pixels (2.5.5).
Reasonable requirements, but they reach right into the core of your editorial process.
Why AA is the practical standard
AA is the practical standard because regulation points to it, not because AAA would be too hard.
The European Accessibility Act, Directive 2019/882, has applied since 28 June 2025 and sets functional accessibility requirements.
In practice the technical bar is derived from the European standard EN 301 549, but that standard has not yet been cited in the Official Journal for the EAA, so it does not yet carry a formal presumption of conformity.
That standard points to WCAG level AA, and the web accessibility directive for public sector sites hangs on the same standard.
Which version of EN 301 549 is formally cited at any given moment shifts, and with it whether WCAG 2.1 or 2.2 is the reference.
If you want to put that in an accessibility statement, have the exact standard and version checked legally.
On top of that, the W3C itself advises against requiring AAA for an entire site, because not every AAA criterion is achievable for all content.
A news site with daily video cannot guarantee a sign language version, and then your whole statement rests on a promise nobody should have made.
AA is achievable and demonstrable, so that is the bar you commit to.
Whether you also have to account for that bar publicly is covered in my article on whether an accessibility statement is mandatory or not.
Whether the EAA applies to your site depends on what you offer, so have that checked legally.
I wrote earlier about when the European Accessibility Act applies to your website.
Where to start if you have nothing yet
You do not need to know all 86 criteria to get going.
Three things give you an honest picture within an hour: tab through the whole site and check that you always see where you are, walk through the heading structure from h1 to h3, and look at your main form for labels and error messages.
Automated tools such as Lighthouse and axe DevTools belong in the mix, but they only catch part of the problems.
A good score does not say much on its own, because an alt text that is present but describes nothing still counts as correct.
Tools for the basics, manual work for the rest.
Which tools to use for what, and what to check by hand yourself, I work through step by step in my article on how to test your website for accessibility.
Stuck with an audit report nobody acts on, or do you want accessibility built in from the architecture up? See what an accessibility project involves, or lay out your situation via contact.
I look at your request and give you an honest picture of what is needed within 24 hours.
Frequently asked questions
What are the four principles of accessibility?
Perceivable, operable, understandable and robust, POUR for short.
Each of the 86 success criteria in WCAG 2.2 falls under one of those four principles.
Perceivable is about taking in information, operable about use without a mouse, understandable about language and predictability, robust about what assistive software can read.
They apply to the entire interface, so also to forms and dynamic components.
What types of accessibility are there?
In WCAG there are no types of accessibility, but four principles and three conformance levels.
A distinction by target group is often made though: visual, auditory, motor and cognitive.
That helps to understand why a criterion exists, but not to work towards it, since a single mistake usually affects multiple groups: a missing label breaks both the screen reader and voice control.
What does robust mean in WCAG 2.2?
Robust is the smallest and most technical of the four principles: two success criteria, about name, role and value (4.1.2) and about status messages (4.1.3).
Assistive software needs to be able to read what an element is, what state it's in, and what just changed.
A custom-built tab component without roles and states is, to a screen reader, just a row of separate links.
Success criterion 4.1.1 on parsing has been dropped in WCAG 2.2, since modern browsers handle broken HTML themselves.
How accessible do websites need to be?
In practice, to WCAG 2.2 level AA, which is 55 success criteria including level A.
That bar comes from the newest version of the European standard EN 301 549, which the European accessibility rules refer back to.
That version hasn't been cited in the Official Journal yet, so formally WCAG 2.1 level AA still counts as the starting point; anyone building now is best off aiming straight for 2.2 AA.
The European Accessibility Act, in effect since 28 June 2025, doesn't itself name a WCAG version but functional requirements.
Whether your site falls under it, and which standard exactly then applies, depends on what you offer, so have that checked legally.
What is the difference between level A, AA and AAA?
They're not three types of accessibility, but three thresholds within the same set of criteria, and they're cumulative.
Level A counts 31 success criteria, AA adds 24 more for a total of 55, AAA adds another 31 for all 86.
The difference shows well in contrast: AA requires 4.5 to 1 for normal text (1.4.3), AAA requires 7 to 1 (1.4.6).
AAA also requires things like a sign-language version for recorded video, which hits your editorial process at its core.
Why is level AA the practical standard and not AAA?
Because the regulation refers to AA, not because AAA would be too difficult.
In practice, the technical bar is derived from the European standard EN 301 549, and that standard refers to WCAG level AA.
On top of that, the W3C itself advises against requiring AAA for an entire site, since not all AAA criteria are achievable for all content.
A news site with daily video can't guarantee a sign-language version.
AA is achievable and demonstrable, so that's the bar you set.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
