Novità in WCAG 2.2: Cambiamenti e aggiornamenti rispetto a WCAG 2.1

Le Web Content Accessibility Guidelines(opens in a new tab) (WCAG) forniscono un quadro di riferimento per creare contenuti digitali accessibili a tutti gli utenti e conformi alle principali leggi sull’accessibilità. Seguire le WCAG aiuta a garantire che tutti possano utilizzare i tuoi contenuti digitali, amplia la portata del tuo pubblico e riduce il rischio legale. 

Man mano che il settore dell’accessibilità e la tecnologia continuano a evolversi, anche le linee guida WCAG si aggiornano. L’ultima versione, pubblicata nell’ottobre 2023, rafforza gli standard di accessibilità digitale. Di seguito analizziamo le novità di WCAG 2.2 e come applicare questi aggiornamenti ai tuoi contenuti digitali.

Una serie di quattro simboli di accessibilità che sfumano in lontananza, su uno sfondo a gradiente arcobaleno.

Che cos’è WCAG 2.2?

Pubblicate dal World Wide Web Consortium(opens in a new tab) (W3C), le WCAG sono standard internazionali che spiegano come rendere siti web e contenuti digitali accessibili alle persone con disabilità. Il W3C ha pubblicato per la prima volta gli standard WCAG il 5 maggio 1999. Con l’evoluzione e la crescente complessità delle esperienze digitali, il W3C aggiorna le linee guida sulla base di rigorose revisioni, numerosi cicli di modifica e feedback del pubblico(opens in a new tab). Dalla pubblicazione, il W3C ha annunciato tre versioni delle linee guida, ognuna delle quali si basa sulla precedente.

Ogni versione delle WCAG contiene criteri di successo organizzati in tre livelli di conformità:

• Livello A: Il livello minimo di conformità, il Livello A contiene criteri di successo di base per rimuovere gravi barriere all’accessibilità che colpiscono una vasta gamma di utenti. 

• Livello AA: Il criterio di successo del Livello AA rimuove ulteriori barriere e stabilisce un livello di accessibilità che funziona per la maggior parte degli utenti con disabilità e tecnologie assistive, inclusi i lettori di schermo. 

• Livello AAA: Il livello di conformità più rigoroso, il Livello AAA contiene criteri di successo aggiuntivi per stabilire il massimo livello possibile di accessibilità. Dichiarare la conformità al Livello AAA significa che il tuo sito soddisfa tutti i criteri di successo WCAG.

Icona di accessibilità con l’etichetta 2.1 accanto a un’icona di accessibilità con l’etichetta 2.2

Qual è la differenza tra WCAG 2.1 e 2.2?

La differenza principale tra WCAG 2.1 e WCAG 2.2 è il focus. Da ottobre 2025, WCAG 2.2 è lo standard di accessibilità W3C attuale(opens in a new tab), e pone maggiore enfasi sull’usabilità — in particolare per la navigazione tramite tastiera, le interazioni touch e l’accessibilità cognitiva — mantenendo i requisiti WCAG 2.1 esistenti.

I nuovi criteri di successo di WCAG 2.2 affrontano barriere comuni che gli utenti incontrano ancora nelle esperienze digitali reali, tra cui indicatori di focus oscurati, interazioni solo tramite trascinamento, target touch troppo piccoli, posizionamento incoerente dell’aiuto e flussi di autenticazione inaccessibili.

Questi aggiornamenti migliorano l’accessibilità su siti web, app mobili, documenti online e altri contenuti digitali, continuando ad allinearsi ai quattro principi delle WCAG: i contenuti devono essere percepibili, utilizzabili, comprensibili e robusti. 

È inoltre importante notare che WCAG 2.2 non sostituisce le versioni precedenti delle linee guida. Tutti i criteri di successo di WCAG 2.1 (e WCAG 2.0) rimangono invariati e pienamente applicabili, con WCAG 2.2 che si limita a costruire su queste basi.

Nuovi criteri di successo WCAG 2.2 spiegati

Con una migliore comprensione di come WCAG 2.2 differisce dalle versioni precedenti, esaminiamo i nuovi criteri di WCAG 2.2(opens in a new tab).

2.4.11 Focus non oscurato (Minimo)

Questo criterio(opens in a new tab) garantisce che un indicatore visivo di focus tramite tastiera (come un bordo o un’evidenziazione) sia almeno parzialmente visibile agli utenti. Aggiungere un indicatore di focus assicura che gli utenti possano individuare e interagire con il componente focalizzato, come pulsanti o link. 

Quando si progetta con header fissi, elementi sticky o modali, assicurarsi che il focus tramite tastiera non finisca dietro elementi dell’interfaccia che lo coprono. Gli sviluppatori possono usare JavaScript per scorrere gli elementi in vista tramite ‘.scrollIntoView({block:”nearest”})’ o metodi simili. Anche il CSS dovrebbe evitare layout fissi che coprono elementi interattivi senza riposizionarli dinamicamente. 

