Cosa è cambiato in WCAG 2.2 rispetto a WCAG 2.1

Le Web Content Accessibility Guidelines (WCAG) sono lo standard al quale puntano la maggior parte delle leggi sull'accessibilità. WCAG 2.2 è diventata Raccomandazione W3C il 5 ottobre 2023, ha aggiunto nove nuovi criteri di successo e ne ha rimosso uno. È ora anche ISO/IEC 40500:2025. Se mantieni un sito web, un design system o un prodotto nel 2026, la domanda pratica è: cosa è cambiato, cosa richiede effettivamente ogni nuovo criterio e come dovresti dare priorità alle correzioni? Questo articolo risponde a ciascuno a turno, con le fonti citate per poter verificare prima di agire.

Breve storia di WCAG

Il W3C ha pubblicato le prime Web Content Accessibility Guidelines il 5 maggio 1999. WCAG 1.0 era prescrittiva e specifica per HTML; è invecchiata rapidamente quando il web è passato dai documenti semplici alle applicazioni ricche.

WCAG 2.0 è arrivata l'11 dicembre 2008. Ha astratto le linee guida da qualsiasi tecnologia specifica, le ha organizzate sotto i quattro principi "Percepibile, Utilizzabile, Comprensibile, Robusto" (POUR) e ha introdotto lo schema di conformità a tre livelli A/AA/AAA che i professionisti usano ancora oggi. È la versione a cui la maggior parte delle normative statunitensi e internazionali faceva originariamente riferimento.

WCAG 2.1 è seguita il 5 giugno 2018. Ha aggiunto 17 nuovi criteri di successo che coprono il mobile (orientamento, target touch, attivazione tramite movimento), gli utenti ipovedenti (reflow, spaziatura del testo, contrasto non-testo) e l'accessibilità cognitiva (label-in-name, messaggi di stato). È la versione integrata nello standard EN 301 549 v3.2.1 referenziato dall'European Accessibility Act.

WCAG 2.2 è stata pubblicata il 5 ottobre 2023 e ripubblicata con aggiornamenti editoriali il 12 dicembre 2024. Aggiunge nove nuovi criteri di successo, ne rimuove uno (4.1.1 Parsing) ed è ora anche ISO/IEC 40500:2025. WCAG 3, un framework sostanzialmente diverso con un nuovo sistema di punteggio, è ancora in bozza e non è atteso per l'adozione generale prima del 2027.

I nove nuovi criteri di successo

I nuovi criteri ricadono in tre gruppi tematici: focus, modalità di input e accessibilità cognitiva.

Gruppo focus

2.4.11 Focus Non Oscurato (Minimo), Livello AA. Quando un componente dell'interfaccia utente riceve il focus da tastiera, il componente non deve essere interamente nascosto da contenuti creati dall'autore (intestazioni adesive, banner cookie, widget di chat). Il componente può essere parzialmente oscurato; il criterio fallisce solo quando nulla di esso è visibile. La maggior parte dei fallimenti nel mondo reale viene da barre adesive in basso che galleggiano sopra un campo focalizzato in un modulo, lasciando il focus invisibile mentre l'utente digita.

2.4.12 Focus Non Oscurato (Avanzato), Livello AAA. Versione più rigorosa di 2.4.11: quando un componente riceve il focus, nessuna parte di esso può essere nascosta. Questa è la versione AAA mirata dalla maggior parte dei design system aziendali.

2.4.13 Aspetto del Focus, Livello AAA. L'indicatore di focus stesso deve essere spesso almeno 2 pixel CSS attorno al controllo focalizzato, e il contrasto dell'indicatore di focus rispetto allo stato adiacente non focalizzato deve essere di almeno 3:1. Un anello di focus predefinito del browser da 1 pixel su un pulsante scuro non rispetta questo criterio; un anello ad alto contrasto da 2 pixel lo rispetta.

Gruppo modalità di input

2.5.7 Movimenti di Trascinamento, Livello AA. Qualsiasi cosa che possa essere fatta con un gesto di trascinamento deve essere possibile anche senza di esso. Esempi: liste ordinabili che rispondono solo al trascinamento, slider che rispondono solo al trascinamento, panning di mappe che richiede trascinamento. Il criterio non vieta il trascinamento; richiede un'alternativa come frecce su/giù per il riordino, o campi di input testuale per i valori degli slider.

