WCAG 2.2 vs WCAG 2.1: Cosa c’è di nuovo e cosa devi aggiornare

Più del 96% delle home page non soddisfa ancora i requisiti WCAG di base, secondo l’analisi sull’accessibilità 2024 di WebAIM — e questo rispetto a uno standard che aveva già cinque anni. Il 5 ottobre 2023, il W3C ha pubblicato WCAG 2.2 come standard web ufficiale, alzando l’asticella con nove nuovi criteri di successo e ritirando un criterio che era diventato obsoleto. Se gestisci un sito web, sviluppi prodotti digitali o supervisioni la conformità, questo aggiornamento non è qualcosa che puoi rimandare indefinitamente. I regolamenti nell’UE, nel Regno Unito e in un numero crescente di stati USA si stanno già muovendo per fare riferimento a WCAG 2.2 come loro parametro di riferimento.

Una breve storia: da WCAG 2.1 a WCAG 2.2

Le Web Content Accessibility Guidelines si sono evolute costantemente da quando WCAG 2.0 è stato lanciato nel dicembre 2008. WCAG 2.1 è arrivato nel giugno 2018, aggiungendo 17 nuovi criteri di successo con un’attenzione particolare agli utenti mobile e alle persone con ipovisione o disabilità cognitive. Per cinque anni è stato il parametro di conformità de facto per leggi come l’ADA, la Section 508 e la Direttiva UE sull’accessibilità del web.

WCAG 2.2 riprende esattamente da dove 2.1 si era fermato. Il W3C lo ha avviato con l’obiettivo esplicito di continuare a migliorare le linee guida sull’accessibilità per tre grandi gruppi: utenti con disabilità cognitive o di apprendimento, utenti con ipovisione e utenti con disabilità su dispositivi mobili. Questa continuità è importante perché significa che l’aggiornamento è evolutivo, non rivoluzionario — ma è comunque abbastanza significativo da richiedere un’azione da parte tua.

Una delle cose più importanti da capire a livello strutturale è che WCAG 2.2 è pienamente retrocompatibile con WCAG 2.1. Conformarsi a WCAG 2.2 significa automaticamente conformarsi anche a WCAG 2.1 e WCAG 2.0. Se la tua organizzazione è attualmente conforme a WCAG 2.1 AA, devi solo affrontare i nuovi criteri introdotti in 2.2 — non stai ricominciando da zero. Il W3C consiglia anche che, sebbene WCAG 2.0 e 2.1 restino raccomandazioni valide, le organizzazioni dovrebbero usare WCAG 2.2 per massimizzare l’applicabilità futura del loro lavoro sull’accessibilità.

Si prevede inoltre ampiamente che WCAG 2.2 sia l’ultima “dot-release” della famiglia WCAG 2.x. La prossima versione principale, WCAG 3.0, è una creatura completamente diversa — una riprogettazione dalle fondamenta di come sono strutturate le linee guida sull’accessibilità. Questo rende WCAG 2.2 il punto di arrivo definitivo di una linea che risale al 2008, e quello che devi mettere a posto ora.

I numeri: cosa è effettivamente cambiato

Essere precisi sull’entità del cambiamento. WCAG 2.1 conteneva 78 criteri di successo distribuiti su tre livelli di conformità (A, AA e AAA). WCAG 2.2 aggiunge nove nuovi criteri di successo e ne rimuove uno — il Criterio di successo 4.1.1 Parsing — lasciando il totale a 86 criteri attivi. Di queste nove aggiunte, due sono al Livello A, quattro al Livello AA e tre al Livello AAA.

Per la grande maggioranza delle organizzazioni che puntano alla conformità di Livello AA — il livello richiamato nella maggior parte delle leggi e dei regolamenti — l’impatto pratico è di sei nuovi criteri da implementare. Le tre aggiunte di Livello AAA sono considerate buone pratiche e sono spesso raccomandate per contesti governativi e sanitari, ma non sono un requisito legale rigido nella maggior parte delle giurisdizioni oggi.

