QualiBooth

wcag

WCAG 2.1 e 2.2 a confronto: cosa è cambiato e perché conta

Un'analisi chiara di ogni differenza tra WCAG 2.1 e WCAG 2.2 — i nuovi criteri di successo, cosa è stato rimosso e cosa devi correggere per restare conforme.

7 min read QualiBooth
Arte digitale astratta che rappresenta il monitoraggio continuo dell'accessibilità e le verifiche di conformità WCAG.

Le WCAG 2.2 sono diventate Raccomandazione W3C nell’ottobre 2023. Se il tuo sito è stato sottoposto ad audit rispetto alle WCAG 2.1, potrebbe già non superare criteri che oggi definiscono la conformità legale nell’UE, nel Regno Unito e, sempre più spesso, nelle azioni di enforcement negli Stati Uniti. Questa guida ripercorre ogni cambiamento — cosa è stato aggiunto, cosa è stato rimosso e cosa significa nella pratica ciascun criterio.

Un rapido antefatto: cosa avevano aggiunto le WCAG 2.1

Le WCAG 2.1 (pubblicate nel 2018) hanno esteso lo standard originale 2.0 con 17 nuovi criteri di successo dedicati a tre gruppi fino ad allora trascurati:

  • Utenti mobile — gesti touch, orientamento dello schermo, precisione del puntatore
  • Utenti ipovedenti — ridistribuzione del contenuto (reflow), contrasto degli elementi non testuali, spaziatura del testo
  • Disabilità cognitive e del linguaggio — timeout, messaggi di stato

Le WCAG 2.2 si basano direttamente sulle 2.1. Tutti i requisiti delle 2.1 continuano ad applicarsi. La domanda è: cosa hanno aggiunto le 2.2?

Cosa hanno aggiunto le WCAG 2.2: 9 nuovi criteri di successo

2.4.11 Focus non oscurato (Minimo) — Livello AA

Quando un componente riceve il focus da tastiera, non deve essere interamente nascosto da altri contenuti (intestazioni fisse, banner dei cookie, widget di chat). Almeno una parte dell’elemento con il focus deve restare visibile.

Difetto comune: una barra di navigazione fissa copre il campo modulo con il focus mentre l’utente scorre la pagina con il tasto Tab.

2.4.12 Focus non oscurato (Avanzato) — Livello AAA

Versione più rigorosa del 2.4.11 — il componente con il focus deve essere completamente visibile, non solo parzialmente.

2.4.13 Aspetto del focus — Livello AA

Gli indicatori del focus da tastiera devono rispettare soglie minime di dimensione e contrasto:

  • L’area dell’indicatore di focus deve essere almeno pari a un perimetro di 2 pixel CSS attorno al componente
  • Il contrasto tra lo stato con focus e quello senza focus deve essere di almeno 3:1

Questo va oltre l’esistente 2.4.7 (Focus visibile), che richiedeva soltanto che un indicatore di focus esistesse.

Difetto comune: un sottile contorno punteggiato da 1px con contrasto basso soddisfa il 2.4.7 ma non il 2.4.13.

2.5.7 Movimenti di trascinamento — Livello AA

Qualsiasi azione che richieda un trascinamento deve poter essere compiuta anche con un singolo puntatore (tocco o clic). Questo aiuta gli utenti con disabilità motorie che non riescono a controllare in modo affidabile le operazioni di trascinamento.

Esempio: un elenco riordinabile deve offrire un’alternativa (per esempio pulsanti su/giù) per gli utenti che non possono trascinare gli elementi.

2.5.8 Dimensione del bersaglio (Minimo) — Livello AA

I bersagli interattivi (pulsanti, link, controlli dei moduli) devono misurare almeno 24×24 pixel CSS — oppure avere una spaziatura sufficiente dai bersagli adiacenti in modo che l’area di attivazione complessiva raggiunga la soglia.

Questa è la versione minima. Il criterio avanzato (2.5.5, ereditato dalle 2.1 al Livello AAA) raccomanda 44×44px.

Difetti comuni: pulsanti composti solo da un’icona, icone di chiusura (×) e link testuali in linea all’interno di menu di navigazione compatti.

3.2.6 Aiuto coerente — Livello A

Se un sito web offre un meccanismo di aiuto (numero di telefono, link alla chat, modulo di contatto, link alle FAQ), questo deve comparire nella stessa posizione relativa in tutte le pagine in cui è presente. Gli utenti con disabilità cognitive dipendono spesso da una collocazione prevedibile.

3.3.7 Inserimento ridondante — Livello A

Le informazioni che un utente ha già fornito nella stessa sessione non devono essere richieste di nuovo — a meno che il reinserimento non sia essenziale (per esempio un campo di conferma della password) o che i dati siano sensibili sotto il profilo della sicurezza.