2.5.8 Dimensione del Target (Minimo), Livello AA. I target del puntatore devono essere di almeno 24 per 24 pixel CSS, a meno che non siano in linea (link in un paragrafo), esposti in un default dello user-agent (come un menu a tendina <select>), essenziali per la funzione (un simulatore di tastiera di chitarra), o abbiano un controllo equivalente altrove nella pagina che rispetta 24x24. Il precedente criterio WCAG 2.1 2.5.5 fissava la soglia a 44x44 ma a Livello AAA; 2.5.8 rende obbligatorio un minimo più piccolo di 24x24 a Livello AA.

Gruppo accessibilità cognitiva

3.2.6 Aiuto Coerente, Livello A. Se i meccanismi di aiuto (un link "Contattaci", un widget di chat, un link di aiuto, un numero di telefono di aiuto) appaiono su più pagine, devono apparire nello stesso ordine relativo su ogni pagina. L'intento è ridurre il carico cognitivo: gli utenti trovano l'aiuto nel posto in cui se lo aspettano, ogni volta.

3.3.7 Inserimento Ridondante, Livello A. Agli utenti non dovrebbe essere richiesto di reinserire informazioni già inserite nello stesso processo. I moduli a più passi devono ricordare gli input precedenti. Il criterio non vieta di richiederle di nuovo quando è essenziale (verifica di sicurezza) o quando l'informazione è cambiata.

3.3.8 Autenticazione Accessibile (Minimo), Livello AA. L'autenticazione non può richiedere test di funzione cognitiva come ricordare una password, risolvere un puzzle o trascrivere un CAPTCHA basato su immagini, a meno che non venga fornita un'alternativa. Le alternative accettabili includono un password manager, un codice monouso, biometria o un token hardware. Questo è il criterio che ha posto fine al pattern "digita le lettere da questa immagine" per i siti accessibili.

3.3.9 Autenticazione Accessibile (Avanzato), Livello AAA. Versione più forte: i puzzle di riconoscimento di oggetti e di contenuto personale (quali immagini contengono un autobus?, qual era il nome del tuo primo animale domestico?) sono anch'essi vietati, a meno che non venga fornita un'alternativa.

L'unico criterio rimosso

4.1.1 Parsing è stato ritirato come obsoleto. Richiedeva che il contenuto fosse analizzabile: tag di apertura/chiusura completi, nessun ID duplicato, elementi annidati correttamente. Nel 2008 questo contava perché le tecnologie assistive analizzavano l'HTML autonomamente e fallivano sulla markup malformata. Nel 2024 ogni tecnologia assistiva consuma l'accessibility tree del browser, non l'HTML grezzo; il browser recupera già dalla markup malformata in modo elegante. WCAG 2.2 riconosce questo eliminando il criterio. Appare ancora nella conformità WCAG 2.0 e 2.1, ma non in 2.2.

Questo è l'unico criterio mai rimosso da WCAG. Gli audit esistenti 2.0 / 2.1 che hanno segnalato fallimenti 4.1.1 dovrebbero essere ri-testati rispetto a 2.2; alcuni di quei fallimenti ora non sono più problemi.

Riepilogo dei livelli di conformità

WCAG 2.2 aggiunge 4 criteri di Livello A o AA (2.5.7, 2.5.8, 2.4.11, 3.2.6, 3.3.7, 3.3.8) e 4 criteri di Livello AAA (2.4.12, 2.4.13, 3.3.9, più la branca AAA di 2.4.11). Per la maggior parte del lavoro di conformità legale, concentrati prima sulle aggiunte AA.

Impatto pratico, cosa correggere per primo

Per un sito tipico già conforme a WCAG 2.1 AA, il gap 2.2 AA è di solito:

1. 2.5.8 Dimensione del Target (Minimo), 24x24 pixel CSS. Verifica i tuoi pulsanti, i link icona e i piccoli toggle. I controlli più piccoli di 24x24 necessitano di un'area di tocco più grande, di più spaziatura attorno a essi, o di un controllo equivalente più grande nella pagina. Questo è il singolo fallimento 2.2 più comune sui siti esistenti.
2. 2.4.11 Focus Non Oscurato (Minimo). Cerca barre adesive in basso, footer adesivi, widget di chat, banner cookie che sovrappongono il fondo della viewport. Quando un elemento focalizzabile scorre dietro a uno di essi, il criterio fallisce. Correggi aggiungendo scroll-margin-bottom agli elementi focalizzabili pari all'altezza della barra adesiva.
3. 3.3.8 Autenticazione Accessibile (Minimo). Rimuovi i CAPTCHA basati su immagini dai flussi di login; sostituiscili con un approccio invisibile-CAPTCHA o limitato a rate. Permetti i password manager (non disabilitare autocomplete sui campi password). Permetti il paste dei codici monouso.
4. 2.5.7 Movimenti di Trascinamento. Fornisci un'alternativa non-trascinamento per qualsiasi interazione solo-trascinamento. Le liste ordinabili necessitano di frecce su/giù; gli slider di un input numerico; le mappe di pulsanti di pan.
5. 3.2.6 Aiuto Coerente. Se il tuo link "Contatti" o "Aiuto" appare su più pagine, posizionalo in modo coerente. La maggior parte dei siti lo fa già; il fallimento è sui siti che spostano il link di aiuto in base al tipo di pagina.
6. 3.3.7 Inserimento Ridondante. I moduli a più passi devono ricordare gli input precedenti. La maggior parte dei framework moderni lo fa già se cabli correttamente lo stato; il fallimento è sui moduli legacy a più pagine che resettano lo stato tra i passi.

Insidie comuni nell'implementare i nuovi criteri

• Trattare 4.1.1 Parsing come sparito ovunque. 4.1.1 è rimosso da WCAG 2.2 ma è ancora richiesto da WCAG 2.0 e 2.1. Se il tuo contratto o la normativa specifica 2.1, la regola di parsing si applica ancora.
• Interpretare male 2.5.8 Dimensione del Target. Il minimo 24x24 è per il target, non per l'icona visibile. Un'icona 16x16 dentro un pulsante 24x24 passa. Un'icona 16x16 in un pulsante 16x16 fallisce.
• Dimenticare le eccezioni di 2.5.8. Link in linea in un paragrafo, controlli predefiniti dello user-agent, target essenziali e controlli equivalenti più grandi altrove nella pagina sono tutti esenti.
• Implementare 3.3.8 rimuovendo tutti i CAPTCHA. Puoi mantenere i CAPTCHA; ti serve solo un percorso alternativo accessibile. Reverse Turing test, rate limit, magic link, passkey o token hardware sono tutti idonei.
• 2.4.11 confuso con 2.4.13. Focus Non Oscurato (2.4.11) riguarda se l'elemento focalizzato è visibile del tutto. Aspetto del Focus (2.4.13) riguarda l'indicatore di focus stesso che deve essere spesso e contrastato. Sono requisiti diversi a livelli diversi.
• Saltare 2.4.13 perché è AAA. Diversi governi (Norvegia, parti del Canada) hanno adottato regole di livello AAA per i siti del settore pubblico. Controlla la tua giurisdizione.

Strumenti per verificare la conformità a WCAG 2.2

Alcuni strumenti si sono già aggiornati per testare i nuovi criteri 2.2; altri testano ancora solo rispetto a 2.0 / 2.1.

Gli strumenti automatizzati catturano circa il 30-40% dei fallimenti WCAG anche al meglio. I nuovi criteri 2.2 sono particolarmente difficili da automatizzare (2.5.7 Trascinamento, 3.2.6 Aiuto Coerente, 3.3.7 Inserimento Ridondante, 3.3.8 Autenticazione) perché richiedono di comprendere il flusso utente, non solo la markup. Pianifica test manuali da tastiera a ogni rilascio.

Privacy e gli strumenti

Il color contrast checker, il WCAG heading checker e il generatore di palette accessibile su Absolutool girano tutti interamente nel tuo browser. I valori HTML o di colore che incolli vengono processati da JavaScript sul tuo dispositivo, i risultati vengono renderizzati nella pagina, e nulla viene inviato a un server. Nessuna telemetria sull'input, nessuno script di terze parti che tocca il contenuto, nessuna cache dopo la navigazione. Per gli audit interni di design system, i colori del marchio non ancora rilasciati, o qualsiasi dato di audit sotto embargo, quel flusso solo-locale è il default giusto. Gli strumenti possono girare offline una volta caricata la pagina, cosa che puoi verificare spegnendo la tua rete e ricontrollando una coppia di contrasto.