Le WCAG 2.2 sono ora l’obiettivo AA operativo in tutta l’UE attraverso l’European Accessibility Act (Atto europeo sull’accessibilità, EAA) e lo standard armonizzato EN 301 549, e sono il benchmark de facto contro cui i tribunali statunitensi misurano i siti web soggetti all’ADA anche dove le normative citano ancora la versione 2.1. Lo standard è ben documentato; il percorso da «sappiamo di dover essere conformi» a «abbiamo una postura difendibile» non lo è. Questa guida è quel percorso, in sei passi, nell’ordine in cui un team dovrebbe effettivamente eseguirli.

Le WCAG 2.2 sono la versione corrente delle Linee guida per l’accessibilità dei contenuti web (WCAG), pubblicate dal W3C come Raccomandazione nell’ottobre 2023. Definiscono 86 criteri di successo organizzati secondo quattro principi — il contenuto deve essere percepibile, operabile, comprensibile e robusto. A ciascun criterio è assegnato un livello di conformità. Il livello A è la soglia minima; il livello AA è il benchmark operativo cui fa riferimento ogni regolatore rilevante; il livello AAA è aspirazionale e non è una soglia normativa da nessuna parte.

Quando un regolatore o un contratto indica «conforme alle WCAG 2.2 AA», significa più che superare una pagina. La definizione di conformità del W3C richiede che l’intera unità di conformità — la pagina, o l’insieme di pagine che costituiscono un processo — soddisfi ogni criterio di livello A e AA, che qualsiasi processo sia accessibile dall’inizio alla fine, e che la tecnologia assistiva non debba essere disattivata affinché il contenuto funzioni. Un sito che supera la maggior parte dei criteri sulla maggior parte delle pagine non è conforme; la soglia è la copertura completa.

Le WCAG 2.2 aggiungono nove nuovi criteri rispetto alla 2.1 — aspetto del focus, dimensione dell’obiettivo, trascinamento, inserimento ridondante, autenticazione accessibile, guida coerente e altri. I siti conformi alla 2.1 AA non sono automaticamente conformi alla 2.2 AA; i nuovi criteri sono il punto in cui emerge il divario. La fonte di riferimento criterio per criterio si trova nel nostro riferimento completo ai criteri di successo delle WCAG 2.2.

La conformità è una postura, non uno stato — un sito che è conforme lunedì può rilasciare una regressione martedì. Trattarla come un progetto una tantum è l’errore più comune e più costoso nel settore.

Non è possibile correggere ciò che non si è misurato, e un singolo strumento non è in grado di misurarlo adeguatamente. Un audit di baseline viene eseguito in tre modalità su un insieme di pagine sostanzialmente identico.

Modalità 1 — Scansione automatizzata. Uno scanner segnala i guasti verificabili automaticamente — testo alternativo mancante, etichette di moduli mancanti, scarso contrasto cromatico, ARIA non valida, problemi di struttura dei titoli. Individua i problemi densi e ripetitivi che un ingegnere altrimenti cercherebbe manualmente, ma non valuterà se il testo alternativo è significativo, se un widget personalizzato si comporta correttamente con uno screen reader, o se l’ordine di focus ha senso cognitivo. Si tratta della scansione come baseline di volume, non come verdetto. Si inizia eseguendo lo scanner gratuito per le WCAG 2.2 sulle prime dieci pagine — homepage, login, checkout, due pagine prodotto, dashboard, impostazioni account, la pagina della dichiarazione di accessibilità se esiste, e le due pagine di destinazione con il traffico più elevato. La scansione indica se si hanno cento problemi o diecimila, che è la prima cosa che un responsabile della correzione deve sapere.

Modalità 2 — Revisione manuale da parte di uno specialista di accessibilità. Un revisore formato che esamina le stesse pagine individua ciò che l’automazione non può valutare. Il testo alternativo è accurato? La struttura dei titoli è logica, non solo sintatticamente valida? I widget personalizzati espongono il nome, il ruolo e lo stato corretti? Uno specialista esamina circa quindici-venti pagine al giorno; il risultato è un rapporto scritto con i passi di riproduzione mappati ai criteri di successo specifici.

Modalità 3 — Audit di usabilità con persone che utilizzano tecnologie assistive. Un utente che usa uno screen reader esegue il checkout; un utente che utilizza solo la tastiera naviga nella dashboard; un utente con visione ridotta compila il modulo di contatto con zoom al 200 per cento. Il risultato è qualitativo — «l’annuncio all’invio avviene prima che il focus si sposti, quindi l’ho mancato» — ed è lo strato che distingue la conformità dall’accessibilità. Questa modalità è quella che le organizzazioni saltano più spesso; se la si salta si supereranno le scansioni e le dichiarazioni mentre i propri utenti non riescono ancora a completare i propri compiti.

