Novità delle WCAG 2.2: i 9 nuovi criteri in parole semplici

Una persona che usa la tastiera attraversa il checkout con il tasto Tab. Il focus arriva sul pulsante “Paga ora”, ma sopra c'è un banner dei cookie fisso, e non si capisce più dove ci si trova. Con le WCAG 2.1 quella pagina poteva ancora passare. Con le WCAG 2.2 non passa.

È questo il tipo di lacuna che l'aggiornamento 2.2 colma. Qui sotto ogni nuovo criterio di successo viene trattato allo stesso modo: cosa dice, chi aiuta, un test rapido e la correzione più comune. Per i quattro principi e i livelli in un'unica pagina c'è il nostro riferimento alle WCAG 2.2.

Che cosa sono le WCAG 2.2?

Le WCAG 2.2 sono la versione attuale delle Linee guida per l'accessibilità dei contenuti web (Web Content Accessibility Guidelines), lo standard del W3C a cui rimanda la maggior parte delle leggi e dei contratti sull'accessibilità. Sono diventate Raccomandazione W3C il 5 ottobre 2023 (si apre in una nuova scheda), sono state aggiornate il 12 dicembre 2024 (si apre in una nuova scheda) e sono state approvate come ISO/IEC 40500:2025 (si apre in una nuova scheda) nell'ottobre 2025.

Le WCAG sono composte da requisiti verificabili chiamati criteri di successo, ciascuno con un livello: A (il minimo), AA (quello che di solito chiedono le leggi) o AAA (il più severo). “Ci servono le WCAG 2.2 AA” significa tutti i criteri A e AA della versione 2.2. Secondo la traduzione italiana autorizzata, le WCAG 2.2 “si basano sulle WCAG 2.1” e sono “retrocompatibili con esse”: si aggiungono alla 2.1, non la sostituiscono.

Cosa è cambiato tra le WCAG 2.1 e le 2.2?

Le WCAG 2.2 aggiungono nove criteri di successo e ne rimuovono uno. Sei dei nuovi sono di livello A o AA, quindi contano per il consueto obiettivo AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 e 3.3.8. Gli altri tre sono AAA. Il criterio rimosso è il 4.1.1 Analisi sintattica (parsing), che il W3C oggi definisce obsoleto.

Il 4.1.1 Analisi sintattica verificava gli errori di markup, come gli ID duplicati. Le FAQ sulle WCAG 2 (si apre in una nuova scheda) spiegano che oggi quei problemi ricadono sotto altri criteri, come il 4.1.2 Nome, ruolo, valore. Un'avvertenza: se un contratto richiede ancora le WCAG 2.0 o 2.1, potrebbe essere necessario “continuare a testare e documentare il 4.1.1”.

Focus non nascosto e aspetto del focus: chi usa la tastiera vede dove si trova?

Questi criteri mantengono visibile l'elemento che ha il focus da tastiera. Al livello AA (2.4.11), un link o un pulsante con il focus non deve essere completamente nascosto da contenuti aggiunti dal sito, come un header fisso, un banner dei cookie o una bolla della chat. Al livello AAA nessun elemento può coprirne neanche una parte (2.4.12), e il contorno del focus deve essere grande e ben contrastato (2.4.13).

• Chi aiuta: le persone vedenti che usano la tastiera invece del mouse, spesso per una disabilità motoria. Se non vedono il focus, procedono a tentativi.
• Test rapido: caricare una pagina lunga con banner dei cookie, header fisso e widget della chat tutti visibili, poi premere Tab più volte. Se il focus sparisce del tutto dietro qualcosa, il 2.4.11 non è soddisfatto.
• Correzione comune: aggiungere in CSS uno scroll-padding pari all'altezza dell'header o del footer fisso, così il browser, scorrendo, non lascia gli elementi con il focus sotto l'header o il footer. Il W3C la indica tra le tecniche sufficienti (si apre in una nuova scheda). Un banner è conforme anche quando è modale e va chiuso prima di proseguire.

L'aspetto del focus (2.4.13) richiede un indicatore grande almeno quanto un contorno spesso 2 pixel CSS intorno al componente, con una variazione di contrasto di almeno 3:1 tra lo stato con focus e quello senza. È un criterio AAA, ma di solito basta un contorno pieno di 2 pixel in un colore deciso. La nostra guida sul contrasto dei colori spiega come misurare il rapporto 3:1.

Movimenti di trascinamento e dimensione dell'obiettivo: il sito si usa senza puntare con precisione?

