Novità in WCAG 2.2: Spiegazione dei 9 nuovi criteri di successo

Gli standard per l’accessibilità web non restano mai fermi. Man mano che le abitudini di navigazione si spostano verso il mobile, sempre più persone si affidano alla tastiera e alla navigazione vocale, e le lacune delle linee guida più vecchie diventano più evidenti, le regole per costruire siti web accessibili vengono aggiornate per stare al passo. L’aggiornamento più recente è WCAG 2.2(opens in a new tab).

Una distinzione importante: WCAG 2.2 non sostituisce WCAG 2.0 o 2.1 — tutte e tre restano standard attivi. Ma il World Wide Web Consortium (W3C) raccomanda di lavorare verso la versione più recente, perché si basa su tutto ciò che è venuto prima.

Per la maggior parte delle organizzazioni, la domanda è “cosa è cambiato in WCAG 2.2 e cosa devo fare” piuttosto che “cos’è WCAG 2.2”. Se già rispetti WCAG 2.1 Livello AA, sei già a buon punto: WCAG 2.2 aggiunge nove nuovi criteri di successo e ne ritira uno, quindi la differenza è piccola ma specifica.

Di seguito analizzeremo tutti e nove i nuovi criteri, spiegheremo cosa è cambiato rispetto a WCAG 2.1 e mostreremo come verificare dove il tuo sito non è conforme.

L’evoluzione delle Linee guida per l’accessibilità dei contenuti web

WCAG si è evoluto costantemente da quando il W3C ha pubblicato la prima versione nel 1999. WCAG 2.0 (creato nel 2008) ha introdotto i quattro principi dell’accessibilità web ed esteso le linee guida a tutti i contenuti digitali; WCAG 2.1 (creato nel 2018) ha aggiunto criteri per il mobile e una gamma più ampia di disabilità; e WCAG 2.2, rilasciato nell’ottobre 2023, aggiunge i nove nuovi criteri di successo trattati di seguito, focalizzati su utenti con ipovisione, disabilità cognitive o di apprendimento e abilità motorie limitate.

WCAG 2.2: Novità e perché è importante

Le nove aggiunte si suddividono in tre livelli di conformità: A, AA e AAA, che indicano quanto un sito deve fare per essere conforme, con la maggior parte degli obiettivi legali e organizzativi che si attestano al livello AA. La tabella seguente copre ciascun nuovo criterio: cosa richiede, a chi aiuta e perché è importante nella pratica.

WCAG 2.4.11: Focus non oscurato (Minimo) (Livello AA)

WCAG 2.4.11(opens in a new tab) richiede che, quando un elemento riceve il focus da tastiera, almeno una parte di esso rimanga visibile e non sia completamente nascosta da altri contenuti, come intestazioni fisse o pop-up. Per gli utenti vedenti che si affidano alla tastiera per navigare nei siti web, sapere dove si trova il focus è fondamentale per muoversi tra le pagine. Tuttavia, gli elementi con focus possono talvolta essere oscurati da altri elementi web.

Aggiungere un elemento di focus visibile può aiutare a migliorare il focus e la navigazione per utenti con disabilità cognitive o visive; tuttavia, più l’indicatore di focus è visibile, più è facile per gli utenti seguirlo durante la navigazione.

WCAG 2.4.12: Focus non oscurato (Avanzato) (Livello AAA)

WCAG 2.4.12(opens in a new tab) va oltre il 2.4.11, richiedendo che un elemento con focus da tastiera sia completamente visibile, senza che nessuna parte sia nascosta da altri contenuti nella pagina. Questo garantisce che l’elemento su cui si trova il focus sia pienamente visibile all’utente, migliorando la navigazione per chi ha una visione limitata o ridotta. Anche gli utenti con limitazioni di attenzione (come difficoltà di memoria a breve termine) possono concentrarsi meglio quando il focus è completamente visibile.

WCAG 2.4.13: Aspetto del focus (Livello AAA)

WCAG 2.4.13(opens in a new tab) richiede che gli indicatori di focus siano abbastanza grandi e abbiano almeno un contrasto di colore di 3:1 tra stato con e senza focus, così che gli utenti possano vedere chiaramente quale elemento è in focus. Ad esempio, quando un link riceve il focus, appare un contorno attorno ad esso. Il colore di questo contorno deve avere un contrasto sufficiente con il colore di sfondo della pagina.

