WCAG 2.2: principi POUR, criteri di successo e livelli A, AA, AAA — guida operativa

Hai mai provato a navigare un sito con la sola tastiera e ti sei fermato al secondo link? O hai visto un video senza sottotitoli, un form senza etichette, un contrasto che acceca? Chi progetta per il web spesso dimentica che l’accessibilità non è un bonus: è un requisito. E per le PMI è anche un vantaggio competitivo.

Noi, di Meteora Web, lavoriamo ogni giorno su siti che devono funzionare per tutti — clienti, fornitori, dipendenti con esigenze diverse. E la prima cosa che controlliamo è se il sito rispetta le WCAG (Web Content Accessibility Guidelines). Nel 2023 è uscita la versione 2.2, che aggiunge criteri nuovi e aggiorna quelli vecchi. In questa guida ti spieghiamo i tre ingredienti fondamentali: principi POUR, criteri di successo e livelli di conformità. Niente teoria astratta: esempi concreti, azioni da fare subito.

I quattro pilastri delle WCAG: Perceivable, Operable, Understandable, Robust

Le WCAG 2.2 si basano su quattro principi, conosciuti con l’acronimo POUR. Ogni principio racchiude una serie di linee guida, e ogni linea guida contiene criteri di successo misurabili. Se un sito non rispetta almeno uno di questi principi, una persona con disabilità rischia di non poterlo usare.

1. Perceivable – Percepibile

Le informazioni e i componenti dell’interfaccia devono essere presentati in modo che gli utenti possano percepirli. Esempio pratico: un'immagine che trasmette informazioni deve avere un testo alternativo. Un video deve avere sottotitoli. Un contenuto audio deve avere una trascrizione.

Cosa fare subito: Controlla tutte le immagini del tuo sito: ogni tag <img> deve avere l’attributo alt descrittivo. Se l’immagine è puramente decorativa, usa alt="" (vuoto) per nasconderla agli screen reader.

<!-- Immagine informativa -->
<img src="fatturato-2026.png" alt="Grafico a barre del fatturato annuale: 2024: 120k, 2025: 180k, 2026 previsione 250k" />

<!-- Immagine decorativa -->
<img src="sfondo.jpg" alt="" role="presentation" />

2. Operable – Operabile

I componenti dell’interfaccia e la navigazione devono poter essere utilizzati. Un utente che non può usare il mouse deve poter navigare con tastiera, comandi vocali o altri dispositivi.