Esempio: un checkout a più passaggi non dovrebbe chiedere l’indirizzo di fatturazione al passaggio 3 se l’utente lo ha già inserito al passaggio 1.

3.3.8 Autenticazione accessibile (Minimo) — Livello AA

I passaggi di autenticazione non devono basarsi su un test di funzione cognitiva — riconoscere oggetti, trascrivere caratteri o risolvere rompicapo — a meno che non sia fornita un’alternativa o che il test consista nel riconoscere contenuti controllati dall’utente (per esempio una foto che l’utente ha caricato).

Difetti comuni: CAPTCHA che richiedono di identificare testo distorto senza alternativa audio, oppure le sfide del tipo “clicca su tutte le immagini con i semafori”.

3.3.9 Autenticazione accessibile (Avanzato) — Livello AAA

La versione avanzata elimina anche l’eccezione per i contenuti controllati dall’utente. Nel flusso di autenticazione non è ammesso alcun test di funzione cognitiva.

Cosa hanno rimosso le WCAG 2.2: 4.1.1 Analisi sintattica

Le WCAG 2.1 includevano il criterio 4.1.1 Analisi sintattica (Livello A), che richiedeva HTML ben formato — ID di elemento univoci, tag annidati correttamente e coppie complete di tag di apertura e chiusura. I browser moderni erano diventati così bravi a correggere silenziosamente l’HTML malformato che questo criterio è diventato di fatto non misurabile.

Nelle WCAG 2.2, il 4.1.1 Analisi sintattica è contrassegnato come obsoleto e viene sempre considerato soddisfatto. Non è più necessario verificarlo in sede di audit, anche se scrivere HTML pulito resta una buona pratica.

Tabella riepilogativa

CriterioLivelloTema
2.4.11 Focus non oscurato (Minimo)AAFocus da tastiera
2.4.12 Focus non oscurato (Avanzato)AAAFocus da tastiera
2.4.13 Aspetto del focusAAIndicatore di focus
2.5.7 Movimenti di trascinamentoAAInput con puntatore
2.5.8 Dimensione del bersaglio (Minimo)AABersagli tattili
3.2.6 Aiuto coerenteAPrevedibilità
3.3.7 Inserimento ridondanteAModuli
3.3.8 Autenticazione accessibile (Minimo)AALogin / CAPTCHA
3.3.9 Autenticazione accessibile (Avanzato)AAALogin / CAPTCHA
4.1.1 Analisi sintatticaARimosso

Chi deve fare l’aggiornamento?

Praticamente tutti. Le WCAG 2.2 sono ormai il riferimento di base richiamato da:

  • Lo European Accessibility Act (EAA), in vigore da giugno 2025
  • Lo standard armonizzato EN 301 549 (aggiornato per richiamare le WCAG 2.2)
  • Le UK Public Sector Bodies Accessibility Regulations (linee guida aggiornate)
  • Numerose leggi statali statunitensi e le posizioni informali di enforcement del DOJ

Se il tuo ultimo audit completo era rispetto alle WCAG 2.1 AA, concentra lo sforzo di aggiornamento su questi cinque criteri, che riguardano la maggior parte dei siti: 2.4.11, 2.4.13, 2.5.8, 3.3.8 e 3.3.7 (se hai moduli o checkout a più passaggi).

Come verificare i nuovi criteri

La maggior parte degli scanner automatici oggi segnala il 2.5.8 (dimensione del bersaglio) e alcuni casi del 2.4.13 (aspetto del focus). I seguenti, però, richiedono test manuali:

  • 2.4.11 / 2.4.12 — scorri con Tab tutte le pagine con intestazioni e piè di pagina fissi attivi e verifica che gli elementi con il focus siano visibili
  • 2.4.13 — misura le dimensioni e il contrasto dell’indicatore di focus con i DevTools del browser o con un verificatore di contrasto
  • 2.5.7 — individua ogni interazione basata sul trascinamento e verifica che esista un’alternativa con il solo puntatore
  • 3.2.6 — controlla che i link di aiuto compaiano in posizioni coerenti nelle varie pagine
  • 3.3.7 — percorri tutti i flussi a più passaggi e verifica che nessun dato venga richiesto due volte
  • 3.3.8 — testa ogni passaggio di login, registrazione e verifica alla ricerca di test di funzione cognitiva

Le WCAG 2.2 non sono una riprogettazione radicale — sono un insieme mirato di aggiunte che affrontano barriere reali sfuggite alle 2.1. La buona notizia è che la maggior parte dei nuovi criteri AA può essere risolta con un lavoro di remediation circoscritto, senza dover ricostruire l’intero sito.

Correlati: Come rendere il tuo sito conforme alle WCAG 2.2 · Guida agli audit manuali di accessibilità

Ti serve aiuto per verificare il sito rispetto alle WCAG 2.2?