WCAG 2.2: guida completa ai criteri di accessibilità per siti web e app

Cosa sono le WCAG

Le WCAG (Web Content Accessibility Guidelines, in italiano Linee guida per l'accessibilità dei contenuti web) sono un insieme di requisiti tecnici, scritti dal gruppo di lavoro Accessibility Guidelines Working Group della Web Accessibility Initiative (WAI) del W3C, l'organizzazione internazionale che definisce gli standard del web come HTML e CSS.

Il loro obiettivo è rendere i contenuti digitali utilizzabili da persone con disabilità visive (cecità, ipovisione, daltonismo), uditive (sordità, ipoacusia), motorie (difficoltà a usare mouse o touch, tremori, paralisi), cognitive, di apprendimento e neurologiche (dislessia, disturbi dell'attenzione, deficit di memoria, epilessia fotosensibile) e del linguaggio. Ne beneficiano anche le persone anziane, chi ha una disabilità temporanea (un braccio ingessato) e chi si trova in una situazione sfavorevole (sole sullo schermo, connessione lenta, ambiente rumoroso).

Le WCAG sono tecnologicamente neutrali: non dicono "usa questo tag" o "usa quel framework", ma descrivono il risultato da ottenere in forma di frasi verificabili, i criteri di successo. Per questo valgono per HTML, PDF, app native, documenti Office e qualsiasi altra tecnologia.

Quando sono uscite le WCAG 2.2: la storia delle versioni

La pubblicazione di WCAG 2.2 era attesa da tempo: la prima bozza pubblica risale a febbraio 2020 e il processo ha subito diversi rinvii, soprattutto per la discussione sul criterio dell'aspetto del focus, che alla fine è stato spostato al livello AAA.

Come sono organizzate le WCAG 2.2

Per leggere qualsiasi criterio bisogna conoscere la struttura a quattro livelli.

I 4 principi (POUR)

Tutto parte da quattro principi. Un contenuto accessibile deve essere:

1. Percepibile: le informazioni devono poter essere percepite con almeno uno dei sensi disponibili (testo alternativo per le immagini, sottotitoli per i video, contrasto sufficiente).
2. Utilizzabile (Operable): tutti i comandi devono poter essere usati, anche senza mouse, senza limiti di tempo impossibili e senza provocare crisi.
3. Comprensibile: testi e funzionamento dell'interfaccia devono essere chiari e prevedibili, e i moduli devono aiutare a evitare e correggere gli errori.
4. Robusto: il codice deve essere interpretabile in modo affidabile dai browser e dalle tecnologie assistive, come gli screen reader.

Le 13 linee guida

Sotto i principi ci sono 13 linee guida, che indicano gli obiettivi generali:

Gli 86 criteri di successo e i tre livelli

Ogni linea guida contiene criteri di successo: frasi verificabili, a cui si risponde con "soddisfatto", "non soddisfatto" o "non applicabile". Ogni criterio ha un livello:

• Livello A (31 criteri): il minimo indispensabile. Se manca, alcune persone non riescono proprio a usare il contenuto.
• Livello AA (24 criteri): elimina le barriere più diffuse. È il livello richiesto da quasi tutte le leggi, e per raggiungerlo bisogna soddisfare tutti i criteri A e AA, 55 in totale.
• Livello AAA (31 criteri): il livello più alto. Il W3C stesso sconsiglia di imporlo come requisito per interi siti, perché alcuni contenuti non possono soddisfarlo.

I documenti di supporto

I criteri sono volutamente sintetici. Per applicarli il W3C pubblica materiali di supporto, non normativi ma indispensabili:

• Understanding WCAG 2.2: spiega l'intento di ogni criterio, chi aiuta, esempi ed eccezioni.
• Techniques for WCAG 2.2: tecniche sufficienti (se le applichi, il criterio è soddisfatto), consigliate e fallimenti comuni (se li commetti, il criterio non è soddisfatto).
• How to Meet WCAG (Quick Reference): la checklist filtrabile per livello e tecnologia.

I 5 requisiti di conformità

Dichiarare che un sito è "conforme alle WCAG 2.2 AA" significa rispettare cinque requisiti, non solo una lista di criteri:

1. Livello di conformità: la pagina soddisfa tutti i criteri del livello dichiarato (oppure esiste una versione alternativa conforme).
2. Pagine intere: la conformità vale per l'intera pagina, non per una sua parte. Non si può escludere il carosello o il widget della chat.
3. Processi completi: se una pagina fa parte di un processo (carrello, checkout, registrazione), tutte le pagine del processo devono essere conformi. Un checkout accessibile con un pagamento finale inaccessibile non è conforme.
4. Solo tecnologie supportate dall'accessibilità: le informazioni e le funzioni devono essere fornite con tecnologie che le tecnologie assistive sanno gestire.
5. Non interferenza: anche le parti realizzate con tecnologie non supportate non devono bloccare il resto della pagina (per esempio audio che parte da solo, trappole per la tastiera, lampeggiamenti).

È possibile anche una dichiarazione di conformità parziale quando un contenuto di terze parti, non controllato dall'autore, non è conforme, a patto di dichiararlo esplicitamente.

Le 9 novità di WCAG 2.2

WCAG 2.2 aggiunge nove criteri. Si concentrano su tre gruppi di persone: chi usa la tastiera e ha bisogno di vedere dove si trova, chi ha difficoltà motorie o usa il touch, chi ha disabilità cognitive o di memoria.

Per il livello AA, quindi, i criteri nuovi da rispettare sono sei: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 e 3.3.8.

2.4.11 Focus non oscurato (minimo) – Livello AA

Cosa chiede. Quando un elemento riceve il focus da tastiera, non deve essere interamente nascosto da contenuti creati dall'autore della pagina.

Il problema che risolve. Chi naviga con il tasto Tab segue l'indicatore di focus per sapere dove si trova. Se il pulsante attivo finisce sotto un header fisso, un banner dei cookie, una barra di chat o un pop-up, la persona non sa più dove si trova e cosa sta per attivare.

Come rispettarlo.

• Usa la proprietà CSS scroll-padding-top (o scroll-margin) pari all'altezza dell'header fisso, così il browser lascia spazio quando scorre verso l'elemento con il focus.
• Fai in modo che i banner (cookie, newsletter, chat) non coprano il contenuto finché sono aperti, oppure che si possano chiudere senza dover spostare il focus.
• Controlla le barre fisse in basso, frequenti nei siti mobile e negli e-commerce ("Aggiungi al carrello" fisso).

Eccezioni. I contenuti che l'utente ha aperto da sé e che può chiudere senza spostare il focus (per esempio un menu espanso, chiudibile con Esc) non violano il criterio. Basta che almeno una parte dell'elemento resti visibile: un elemento coperto in parte soddisfa il livello minimo.

Errore tipico. Il banner dei cookie in basso che resta aperto e copre l'ultimo link del footer mentre si naviga con la tastiera.

2.4.12 Focus non oscurato (avanzato) – Livello AAA

È la versione rigorosa del criterio precedente: nessuna parte dell'elemento con il focus può essere nascosta da contenuti dell'autore. Se l'header fisso copre anche solo il bordo superiore del pulsante, il criterio non è soddisfatto.

2.4.13 Aspetto del focus – Livello AAA

Cosa chiede. Quando l'indicatore di focus è visibile, una sua area deve essere:

• almeno grande quanto un bordo spesso 2 pixel CSS attorno al perimetro dell'elemento non focalizzato;
• con un contrasto di almeno 3:1 tra lo stato con focus e lo stato senza focus, negli stessi pixel.

Come rispettarlo. Il modo più semplice è un contorno (outline) solido di almeno 2 px, con un colore che contrasti di almeno 3:1 sia con lo sfondo sia con l'elemento, magari con un piccolo distacco (outline-offset). Usa la pseudo-classe :focus-visible per mostrarlo solo quando serve, senza disturbare chi usa il mouse.

Eccezioni. Il criterio non si applica se l'indicatore è quello predefinito del browser e l'autore non lo ha modificato, o se il colore dell'elemento e dello sfondo sono decisi dal browser.

Attenzione. Il criterio 2.4.7 Focus visibile (livello AA, già presente nelle versioni precedenti) resta obbligatorio: il focus deve sempre essere visibile. La regola CSS outline: none senza un'alternativa è ancora uno degli errori più diffusi.

2.5.7 Movimenti di trascinamento – Livello AA

Cosa chiede. Ogni funzione che si usa trascinando deve poter essere eseguita anche con un singolo puntatore senza trascinamento (un tocco o un clic), a meno che il trascinamento sia essenziale o che il comportamento sia gestito dal browser e non modificato dall'autore.

Il problema che risolve. Trascinare richiede di premere, tenere premuto, spostare con precisione e rilasciare. Per chi ha tremori, usa un puntatore oculare, un caschetto, un trackball o semplicemente il pollice su uno schermo piccolo, è spesso impossibile.

Esempi e soluzioni.

• Slider per valori e prezzi: oltre al cursore da trascinare, consenti di cliccare sul punto della barra o affianca campi numerici o pulsanti più/meno.
• Liste riordinabili e kanban: aggiungi pulsanti "sposta su/giù" o un menu "sposta in…".
• Mappe: prevedi pulsanti di spostamento e zoom.
• Caricamento file con drag and drop: affianca sempre il pulsante "Scegli file".
• Caroselli a scorrimento: aggiungi frecce o indicatori cliccabili.

Differenza con 2.5.1 Gesti del puntatore. Il criterio 2.5.1 (livello A) riguarda i gesti basati sul percorso o con più dita (swipe, pinch). Il 2.5.7 riguarda il trascinamento in sé, anche se il percorso è libero. Il criterio vale per il puntatore: le alternative da tastiera sono già richieste dal 2.1.1, ma non bastano per soddisfare il 2.5.7.

2.5.8 Dimensione dell'obiettivo (minimo) – Livello AA

Cosa chiede. Gli obiettivi dei puntatori (pulsanti, link, icone, caselle di controllo) devono misurare almeno 24×24 pixel CSS, salvo eccezioni.

Le eccezioni.

• Spaziatura: un obiettivo più piccolo è ammesso se, disegnando un cerchio di 24 px di diametro centrato su di esso, il cerchio non interseca altri obiettivi né i cerchi degli altri obiettivi piccoli. In pratica: icone piccole ma ben distanziate vanno bene.
• Equivalente: la stessa funzione è disponibile con un altro comando della stessa pagina che rispetta la dimensione.
• In linea: link inseriti in una frase o in un blocco di testo, la cui dimensione dipende dall'interlinea.
• Controllo dello user agent: la dimensione è decisa dal browser e non modificata dall'autore (per esempio un selettore di data nativo).
• Essenziale: una presentazione specifica è essenziale o richiesta per legge (i punti di una mappa interattiva, per esempio).

Come rispettarlo. Imposta una dimensione minima di 24 px per pulsanti e icone cliccabili e, se l'icona deve restare piccola, aumenta l'area cliccabile con il padding invece che con l'immagine. Attenzione alle icone social nel footer, alle "x" di chiusura dei pop-up, ai pallini dei caroselli, alle paginazioni e alle stelline delle recensioni.

Rapporto con 2.5.5. Il criterio 2.5.5 Dimensione dell'obiettivo (avanzato), di livello AAA, chiede 44×44 px. Le linee guida per le app di Apple e Google consigliano dimensioni simili (44 pt e 48 dp): se le rispetti, sei ben oltre il minimo AA.

3.2.6 Aiuto coerente – Livello A

Cosa chiede. Se una pagina web offre uno o più di questi meccanismi di aiuto, e questi si ripetono su più pagine dello stesso sito, devono trovarsi nello stesso ordine relativo rispetto agli altri contenuti della pagina:

• recapiti di contatto umano (telefono, email, orari);
• meccanismo di contatto umano (chat con operatore, modulo di contatto, link ai social);
• opzioni di auto-aiuto (pagina FAQ, centro assistenza);
• meccanismo di contatto completamente automatizzato (chatbot).

Cosa non chiede. Il criterio non obbliga a offrire aiuto: dice solo che, se c'è, deve essere coerente. Non chiede nemmeno che l'aiuto sia in ogni pagina. Il cambio di ordine richiesto dall'utente (per esempio un layout personalizzato) è ammesso.

Perché conta. Le persone con difficoltà cognitive o di memoria, quando sono in difficoltà, cercano l'aiuto nel posto in cui l'hanno visto l'ultima volta. Se il link "Contatti" è nel footer in una pagina e nel menu in un'altra, rischiano di arrendersi.

3.3.7 Inserimento ridondante – Livello A

Cosa chiede. Le informazioni che l'utente ha già inserito, o che gli sono già state fornite, e che devono essere inserite di nuovo nello stesso processo, devono essere compilate automaticamente oppure disponibili per la selezione.

Esempi.

• Nel checkout, la casella "L'indirizzo di fatturazione è uguale a quello di spedizione".
• In un modulo a più passaggi, il nome inserito al passo 1 che compare già nel riepilogo o nel passo 3.
• Un elenco a discesa con gli indirizzi già usati nella stessa sessione.

Eccezioni. Si può chiedere di reinserire un dato quando è essenziale (un gioco di memoria), quando serve per la sicurezza (la conferma della password) o quando l'informazione precedente non è più valida.

Cosa non copre. Il criterio riguarda un singolo processo, non sessioni diverse: non obbliga a ricordare i dati di un acquisto fatto la settimana prima. L'attributo autocomplete nei campi (richiesto dal criterio 1.3.5) aiuta comunque il browser a compilare i dati personali.

3.3.8 Autenticazione accessibile (minimo) – Livello AA

Cosa chiede. Nessun passaggio di un processo di autenticazione deve basarsi su un test della funzione cognitiva (ricordare una password, risolvere un enigma, fare un calcolo, trascrivere caratteri) a meno che sia disponibile almeno una di queste soluzioni:

• Alternativa: un altro metodo di autenticazione che non richiede il test.
• Meccanismo di assistenza: un meccanismo che aiuta a superare il test, come la possibilità di incollare la password o di farla compilare da un gestore di password.
• Riconoscimento di oggetti: il test chiede di riconoscere oggetti comuni (le immagini con i semafori).
• Contenuto personale: il test chiede di identificare un contenuto non testuale che l'utente stesso ha fornito al sito (una foto caricata da lui).

Cosa è conforme.

• Login con email e password, se i campi permettono di incollare e l'autocompletamento non è bloccato (autocomplete con valori come username e current-password).
• Passkey, impronta digitale, riconoscimento del volto, chiavi di sicurezza hardware.
• Link magico via email o codice monouso inviato per SMS o email, purché si possa incollare o compilare automaticamente (autocomplete one-time-code), senza obbligare a copiarlo a mano carattere per carattere.
• Accesso con un account esterno (Google, Apple, SPID, CIE), che a sua volta deve rispettare il criterio.

Cosa non è conforme.

• Bloccare l'incolla nei campi password o dividere il codice OTP in sei caselle che non accettano l'incolla.
• CAPTCHA di testo distorto da trascrivere, o calcoli ("quanto fa 3+4?"), senza alternativa.
• Domande di sicurezza tipo "nome del tuo primo animale", se sono l'unica strada.

E i CAPTCHA a immagini? Al livello AA sono ammessi grazie all'eccezione del riconoscimento di oggetti. Restano però un problema per le persone cieche (criterio 1.1.1): serve sempre un'alternativa, come un CAPTCHA audio o, meglio, un sistema di verifica invisibile.

3.3.9 Autenticazione accessibile (avanzato) – Livello AAA

È uguale al 3.3.8 ma senza le eccezioni per il riconoscimento di oggetti e per il contenuto personale. Restano solo l'alternativa e il meccanismo di assistenza: niente CAPTCHA a immagini.

Il criterio eliminato: 4.1.1 Parsing

WCAG 2.2 elimina il criterio 4.1.1 Parsing (analisi sintattica), di livello A, che chiedeva un codice senza errori di sintassi (tag aperti e non chiusi, attributi duplicati, ID ripetuti).

Il motivo è che era diventato obsoleto: i browser moderni e le tecnologie assistive non leggono più il codice sorgente da soli, ma usano l'albero di accessibilità costruito dal browser secondo regole di analisi ormai standardizzate in HTML5. Gli errori che causano problemi reali sono già coperti da altri criteri, soprattutto 1.3.1 e 4.1.2.

Per chi deve ancora valutare la conformità a WCAG 2.0 o 2.1, il W3C ha pubblicato una nota che considera il criterio 4.1.1 sempre soddisfatto per i contenuti HTML e XML. Gli ID duplicati vanno comunque evitati quando rompono le relazioni tra etichette e campi.

WCAG 2.2 è retrocompatibile?

Sì. Ogni contenuto conforme a WCAG 2.2 è conforme anche a WCAG 2.1 e 2.0: i criteri precedenti non sono cambiati nella sostanza né di livello, e l'unico eliminato (4.1.1) è comunque considerato soddisfatto. Durante le bozze si era ipotizzato di spostare il criterio 2.4.7 Focus visibile dal livello AA al livello A, ma nella versione finale è rimasto AA.

In pratica: se il tuo sito è conforme a WCAG 2.1 AA, per arrivare a WCAG 2.2 AA devi verificare solo i 6 criteri nuovi di livello A e AA.

Elenco completo degli 86 criteri di successo WCAG 2.2

Le tabelle seguenti riportano tutti i criteri, con il livello. I nomi in italiano seguono la traduzione autorizzata delle versioni precedenti; i criteri contrassegnati con (nuovo) sono stati introdotti con WCAG 2.2.

Principio 1 – Percepibile (29 criteri)

Principio 2 – Utilizzabile (34 criteri)

Principio 3 – Comprensibile (21 criteri)

Principio 4 – Robusto (2 criteri)

I numeri da ricordare

Molti criteri si basano su valori precisi. Eccoli raccolti in una tabella.

Se lavori sulle palette del tuo marchio, ti sarà utile anche la nostra guida su come creare una color ramp efficace per un design system, che parte proprio dai rapporti di contrasto.

Cosa dice la legge: WCAG 2.2 è obbligatoria?

La risposta breve: le leggi non citano quasi mai direttamente le WCAG, ma rimandano alla norma europea EN 301 549, che a sua volta incorpora le WCAG. Quale versione delle WCAG sia obbligatoria dipende quindi dalla versione della EN 301 549 in vigore.

La norma europea EN 301 549

La EN 301 549 è la norma armonizzata europea sui requisiti di accessibilità dei prodotti e servizi ICT (siti, app, software, documenti, hardware, terminali self-service). Per il web riprende i criteri WCAG di livello A e AA.

• La versione V3.2.1 (2021) si basa su WCAG 2.1 AA ed è quella richiamata finora da leggi e linee guida.
• La versione V4.1.1, adottata ad agosto e pubblicata il 2 settembre 2026 da ETSI, CEN e CENELEC, passa a WCAG 2.2 livello A e AA ed è la prima pensata espressamente per l'European Accessibility Act.

La V4.1.1 produce pienamente i suoi effetti giuridici, cioè la presunzione di conformità ai requisiti dell'European Accessibility Act, quando viene citata nella Gazzetta Ufficiale dell'Unione Europea, passaggio atteso per la fine del 2026. Da quel momento WCAG 2.2 AA diventerà il riferimento di fatto in tutta l'Unione.

In Italia: Legge Stanca e Linee guida AgID

La Legge 9 gennaio 2004, n. 4 (Legge Stanca), aggiornata dal D.Lgs. 106/2018 che recepisce la Direttiva UE 2016/2102, obbliga all'accessibilità di siti e app:

• le pubbliche amministrazioni e gli enti pubblici, le società a controllo pubblico, i concessionari di servizi pubblici e gli altri soggetti elencati dalla legge;
• dal 2020 (DL 76/2020, convertito dalla Legge 120/2020) anche i soggetti privati con un fatturato medio superiore a 500 milioni di euro negli ultimi tre anni, che offrono servizi al pubblico tramite siti web o app.

I requisiti tecnici sono fissati dalle Linee guida AgID sull'accessibilità degli strumenti informatici, che rimandano alla EN 301 549 e quindi oggi a WCAG 2.1 AA. Le pubbliche amministrazioni devono inoltre pubblicare entro il 23 settembre di ogni anno la dichiarazione di accessibilità tramite la piattaforma AgID, prevedere un meccanismo di feedback per segnalare i problemi e pubblicare entro il 31 marzo gli obiettivi di accessibilità.

L'European Accessibility Act (D.Lgs. 82/2022)

La Direttiva UE 2019/882, nota come European Accessibility Act (EAA), è stata recepita in Italia dal D.Lgs. 27 maggio 2022, n. 82 ed è applicabile dal 28 giugno 2025. Riguarda anche le imprese private che offrono ai consumatori determinati prodotti e servizi:

• commercio elettronico (siti e app che vendono prodotti o servizi online);
• servizi bancari per i consumatori;
• servizi di comunicazione elettronica (telefonia, messaggistica);
• servizi di accesso ai media audiovisivi;
• elementi digitali dei servizi di trasporto passeggeri (siti, app, biglietterie elettroniche, informazioni di viaggio);
• e-book e software di lettura;
• prodotti come computer, smartphone, terminali di pagamento, bancomat, biglietterie automatiche, lettori di e-book.

Sono esentate le microimprese che forniscono servizi, cioè quelle con meno di 10 dipendenti e un fatturato annuo o un totale di bilancio non superiore a 2 milioni di euro. L'esenzione non vale per chi fabbrica o vende prodotti.

Sono previsti periodi transitori: i servizi basati su contratti già in essere possono restare invariati fino al 28 giugno 2030, e i terminali self-service già installati possono restare in uso fino alla fine della loro vita utile, entro un massimo di 20 anni.

Le autorità di vigilanza sono AgID per la maggior parte dei servizi digitali, oltre ad altre autorità di settore (come AGCOM e l'Autorità di regolazione dei trasporti per i rispettivi ambiti). Nel marzo 2026 AgID ha pubblicato le linee guida operative sull'accessibilità dei servizi soggetti all'EAA e attivato una piattaforma pubblica per le segnalazioni dei cittadini; nel maggio 2026 ha pubblicato il regolamento sulle attività di vigilanza.

Le sanzioni amministrative per chi non rispetta gli obblighi vanno, a seconda dei casi, da 5.000 a 40.000 euro, e per alcune categorie di soggetti possono arrivare fino al 5% del fatturato annuo; nei casi più gravi l'autorità può ordinare il ritiro del prodotto o la sospensione del servizio.

E fuori dall'Europa?

• Stati Uniti: la Section 508 per le agenzie federali rimanda a WCAG 2.0 AA; per il settore pubblico statale e locale le regole dell'ADA fanno riferimento a WCAG 2.1 AA; per i privati i tribunali usano le WCAG come metro di giudizio nelle cause per discriminazione.
• Regno Unito: le regole per il settore pubblico fanno riferimento a WCAG 2.2 AA, e il Government Digital Service ha iniziato a monitorare i nuovi criteri dal 2024.
• Canada, Australia, Nuova Zelanda e molti altri paesi usano le WCAG come riferimento, con versioni diverse a seconda della norma nazionale.

Le norme cambiano spesso: per un caso concreto conviene sempre verificare il testo in vigore e, se necessario, chiedere un parere legale.

Cosa conviene fare oggi

Anche dove la legge richiede ancora WCAG 2.1, conviene progettare direttamente per WCAG 2.2 AA: è retrocompatibile, costa poco in più (sei criteri) e evita di dover rimettere mano al sito quando la EN 301 549 V4.1.1 diventerà il riferimento ufficiale.

Come verificare se un sito rispetta le WCAG 2.2

Non esiste un pulsante che certifica l'accessibilità. Una verifica seria combina tre livelli.

1. Strumenti automatici

Gli strumenti automatici trovano velocemente gli errori più evidenti (testi alternativi mancanti, contrasto insufficiente, campi senza etichetta, lingua non dichiarata), ma coprono solo una parte dei criteri: non possono capire se un testo alternativo è sensato o se l'ordine di lettura ha senso. I più usati:

• axe DevTools (estensione per browser, con motore open source axe-core);
• WAVE di WebAIM;
• Lighthouse, integrato in Chrome (la sezione Accessibilità);
• Accessibility Insights for Web di Microsoft, con un percorso guidato di verifica manuale;
• Colour Contrast Analyser di TPGi per misurare il contrasto di qualsiasi elemento sullo schermo;
• per i PDF, PAC (PDF Accessibility Checker) e il controllo di accessibilità di Adobe Acrobat.

Un punteggio Lighthouse di 100 non significa che il sito è accessibile: significa solo che non sono stati trovati gli errori che lo strumento sa riconoscere.

2. Verifiche manuali

Sono indispensabili. Le prove minime:

• Solo tastiera: scollega il mouse e prova a usare tutto il sito con Tab, Maiusc+Tab, Invio, Spazio, frecce ed Esc. Il focus si vede sempre? È coperto da header o banner? Ci sono trappole?
• Zoom al 200% e al 400%: il testo si legge senza tagli? A 320 px di larghezza serve lo scorrimento orizzontale?
• Spaziatura del testo: applica con un bookmarklet i valori del criterio 1.4.12 e controlla che non si sovrapponga nulla.
• Moduli: errori descritti a parole? Etichette visibili? Dati già inseriti riproposti? Si può incollare la password?
• Obiettivi touch: le icone piccole sono ben distanziate?
• Trascinamento: ogni slider, mappa o lista riordinabile ha un'alternativa?
• Contenuti multimediali: sottotitoli, trascrizioni, pulsanti di pausa.

3. Prove con tecnologie assistive e utenti reali

• Screen reader: NVDA (gratuito) o JAWS su Windows, VoiceOver su macOS e iOS, TalkBack su Android.
• Ingranditori e modalità di contrasto elevato del sistema operativo.
• Comandi vocali (Controllo vocale su Apple, Accesso vocale su Android).

Il modo migliore per capire se un servizio funziona davvero è osservarne l'uso da parte di persone con disabilità: nessun audit tecnico sostituisce questo passaggio.

La metodologia di valutazione

Per un audit formale il W3C propone la metodologia WCAG-EM (Website Accessibility Conformance Evaluation Methodology): definizione del perimetro, esplorazione del sito, scelta di un campione rappresentativo di pagine e processi, verifica criterio per criterio e rapporto finale. Per i prodotti ICT venduti alla pubblica amministrazione o in mercati esteri si usa spesso il VPAT (Voluntary Product Accessibility Template), che produce un rapporto di conformità chiamato ACR.

Checklist rapida WCAG 2.2 AA per il tuo sito

Usa questa lista come primo controllo. Non sostituisce un audit, ma copre gli errori più frequenti.

1. Ogni immagine informativa ha un testo alternativo utile; le immagini decorative hanno alt vuoto.
2. La pagina dichiara la lingua e ha un titolo descrittivo.
3. I titoli (H1, H2, H3) seguono la struttura logica dei contenuti.
4. Il testo rispetta il contrasto di 4,5:1 (3:1 per il testo grande); icone e bordi dei campi almeno 3:1.
5. Il colore non è l'unico modo per segnalare link, errori o stati.
6. Tutto funziona da tastiera, nell'ordine giusto, senza trappole.
7. Il focus è sempre visibile e non viene coperto da header fissi, banner o chat.
8. C'è un link "Salta al contenuto".
9. Il sito si legge a 320 px di larghezza e con lo zoom al 200%.
10. Pulsanti e icone misurano almeno 24×24 px o sono ben distanziati.
11. Slider, mappe, liste riordinabili e caricamenti hanno un'alternativa senza trascinamento.
12. Caroselli e animazioni automatiche si possono fermare.
13. Ogni campo ha un'etichetta visibile e l'attributo autocomplete corretto per i dati personali.
14. Gli errori sono descritti a parole, con un suggerimento per correggerli.
15. I dati già inseriti nello stesso processo non vanno riscritti.
16. Il login permette di incollare la password, usa i gestori di password e non impone CAPTCHA di testo.
17. Contatti, chat e FAQ sono sempre nello stesso posto.
18. I video hanno sottotitoli e, quando serve, audiodescrizione o trascrizione.
19. I messaggi di stato (prodotto aggiunto, modulo inviato) sono annunciati agli screen reader.
20. Pulsanti e menu personalizzati espongono nome, ruolo e stato (con HTML nativo o ARIA corretto).

Errori comuni e falsi miti

"Basta installare un plugin o un widget di accessibilità." Gli overlay, i widget che promettono di rendere accessibile un sito con una riga di codice, non correggono i problemi del codice sottostante e a volte interferiscono con le tecnologie assistive che gli utenti già usano. Possono essere un'aggiunta, mai una soluzione. In diversi paesi le aziende che li usavano come unica misura sono state comunque citate in giudizio, e un fornitore di overlay è stato sanzionato dalla Federal Trade Commission statunitense per pubblicità ingannevole.

"L'accessibilità riguarda solo i ciechi." Una buona parte dei criteri riguarda la disabilità motoria, uditiva e cognitiva. I nuovi criteri di WCAG 2.2 sono quasi tutti dedicati a queste ultime.

"Un sito accessibile è brutto." L'accessibilità vincola il contrasto, la dimensione dei comandi e la struttura, non lo stile. Molti dei siti con il miglior design rispettano WCAG AA.

"Lo facciamo alla fine." Correggere un sito già sviluppato costa molto di più che progettarlo accessibile. Palette, componenti e moduli vanno pensati per l'accessibilità fin dal design system.

"AAA è meglio, quindi puntiamo a quello." Puntare ad AA e applicare i criteri AAA dove ha senso è la strategia consigliata dallo stesso W3C.

"Il bollino di accessibilità basta." Badge e certificazioni hanno valore solo se corrispondono a un audit reale. Ne parliamo anche nella guida ai badge di qualità per siti web.

Le WCAG 2.2 e le altre specifiche del W3C

• WAI-ARIA: attributi HTML (ruoli, stati, proprietà) che servono a rendere accessibili componenti personalizzati. La prima regola di ARIA è non usarlo quando esiste un elemento HTML nativo che fa la stessa cosa.
• ATAG (Authoring Tool Accessibility Guidelines): per gli strumenti con cui si creano contenuti, come CMS ed editor.
• UAAG (User Agent Accessibility Guidelines): per browser e lettori multimediali.
• WCAG2ICT: nota del W3C che spiega come applicare le WCAG 2 a documenti e software non web (app desktop, PDF, documenti Office). È aggiornata a WCAG 2.2.
• Mobile: non esistono WCAG separate per le app; la WAI ha pubblicato indicazioni su come applicare WCAG 2.2 alle app mobili.

WCAG 3.0: cosa arriverà dopo

Il W3C sta lavorando a WCAG 3.0 (W3C Accessibility Guidelines, la "W" ora sta per W3C perché le linee guida non riguardano solo il web). La bozza più recente, pubblicata il 3 marzo 2026, introduce:

• un numero molto più alto di requisiti, formulati come risultati da ottenere;
• valutazioni graduate invece del semplice "superato/non superato";
• tre livelli di conformità: Bronzo, Argento e Oro;
• un nuovo metodo per il contrasto, in discussione da anni.

WCAG 3.0 è ancora una bozza di lavoro e non dovrebbe diventare definitiva prima del 2028. Quando sarà pubblicata, non sostituirà automaticamente WCAG 2.2: le leggi continueranno a richiamare WCAG 2.x finché non verranno aggiornate. Oggi WCAG 2.2 è e resta lo standard su cui lavorare.

Conclusioni

Le WCAG 2.2, pubblicate il 5 ottobre 2023, sono oggi lo standard più aggiornato per l'accessibilità digitale e, con la EN 301 549 V4.1.1, stanno diventando il riferimento ufficiale in tutta Europa. Per chi parte da WCAG 2.1 il salto è contenuto: sei criteri, quasi tutti di buon senso, che migliorano l'esperienza di chiunque usi tastiera, touch o abbia poca pazienza con i moduli e le password.

Se vuoi sapere a che punto è il tuo sito, o vuoi realizzarne uno nuovo accessibile fin dall'inizio, il team di IOCOS può aiutarti con un'analisi dei criteri WCAG 2.2 AA, le correzioni tecniche e la dichiarazione di accessibilità. Richiedi un progetto web per parlarne.