I nuovi criteri affrontano principalmente quattro aree problematiche che gli audit di accessibilità nel mondo reale avevano ripetutamente segnalato come poco coperte dallo standard esistente: visibilità del focus da tastiera, interazioni touch e con puntatore, accessibilità cognitiva e barriere di autenticazione. Non si tratta di preoccupazioni teoriche. Sono il tipo di barriere che regolarmente impediscono alle persone con disabilità di completare attività quotidiane come effettuare il login, compilare un modulo o navigare in una pagina con un’intestazione fissa.

I nove nuovi criteri di successo spiegati

Ecco una ripartizione di ciascun nuovo criterio, di ciò che richiede e del perché è importante nella pratica. I criteri sono presentati per livello di conformità in modo che tu possa dare priorità al tuo lavoro di correzione.

Livello A (Minimo — richiesto per tutti)

• 2.4.11 Focus non oscurato (Minimo): Quando un componente dell’interfaccia utente riceve il focus da tastiera, non deve essere completamente nascosto da contenuti creati dall’autore. I colpevoli più comuni qui sono le intestazioni fisse, i banner dei cookie flottanti e i widget di live chat che si sovrappongono alla pagina. Se un utente che preme Tab atterra su un pulsante completamente coperto dalla barra di navigazione fissa, questo criterio è violato. Nota che un elemento parzialmente oscurato è accettabile al Livello A — l’elemento semplicemente non può essere nascosto al 100%.
• 2.5.7 Movimenti di trascinamento: Qualsiasi funzionalità che richiede un movimento di trascinamento — pensa al drag-and-drop per il caricamento di file, agli elementi di elenco ordinabili o ai controlli slider — deve essere operabile anche con un’azione a singolo puntatore (come un clic o un tap) senza trascinamento. Questo è fondamentale per gli utenti con disabilità motorie che non possono eseguire in modo affidabile gesti di trascinamento controllati. Il requisito si applica ai contenuti creati dall’autore; i comportamenti nativi del browser sono esenti.

Livello AA (Richiesto per la conformità standard)

• 2.4.12 Focus non oscurato (Avanzato): Una versione più rigorosa di 2.4.11. Al Livello AA, nessuna parte dell’indicatore di focus può essere nascosta da contenuti creati dall’autore quando un elemento riceve il focus da tastiera. Questo chiude la scappatoia presente nella versione di Livello A e richiede che gli elementi con focus siano completamente visibili — non solo parzialmente.
• 2.5.8 Dimensione del target (Minimo): L’area cliccabile o tappabile degli elementi interattivi deve essere almeno di 24×24 pixel CSS, con specifiche eccezioni per i link di testo in linea, gli elementi controllati dall’agente utente e i casi in cui esiste nelle vicinanze un target equivalente di 24×24. Si tratta di un cambiamento significativo rispetto a WCAG 2.1, dove una dimensione del target di 44×44 pixel era solo raccomandata a livello AAA. Ora una soglia minima è applicabile a livello AA. Nota che, sebbene 24×24px sia il minimo, il criterio AAA (2.5.5) raccomanda ancora 44×44px, che rimane il gold standard per un design adatto al touch.
• 3.2.6 Aiuto coerente: Se un sito web fornisce meccanismi di aiuto — contatti umani, strumenti di auto-aiuto, chat automatizzata o un modulo di contatto — e tali meccanismi compaiono su più pagine, devono apparire nella stessa posizione relativa su tutte queste pagine. Gli utenti che hanno bisogno di aiuto, in particolare quelli con disabilità cognitive, devono poterlo trovare sempre nello stesso posto senza doverlo cercare.
• 3.3.7 Inserimento ridondante: Le informazioni che un utente ha già inserito in una fase precedente dello stesso processo devono essere o precompilate automaticamente per lui o disponibili per la selezione, in modo che non debba digitarle di nuovo. Pensa ai flussi di checkout a più fasi che chiedono un indirizzo di fatturazione e poi chiedono di nuovo un indirizzo di spedizione — agli utenti dovrebbe essere offerta la possibilità di copiare ciò che hanno già inserito. Sono consentite eccezioni quando reinserire le informazioni è essenziale per la sicurezza (come confermare una password) o quando i dati inseriti in precedenza non sono più validi.
• 3.3.8 Autenticazione accessibile (Minimo): I test di funzione cognitiva — come risolvere un puzzle, memorizzare una password o trascrivere caratteri da un CAPTCHA in immagine — non devono essere richiesti come unico mezzo di autenticazione. Deve essere disponibile un metodo alternativo, oppure un meccanismo deve assistere l’utente (ad esempio consentendo l’uso di un password manager o permettendo il copia-incolla nel campo della password). Questo criterio non vieta i CAPTCHA in assoluto, ma richiede che non siano mai l’unica opzione per gli utenti che non possono completarli.