Cosa fare subito: Prova a navigare il tuo sito usando solo Tab, Shift+Tab, Invio e Esc. Tutti i link, pulsanti e form devono essere raggiungibili e attivabili. Se vedi un focus style (un bordo o un'ombra) che si muove, sei a buon punto. Se no, devi aggiungere il supporto al :focus-visible.

/* Focus visibile per tutti gli elementi interattivi */
:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

3. Understandable – Comprensibile

Le informazioni e il funzionamento dell’interfaccia devono essere comprensibili. Lingua chiara, messaggi di errore utili, comportamento prevedibile. Un classico errore: un form che non spiega perché un campo è invalido, o un cambio di contesto (es. apertura di una nuova finestra) senza preavviso.

Cosa fare subito: Rivedi i messaggi di errore dei form. Devono indicare esattamente cosa è sbagliato e come correggerlo. Non generici "Errore".

<label for="email">Indirizzo email</label>
<input type="email" id="email" name="email" required aria-describedby="email-error" />
<p id="email-error" role="alert">Inserisci un indirizzo email valido (es. nome@dominio.it)</p>

4. Robust – Robusto

I contenuti devono poter essere interpretati in modo affidabile da una varietà di user agent, compresi gli screen reader. Questo significa codice HTML valido, semantico e conforme agli standard.

Cosa fare subito: Usa uno strumento come il W3C Validator per controllare il tuo HTML. Un codice valido è la base per essere robusti.

Criteri di successo: la vera sostanza delle WCAG 2.2

Ogni principio ha delle linee guida, e ogni linea guida ha dei criteri di successo testabili. Le WCAG 2.2 hanno introdotto nuovi criteri (come Focus Not Obscured, Dragging Movements, Target Size) e ne hanno resi più stringenti alcuni della versione 2.1. Non serve memorizzarli tutti: basta sapere dove trovarli e come testarli.

Ecco i nuovi criteri di successo introdotti in WCAG 2.2 (livelli AA e AAA) che ogni sviluppatore dovrebbe conoscere:

• 2.4.11 Focus Not Obscured (AA) — Il focus della tastiera non deve essere nascosto da altri elementi (es. popup, footer fissi).
• 2.4.12 Focus Not Obscured (Enhanced) (AAA) — Il focus non deve essere oscurato da nessun elemento.
• 2.4.13 Focus Appearance (AAA) — Il contorno del focus deve avere spessore e contrasto minimi.
• 2.5.7 Dragging Movements (AA) — Le azioni che richiedono trascinamento devono avere un’alternativa con un semplice click.
• 2.5.8 Target Size (AA) — Le aree cliccabili (target) devono avere dimensioni almeno 24×24px, esenti alcune eccezioni.
• 3.2.6 Consistent Help (A) — I meccanismi di aiuto (es. chat, FAQ) devono essere posizionati in modo coerente su tutte le pagine.
• 3.3.7 Accessible Authentication (AA) — I processi di autenticazione non devono basarsi su compiti cognitivi (es. riconoscere immagini, digitare una parola).
• 3.3.8 Accessible Authentication (No Exception) (AAA) — Stessa cosa, ma senza eccezioni.

Livelli A, AA, AAA: cosa significano per il tuo progetto

I criteri di successo sono organizzati su tre livelli crescenti di conformità:

Livello A (base)

Rimuove le barriere più gravi. Esempi: testo alternativo alle immagini, controllo tramite tastiera, contrasto colore minimo. È il minimo indispensabile per non escludere completamente nessuno. Noi consigliamo di partire da qui.

Livello AA (intermedio)

Rimuove le barriere più comuni. Include tutti i criteri A più: contrasto 4.5:1, etichette nei form, navigazione coerente, ridimensionamento del testo al 200%. È lo standard richiesto dalla legge europea (EN 301 549) e da molti contratti pubblici. Se fai un sito per un cliente serio, devi puntare almeno a AA.

Livello AAA (avanzato)

Rimuove le barriere residue. Esempi: contrasto 7:1, lingua dei segni per video, nessuna limitazione di tempo per leggere i contenuti. Raggiungere AAA su tutto il sito è molto difficile e talvolta impraticabile (es. un grafico complesso non può avere un contrasto 7:1 su ogni dettaglio). Non è obbligatorio, ma è un obiettivo nobile per chi vuole andare oltre.

Attenzione: Dichiarare “conforme WCAG 2.2 AA” significa aver soddisfatto tutti i criteri di livello A e AA. Non basta averne rispettati alcuni.

Come testare velocemente il tuo livello attuale

1. Usa un validatore automatico (es. WAVE, axe DevTools, Lighthouse) — identifica subito errori A e AA.
2. Prova con screen reader (NVDA su Windows, VoiceOver su Mac) — fai un giro completo del sito.
3. Verifica con tastiera — nessun mouse, solo Tab/Invio.
4. Controlla il contrasto con strumenti come il Colour Contrast Analyser.
5. Esegui un test con persone reali — è il test più prezioso.

Abbiamo visto clienti che pensavano di essere a posto e scoprivano che il loro menu a discesa non era accessibile con tastiera. Un controllo rapido evita brutte sorprese e costose correzioni dopo il lancio.

In sintesi — cosa fare adesso

1. Valuta il tuo sito con uno strumento automatico (WAVE o axe) e prendi nota dei criteri falliti.
2. Definisci il tuo target di conformità: minimo A, obiettivo AA.
3. Correggi prima i criteri di livello A: alt testuale, navigazione tastiera, etichette form.
4. Poi passa a livello AA: contrasto 4.5:1, ridimensionamento, form chiari, focus non oscurato.
5. Documenta la tua dichiarazione di conformità — in Italia non è obbligatoria per le PMI, ma è un segnale di professionalità.

Noi, di Meteora Web, accompagniamo i nostri clienti in questo percorso. Partiamo sempre da un audit, poi pianifichiamo le correzioni. Perché un sito accessibile è un sito che funziona per tutti — e che vende di più.