Le Web Content Accessibility Guidelines (WCAG) sono lo standard internazionale per i contenuti web accessibili, pubblicato dalla Web Accessibility Initiative (WAI) del W3C. La versione attuale, WCAG 2.2, è diventata W3C Recommendation ufficiale il 5 ottobre 2023. Contiene 86 criteri di successo verificabili, organizzati in 4 principi e 13 linee guida, e ogni criterio è assegnato a uno di tre livelli di conformità: A, AA o AAA. Il livello AA è l'obiettivo che conta nella pratica, perché le leggi di tutto il mondo vi ancorano i propri requisiti. Nell'UE la norma armonizzata EN 301 549 richiama le WCAG 2.1 livello AA, il che ne fa il riferimento tecnico per l'European Accessibility Act e il BFSG tedesco. Le WCAG 2.2 aggiungono nove nuovi criteri di successo rispetto alla 2.1, su temi come la dimensione minima dei bersagli, il focus da tastiera visibile e il login senza enigmi cognitivi, e rimuovono il superato criterio di parsing 4.1.1.
Chi pubblica le Web Content Accessibility Guidelines?
Le WCAG nascono in seno al World Wide Web Consortium (W3C), la stessa organizzazione che standardizza HTML e CSS, attraverso la sua Web Accessibility Initiative. Le linee guida hanno una storia lunga: le WCAG 1.0 sono comparse nel 1999, le WCAG 2.0 sono seguite nel 2008 e sono rimaste il riferimento per un intero decennio, le WCAG 2.1 sono arrivate nel 2018 con un'attenzione particolare agli utenti mobile e ipovedenti, e le WCAG 2.2 sono state pubblicate nell'ottobre 2023.
Le versioni 2.x sono retrocompatibili per costruzione. Una pagina conforme alle WCAG 2.2 AA è conforme anche alle 2.1 AA e alle 2.0 AA. È un aspetto rilevante, perché le leggi restano spesso indietro rispetto alla versione più recente e lavorare puntando alla 2.2 ti mette al sicuro su entrambi i fronti.
I quattro principi WCAG: percepibile, utilizzabile, comprensibile, robusto
Ogni criterio di successo dipende da uno di quattro principi, riassunti dall'acronimo POUR:
- Percepibile: gli utenti devono poter percepire il contenuto. Esempi: alternative testuali per le immagini, sottotitoli per i video, contrasto cromatico sufficiente.
- Utilizzabile: gli utenti devono poter usare l'interfaccia. Esempi: tutto funziona da tastiera, gli utenti hanno tempo a sufficienza, nulla lampeggia in modo da provocare crisi epilettiche, i bersagli sono abbastanza grandi da essere colpiti.
- Comprensibile: contenuto e funzionamento devono essere comprensibili. Esempi: linguaggio leggibile, navigazione prevedibile, messaggi di errore utili nei moduli.
- Robusto: il contenuto deve funzionare in modo affidabile con gli user agent attuali e futuri, screen reader compresi. Esempio: messaggi di stato che le tecnologie assistive possano annunciare.
I principi sono volutamente neutri rispetto alla tecnologia. Valgono per un blog WordPress esattamente come per un'app React o un PDF.
Livelli di conformità WCAG A, AA e AAA a confronto
| Livello | Criteri nelle WCAG 2.2 | Significato | Esempi tipici |
|---|---|---|---|
| A | 31 | Minimo assoluto. Non rispettarli esclude interi gruppi di utenti. | Testo alternativo per le immagini, utilizzo da tastiera, nessuna trappola per la tastiera |
| AA | 24 | L'obiettivo standard, richiamato dalle leggi in tutto il mondo. | Contrasto 4,5:1, focus visibile, navigazione coerente, suggerimenti in caso di errore |
| AAA | 31 | Il livello più alto, un traguardo ideale per la maggior parte dei siti. | Contrasto 7:1, lingua dei segni per i video, requisiti sul livello di leggibilità |
La conformità è cumulativa: AA significa che soddisfi tutti i criteri di livello A e tutti quelli di livello AA. Il W3C stesso afferma che la piena conformità AAA non dovrebbe essere richiesta come politica generale, perché alcuni criteri AAA semplicemente non possono essere soddisfatti per ogni tipo di contenuto. Nessuno si aspetta l'interpretariato in lingua dei segni sul sito di una panetteria. Singoli criteri AAA restano comunque adottabili dove hanno senso, e il rapporto di contrasto rafforzato è tra i più gettonati.
Quanti criteri di successo hanno le WCAG 2.2?
Le WCAG 2.2 contengono 86 criteri di successo: 31 di livello A, 24 di livello AA e 31 di livello AAA. Per confronto, le WCAG 2.1 ne avevano 78. I conti tornano perché la 2.2 aggiunge nove nuovi criteri e ne rimuove uno: il 4.1.1 Parsing, un residuo dell'epoca in cui un HTML malformato poteva davvero mandare in crisi gli screen reader. Browser e tecnologie assistive moderni interpretano l'HTML allo stesso modo, quindi il criterio era diventato obsoleto.
Cosa c'è di nuovo nelle WCAG 2.2? I nove nuovi criteri di successo
Le aggiunte della 2.2 si concentrano sugli utenti con disabilità motorie e cognitive e, a essere onesti, la maggior parte di esse è semplicemente buona UX:
- 2.4.11 Focus Not Obscured (Minimum), AA: l'elemento con il focus non deve risultare completamente nascosto dietro header sticky, cookie banner o widget di chat.
- 2.4.12 Focus Not Obscured (Enhanced), AAA: l'elemento con il focus non deve essere nascosto affatto, nemmeno in parte.
- 2.4.13 Focus Appearance, AAA: l'indicatore di focus deve soddisfare requisiti minimi di dimensione e contrasto.
- 2.5.7 Dragging Movements, AA: tutto ciò che funziona per trascinamento richiede un'alternativa utilizzabile con semplici clic o tocchi.
- 2.5.8 Target Size (Minimum), AA: i bersagli per clic e tocco devono misurare almeno 24 per 24 pixel CSS oppure avere spazio a sufficienza attorno.
- 3.2.6 Consistent Help, A: le opzioni di aiuto come i link ai contatti o la chat devono comparire nella stessa posizione su ogni pagina.
- 3.3.7 Redundant Entry, A: non costringere gli utenti a digitare due volte la stessa informazione all'interno di una procedura. Indirizzo di spedizione uguale a quello di fatturazione dev'essere una casella da spuntare, non un secondo modulo.
- 3.3.8 Accessible Authentication (Minimum), AA: il login non deve dipendere da un enigma cognitivo. Trascrivere caratteri distorti o risolvere giochi di memoria è fuori discussione, e i password manager e l'incolla devono funzionare.
- 3.3.9 Accessible Authentication (Enhanced), AAA: la stessa regola senza le eccezioni che il 3.3.8 ancora consente.
Quale livello WCAG è richiesto per legge?
Nell'UE la norma armonizzata EN 301 549 definisce i requisiti tecnici sia per le regole del settore pubblico sia per l'European Accessibility Act, e attualmente richiama le WCAG 2.1 livello AA. Questo rende la 2.1 AA il riferimento giuridico formale per il BFSG tedesco e la BITV 2.0. È atteso un aggiornamento della EN 301 549 alle WCAG 2.2, ed è esattamente il motivo per cui lavorare oggi puntando alla 2.2 è la scelta pragmatica: soddisfi allo stesso tempo il requisito attuale e quello probabile di domani.
Il quadro è simile altrove. Negli Stati Uniti il Department of Justice ha adottato nel 2024 una regola definitiva che impone agli enti statali e locali di rispettare le WCAG 2.1 AA ai sensi dell'ADA Title II, e i tribunali usano abitualmente le WCAG come riferimento nelle cause ADA tra privati. Se di questo paragrafo devi ricordare una cosa sola, che sia questa: WCAG AA è il livello a cui la legge pensa quando dice accessibile.
Come si presentano i criteri di successo WCAG nella pratica?
Tre esempi mostrano quanto i criteri diventino concreti. Il criterio 1.4.3 Contrast (Minimum) richiede un rapporto di contrasto di almeno 4,5:1 tra il testo normale e il suo sfondo, e di 3:1 per il testo di grandi dimensioni. Quel testo grigio su bianco nel footer, con #999999 su #ffffff? Non passa, si ferma a 2,85:1. Il criterio 2.1.1 Keyboard pretende che tutte le funzionalità siano utilizzabili senza mouse, ed è qui che la maggior parte dei menu a tendina personalizzati e degli slider di immagini si rompe in silenzio. E il criterio 1.1.1 Non-text Content è la classica regola sul testo alternativo:
<!-- Immagine informativa: descrivi cosa mostra -->
<img src="warehouse.jpg" alt="Dipendente che scansiona pacchi in magazzino">
<!-- Immagine decorativa: alt vuoto, così gli screen reader la saltano -->
<img src="divider.svg" alt="">Ogni criterio nel documento ufficiale rimanda a tecniche ed esempi di errore, e il riferimento rapido WCAG ti permette di filtrare tutti gli 86 criteri per livello e tecnologia, il che è molto più pratico che leggere la specifica dall'inizio alla fine.
Come si verifica la conformità alle WCAG 2.2?
Parti dagli strumenti automatici: WAVE, axe DevTools, Lighthouse o i controlli di accessibilità integrati in InspectWP individuano in pochi secondi attributi alt mancanti, contrasti insufficienti, etichette assenti e problemi strutturali. Ma tieni presente il limite. I controlli automatici rilevano in modo affidabile tra un terzo e la metà delle violazioni WCAG, perché molti criteri richiedono un giudizio umano. Una macchina può vedere che un'immagine ha un testo alternativo, non se quel testo descrive davvero l'immagine.
Completa quindi il quadro a mano: stacca il mouse e naviga l'intero sito da tastiera, fai una sessione con uno screen reader come NVDA (gratuito) o VoiceOver, ingrandisci la pagina al 200 percento e percorri dall'inizio alla fine il tuo percorso utente più importante, di solito il checkout o il contatto. Se puoi, coinvolgi nei test persone con disabilità. In dieci minuti troveranno problemi che nessuna checklist di audit fa emergere.
Cosa arriva dopo le WCAG 2.2? Uno sguardo veloce alle WCAG 3.0
Il W3C sta lavorando alle WCAG 3.0, una riscrittura da zero con un nuovo modello di punteggio che si allontana dalla logica binaria passa o non passa. Sono in bozza da anni e resteranno in bozza per anni ancora, e il W3C dice esplicitamente che non sostituiranno la 2.2 per molto tempo. Ai fini della pianificazione: l'obiettivo sono le WCAG 2.2 AA e nulla di ciò che riguarda la 3.0 dovrebbe cambiare la tua roadmap di oggi.
Come verifica InspectWP i criteri WCAG?
InspectWP include controlli di accessibilità automatizzati nei suoi report e collega le violazioni più comuni ai criteri WCAG sottostanti: testi alternativi mancanti, contrasto cromatico insufficiente, campi di modulo senza etichetta, lingua del documento assente e gerarchia dei titoli non corretta, tra gli altri. Ogni risultato arriva con un grado di gravità, così puoi correggere prima i blocchi di livello A e salire poi verso l'AA. In combinazione con i report pianificati, questo trasforma l'accessibilità da audit occasionale in qualcosa che tieni davvero d'occhio, che è poi ciò che l'European Accessibility Act si aspetta da te.