Livello AAA (Avanzato — raccomandato ma non obbligatorio per la maggior parte)

• 2.4.13 Aspetto del focus: Quando l’indicatore di focus da tastiera è visibile, deve soddisfare specifici requisiti minimi di dimensione e contrasto: l’area di focus deve essere almeno grande quanto un perimetro spesso 2 pixel CSS attorno all’elemento, e deve esserci un rapporto di contrasto di almeno 3:1 tra gli stati con focus e senza focus. Questo criterio era originariamente previsto per il Livello AA ma è stato spostato al AAA a causa della sua complessità. Significa che, per la sola conformità AA, non esiste ancora una dimensione minima definita in modo normativo per un indicatore di focus — è richiesto solo che sia visibile.
• 2.5.9 Movimenti di trascinamento (Avanzato): Aspetta — in questa versione non esiste un 2.5.9. Il miglioramento AAA relativo al trascinamento è incluso nel 3.3.9 qui sotto.
• 3.3.9 Autenticazione accessibile (Avanzato): Una versione più rigorosa di 3.3.8. Al Livello AAA, sono vietati anche i test di riconoscimento di oggetti e di contenuti personali (come “clicca su tutti i semafori” o “seleziona le foto dal tuo account”), non solo le eccezioni previste al Livello AA. Restano solo due eccezioni invece di quattro.

Cosa è stato rimosso: 4.1.1 Parsing

WCAG 2.2 rimuove un criterio di successo in vigore fin da WCAG 2.0: 4.1.1 Parsing. Questo criterio richiedeva originariamente che l’HTML fosse ben formato, con tag di apertura e chiusura completi, annidamento corretto e nessun attributo duplicato. L’intento era garantire che i browser e le tecnologie assistive potessero analizzare il markup in modo affidabile e presentare correttamente i contenuti agli utenti.

La rimozione non è controversa — riflette un reale cambiamento nel panorama tecnico. Dal 2008, i browser sono diventati straordinariamente bravi a gestire in modo elegante l’HTML malformato, seguendo un algoritmo di correzione degli errori coerente e standardizzato. Le tecnologie assistive come gli screen reader ora si basano sul Document Object Model (DOM) del browser, non sul codice sorgente HTML grezzo. Il W3C ha concluso che il criterio non fornisce più alcun beneficio significativo in termini di accessibilità nell’ambiente moderno. I problemi di accessibilità che in passato venivano intercettati da 4.1.1 sono ancora coperti da criteri più specifici come 1.3.1 (Info and Relationships) e 4.1.2 (Name, Role, Value).

Le implicazioni pratiche per il tuo team: se i tuoi strumenti di test automatici hanno segnalato errori di 4.1.1 Parsing, questi non sono più problemi di WCAG 2.2. Potresti vedere una riduzione degli errori riportati semplicemente per effetto dell’aggiornamento di versione, non perché qualcosa sia stato corretto. Detto questo, scrivere HTML valido e ben strutturato rimane una buona pratica importante — semplicemente non è più un requisito di conformità di per sé.

Implicazioni normative e legali

Capire i nuovi criteri è una cosa. Capire cosa significano per la tua esposizione legale è un’altra. La risposta breve è: WCAG 2.2 sta diventando la legge vigente in più giurisdizioni, e la tempistica si sta muovendo più velocemente di quanto molte organizzazioni si rendano conto.

Nel Regno Unito, gli enti del settore pubblico sono già tenuti a soddisfare WCAG 2.2 Livello AA ai sensi delle Public Sector Bodies Accessibility Regulations. Nell’Unione Europea, la EN 301 549 — lo standard tecnico che sostiene l’European Accessibility Act — è in fase di adozione di WCAG 2.2 come base. L’EAA stessa ha una scadenza di applicazione a giugno 2025 per la maggior parte delle organizzazioni del settore privato che offrono prodotti e servizi nell’UE. Diversi stati USA, tra cui il Colorado, hanno inoltre espresso l’intenzione di aggiornare le loro leggi statali sull’accessibilità da WCAG 2.1 a WCAG 2.2.