Questi due criteri di livello AA aiutano chi ha difficoltà a controllare il puntatore con precisione. Il 2.5.7 chiede che tutto ciò che si può fare trascinando funzioni anche con singoli clic o tocchi. Il 2.5.8 chiede che gli obiettivi misurino almeno 24 per 24 pixel CSS, oppure siano distanziati in modo che un cerchio di 24 pixel centrato su ciascuno non tocchi un altro obiettivo.

2.5.7 Movimenti di trascinamento

Si pensi allo slider della fascia di prezzo nei filtri di un negozio online, o a una lista dei desideri da riordinare trascinando. Per chi ha un tremore, o usa un puntatore comandato con la testa, premere, tenere premuto, spostare e rilasciare può essere molto difficile.

Test rapido: completare ogni operazione di trascinamento solo con clic o tocchi. Correzione comune: permettere di cliccare in un punto qualsiasi della barra dello slider, aggiungere accanto i campi “min” e “max”, oppure pulsanti “Sposta su” e “Sposta giù” negli elenchi ordinabili. Il solo supporto da tastiera non basta: il documento esplicativo (si apre in una nuova scheda) del W3C precisa che l'equivalenza da tastiera “non soddisfa automaticamente questo criterio di successo”.

2.5.8 Dimensione dell'obiettivo (minimo)

Gli errori tipici sono i piccoli pulsanti “×” dei pop-up, i numeri di pagina troppo ravvicinati, le valutazioni a stelle e le file di icone social. Toccare l'elemento sbagliato irrita chiunque, ed è un vero ostacolo per chi ha una destrezza limitata.

• Eccezioni: i link all'interno di una frase, gli obiettivi che hanno altrove nella pagina un controllo equivalente della dimensione giusta, i controlli dimensionati dal browser di cui non si è modificato lo stile, e i casi in cui una certa dimensione è essenziale o imposta per legge.
• Test rapido: su uno smartphone, provare ogni piccola icona e ogni pulsante; per misurarne uno, ispezionarlo con gli strumenti per sviluppatori del browser.
• Correzione comune: aggiungere padding. L'area cliccabile cresce anche se l'icona resta uguale. E considerare i 24 pixel un minimo: il vecchio criterio AAA 2.5.5 chiede 44 per 44.

Aiuto coerente e inserimento ridondante: il sito costringe a cercare o a ripetersi?

Sono entrambi di livello A. Il 3.2.6 Aiuto coerente dice che, se un aiuto come i recapiti, una chat o un link alle FAQ compare su più pagine, deve trovarsi ogni volta nello stesso ordine rispetto al resto della pagina. Il 3.3.7 Inserimento ridondante dice che non si dovrebbero ridigitare informazioni già fornite nello stesso processo.

L'aiuto coerente non obbliga a offrire aiuto. Dice solo che, se il numero di telefono sta nell'header delle schede prodotto, non deve finire nel footer durante il checkout, proprio dove serve di più. Ne beneficiano soprattutto le persone con difficoltà di memoria o di attenzione. Di solito la soluzione è un template condiviso, non un posizionamento pagina per pagina.

L'inserimento ridondante riguarda i moduli in più passaggi. Un modulo di prenotazione che chiede l'email al passo 1 e di nuovo al passo 3 non è conforme, e nemmeno un checkout che fa ridigitare un indirizzo di fatturazione identico. Il campo va compilato in automatico o reso selezionabile, per esempio con una casella “L'indirizzo di fatturazione coincide con quello di consegna”. Le eccezioni: il reinserimento è essenziale, serve alla sicurezza, oppure l'informazione precedente non è più valida.

Autenticazione accessibile: si può accedere senza un test di memoria?

Il criterio di successo 3.3.8 (livello AA) dice che nessuna fase del login può basarsi su un test basato su abilità cognitive, come ricordare una password, digitare caratteri distorti o risolvere un rompicapo, a meno che non si offra un'alternativa o un aiuto. In pratica: lasciare che i password manager compilino i campi, consentire di incollare e offrire un metodo che non dipenda dalla memoria.

Le WCAG definiscono questo test come “un compito che richiede all'utente di ricordare, manipolare o trascrivere informazioni”. Inserire nome, indirizzo email o numero di telefono non conta, perché sono dati personali e uguali ovunque. Una fase di login è conforme al livello AA se offre almeno una di queste opzioni:

• Un'alternativa senza test cognitivo, come una passkey o un link via email.
• Un meccanismo di aiuto, come il supporto ai password manager o il copia e incolla, così un codice monouso non va ridigitato.
• Il riconoscimento di oggetti, per esempio “seleziona le immagini con una bicicletta”.
• Contenuti personali, come riconoscere un'immagine caricata in precedenza dalla persona stessa.