Garantire che gli indicatori di focus abbiano un contrasto di colore sufficiente assicura che gli utenti possano vedere facilmente anche piccoli cambiamenti visivi. Questo è particolarmente utile per le persone anziane o per chi usa la tastiera, che possono così seguire facilmente la propria posizione nella pagina durante la navigazione.

WCAG 2.5.7: Movimenti di trascinamento (Livello AA)

WCAG 2.5.7(opens in a new tab) richiede che qualsiasi azione eseguita tramite trascinamento abbia anche un’alternativa a singolo puntatore, come un tocco o un pulsante a schermo, a meno che il trascinamento non sia essenziale. Ad esempio, un sito web potrebbe permettere l’uso della tastiera con le frecce direzionali oppure fornire pulsanti a schermo che l’utente può premere per spostare uno slider o riordinare una lista. Questo assicura che anche chi ha difficoltà o non può eseguire movimenti di trascinamento possa comunque utilizzare l’interfaccia drag-and-drop.

WCAG 2.5.8: Dimensione del target (Minimo) (Livello AA)

WCAG 2.5.8(opens in a new tab) richiede che i target cliccabili siano almeno 24x24 pixel CSS, oppure che abbiano uno spazio sufficiente attorno per evitare attivazioni accidentali. Quando i pulsanti e altri elementi cliccabili sono piccoli, è difficile per chi ha tremori alle mani o altre disabilità motorie fini attivarli senza premere accidentalmente un altro elemento.

Questa nuova capacità permette alle persone con limitazioni motorie fini di cliccare facilmente sui pulsanti. Migliora anche l’esperienza mobile, poiché gli utenti hanno abbastanza spazio per selezionare pulsanti più piccoli.

WCAG 3.2.6: Aiuto coerente (Livello A)

WCAG 3.2.6(opens in a new tab) richiede che i meccanismi di aiuto, come dettagli di contatto o un’opzione chat, compaiano nello stesso ordine relativo su ogni pagina in cui sono presenti. Ad esempio, se un sito ha un’opzione ‘Chat’, dovrebbe apparire sempre nell’angolo in basso a destra di ogni pagina. Oppure i dettagli di contatto, come numero di telefono, orari di apertura o indirizzo email, sono elencati nel footer di ogni pagina.

Elencando costantemente le informazioni utili nello stesso posto, le persone che hanno difficoltà a trovare aiuto o a ricordare dove sono elencate le informazioni possono trovarle più facilmente.

WCAG 3.3.7: Inserimento ridondante (Livello A)

WCAG 3.3.7(opens in a new tab) richiede che le informazioni già inserite da un utente in un processo vengano auto-compilate o rese selezionabili invece di essere richieste nuovamente. Questo evita agli utenti di inserire ripetutamente le stesse informazioni, riduce la probabilità di errori e la necessità di digitare testo.

WCAG 3.3.8: Autenticazione accessibile (Minimo) (Livello AA)

WCAG 3.3.8(opens in a new tab) richiede che i login non dipendano da un test di funzione cognitiva(opens in a new tab), come memorizzare una password o risolvere un puzzle, a meno che non sia disponibile un metodo alternativo o assistenza. Questo semplifica il processo di autenticazione per le persone con disabilità cognitive e permette loro di autenticarsi in modi adatti alle proprie esigenze. Un meccanismo utile può essere l’uso di gestori di password, che aiutano a ridurre la necessità di memoria e la fatica di digitare ripetutamente le informazioni.

WCAG 3.3.9: Autenticazione accessibile (Avanzata) (Livello AAA)

WCAG 3.3.9(opens in a new tab) applica la stessa regola del 3.3.8 ma in modo più restrittivo, vietando il riconoscimento di oggetti o contenuti forniti dall’utente (come un’immagine caricata) come metodo di autenticazione. Questo garantisce che utenti con difficoltà cognitive legate a memoria, lettura (ad esempio dislessia), numeri o limiti di elaborazione percettiva possano accedere o autenticarsi facilmente.

Cosa è stato rimosso: 4.1.1 Parsing

WCAG 2.2 ha rimosso un criterio, 4.1.1 Parsing, segnando la prima volta che un criterio di successo viene ritirato dalle linee guida. Il criterio richiedeva originariamente un markup HTML pulito e ben formato, ma il W3C ha stabilito che fosse obsoleto perché i browser moderni e le tecnologie assistive ora gestiscono senza problemi gli errori di markup che copriva.