Negli Stati Uniti, il Titolo II dell’ADA fa attualmente riferimento a WCAG 2.1 AA come standard tecnico per i siti web di governi statali e locali. Tuttavia, i tribunali statunitensi hanno citato sempre più spesso WCAG 2.2 nelle cause relative all’accessibilità, e la traiettoria è chiara. Aspettare un mandato federale formale prima di agire è una strategia di conformità che comporta un rischio legale crescente, in particolare per le organizzazioni di e-commerce, servizi finanziari e sanità, che sono obiettivi di alto valore per il contenzioso in materia di accessibilità.

Anche se la tua organizzazione non è ancora legalmente obbligata a conformarsi a WCAG 2.2, soddisfare i nuovi criteri di successo prima che tardi ti garantirà di restare avanti rispetto ai cambiamenti normativi — e, cosa più importante, avanti rispetto alle reali barriere di accessibilità che i tuoi utenti affrontano oggi.

Come verificare e aggiornare il tuo sito

Se sei già conforme a WCAG 2.1 AA, il percorso di aggiornamento a WCAG 2.2 è gestibile. Ecco un quadro pratico per affrontarlo.

Inizia con un audit mirato dei sei nuovi criteri di Livello AA. Sono quelli che hanno peso legale per la maggior parte delle organizzazioni. Concentrati in particolare su 2.4.11 e 2.4.12 (focus oscurato), 2.5.8 (dimensione del target), 3.2.6 (aiuto coerente), 3.3.7 (inserimento ridondante) e 3.3.8 (autenticazione accessibile). Un ingegnere dell’accessibilità esperto può in genere verificare manualmente questi criteri in poche ore per un sito di complessità moderata.

Verifica prima i tuoi elementi fissi/a posizione fissa. I criteri sul focus oscurato (2.4.11 e 2.4.12) vengono violati da alcuni dei pattern di interfaccia più comuni sul web — intestazioni fisse, pulsanti di azione flottanti, barre di consenso ai cookie e widget di chat. Percorri l’intero sito usando solo il tasto Tab e osserva se qualche elemento con focus scompare mai sotto un livello fisso. Una correzione CSS è di solito semplice:

/* Impedire all'intestazione fissa di coprire gli elementi con focus */
:focus {
  scroll-margin-top: 80px; /* corrisponde all'altezza della tua intestazione fissa */
}

Verifica la dimensione del target di ogni elemento interattivo. Spesso è un risultato rapido sia in termini di conformità che di esperienza utente. Pulsanti, link, controlli di modulo e icone necessitano tutti di un minimo di 24×24 pixel CSS. Molti design system superano già questa soglia, ma i piccoli pulsanti icona — icone di chiusura, pulsanti di condivisione social e link di azione in linea — sono spesso i principali responsabili. Ispeziona i tuoi componenti e aggiungi padding o regola le dimensioni dove necessario.

Esamina con attenzione i tuoi flussi di autenticazione. Il criterio 3.3.8 (Autenticazione accessibile) ha un impatto concreto. Se usi un CAPTCHA che non può essere bypassato o risolto tramite un metodo alternativo, è probabile che tu non sia conforme. Valuta se i tuoi flussi di login, registrazione e autenticazione a due fattori consentono ai password manager di compilare automaticamente, permettono il copia-incolla, offrono un metodo di verifica alternativo (come un magic link o un codice monouso) o forniscono qualsiasi altra soluzione per gli utenti che non possono completare una sfida cognitiva.

Verifica i moduli a più fasi per l’inserimento ridondante. Mappa tutti i processi che si estendono su più fasi — checkout, flussi di onboarding, domande — e identifica ogni caso in cui a un utente viene chiesto di fornire informazioni che ha già fornito. Aggiungi logica di precompilazione o un interruttore “uguale a sopra” dove applicabile. Si tratta in genere di una modifica lato back-end o di gestione dello stato del modulo piuttosto che di una revisione architetturale complessa.