2.4.12 Focus non oscurato (Avanzato)

Basandosi sul requisito minimo, il criterio avanzato(opens in a new tab) richiede indicatori visivi ancora più robusti per gli stati di focus. Richiede che l’intero elemento in focus sia completamente visibile senza essere oscurato in alcun modo. Questo incoraggia i designer a utilizzare elementi che si distinguano chiaramente, migliorando la visibilità e la chiarezza degli oggetti focalizzati. 

Per soddisfare questo requisito, gli sviluppatori dovrebbero creare interfacce che facciano sempre scorrere l’elemento in focus completamente in vista. Evitare visibilità parziale o sovrapposizioni di componenti dell’interfaccia. Usare JavaScript come ‘.scrollIntoView({block:”center”})’ o implementare logiche di scroll personalizzate che garantiscano un target in focus completamente visibile in tutte le dimensioni e orientamenti del viewport.

2.4.13 Aspetto del focus

Il criterio 2.4.13(opens in a new tab) richiede che l’indicatore visibile per qualsiasi componente dell’interfaccia utente soddisfi requisiti minimi di dimensione e contrasto. Gli indicatori devono essere almeno grandi quanto un bordo di 2 pixel attorno al componente e devono avere un contrasto con i colori adiacenti di almeno 3:1. 

Quando si creano indicatori di focus, utilizzare stili di focus visibili che non si basino solo su contorni sottili o ombre. Ad esempio, un bordo solido di 2 pixel con contrasto cromatico sufficiente o un’evidenziazione di sfondo soddisfa gli standard di conformità. Inoltre, evitare di rimuovere i contorni degli indicatori di focus tramite ‘outline: none’ a meno che non venga applicata un’alternativa più accessibile. 

2.5.7 Movimenti di trascinamento

Il criterio 2.5.7(opens in a new tab) richiede che le azioni di trascinamento eseguite dagli utenti siano rese accessibili. Ad esempio, quando un utente trascina un elemento per riordinarlo o interagisce con uno slider, dovrebbero essere disponibili metodi alternativi (come pulsanti) per chi non può eseguire l’azione. 

Gli sviluppatori dovrebbero assicurarsi che questi movimenti supportino metodi di input alternativi come l’interazione tramite tastiera (ad esempio, frecce o pulsanti per spostare elementi) o input digitato. Ad esempio, gli utenti possono cliccare sulle frecce per spostare un elemento di una lista invece di dover trascinare e rilasciare. Questo supporta gli utenti con limitazioni motorie che potrebbero avere difficoltà con movimenti precisi del puntatore. 

2.5.8 Dimensione minima del target

Gli elementi interattivi, come pulsanti e link, devono avere una dimensione minima del target(opens in a new tab) per garantire che possano essere facilmente toccati o cliccati. Target più grandi riducono la probabilità di errori e migliorano l’esperienza per gli utenti di tecnologie assistive. Il criterio di successo raccomanda che i target interattivi siano almeno 24x24 pixel CSS, a meno che non ci sia sufficiente spazio attorno o si applichino eccezioni specifiche. 

Per soddisfare questo requisito, assicurarsi che i target per tap e click rispettino la dimensione minima direttamente o tramite padding. Se i target sono più piccoli, garantire uno spazio minimo di 24 pixel tra di essi per ridurre le attivazioni accidentali. Utilizzare media query e CSS per adattare la dimensione dei target su dispositivi mobili e touch senza compromettere il layout. 

3.2.6 Aiuto coerente

L’aiuto coerente(opens in a new tab) si riferisce alla necessità che le funzionalità di assistenza e guida, come meccanismi di aiuto o sezioni FAQ, compaiano in posizioni prevedibili all’interno del sito (a meno che non sia l’utente a modificarle). Questa coerenza aiuta gli utenti a trovare rapidamente le opzioni di aiuto e a navigare più facilmente — un vantaggio particolare per chi ha disabilità cognitive. 

Per essere conformi, assicurarsi che meccanismi di aiuto come pulsanti di chat live, link di contatto o accesso alle FAQ siano posizionati in modo coerente su tutte le pagine rilevanti — sia visivamente che a livello di codice. Ordine e posizione dovrebbero rimanere statici nelle aree di navigazione, a meno che l’utente non li personalizzi o li riordini. La coerenza nell’etichettatura e nel posizionamento permette agli utenti, in particolare a quelli con disabilità cognitive, di prevedere dove trovare l’aiuto. 

3.3.7 Inserimento ridondante