La versione AAA, il 3.3.9, elimina le ultime due opzioni: un CAPTCHA a immagini può quindi superare il livello AA ma non il livello AAA. Errori tipici: campi password che impediscono di incollare o bloccano i password manager, caselle per il codice monouso che smettono di funzionare quando si incolla e un CAPTCHA testuale senza alternativa. Ne traggono più vantaggio le persone con dislessia o difficoltà di memoria, ma chiunque sia rimasto chiuso fuori da un account dopo una lunga giornata riconoscerà il problema.

Le WCAG 2.2 sono obbligatorie per legge?

Dipende da dove ci si trova e da chi si è. Le leggi citano raramente una versione delle WCAG, e diverse rimandano ancora alle WCAG 2.1 AA. Dato che le WCAG 2.2 sono retrocompatibili, chi soddisfa le 2.2 AA soddisfa anche le 2.1 AA, a parte il 4.1.1 rimosso. Puntare alle 2.2 copre quindi entrambe. Se un contratto indica una versione, vale il contratto.

• Unione europea: con l'European Accessibility Act la conformità si presume quando si rispetta la norma armonizzata EN 301 549. Secondo AccessibleEU (si apre in una nuova scheda), la versione 4.1.1, pubblicata a settembre 2026, adotta le WCAG 2.2 ma non è ancora il riferimento giuridico; finché non sarà citata nella Gazzetta ufficiale, si applica la v3.2.1 (basata sulle WCAG 2.1 AA). In Italia la pubblica amministrazione segue inoltre la Legge Stanca (L. 4/2004) e le linee guida AgID. La nostra guida all'European Accessibility Act spiega a chi si applica.
• Regno Unito: le indicazioni del governo (si apre in una nuova scheda) prevedono che siti e app del settore pubblico soddisfino le WCAG 2.2 AA. Riguardano gli enti pubblici, non le imprese private.
• Stati Uniti: la norma del Dipartimento di Giustizia per gli enti statali e locali usa le WCAG 2.1 AA, con scadenze spostate ad aprile 2026 (si apre in una nuova scheda) al 26 aprile 2027 e al 26 aprile 2028. Per le imprese private, le indicazioni del 2022 (si apre in una nuova scheda) del Dipartimento affermano che l'ADA si applica ai loro siti web, ma non fissano uno standard tecnico specifico.

E le WCAG 3?

Le WCAG 3 sono una bozza, quindi nessuno può ancora conformarvisi. Il W3C ha pubblicato bozze aggiornate a settembre 2026 e dice che le WCAG 3 non dovrebbero diventare uno standard completo “ancora per qualche anno”. Le WCAG 2 non saranno dismesse per diversi anni dopo, quindi la 2.2 è la versione su cui lavorare oggi.

Come verificare i nuovi criteri in 15 minuti?

La maggior parte degli errori sui sei criteri A e AA si individua in circa 15 minuti con una tastiera, uno smartphone e la propria pagina di login. Non sostituisce un audit completo né i test con persone con disabilità, ma indica da dove partire e dà agli sviluppatori un elenco concreto su cui lavorare.

1. Scorrere con Tab la home page, una scheda prodotto e il checkout con tutti i banner visibili. Il focus si vede sempre? (2.4.11)
2. Completare ogni operazione con slider o drag and drop solo con clic o tocchi. (2.5.7)
3. Su uno smartphone, provare ogni pulsante di chiusura, numero di pagina e piccola icona. (2.5.8)
4. Confrontare dove compaiono aiuto e recapiti su tre tipi di pagina. (3.2.6)
5. Fare un acquisto o una prenotazione e annotare ogni domanda a cui si risponde due volte. (3.3.7)
6. Accedere con un password manager, poi incollare una password e un codice monouso. Ogni CAPTCHA ha un'alternativa? (3.3.8)

Per il resto delle WCAG, la nostra guida su come testare l'accessibilità di un sito web presenta strumenti gratuiti e verifiche manuali, e la nostra checklist di accessibilità per siti web trasforma gli errori più comuni in un elenco di attività. Ciò che non si può ancora correggere va indicato nella dichiarazione di accessibilità.

Una nota sui widget, compreso il nostro: nessuno di questi criteri si può soddisfare con un pannello lato visitatore. Un cursore grande aiuta a mirare gli obiettivi piccoli, ma non li rende larghi 24 pixel, ed evidenziare il focus non sposta un banner fisso. Ogni nuovo criterio riguarda il modo in cui sono costruite le pagine, quindi la correzione sta nei template e nel codice.