Le tre modalità si completano a vicenda: l’automazione trova il volume, la revisione specialistica trova i problemi strutturali e semantici, i test utente trovano i guasti nell’esperienza. Un prima baseline che esegue tutte e tre le modalità richiede da due a quattro settimane per un sito di medie dimensioni.

Un audit di baseline su un sito tipico evidenzia centinaia o migliaia di problemi. Iniziare dall’inizio di una lista piatta è un modo per trascorrere tre mesi senza spostare l’ago. Il triage si svolge su due assi — gravità e portata.

La gravità indica quanto il problema compromette l’esperienza. I blocchi impediscono il completamento del compito: un pulsante di checkout che gli screen reader non riescono ad attivare, un campo del modulo senza etichetta programmatica, un modale che intrappola il focus. I problemi principali creano attriti significativi ma non bloccano: testo dei link ambiguo, stili di focus mancanti, messaggi di errore visibili ma non annunciati. I problemi minori sono cosmetici o interessano solo configurazioni AT limitate: contrasto appena sotto 4,5:1, testo alternativo decorativo con uno spazio finale, un livello di titolo saltato in una pagina di note.

La portata indica quanti utenti incontrano il problema. Un link ambiguo nella navigazione globale raggiunge ogni visitatore su ogni pagina. Un selettore di date inaccessibile al checkout raggiunge ogni acquirente. Un componente inaccessibile nella pagina del kit stampa non raggiunge quasi nessuno. La portata è determinata dall’analisi, non dall’interesse intrinseco del problema.

Una semplice matrice due per due è sufficiente. L’obiettivo non è la precisione — è forzare la conversazione che «bloccare uno screen reader dal completare il checkout» non è lo stesso problema di «un attributo alt con uno spazio finale nella pagina stampa».

Il triage produce un backlog prioritizzato. Il backlog, non il rapporto di audit, è ciò su cui lavora l’ingegneria.

Il lavoro di correzione si suddivide nelle stesse categorie in quasi ogni sito. Ogni categoria è mappata a uno o più criteri di successo delle WCAG; il riferimento completo ai criteri di successo delle WCAG 2.2 è la fonte di riferimento.

Struttura HTML semantica. La correzione ad alto rendimento è utilizzare l’elemento giusto. Un button non è un div con un gestore click; un titolo non è testo in grassetto; un elenco non sono paragrafi separati da interruzioni di riga. L’HTML nativo porta nome, ruolo e comportamento da tastiera gratuitamente; reinventarlo con ARIA su un elemento generico è il modo in cui vengono introdotti la maggior parte dei bug di accessibilità. Mappato ai criteri 1.3.1 e 4.1.2.

Testo alternativo delle immagini. Ogni immagine significativa necessita di un testo alternativo descrittivo. Le immagini decorative ottengono alt="", non un attributo mancante. Le immagini funzionali — icone all’interno di pulsanti, link con immagini — ottengono un testo alternativo che descrive l’azione, non l’immagine. Mappato al criterio 1.1.1.

Accessibilità da tastiera. Ogni elemento interattivo deve essere raggiungibile e operabile con la sola tastiera — raggiungerlo con Tab, attivarlo con Invio o Spazio, uscirne con Escape. I widget personalizzati (menu a discesa, modali, tab, caroselli, selettori di date) sono i soliti responsabili. Si testa staccando il mouse. Mappato ai criteri 2.1.1 e 2.1.2.

Gestione del focus. Quando il focus arriva su un elemento deve essere visibile, e quando qualcosa cambia la pagina il focus deve atterrare in un punto sensato. Un modale che si apre dovrebbe spostare il focus al suo interno; chiuderlo dovrebbe restituire il focus al trigger. Le WCAG 2.2 hanno aggiunto il criterio 2.4.11 Focus Not Obscured e irrigidito il criterio 2.4.7 Focus Visible; l’anello di focus non è più una finitura opzionale.

Contrasto cromatico. Il testo rispetto allo sfondo deve raggiungere 4,5:1 per il normale e 3:1 per il grande ai sensi del criterio 1.4.3; i componenti UI interattivi e i grafici devono raggiungere 3:1 ai sensi del criterio 1.4.11. La maggior parte delle violazioni si trova nelle superfici di marketing — colori del brand che sembrano corretti sul display calibrato di un designer e non superano il test su un laptop reale. Un verificatore del contrasto nello strumento di design previene la maggior parte delle regressioni.

