f in x
WCAG 2.2: POUR Principles, Success Criteria, and Levels A, AA, AAA — Practical Guide
> cd .. / HUB_EDITORIALE
Analisi dei dati e metriche

WCAG 2.2: POUR Principles, Success Criteria, and Levels A, AA, AAA — Practical Guide

[2026-06-09] Author: Ing. Calogero Bono

Have you ever tried to navigate a website using only the keyboard and got stuck at the second link? Or watched a video without captions, a form without labels, or a contrast that hurts your eyes? Designing for the web often forgets that accessibility is not a bonus: it's a requirement. And for SMEs it's also a competitive advantage.

We, at Meteora Web, work every day on sites that must work for everyone — clients, suppliers, employees with different needs. And the first thing we check is whether the site meets the Web Content Accessibility Guidelines (WCAG). In 2023 version 2.2 was released, adding new criteria and updating old ones. In this guide we explain the three key ingredients: POUR principles, success criteria, and conformance levels. No abstract theory: concrete examples, actions you can take immediately.

The four pillars of WCAG: Perceivable, Operable, Understandable, Robust

WCAG 2.2 is built on four principles, known by the acronym POUR. Each principle contains a set of guidelines, and each guideline contains testable success criteria. If a site fails at least one of these principles, a person with a disability may not be able to use it.

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. Practical example: an image conveying information must have alternative text. A video must have captions. An audio content must have a transcript.

Action now: Check all images on your site: every <img> tag must have a descriptive alt attribute. If the image is purely decorative, use alt="" (empty) to hide it from screen readers.

<!-- Informative image -->
<img src="revenue-2026.png" alt="Bar chart of annual revenue: 2024: $120k, 2025: $180k, 2026 forecast $250k" />

<!-- Decorative image -->
<img src="background.jpg" alt="" role="presentation" />

2. Operable

User interface components and navigation must be operable. A user who cannot use a mouse must be able to navigate with keyboard, voice commands, or other devices.

Action now: Try navigating your site using only Tab, Shift+Tab, Enter, and Esc. All links, buttons, and form elements must be reachable and activatable. If you see a focus style (a border or shadow) moving, you're on the right track. If not, add support for :focus-visible.

/* Visible focus for all interactive elements */
:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

3. Understandable

Information and the operation of the user interface must be understandable. Clear language, helpful error messages, predictable behavior. A classic mistake: a form that does not explain why a field is invalid, or a context change (e.g., opening a new window) without warning.

Action now: Review your form error messages. They must tell exactly what is wrong and how to fix it. Not generic "Error".

<label for="email">Email address</label>
<input type="email" id="email" name="email" required aria-describedby="email-error" />
<p id="email-error" role="alert">Please enter a valid email address (e.g., name@domain.com)</p>

4. Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means valid, semantic HTML that follows standards.

Action now: Use a tool like the W3C Validator to check your HTML. Valid code is the foundation for robustness.

Success criteria: the real substance of WCAG 2.2

Each principle has guidelines, and each guideline has testable success criteria. WCAG 2.2 introduced new criteria (such as Focus Not Obscured, Dragging Movements, Target Size) and tightened some from 2.1. You don't need to memorize them all: just know where to find them and how to test.

Here are the new success criteria in WCAG 2.2 (levels AA and AAA) every developer should know:

  • 2.4.11 Focus Not Obscured (AA) — Keyboard focus must not be hidden by other elements (e.g., popups, fixed footers).
  • 2.4.12 Focus Not Obscured (Enhanced) (AAA) — Focus must not be obscured by any element.
  • 2.4.13 Focus Appearance (AAA) — Focus indicator must have minimum thickness and contrast.
  • 2.5.7 Dragging Movements (AA) — Actions that require dragging must have a single-click alternative.
  • 2.5.8 Target Size (AA) — Clickable targets must be at least 24×24px, with some exceptions.
  • 3.2.6 Consistent Help (A) — Help mechanisms (e.g., chat, FAQ) must be placed consistently across pages.
  • 3.3.7 Accessible Authentication (AA) — Authentication must not rely on cognitive tasks (e.g., recognizing images, typing a word).
  • 3.3.8 Accessible Authentication (No Exception) (AAA) — Same, but without exceptions.

Levels A, AA, AAA: what they mean for your project

Success criteria are organized into three increasing levels of conformance:

Level A (minimum)

Removes the most severe barriers. Examples: alt text for images, keyboard operability, minimum color contrast. It's the bare minimum to not exclude anyone entirely. We recommend starting here.

Level AA (intermediate)

Removes the most common barriers. Includes all A criteria plus: contrast 4.5:1, form labels, consistent navigation, text resize up to 200%. It's the standard required by European law (EN 301 549) and many public contracts. If you build a site for a serious client, aim for at least AA.

Level AAA (advanced)

Removes residual barriers. Examples: contrast 7:1, sign language for videos, no time limits for reading content. Achieving AAA across an entire site is very difficult and sometimes impractical (e.g., a complex chart cannot have 7:1 contrast on every detail). It's not mandatory, but it's a noble goal for those who want to go further.

Important: Declaring “WCAG 2.2 AA conformant” means you have satisfied all Level A and AA success criteria. It's not enough to comply with just a few.

How to quickly test your current level

  1. Use an automated validator (e.g., WAVE, axe DevTools, Lighthouse) — immediately identifies A and AA errors.
  2. Test with a screen reader (NVDA on Windows, VoiceOver on Mac) — go through the entire site.
  3. Check with keyboard only — no mouse, just Tab/Enter.
  4. Check contrast with tools like the Colour Contrast Analyser.
  5. Run a test with real people — the most valuable test of all.

We've seen clients who thought they were fine and discovered that their dropdown menu was not keyboard accessible. A quick check avoids nasty surprises and costly fixes after launch.

In summary — what to do now

  1. Evaluate your site with an automated tool (WAVE or axe) and note the failed criteria.
  2. Define your conformance target: minimum A, aim for AA.
  3. First fix Level A criteria: alt text, keyboard navigation, form labels.
  4. Then move to Level AA: contrast 4.5:1, text resize, clear forms, unobscured focus.
  5. Document your conformance claim — not mandatory for SMEs in most countries, but a sign of professionalism.

We, at Meteora Web, guide our clients through this process. We always start with an audit, then plan the fixes. Because an accessible site is a site that works for everyone — and that sells more.

Sponsored Protocol

Ing. Calogero Bono

> AUTHOR_EXTRACTED

Ing. Calogero Bono

Co-founder di Meteora Web. Ingegnere informatico, sviluppo ecosistemi digitali ad alte prestazioni. AI, automazione, SEO tecnica e infrastrutture web. Scrivo di tecnologia per rendere complesso… semplice.

[ Read Full Dossier ]

Hai bisogno di applicare questa strategia?

Esegui il protocollo di contatto per iniziare un progetto con noi.

> INIZIA_PROGETTO

Sponsored

> MW_JOURNAL

> READ_ALL()