Verifica che i meccanismi di aiuto siano posizionati in modo coerente. Se hai un widget di chat, un link di aiuto o un numero di telefono che compare in un footer o in una sidebar su più pagine, controlla che la sua posizione relativa non cambi. Di solito è un problema di template o layout piuttosto che pagina per pagina — correggilo nella tua libreria di componenti o nel template del CMS e la correzione si propaga ovunque.

Usa strumenti automatici per la scoperta iniziale, ma non fermarti lì. Gli scanner automatici possono rilevare circa il 40% dei problemi WCAG 2.2 — sono utili per individuare violazioni della dimensione del target e problemi evidenti di gestione del focus, ma non possono valutare se un CAPTCHA è l’unica opzione di autenticazione o se un meccanismo di aiuto è posizionato in modo coerente. I test manuali, inclusa la navigazione solo da tastiera e i test con screen reader, restano essenziali. I test con utenti reali con disabilità individueranno problemi che nessuno strumento automatico potrà mai rilevare.

WCAG 2.2 e widget overlay: cosa dovresti sapere

I widget e gli SDK di overlay per l’accessibilità — strumenti come Accsible — possono fornire un aiuto significativo nell’individuare e correggere alcune categorie di problemi di accessibilità, in particolare per gli utenti che hanno bisogno di regolazioni in tempo reale come l’aumento della dimensione del font, modifiche del contrasto o miglioramenti della navigazione da tastiera. Vale la pena essere lucidi su ciò che gli overlay possono e non possono fare nel contesto della conformità a WCAG 2.2.

Gli overlay possono contribuire ad affrontare alcuni problemi di visibilità del focus, fornire modalità di navigazione alternative e offrire personalizzazioni lato utente che compensano alcune carenze a livello di design. Sono uno strato utile della “stack” di accessibilità, soprattutto per i team che devono migliorare rapidamente l’esperienza utente mentre è in corso un lavoro di correzione a lungo termine. Tuttavia, non sono un sostituto della correzione del codice sottostante. I nuovi criteri WCAG 2.2 — in particolare quelli relativi all’autenticazione (3.3.8), all’inserimento ridondante (3.3.7) e ai movimenti di trascinamento (2.5.7) — richiedono cambiamenti strutturali nel modo in cui la tua applicazione è costruita, non solo nel modo in cui è presentata.

L’approccio più efficace combina un overlay ben implementato per l’adattabilità lato utente con adeguate correzioni a livello di codice per i nuovi criteri 2.2. Pensa a un SDK di overlay come a un moltiplicatore di forza: estende la tua portata, migliora l’esperienza per più utenti e colma le lacune — ma le fondamenta devono comunque essere solide.

Punti chiave

• WCAG 2.2 aggiunge nove nuovi criteri di successo e rimuove una regola obsoleta (4.1.1 Parsing). È pienamente retrocompatibile con 2.1, quindi il lavoro di conformità già svolto non è sprecato — devi solo sovrapporre ciò che è nuovo.
• Per la conformità di Livello AA, concentrati su sei specifici nuovi criteri: Focus non oscurato (2.4.11 e 2.4.12), Dimensione minima del target (2.5.8), Aiuto coerente (3.2.6), Inserimento ridondante (3.3.7) e Autenticazione accessibile (3.3.8). Sono quelli giuridicamente rilevanti per la maggior parte delle organizzazioni.
• L’adozione normativa sta accelerando. Il settore pubblico del Regno Unito applica già WCAG 2.2, l’UE vi sta passando nell’ambito dell’European Accessibility Act e i tribunali USA lo citano sempre più spesso. Non aspettare un mandato formale nella tua giurisdizione prima di agire.
• Gli strumenti automatici rilevano solo circa il 40% dei problemi WCAG 2.2 — i test manuali, le walkthrough di navigazione solo da tastiera e i test con utenti reali sono essenziali per ottenere una conformità autentica, soprattutto per i nuovi criteri relativi all’autenticazione e all’accessibilità cognitiva.
• I risultati rapidi più comuni sono la correzione delle intestazioni fisse che oscurano gli elementi con focus, l’ingrandimento dei piccoli target tappabili e la verifica dei flussi di login/autenticazione per la dipendenza dai CAPTCHA. Questi cambiamenti sono spesso a basso sforzo e ad alto impatto — un buon punto di partenza per il tuo sprint di correzione WCAG 2.2.