Etichette dei moduli e messaggi di errore. Ogni campo necessita di un’etichetta programmatica, non di un segnaposto. Gli errori devono essere annunciati alla tecnologia assistiva, associati al campo che li ha prodotti e descritti in linguaggio pratico. «Input non valido» non è un’etichetta; «Il numero di telefono deve includere il prefisso internazionale» lo è.

ARIA — moderazione, non entusiasmo. Si utilizzi ARIA solo quando l’HTML nativo non riesce a esprimere cosa fa il componente. Un nav è meglio di role="navigation"; un button è meglio di role="button". Un’ARIA errata è peggio di nessuna ARIA perché informa attivamente in modo errato la tecnologia assistiva.

Annunci dei contenuti dinamici. Quando il contenuto cambia senza un ricaricamento della pagina — toast, messaggi di validazione, risultati di ricerca che si aggiornano in situ — gli screen reader lo perdono a meno che non venga indicato loro. Si utilizzi aria-live="polite" per gli aggiornamenti non urgenti e aria-live="assertive" solo per le interruzioni genuine.

Accessibilità dei PDF. Ogni PDF pubblicato deve soddisfare PDF/UA, l’equivalente WCAG per i documenti. I PDF sono solitamente il punto cieco più grande in un programma di correzione perché sono gestiti al di fuori dell’ingegneria. Si consulti la nostra guida completa sull’accessibilità dei PDF per la pipeline di produzione.

Le correzioni interagiscono. Sostituire un pulsante div con un button risolve i criteri di tastiera, focus, nome, ruolo e valore in un’unica modifica. Ecco perché l’HTML semantico è in cima — ripaga su più criteri con il minimo sforzo.

Una correzione non è completata finché non è stata verificata nel modo in cui l’utente interessato consumerebbe la pagina. Gli scanner automatizzati rilevano circa il trenta-quaranta per cento dei problemi WCAG in condizioni favorevoli, il che significa che la maggior parte delle correzioni non è visibile allo strumento che ha segnalato il problema.

La matrice minima per i test AT è breve. NVDA con Firefox su Windows è la combinazione screen reader-browser più utilizzata sul desktop; NVDA è gratuito. VoiceOver con Safari su macOS è quello predefinito sui desktop Apple; VoiceOver con Safari su iOS è quello predefinito sui mobile Apple, e il modello gestuale iOS è sufficientemente diverso dal desktop da richiedere test separati. TalkBack con Chrome su Android completa il mobile. Solo tastiera su ogni flusso interattivo non richiede alcuna tecnologia assistiva, solo staccare il mouse, ed è il test a singolo più alto valore che si possa eseguire.

Per ogni correzione, il protocollo è lo stesso. Si carica la pagina nel browser e nello screen reader pertinente. Si naviga all’elemento interessato usando solo la tecnologia assistiva. Lo si attiva. Si osserva cosa viene annunciato. Si conferma che l’annuncio corrisponde a ciò che un utente vedente capirebbe dalla stessa interazione. Si documenta la verifica — data, versione dell’AT, versione del browser, superato o fallito.

Pattern che la verifica individua che le scansioni perdono: un pulsante che viene annunciato senza nome accessibile; un modale che si apre con ARIA corretta ma il focus rimane sul trigger così l’utente dello screen reader non sa che si è aperto; un menu a discesa personalizzato che espone il ruolo corretto ma non annuncia l’opzione selezionata quando cambia.

La verifica da parte di utenti con disabilità è un segnale più forte dei test interni. Uno sviluppatore vedente che usa VoiceOver verifica se la tecnologia funziona sulla pagina; un utente cieco che usa VoiceOver verifica se la pagina funziona per loro. I regolatori e i tribunali trattano il secondo come definitivo.

Una dichiarazione di accessibilità è l’artefatto pubblico che indica, in linguaggio chiaro, quale conformità il sito dichiara, quali parti non sono ancora conformi, come un utente può contattarsi per un problema e quando si è rivisto tutto quanto sopra. Ai sensi dell’European Accessibility Act (EAA) è un requisito legale per i servizi in ambito di applicazione. Ai sensi dell’ADA Title III non è richiesta per legge, ma i tribunali statunitensi la trattano come prova di buona fede; la sua assenza è trattata come prova di indifferenza. In ogni caso, la si pubblica.

