Le WCAG 2.2: cosa cambia rispetto alle WCAG 2.1, i vantaggi e le novità introdotte

Negli ultimi mesi si sta parlando sempre più spesso delle WCAG 2.2 nonostante siano state pubblicate ufficialmente da W3C nell’ottobre 2023.

Come abbiamo visto nei post precedenti le WCAG (Web Content Accessibility Guidelines) sono delle linee guida internazionali che indicano come rendere i contenuti digitali (siti web, app e documenti online) accessibili a tutte le persone, comprese quelle con disabilità.

Sono sviluppate dal W3C, il consorzio che definisce gli standard del web, attraverso il gruppo di lavoro WAI (Web Accessibility Initiative).

Le WCAG si basano su quattro principi fondamentali, un contenuto accessibile deve essere:

• Percepibile: Deve poter essere percepito da tutti, anche senza vista o udito.
• Utilizzabile: Deve poter essere usato anche solo con la tastiera o con tecnologie assistive.
• Comprensibile: Il linguaggio utilizzato e il funzionamento del sito/app/documento devono essere chiari e prevedibili.
• Robusto: Deve funzionare con diversi browser, device e strumenti assistivi.

Ogni linea guida ha tre livelli di conformità:
• A (minimo),
• AA (intermedio, quello richiesto dalla maggior parte delle normative),
• AAA (avanzato).

Ma perché solo nell’ultimo periodo si sta parlando molto delle WCAG 2.2 pur essendo uscite già da quasi 2 anni?

Uno dei motivi per il quale si sta spingendo solo ultimamente sulle WCAG 2.2 è perché dal 28 giugno 2025 l’EAA diventerà obbligatorio e di conseguenza l’argomento è portato alla ribalta da social, media e processi aziendali.

Questo ha acceso i riflettori sull’accessibilità più ampia e aggiornata, spingendo ad includere le WCAG 2.2 come requisito tecnico, anche se non ancora formalmente obbligatorie in tutte le legislazioni.

Un altro motivo di impatto rilevante è dovuto alle pubbliche amministrazioni, enti e grandi aziende che stanno aggiornando i requisiti di accessibilità nei loro progetti digitali solo da inizio 2024, integrando i criteri WCAG 2.2 progressivamente nei bandi e nei collaudi.

Ma cosa cambia davvero rispetto alla versione 2.1? E quante sono le linee guida da tenere d’occhio, soprattutto per chi lavora con siti web, app e contenuti digitali?

Rispetto alla versione WCAG 2.1 sono stati aggiunti in totale 9 criteri.

I criteri esistenti non hanno subito modifiche, ad eccezione di un criterio che è stato rimosso.

I criteri che sono stati aggiunti sono:

2.4.11 – FOCUS NOT OBSCURED (MINIMUM) (AA)
Il focus della tastiera non deve essere nascosto (es. da un header sticky), serve a chi naviga solo da tastiera per sapere dove si trova nel sito.

2.4.12 – FOCUS NOT OBSCURED (ENHANCED) (AAA)
Il focus deve essere completamente visibile, mai tagliato o coperto.

2.4.13 – FOCUS APPEARANCE (AA)
Il focus visibile deve avere un aspetto chiaro e riconoscibile:
• contrasto minimo,
• area visibile sufficiente,
• spessore visibile.
Addio focus sottili e invisibili.

2.5.7 – DRAGGING MOVEMENTS (AA)
Le azioni che richiedono di trascinare elementi (es. slider, sposta file) devono avere un’alternativa, come click o tap, utile a chi ha difficoltà motorie o usa solo tastiera.

2.5.8 – TARGET SIZE (MINIMUM) (AA)
I bottoni, link e altri elementi cliccabili devono avere una dimensione minima di 24x24 CSS pixel, oppure spazio attorno. Questo migliora l’usabilità su mobile e per chi ha problemi di precisione.

3.2.6 – CONSISTENT HELP (AA)
Se fornisci un sistema di aiuto (chat, FAQ, numero di telefono…), deve essere sempre presente nello stesso posto e con lo stesso contenuto. Aiuta chi ha bisogno di orientamento costante.

3.3.7 – REDUNDANT ENTRY (AA)
Se chiedi la stessa informazione più volte in un modulo (es. indirizzo, codice fiscale), devi:
• auto-compilarla, oppure
• evitare di chiederla di nuovo.

3.3.8 – ACCESSIBLE AUTHENTICATION (MINIMUM) (AA)
Il login o l’autenticazione non deve basarsi sulla memoria o su CAPTCHA complessi. Dev’essere possibile usare password manager, copia-incolla o metodi alternativi.

3.3.9 – ACCESSIBLE AUTHENTICATION (ENHANCED) (AAA)
Niente richieste che implicano sforzo cognitivo (es. ricordare password complesse). Permette login con sistemi alternativi (es. passkey, biometria).

Il criterio rimosso è invece il:

4.1.1 – PARSING
Prima era un criterio di livello A ma è stato rimosso perché obsoleto.
Questo criterio richiedeva che il codice fosse ben formato (es. HTML valido).
È stato rimosso in quanto oggi gli screen reader sono molto più tolleranti e i parser moderni gestiscono bene piccoli errori, per cui non è più considerato essenziale per l’accessibilità reale.

Per fare un riepilogo quantitativo possiamo dire che:

Le WCAG 2.1 erano in totale 78, mentre con le 2.2 siamo passati a 86 criteri totali.

Essendo al momento solo A e AA i criteri necessari per rispettare la normativa, con le WCAG 2.1 era sufficiente rispettare 50 criteri per essere compliant, mentre ora se volessimo allinearci a un 2.2 AA siamo costretti a soddisfarne 55.

Ci tengo comunque a rimarcare che anche se al momento (Luglio 2025) non si sia legalmente obbligati ad applicare le WCAG 2.2 sarebbe buona pratica, nonché un buon investimento (in previsione di un imminente entrata in vigore) applicare le 2.2 su tutti i progetti ai quali lavoriamo.