Riepilogo Rapido dei Cambiamenti
WCAG 2.2, pubblicato nell'ottobre 2023, introduce 9 nuovi criteri di successo e ne rimuove uno esistente. Le modifiche includono 2 criteri di livello A, 4 di livello AA e 3 di livello AAA, concentrandosi principalmente sul miglioramento dell'accessibilità per utenti con disabilità cognitive e utenti di dispositivi mobili.
Il criterio rimosso, 4.1.1 Analisi Sintattica (Parsing), è stato considerato obsoleto poiché i browser moderni gestiscono automaticamente gli errori HTML. Questo aggiornamento rafforza l'impegno del W3C verso standard di accessibilità che riflettono le esigenze attuali degli utenti e le capacità tecnologiche.
Introduzione ai Nuovi Criteri di Successo
I nuovi criteri di WCAG 2.2 affrontano lacune identificate nelle versioni precedenti, in particolare in aree come la visibilità del focus da tastiera, le interazioni tattili e i processi di autenticazione. Questi cambiamenti rispondono direttamente a ricerche di usabilità e feedback da utenti con disabilità.
La maggior parte dei nuovi requisiti si concentra sul livello AA, lo standard raccomandato per la conformità legale in molte giurisdizioni, inclusa la Direttiva Europea sull'Accessibilità (EAA). Le organizzazioni che già rispettano WCAG 2.1 livello AA troveranno che la transizione a 2.2 richiede sforzi mirati in aree come le dimensioni dei target tattili e la gestione del focus visivo.
2.4.11 Focus Non Oscurato (Minimo) - Livello AA
Questo nuovo criterio di livello AA richiede che quando un componente dell'interfaccia riceve il focus da tastiera, almeno parte dell'indicatore di focus deve essere visibile senza che l'utente debba spostare la finestra o il contenuto. Questo affronta un problema comune in cui intestazioni fisse, banner di cookie o barre degli strumenti coprono completamente l'elemento focalizzato.
Per soddisfare questo criterio, gli sviluppatori devono assicurarsi che almeno un pixel dell'indicatore di focus rimanga visibile quando l'utente naviga da tastiera. Le soluzioni tipiche includono l'aggiustamento automatico dello scroll per mantenere visibili gli elementi focalizzati, o la riprogettazione di componenti fissi in modo che non ostruiscano aree di contenuto interattivo. Questo requisito beneficia significativamente gli utenti con disabilità motorie che dipendono esclusivamente dalla navigazione da tastiera.
2.4.12 Focus Non Oscurato (Avanzato) - Livello AAA
La versione avanzata di livello AAA di questo criterio richiede che nessuna parte dell'indicatore di focus sia oscurata da contenuto creato dall'autore quando un componente riceve il focus. Questo va oltre il requisito minimo proibendo qualsiasi occlusione, anche parziale.
Mentre il livello AA permette occlusione parziale purché qualcosa del focus rimanga visibile, il livello AAA richiede visibilità completa e senza ostruzioni. Questo può richiedere tecniche avanzate come il riposizionamento dinamico di elementi fluttuanti, gestione sofisticata dello z-index, o meccanismi di scroll automatico più aggressivi. Le organizzazioni che cercano la massima accessibilità dovrebbero considerare questo standard più rigoroso.
2.4.13 Aspetto del Focus - Livello AAA
Questo criterio di livello AAA stabilisce requisiti specifici per come deve apparire l'indicatore di focus. Richiede che l'indicatore di focus abbia un'area minima equivalente a un bordo di 2 pixel CSS di spessore intorno al componente, e che il contrasto di colore tra gli stati focalizzato e non focalizzato sia di almeno 3:1.
Il criterio permette anche che l'indicatore di focus utilizzi il contorno predefinito del browser, che tipicamente soddisfa automaticamente questi requisiti. Per i designer che creano indicatori di focus personalizzati, questo significa calcolare attentamente l'area dell'indicatore (generalmente il perimetro dell'elemento moltiplicato per 2 pixel) e assicurare sufficiente contrasto di colore. Questi requisiti quantificabili eliminano ambiguità su cosa costituisce un indicatore di focus adeguato.
2.5.7 Movimenti di Trascinamento - Livello AA
Il criterio 2.5.7 richiede che tutte le funzionalità che utilizzano movimenti di trascinamento (come riordinare liste, slider o gesti di scorrimento) possano anche essere operate con un singolo puntatore senza trascinare, a meno che il trascinamento sia essenziale. Questo beneficia gli utenti con tremori, controllo motorio limitato o che usano tecnologie assistive alternative.
Le implementazioni tipiche includono fornire pulsanti freccia per riordinare liste, campi di input numerico per slider, o gesti touch singoli come alternativa a scorrimenti. Ad esempio, un carosello di immagini che richiede scorrimento deve anche offrire pulsanti avanti/indietro. Questo requisito riconosce che le interazioni di trascinamento, sebbene intuitive per molti utenti, creano barriere significative per altri.
2.5.8 Dimensione Target (Minimo) - Livello AA
Questo criterio di livello AA introduce un requisito di dimensione minima di 24x24 pixel CSS per i target tattili, con diverse eccezioni. Target più piccoli sono accettabili se c'è spazio sufficiente intorno (almeno 24 pixel di separazione da altri target), se il target è in una frase, se la dimensione è controllata dall'user agent, o se una particolare presentazione è essenziale.
Questo standard è più flessibile del criterio esistente 2.5.5 di livello AAA (che richiede 44x44 pixel), riconoscendo sfide pratiche di design pur fornendo protezioni significative. Aree target più grandi beneficiano tutti gli utenti, in particolare quelli con disabilità motorie, tremori o che usano dispositivi mobili in contesti difficili. I designer devono controllare elementi interattivi come icone di navigazione, pulsanti di chiusura e link inline per soddisfare questa soglia.
3.2.6 Aiuto Coerente - Livello A
Il criterio 3.2.6 richiede che quando meccanismi di aiuto come informazioni di contatto, supporto tecnico, autoaiuto o opzioni di contatto umano appaiono su più pagine, devono apparire nello stesso ordine relativo su ogni pagina. Questo aiuta gli utenti con disabilità cognitive a localizzare l'aiuto in modo prevedibile.
Il criterio non detta quale tipo di aiuto debba essere fornito o dove debba apparire sulla pagina, solo che la sua posizione relativa rimanga coerente in tutto il sito. Ad esempio, se la tua pagina di contatto elenca email, poi telefono, poi chat, tutte le pagine con queste opzioni devono usare lo stesso ordine. Questa prevedibilità riduce il carico cognitivo e aiuta gli utenti che potrebbero necessitare di più tentativi per trovare informazioni di aiuto.
3.3.7 Inserimento Ridondante - Livello A
Questo criterio di livello A impedisce che agli utenti sia richiesto di inserire le stesse informazioni più volte durante una singola sessione, a meno che il reinserimento non sia essenziale per la sicurezza, le informazioni precedenti non siano più valide, o sia necessario per assicurare che il contenuto sia corretto. Le informazioni devono essere compilate automaticamente o selezionabili dall'utente.
Le implementazioni comuni includono il trasferimento di indirizzi di spedizione a moduli di fatturazione, il ricordo di informazioni utente attraverso processi multi-step, o il pre-popolamento di campi con dati precedentemente inseriti. Questo requisito beneficia particolarmente gli utenti con disabilità cognitive, limitazioni di memoria, o coloro che usano metodi di input alternativi dove digitare è costoso. I moduli di e-commerce, i processi di registrazione multi-step e le applicazioni lunghe sono candidati principali per l'ottimizzazione sotto questo criterio.
3.3.8 Autenticazione Accessibile (Minimo) - Livello AA
Il criterio 3.3.8 richiede che i test di funzione cognitiva (come ricordare password o risolvere puzzle) non siano richiesti per nessun passo in un processo di autenticazione, a meno che quel passo fornisca alternative. I metodi alternativi accettabili includono il riconoscimento di oggetti, contenuti personali (come foto che l'utente ha caricato), o meccanismi che non dipendono dal ricordare o trascrivere informazioni.
In pratica, questo significa che i siti devono offrire opzioni come autenticazione biometrica, gestori di password, link magici via email, o codici di accesso monouso insieme alle password tradizionali. Questo requisito riconosce che ricordare password complesse crea barriere significative per utenti con disabilità cognitive, beneficiando anche utenti anziani e coloro con condizioni che influenzano la memoria. L'autenticazione a due fattori deve anche conformarsi a questo criterio se richiesta.
3.3.9 Autenticazione Accessibile (Avanzata) - Livello AAA
La versione avanzata di livello AAA di questo criterio elimina completamente l'eccezione permessa al livello AA, richiedendo che nessun test di funzione cognitiva sia necessario per nessun passo in un processo di autenticazione. Questo significa che anche riconoscere oggetti o contenuti personali non può essere l'unico metodo di autenticazione.
La conformità al livello AAA tipicamente richiede l'implementazione di metodi di autenticazione completamente non cognitivi come biometria (impronta digitale, riconoscimento facciale), token hardware, o autenticazione basata sul possesso di dispositivi (link magici, codici monouso). Mentre questo livello è opzionale, rappresenta il più alto standard di accessibilità di autenticazione e dovrebbe essere considerato da organizzazioni che servono popolazioni con bisogni cognitivi significativi o quelle che cercano la massima inclusività.
Criterio Rimosso: 4.1.1 Analisi Sintattica
WCAG 2.2 rimuove ufficialmente il criterio 4.1.1 Analisi Sintattica, che richiedeva che il contenuto implementato usando linguaggi di markup avesse elementi con tag di inizio e fine completi, elementi annidati secondo le loro specifiche, nessun attributo duplicato e ID univoci. Questo criterio è stato considerato obsoleto perché i browser moderni sono migliorati drammaticamente nella gestione degli errori HTML.
Tuttavia, la rimozione non significa che il markup valido sia senza importanza. Un HTML ben formato rimane cruciale per l'accessibilità perché le tecnologie assistive dipendono da strutture DOM prevedibili. Il Gruppo di Lavoro ha aggiornato la nota esplicativa per chiarire che mentre l'analisi sintattica rigorosa non è più un requisito di conformità, gli sviluppatori devono ancora seguire le migliori pratiche HTML per assicurare compatibilità con le tecnologie assistive. Gli strumenti di validazione rimangono preziosi per identificare problemi che potrebbero influenzare l'esperienza utente.
Requisiti della Direttiva Europea sull'Accessibilità (EAA)
La Direttiva Europea sull'Accessibilità (EAA), che entra in vigore il 28 giugno 2025, fa riferimento a WCAG 2.1 livello AA come suo standard tecnico. Tuttavia, i regolatori e i gruppi di advocacy hanno indicato che mentre WCAG 2.1 è il requisito legale minimo, le organizzazioni dovrebbero puntare a WCAG 2.2 quando possibile, poiché rappresenta le migliori pratiche attuali.
Gli stati membri dell'UE stanno implementando l'EAA attraverso legislazione nazionale, e alcuni potrebbero adottare WCAG 2.2 come loro standard di riferimento direttamente. Le organizzazioni che operano in Europa dovrebbero monitorare gli sviluppi normativi nei loro mercati specifici mentre pianificano le loro strategie di accessibilità. Implementare WCAG 2.2 ora fornisce una protezione più solida e prepara le organizzazioni per futuri requisiti normativi probabili.
Dovresti Puntare a WCAG 2.2?
Per la maggior parte delle organizzazioni, la risposta è sì. WCAG 2.2 è completamente retrocompatibile, il che significa che qualsiasi cosa conforme a WCAG 2.1 soddisfa anche 2.1 sotto 2.2 (eccetto per il criterio rimosso 4.1.1). I nuovi criteri affrontano lacune di accessibilità del mondo reale che colpiscono utenti reali, in particolare quelli con disabilità cognitive e utenti mobili.
Le considerazioni pratiche includono che WCAG 2.2 rappresenta l'attuale standard del settore e probabilmente diventerà il requisito legale man mano che le normative si aggiorneranno. Le modifiche richieste sono generalmente modeste per i siti già conformi a 2.1 livello AA, concentrandosi su dimensioni target, visibilità del focus e miglioramenti dei moduli. L'adozione anticipata dimostra impegno per l'accessibilità e riduce il rischio di rimedi costosi in seguito. A meno che tu non abbia vincoli molto specifici, implementare WCAG 2.2 offre il miglior rapporto tra miglioramento dell'accessibilità e sforzo richiesto.
Come Testare la Conformità a WCAG 2.2
I test di WCAG 2.2 richiedono una combinazione di strumenti automatizzati, ispezione manuale e test con utenti. Inizia usando strumenti di accessibilità automatizzati come axe DevTools, WAVE o Lighthouse per catturare problemi ovvi, ma riconosci che l'automazione può rilevare solo circa il 30-40% dei problemi di accessibilità. La revisione manuale è essenziale per i nuovi criteri.
Per i criteri specifici di 2.2, testa la navigazione da tastiera con intestazioni fisse per verificare la visibilità del focus (2.4.11), misura le dimensioni dei target con gli strumenti per sviluppatori del browser (2.5.8), completa moduli multi-step per verificare l'inserimento ridondante (3.3.7), e rivedi i flussi di autenticazione per alternative cognitive (3.3.8). Considera di assumere auditor di accessibilità professionisti per valutazioni approfondite, e soprattutto, conduci test di usabilità con utenti che hanno disabilità per scoprire problemi che i test tecnici potrebbero perdere. La conformità non è un evento una tantum ma un processo continuo di monitoraggio, test e miglioramento.