WCAG 2.2: lo standard tecnico di riferimento per l’accessibilità digitale
Le WCAG 2.2 — Web Content Accessibility Guidelines, versione 2.2, pubblicate dal W3C nell’ottobre 2023 — sono lo standard tecnico internazionale che definisce i requisiti di accessibilità per siti web, applicazioni mobile e contenuti digitali.
Adeguare il sito alle linee guida WCAG 2.2 è oggi un obbligo normativo per tutti gli operatori economici rientranti nel perimetro dell’European Accessibility Act — Direttiva UE 2019/882, recepita in Italia con D.Lgs. 82/2022 — con scadenza di applicazione al 28 giugno 2025, e per i soggetti già obbligati dalla Legge Stanca (L. 4/2004), che include Pubblica Amministrazione, società quotate e aziende con più di 50 dipendenti o fatturato superiore a 500.000 euro. Uneven Lab conduce audit WCAG 2.2 per brand europei e internazionali dal 2013, producendo roadmap operative con ticket tecnici pronti per i team di sviluppo nei settori ecommerce, insurance e B2B.
I quattro principi WCAG 2.2 e i criteri operativi per la conformità AA
Percepibile: testo alternativo, contrasto e adattabilità
Il principio Percepibile richiede che tutte le informazioni e i componenti dell’interfaccia siano presentati in modo che gli utenti possano percepirli, indipendentemente dalle proprie capacità sensoriali.
Per adeguare il sito alle linee guida WCAG 2.2 sul principio Percepibile, gli interventi prioritari riguardano: testo alternativo descrittivo per tutte le immagini informative (criterio 1.1.1, livello A), assenza di testo alternativo per immagini decorative, rapporto di contrasto minimo 4.5:1 tra testo e sfondo per testo normale e 3:1 per testo grande (criterio 1.4.3, livello AA), e ridimensionamento del testo fino al 200% senza perdita di contenuto o funzionalità (criterio 1.4.4, livello AA). Il criterio 1.4.10 (Reflow, livello AA) — introdotto in WCAG 2.1 e confermato in 2.2 — richiede che il contenuto sia fruibile senza scroll orizzontale fino a una larghezza di 320 pixel CSS, condizione spesso violata da layout complessi non ottimizzati per mobile.
Utilizzabile: navigazione da tastiera, focus e nuovi criteri 2.2
Il principio Utilizzabile richiede che tutti i componenti dell’interfaccia e la navigazione siano operabili da qualsiasi utente, inclusi quelli che non utilizzano il mouse. Per adeguare il sito alle linee guida WCAG 2.2 sul principio Utilizzabile, gli interventi critici includono: navigabilità completa da tastiera di tutti i componenti interattivi (criterio 2.1.1, livello A), nessuna trappola da tastiera (criterio 2.1.2, livello A), e skip link per saltare la navigazione ripetuta (criterio 2.4.1, livello A).
I nuovi criteri introdotti da WCAG 2.2 più rilevanti in questo principio sono: il criterio 2.4.11 (Focus Appearance, livello AA), che richiede un indicatore di focus visibile con area minima pari al perimetro del componente per 2 pixel CSS, e il criterio 2.5.7 (Dragging Movements, livello AA), che richiede un’alternativa a singolo puntatore per tutte le funzionalità che richiedono gesti di trascinamento — come slider e componenti drag-and-drop.
Comprensibile: linguaggio, errori e autenticazione accessibile
Il principio Comprensibile richiede che le informazioni e il funzionamento dell’interfaccia siano intellegibili. Per adeguare il sito alle linee guida WCAG 2.2 sul principio Comprensibile, gli interventi includono: dichiarazione della lingua della pagina nell’attributo lang dell’elemento HTML (criterio 3.1.1, livello A), etichette descrittive associate a ogni campo form tramite <label> o aria-label (criterio 3.3.2, livello A), e messaggi di errore che identificano il campo specifico e descrivono la correzione necessaria (criterio 3.3.3, livello AA).
Il nuovo criterio 3.3.7 (Redundant Entry, livello A) introdotto da WCAG 2.2 richiede che le informazioni già fornite dall’utente in precedenza non vengano richieste nuovamente nello stesso processo — un requisito particolarmente rilevante per i checkout ecommerce con form multi-step. Il criterio 3.3.8 (Accessible Authentication, livello AA) vieta i CAPTCHA cognitivi senza alternativa accessibile nei processi di autenticazione.
Robusto: compatibilità con tecnologie assistive e markup valido
Il principio Robusto richiede che i contenuti siano sufficientemente robusti da essere interpretati correttamente da un’ampia gamma di user agent, incluse le tecnologie assistive.
Per adeguare il sito alle linee guida WCAG 2.2 sul principio Robusto, gli interventi fondamentali riguardano: markup HTML valido senza attributi duplicati o tag non chiusi correttamente (criterio 4.1.1, livello A), nome, ruolo e valore accessibili per tutti i componenti dell’interfaccia tramite ARIA correttamente implementato (criterio 4.1.2, livello A), e messaggi di stato comunicati alle tecnologie assistive senza spostamento del focus (criterio 4.1.3, livello AA). Gli errori ARIA più comuni rilevati negli audit di Uneven Lab con axe-core includono: ruoli ARIA applicati a elementi non compatibili, aria-hidden="true" su elementi con focus attivo, e aria-label assenti su pulsanti con solo icona senza testo visibile.
Processo operativo per adeguare il sito alle linee guida WCAG 2.2
Audit combinato: test automatizzati e verifica manuale
Il processo per adeguare il sito alle linee guida WCAG 2.2 inizia con un audit che combina test automatizzati e verifica manuale. Gli strumenti automatizzati — axe-core, Lighthouse Accessibility, WAVE — rilevano violazioni tecniche verificabili algoritmicamente: assenza di testo alternativo, contrasto insufficiente, form senza etichette, struttura heading non gerarchica.
Coprono mediamente il 30–40% delle violazioni WCAG effettive. Il restante 60–70% richiede verifica manuale: ordine logico del focus con navigazione da tastiera, comportamento con screen reader (NVDA su Windows, VoiceOver su macOS e iOS, TalkBack su Android), comprensibilità delle istruzioni per gli errori, e usabilità dei componenti complessi — modal, accordion, tab panel, datepicker — da parte di utenti con disabilità motorie e cognitive. Uneven Lab struttura i report di audit per categoria WCAG, con riferimento al criterio specifico, livello (A, AA), elemento HTML coinvolto e URL della pagina.
Prioritizzazione e roadmap tecnica
Non tutte le violazioni hanno lo stesso impatto sull’accessibilità effettiva del sito. Per adeguare il sito alle linee guida WCAG 2.2 in modo efficiente, la roadmap di remediation prioritizza gli interventi su tre livelli: violazioni critiche — che impediscono l’accesso a funzionalità essenziali, come form non navigabili da tastiera o immagini informative senza testo alternativo — da risolvere in sprint immediati; violazioni moderate — contrasto insufficiente su testi secondari, heading non sequenziali, link senza testo descrittivo — da pianificare entro 30–60 giorni; e violazioni minori — migliorie ARIA, ottimizzazioni di linguaggio, conformità ai nuovi criteri 2.2 — da integrare nel backlog di sviluppo ordinario. Ogni ticket della roadmap include: criterio WCAG violato, livello, elemento e URL, codice HTML dell’errore, e specifica tecnica della correzione.
Dichiarazione di accessibilità e monitoraggio continuativo
Adeguare il sito alle linee guida WCAG 2.2 non è un intervento una tantum: i contenuti e i componenti evolvono nel tempo, e nuove violazioni possono emergere a ogni aggiornamento del sito. Il processo di conformità include la produzione della dichiarazione di accessibilità — documento pubblico che dichiara il livello di conformità raggiunto, elenca le sezioni non conformi con le motivazioni, e indica un canale di contatto per le segnalazioni — e la definizione di un piano di monitoraggio continuativo.
Il monitoraggio si articola in: audit automatizzato mensile con axe-core su un set di URL campione, verifica manuale semestrale completa, e procedura di segnalazione e risposta per le richieste degli utenti con disabilità. Questo approccio garantisce il mantenimento della conformità nel tempo, non solo il suo raggiungimento iniziale.
Richiedi un audit WCAG 2.2 per il tuo sito
Se vuoi verificare il livello di conformità attuale del tuo sito alle linee guida WCAG 2.2 e costruire una roadmap operativa per l’adeguamento, possiamo avviare la fase di audit e produrre un report dettagliato con priorità e ticket tecnici. Prenota una call conoscitiva.
Quello che le aziende chiedono sulle linee guida WCAG 2.2
Qual è la differenza tra livello A, AA e AAA nelle WCAG 2.2?
Le WCAG 2.2 organizzano i criteri di successo in tre livelli di conformità. Il livello A include i requisiti minimi senza i quali alcune categorie di utenti non possono accedere al contenuto in alcun modo — testo alternativo per le immagini, navigabilità da tastiera, assenza di contenuti lampeggianti. Il livello AA aggiunge requisiti che migliorano significativamente l’accessibilità per la maggior parte delle disabilità — contrasto cromatico, ridimensionamento del testo, etichette sui form — ed è il livello richiesto dall’EAA e dalla Legge Stanca per la conformità legale. Il livello AAA include requisiti avanzati — linguaggio semplificato, interpretazione in lingua dei segni, contrasto potenziato — non obbligatori per legge ma raccomandati per siti con target particolarmente ampio o vulnerabile.
Quanto tempo richiede adeguare un sito medio alle linee guida WCAG 2.2?
I tempi variano significativamente in base alla complessità del sito, alla piattaforma tecnologica e al numero di violazioni esistenti. Per un sito istituzionale di medie dimensioni su CMS standard — WordPress, Drupal — con una struttura di 20–50 template distinti, il percorso completo di audit, roadmap e remediation richiede mediamente 3–6 mesi. Per un ecommerce con centinaia di template di pagina, componenti custom e flussi di checkout complessi, i tempi si estendono a 6–12 mesi. Adeguare il sito alle linee guida WCAG 2.2 in tempi ridotti è possibile concentrando i primi sprint sulle violazioni critiche che impattano i percorsi utente principali — home, prodotto, checkout, area clienti — e pianificando le sezioni secondarie in fasi successive.
I siti costruiti con page builder come Elementor o Divi possono essere adeguati alle WCAG 2.2?
Sì, con alcune limitazioni strutturali da considerare. I page builder generano spesso markup HTML ridondante, strutture heading non sequenziali e componenti interattivi con ruoli ARIA errati o assenti — violazioni che emergono sistematicamente negli audit di Uneven Lab su siti WordPress con Elementor o Divi. Molte di queste violazioni sono correggibili tramite CSS personalizzato, JavaScript aggiuntivo e configurazione dei widget, ma alcune dipendono dal codice del builder stesso e richiedono aggiornamenti del plugin o workaround tecnici. Per adeguare il sito alle linee guida WCAG 2.2 su piattaforme page builder, il punto di partenza è un audit che distingua tra violazioni correggibili a livello di configurazione e violazioni strutturali che richiedono interventi di sviluppo personalizzato.