La sua rimozione non significa che un HTML valido abbia smesso di essere importante; un markup ben strutturato è ancora utile per l’accessibilità e rimane una buona pratica. L’effetto pratico è limitato: se i tuoi test automatici segnalavano errori di parsing come fallimento WCAG, quei fallimenti specifici non contano più contro la conformità 2.2.

WCAG 2.2 vs. WCAG 2.1: Cosa è cambiato davvero

WCAG 2.2 è un superset di WCAG 2.1: mantiene tutti i criteri di successo del 2.1 tranne il 4.1.1 Parsing ritirato, e ne aggiunge nove nuovi. La conseguenza pratica è quella che conta: rispettare WCAG 2.2 significa anche rispettare il 2.1, quindi non c’è alcun compromesso nel puntare alla versione più recente. Se già rispetti WCAG 2.1 Livello AA, il vero gap sono solo i sei nuovi criteri di livello A e AA; le tre aggiunte di livello AAA sono opzionali. In breve, passare dal 2.1 al 2.2 non è una ricostruzione — è una breve lista di cose da fare.

Checklist WCAG 2.2 (Livello AA)

Se già rispetti WCAG 2.1 Livello AA, questi sono i sei nuovi criteri da affrontare per raggiungere WCAG 2.2 Livello AA. Le tre aggiunte di livello AAA (2.4.12, 2.4.13 e 3.3.9) sono opzionali.

• Il focus da tastiera resta visibile (2.4.11): Tabula ogni pagina e verifica che l’elemento con focus non sia mai completamente nascosto da intestazioni fisse, banner cookie o pop-up.

• Il trascinamento ha un’alternativa (2.5.7): Per ogni azione drag-and-drop (slider, riordino, controlli mappa), fornisci un’opzione a singolo puntatore, come un tocco o pulsanti a schermo.

• I target sono abbastanza grandi (2.5.8): Assicurati che gli elementi cliccabili siano almeno 24×24 pixel CSS, o abbiano abbastanza spazio da non essere facilmente premuti per errore.

• L’aiuto è coerente (3.2.6): Posiziona i meccanismi di aiuto (es. link di contatto, chat, supporto, ecc.) nella stessa posizione relativa su ogni pagina che li offre.

• Non chiedere due volte le stesse informazioni (3.3.7): Auto-compila o consenti agli utenti di riutilizzare le informazioni già inserite in precedenza nello stesso processo, a meno che il reinserimento non sia essenziale.

• I login non si basano su memoria o puzzle (3.3.8): Offri un’alternativa accessibile ovunque l’autenticazione richieda un test di funzione cognitiva, come ricordare una password o risolvere un CAPTCHA.

Molti di questi aspetti, in particolare la visibilità del focus, l’aiuto coerente e l’autenticazione accessibile, non possono essere verificati completamente dagli strumenti automatici. Una scansione gratuita dell’accessibilità è un modo rapido per vedere la situazione attuale del tuo sito.

Come AudioEye semplifica la conformità a WCAG 2.2

WCAG 2.2 ha affinato l’accessibilità invece di reinventarla, aggiungendo nove criteri mirati che colmano reali lacune per chi naviga con la tastiera, gestisce i login o usa dispositivi mobili. La sfida per la maggior parte delle organizzazioni è verificare che il proprio sito sia effettivamente conforme e mantenerlo tale mentre gli standard continuano a evolversi.

Ecco perché l’approccio giusto è fondamentale: diversi criteri WCAG 2.2, tra cui visibilità del focus, aiuto coerente e autenticazione accessibile, non possono essere confermati solo tramite automazione.

La piattaforma AudioEye è costruita proprio per questo. AudioEye aiuta le organizzazioni a rispettare WCAG 2.2 Livello AA combinando correzioni automatiche su larga scala con esperti certificati e test con la comunità delle persone con disabilità per verificare i criteri che l’automazione non può confermare da sola. E con il monitoraggio continuo, il tuo sito viene controllato mentre cambia e i problemi vengono risolti più rapidamente, restando al passo con WCAG man mano che evolve, non solo dove si trova oggi.

Vuoi vedere a che punto è il tuo sito rispetto a WCAG 2.2? Usa il controllo gratuito dell’accessibilità del sito web per scoprirlo. Oppure prenota una demo, e ti mostreremo come AudioEye ti aiuta a rispettare gli standard di accessibilità e a mantenerli nel tempo.