Se agli utenti viene richiesto di inserire informazioni in più campi, il criterio di successo 3.3.7(opens in a new tab) richiede meccanismi multipli per ridurre la ridondanza. Ad esempio, le informazioni già inserite dall’utente non dovrebbero essere richieste nuovamente nella stessa sessione, a meno che non sia essenziale per la sicurezza, la reinserzione sia iniziata dall’utente o le informazioni non siano più valide. 

Per essere conformi, è necessario implementare tecniche come la memorizzazione della sessione o la memoria lato client per conservare i dati inseriti dall’utente durante un processo a più passaggi. Ad esempio, se un utente inserisce il proprio indirizzo in una schermata di un modulo di checkout, lo stesso dato dovrebbe essere precompilato nelle schermate successive se necessario. Questo riduce ripetizioni inutili, particolarmente gravose per utenti con difficoltà di memoria o motorie.

3.3.8 Autenticazione accessibile (Minimo)

Gli standard di autenticazione accessibile(opens in a new tab) richiedono che qualsiasi forma di autenticazione utente (come i campi di login) sia progettata per accogliere utenti con disabilità. Questo può includere opzioni per diversi metodi di input, messaggi di errore chiari, processi di autenticazione e assistenza per il recupero delle password, garantendo che gli utenti possano accedere ai propri account senza barriere. 

Per soddisfare questo requisito, occorre creare metodi di autenticazione che riducano il carico cognitivo, come consentire il copia-incolla nei campi password, integrare i gestori di password e offrire opzioni di login senza password (ad esempio, codici monouso via email). Se viene utilizzato un CAPTCHA, assicurarsi che sia disponibile un metodo alternativo di verifica che non richieda la risoluzione di una sfida basata su memoria, riconoscimento di schemi o interpretazione. 

3.3.9 Autenticazione accessibile (Avanzato)

Lo standard avanzato di autenticazione accessibile(opens in a new tab) amplia i requisiti di base richiedendo che nessun test di funzione cognitiva sia richiesto in nessuna fase dell’autenticazione, a meno che non sia disponibile un meccanismo alternativo che non richieda abilità cognitive. 

Per soddisfare pienamente questo requisito, eliminare ove possibile la dipendenza da password tradizionali e domande di sicurezza. Offrire invece alternative come login biometrici, link di autenticazione sicuri inviati via email o SMS, o riconoscimento del dispositivo fidato. Questo assicura che anche gli utenti con disabilità cognitive possano autenticarsi in autonomia senza la barriera del ricordo o della decifrazione di informazioni.

Bilancia della giustizia che regge le icone WCAG 2.2 e WCAG 2.1

Quale versione WCAG dovresti seguire?

Al momento della stesura di questo articolo, le organizzazioni dovrebbero conformarsi agli standard previsti da WCAG 2.2 Livello AA per essere in regola con leggi come l’Americans with Disabilities Act(opens in a new tab) (ADA), la Sezione 508 o l’Accessibility for Ontarians with Disabilities Act(opens in a new tab) (AODA). Queste linee guida affrontano molte delle barriere di accessibilità più frustranti, tra cui:

• Testo alternativo mancante (o alt text) su immagini o altri contenuti non testuali, che incide sulle persone con disabilità visive come cecità o ipovisione. 

• Mancanza di sottotitoli video, descrizioni audio o trascrizioni, che può influire su persone con disabilità uditive, disturbi dell’apprendimento e condizioni neurocognitive. 

• Assenza di titoli, sottotitoli e tag title, che può rendere la navigazione più difficile per chi utilizza lettori di schermo. 

• “Trappole da tastiera”, che possono rendere i contenuti inutilizzabili per chi non utilizza il mouse per navigare sul web.

Aderire agli standard WCAG 2.2 ti permette di restare conforme alle principali leggi sull’accessibilità e di prepararti alle future versioni delle WCAG, inclusa la 3.0. 

Il primo passo verso la conformità WCAG: testa i tuoi contenuti

Man mano che gli standard di accessibilità evolvono, agire in anticipo aiuta a ridurre i rischi e a creare esperienze migliori per tutti. Seguire le indicazioni sopra descritte ti mette nella posizione ideale per soddisfare gli standard WCAG 2.2. 

AudioEye ti aiuta a semplificare i prossimi passi. La nostra Accessibility Platform combina in modo esperto test automatici con Expert Audits per individuare e correggere problemi di accessibilità, aiutandoti a creare un’esperienza online più accessibile e conforme. Il processo inizia con il nostro Web Accessibility Checker gratuito, che verifica 32 violazioni WCAG (più di qualsiasi altro strumento sul mercato). Questi problemi vengono corretti automaticamente tramite le nostre correzioni automatiche, semplificando il percorso verso un’esperienza più accessibile.

Pronto per il prossimo passo? Scansiona ora i tuoi contenuti oppure prenota una demo per vedere come AudioEye supporta la conformità WCAG in modo più rapido ed efficiente.