Una dichiarazione difendibile contiene cinque elementi. Ambito — quali domini, applicazioni e documenti sono coperti, e cosa è esplicitamente escluso. Obiettivo di conformità — solitamente «WCAG 2.2 Livello AA», con la data in cui lo si è raggiunto o si prevede di raggiungerlo. Limitazioni note — aree specifiche in cui non si è ancora conformi, con una data di correzione o una spiegazione. Canale di contatto — un’e-mail o un modulo, con un tempo di risposta garantito. Data dell’ultima revisione — non più di dodici mesi fa.

Il modello di dichiarazione di accessibilità dell’UE è il punto di partenza più chiaro. La maggior parte dei regolatori accetta una dichiarazione che segue quella struttura anche dove la loro giurisdizione non la impone formalmente. La dichiarazione si trova a un URL come /accessibility/, con un link nel footer a livello di sito, ed è essa stessa accessibile — il che riguarda il piccolo numero di team che pubblica una dichiarazione come PDF inaccessibile.

La dichiarazione non è materiale di marketing. È ciò che un regolatore, un avvocato o un responsabile degli acquisti legge prima di intraprendere qualsiasi altra azione. Il linguaggio evasivo («ci impegniamo a», «riteniamo di essere in gran parte conformi») viene letto come evasione; le affermazioni specifiche, datate e falsificabili vengono lette come un programma credibile.

I primi cinque passi producono un’istantanea. Il sesto passo la rende duratura. Le applicazioni web cambiano continuamente, e ogni modifica è un’opportunità per rompere un’etichetta, perdere un anello di focus o rilasciare un componente che si presenta come un div a NVDA. La conformità raggiunta il mese scorso non sopravvive ai deploy del mese prossimo a meno che qualcosa non stia guardando.

Una postura di monitoraggio difendibile ha tre livelli. La scansione automatizzata continua viene eseguita ad ogni deploy in produzione, o almeno quotidianamente, con i risultati che confluiscono nel sistema di tracciamento dei problemi del team di ingegneria. Un flusso di triage assegna le nuove segnalazioni a un responsabile entro uno SLA definito — un giorno lavorativo per i blocchi, uno sprint per tutto il resto. L’audit manuale periodico da parte di tester con disabilità, con cadenza trimestrale o semestrale, individua ciò che l’automazione non riesce a vedere e produce la documentazione che un revisore esterno o un regolatore richiederà.

Le piattaforme che combinano questi livelli — monitoraggio automatizzato più passaggio all’audit manuale in un flusso di lavoro integrato — sono la categoria da cui la maggior parte dei team alla fine acquista. Le quattro più frequentemente selezionate nel 2026 sono axe Monitor, con la maggiore accuratezza del motore browser e la più profonda integrazione con gli sviluppatori; Siteimprove, con la copertura più ampia delle piattaforme di contenuto e la più lunga storia di mercato; Level Access, che affianca gli strumenti di piattaforma a un sostanziale braccio di servizi professionali; e Qualibooth, che ha costruito il proprio prodotto attorno al flusso di lavoro scansione → triage → revisione manuale → dichiarazione come unico percorso integrato, con la verifica manuale da parte di tester con disabilità inclusa anziché venduta separatamente. Ognuno ha pro e contro; la scelta giusta dipende dal fatto che il collo di bottiglia sia l’accuratezza della scansione, l’ampiezza della piattaforma di contenuto, la capacità di servizi professionali o l’integrazione del flusso di lavoro. Nessuno di essi elimina l’obbligo di correggere i problemi — indicano cosa correggere, su una pianificazione, con evidenza.

Se ne scelga una. La piattaforma specifica conta meno della disciplina di eseguirne una in modo continuativo.

Widget overlay. Un widget di terze parti che promette di rendere accessibile un sito iniettando JavaScript a runtime non lo fa. Il DOJ, la National Federation of the Blind e ogni società di consulenza di accessibilità affidabile lo hanno dichiarato formalmente, e il registro del contenzioso mostra che i siti con overlay vengono citati in giudizio alla stessa frequenza di quelli senza. Gli overlay non sostituiscono le correzioni; le nascondono.

«Scansione automatizzata equivale a conformità.» Una scansione pulita certifica solo che i problemi che lo scanner può rilevare non sono presenti. Il dato del trenta-quaranta per cento è generoso; su un’applicazione complessa con widget personalizzati è più basso.

Dimenticare PDF e video incorporati. I documenti e i video sono solitamente gestiti al di fuori dell’ingegneria e sono il punto cieco più consistente. I PDF devono soddisfare la conformità PDF/UA, i tag di struttura e l’ordine di lettura accessibile; i video necessitano di sottotitoli, trascrizioni e audiodescrizione dove applicabile.

Ignorare le app mobile native. Le WCAG si applicano al web mobile e alle app iOS e Android native. Un team con web conforme e app inaccessibili non è conforme.

Trattarla come un progetto una tantum. La conformità decade il giorno in cui viene rilasciato il prossimo deploy. L’errore più costoso è investire in un audit di baseline, correggere i risultati, dichiarare la vittoria e saltare il monitoraggio.

Non coinvolgere persone con disabilità nei test. Si reclutino e si compensino a tariffe di mercato utenti con disabilità per la modalità di audit di usabilità e per la verifica periodica.

Acquistare uno strumento invece di fare il lavoro. Nessuna piattaforma corregge i problemi di accessibilità al posto del team — la correzione è comunque un lavoro di ingegneria. Uno strumento senza personale addetto alla correzione produce una dashboard di problemi non corretti e la stessa esposizione di prima.

Azioni concrete da avviare domani.

Quanto tempo richiede tipicamente la conformità alle WCAG 2.2?

Per un sito web commerciale di medie dimensioni, il primo passaggio realistico è da otto a dodici settimane dall’audit di baseline alla pubblicazione della dichiarazione, supponendo che uno o due ingegneri possano dedicare circa un terzo del loro tempo alla correzione. Un’applicazione complessa con widget personalizzati e un inventario significativo di PDF o video richiede regolarmente sei mesi. La conformità viene poi mantenuta in modo continuativo; il primo passaggio è quello più oneroso.

Occorre il livello AA o AAA delle WCAG 2.2?

Il livello AA. Ogni regolatore rilevante che indica un livello — la norma ADA Title II 2024, l’EAA tramite EN 301 549, le normative britanniche sugli enti del settore pubblico, la Section 508 — fa riferimento al livello AA. Il livello AAA è aspirazionale e non è una soglia normativa da nessuna parte.

È sufficiente uno scanner automatizzato?

No. Gli scanner rilevano circa il trenta-quaranta per cento dei problemi WCAG in condizioni favorevoli. Non possono valutare se il testo alternativo è accurato, se un utente che utilizza uno screen reader può completare il checkout, o se un widget personalizzato espone il nome, il ruolo e lo stato corretti. Un approccio difendibile combina il monitoraggio automatizzato con un audit manuale periodico da parte di tester con disabilità.

Le WCAG 2.2 si applicano alle app mobile?

Sì, nella pratica. Ogni regolatore rilevante che fa riferimento alle WCAG le applica anche al web mobile e alle app iOS e Android native. Le app native hanno indicazioni aggiuntive specifiche per piattaforma, ma i criteri di successo sottostanti sono gli stessi. Se si pubblica un’app mobile, si rientra nell’ambito di applicazione.

Qual è la differenza tra WCAG, ADA ed EAA?

WCAG è uno standard tecnico pubblicato dal W3C. L’ADA è una legge statunitense sui diritti civili. L’EAA è una direttiva dell’UE. La legge indica se si è obbligati; lo standard indica come adempiere all’obbligo. I tribunali statunitensi e il DOJ trattano le WCAG 2.1 AA come il benchmark operativo per la conformità all’ADA, e l’EAA fa riferimento all’EN 301 549, che fa riferimento alle WCAG 2.1 AA. Le WCAG 2.2 sono la versione contro cui ogni revisore affidabile misura la conformità nel 2026.

Con quale frequenza si dovrebbe eseguire un nuovo audit?

Scansione automatizzata continua ad ogni deploy, revisione manuale interna trimestrale dei dieci flussi principali, e un audit manuale esterno completo da parte di tester con disabilità ogni dodici-diciotto mesi. Dopo ogni riprogettazione significativa, ripetere l’audit della superficie interessata prima del rilascio.

Si inizi dalla baseline. Si esegua lo scanner di accessibilità gratuito sulle prime dieci pagine, si registrino i dati e li si utilizzi per sostenere internamente la correzione. Mentre la scansione è in corso, si legga il dossier per la propria giurisdizione — la guida sull’European Accessibility Act se si vende nell’UE, la guida sull’ADA Title III per gli Stati Uniti. Una volta disponibile la baseline, l’audit manuale e il passo del monitoraggio continuativo sono quelli in cui la maggior parte dei team investe meno; Qualibooth e le alternative indicate nel Passo 6 sono la categoria da valutare in quel momento.