Che cos’è un audit di accessibilità? Come verificare se il tuo sito web è conforme alle WCAG

Secondo l’ultimo rapporto WebAIM Million, sono stati rilevati 56 milioni di errori di accessibilità distinti su un milione di home page — una media di 56 errori per pagina. Ciò significa che la stragrande maggioranza dei siti web fallisce attivamente nei confronti degli utenti con disabilità ogni singolo giorno. Se sei un proprietario di sito, uno sviluppatore o un responsabile della conformità che si chiede se il proprio sito sia conforme alle WCAG, la risposta quasi certamente implica l’esecuzione di un audit di accessibilità adeguato. La domanda è: cosa significa esattamente e come si fa nel modo giusto?

Perché gli audit di accessibilità sono diventati non negoziabili

L’accessibilità web è andata ben oltre il semplice ambito delle buone intenzioni. È ormai un requisito legale in un numero crescente di giurisdizioni, e le conseguenze della non conformità sono concrete e misurabili. Oltre 4.000 cause legali relative all’accessibilità web sono state intentate negli Stati Uniti nel 2024, e la tendenza continua a crescere. I tribunali statunitensi hanno costantemente stabilito che i siti web delle attività aperte al pubblico devono essere accessibili ai sensi del Titolo III dell’ADA. Nel frattempo, l’European Accessibility Act è diventato applicabile in tutti gli Stati membri dell’UE nel giugno 2025, estendendo i requisiti oltre i siti governativi per coprire app bancarie, piattaforme di e-commerce, prodotti SaaS e altro ancora.

I numeri delineano un quadro netto. Circa il 16% della popolazione mondiale — circa 1,3 miliardi di persone — vive con qualche forma di disabilità. Solo negli Stati Uniti, circa un adulto su quattro ha una disabilità. Non si tratta di utenti marginali. Sono clienti, dipendenti, studenti e cittadini che incontrano barriere su siti web a cui la maggior parte degli sviluppatori non pensa nemmeno.

Oltre al rischio legale, esiste un business case misurabile. I siti accessibili hanno prestazioni migliori nei motori di ricerca, perché la stessa chiarezza strutturale che aiuta gli screen reader — titoli semantici, testo alternativo descrittivo, markup pulito — aiuta anche i crawler. Il design inclusivo migliora costantemente l’usabilità per tutti: i sottotitoli avvantaggiano le persone in ambienti rumorosi, l’elevato contrasto aiuta le persone alla luce solare intensa e la navigazione da tastiera avvantaggia gli utenti esperti. Un audit di accessibilità è il primo passo per cogliere tutti questi benefici.

Un altro cambiamento importante: il Titolo II dell’ADA ora richiede esplicitamente l’accessibilità web per gli enti governativi statali e locali degli Stati Uniti, con il DOJ che adotta le WCAG 2.1 Livello AA come standard tecnico. Gli enti che servono popolazioni di 50.000 o più persone affrontano una scadenza di conformità fissata al 26 aprile 2026. Se lavori con clienti del settore pubblico o operi in settori regolamentati, l’audit non è più opzionale — è urgente.

Che cos’è esattamente un audit di accessibilità WCAG?

Un audit di accessibilità web è una valutazione sistematica della conformità del tuo sito web alle Web Content Accessibility Guidelines (WCAG) — lo standard tecnico riconosciuto a livello internazionale per l’accessibilità digitale, sviluppato dal W3C. In pratica, un audit identifica barriere specifiche che impediscono agli utenti con disabilità di percepire, comprendere, navigare e interagire con i tuoi contenuti. Mappa tali barriere rispetto ai criteri di successo WCAG, assegna livelli di gravità e produce una roadmap di remediation.

Le WCAG sono attualmente alla versione 2.2, pubblicata alla fine del 2023 e formalmente riaffermata dal W3C nel maggio 2025 come il più alto standard per l’accessibilità web. Includono nove nuovi criteri di successo rispetto alle WCAG 2.1, che coprono aree come la visibilità del focus da tastiera, le dimensioni minime dei target tattili, le alternative al trascinamento e i meccanismi di aiuto coerenti. È importante sottolineare che le WCAG 2.2 sono retrocompatibili — soddisfare la 2.2 significa soddisfare anche la 2.1 e la 2.0.

Le WCAG sono organizzate in tre livelli di conformità. Il Livello A copre le barriere più critiche — i fallimenti a questo livello rendono i contenuti completamente inutilizzabili per alcuni utenti. Il Livello AA è l’obiettivo richiesto dalla maggior parte delle leggi sull’accessibilità nel mondo, inclusi l’ADA, l’European Accessibility Act e la Section 508. Il Livello AAA rappresenta il livello più alto ed è tipicamente aspirazionale piuttosto che legalmente richiesto. Quando qualcuno dice che il proprio sito è “conforme alle WCAG”, quasi sempre intende WCAG 2.1 o 2.2, Livello AA.

Le WCAG si basano su quattro principi fondamentali, spesso ricordati con l’acronimo POUR: i contenuti devono essere Perceivable (gli utenti possono percepirli), Operable (gli utenti possono interagirvi), Understandable (gli utenti possono comprenderli) e Robust (funzionano in modo affidabile con le tecnologie assistive). Ogni criterio di successo si ricollega a uno di questi quattro principi, e un audit approfondito verifica la conformità rispetto a tutti.

I fallimenti più comuni che gli audit rilevano

Circa il 96% di tutti gli errori di accessibilità rilevati rientra in sole sei categorie. Sapere cosa cercare è il modo più rapido per dare priorità al tuo sforzo di audit:

• Testo a basso contrasto. Questo è costantemente il fallimento più comune. Quasi l’84% delle home page presenta testo che non raggiunge la soglia di contrasto WCAG 2 AA di 4,5:1 per il testo normale. Gli auditor verificano i rapporti di colore primo piano-sfondo usando strumenti come TPGi Colour Contrast Analyser.
• Testo alternativo mancante. Oltre il 16% di tutte le immagini in home page è privo di qualsiasi attributo alt, lasciando gli utenti di screen reader senza modo di comprendere il contenuto dell’immagine. Le immagini collegate senza testo alternativo sono particolarmente dannose — diventano destinazioni di navigazione prive di significato.
• Link vuoti. I link che non contengono testo visibile né un nome accessibile creano vicoli ciechi per gli utenti di tastiera e screen reader, che non possono determinare dove porta il link.
• Etichette dei campi modulo mancanti. I moduli senza etichette associate in modo programmatico sono inutilizzabili per gli utenti di screen reader. Ciò include sia le etichette visibili sia le etichette nascoste che utilizzano aria-label o aria-labelledby.
• Pulsanti vuoti. I pulsanti composti solo da icone e privi di un nome accessibile — comuni nella navigazione e negli slider — lasciano gli utenti non visivi incapaci di identificare cosa faccia il pulsante.
• Lingua del documento mancante. L’attributo lang sull’elemento <html> indica agli screen reader quale lingua utilizzare. La sua assenza causa pronunce errate e disorientamento per gli utenti che si affidano alla sintesi vocale.

Gli audit rivelano costantemente che i fallimenti più dannosi sono anche i più facili da correggere. Basso contrasto, testo alternativo mancante e campi modulo senza etichetta possono spesso essere corretti in giorni, non mesi.

Oltre a questi sei, un audit approfondito rileverà anche l’assenza di link per saltare la navigazione (che costringono gli utenti di tastiera a scorrere con Tab ogni elemento di intestazione su ogni pagina), gerarchie di titoli improprie, modali e dialoghi inaccessibili che gestiscono il focus in modo errato, video senza sottotitoli, PDF privi di struttura taggata e widget JavaScript personalizzati che non espongono ruoli e stati accessibili tramite ARIA.

Come condurre un audit di accessibilità: passo dopo passo

Un audit di accessibilità adeguato non è una singola scansione — è un processo a più fasi che combina strumenti automatici con il giudizio di esperti umani. Ecco come affrontarlo in modo sistematico:

Fase 1: Definire l’ambito

Prima di eseguire un singolo test, decidi cosa stai auditando. Per un sito di grandi dimensioni, testare ogni pagina è impraticabile. Applica invece l’approccio WCAG-EM (Website Accessibility Conformance Evaluation Methodology) sviluppato dal W3C: definisci un campione rappresentativo che copra tutti i template di pagina unici, tutti i percorsi utente significativi e tutti i tipi di contenuto distinti. Un campione per un sito di e-commerce potrebbe includere la homepage, una pagina di categoria, una pagina di dettaglio prodotto, il carrello, il flusso di checkout, il login dell’account, il modulo di contatto e un post del blog. Assicurati che gli stati dinamici siano inclusi — menu aperti, messaggi di errore dei moduli, finestre modali e risultati di ricerca caricati devono tutti essere valutati.

Fase 2: Eseguire scansioni automatiche

Gli strumenti automatici sono la base di qualsiasi audit efficiente. Analizzano rapidamente il tuo HTML, segnalano violazioni di regole non ambigue e ti forniscono un elenco di problemi di base. Gli strumenti chiave includono:

• axe DevTools (estensione del browser o CLI) — ampiamente utilizzato, basso tasso di falsi positivi, si integra con le pipeline CI/CD
• WAVE (WebAIM) — annota le pagine visivamente con icone di errore, rendendolo intuitivo per i membri del team non tecnici
• Lighthouse (integrato in Chrome DevTools) — fornisce un punteggio di accessibilità insieme a metriche di performance e SEO
• Colour Contrast Analyser (TPGi) — seleziona qualsiasi colore sullo schermo e lo verifica rispetto alle soglie WCAG
• PAC 2024 — strumento dedicato al controllo dell’accessibilità dei PDF per i documenti scaricabili

Un limite critico: gli strumenti automatici possono rilevare solo tra il 30% e il 40% dei problemi WCAG. Eccellono nell’evidenziare fallimenti basati su regole come attributi mancanti, ruoli ARIA non validi e rapporti di contrasto. Ma non possono giudicare se il testo alternativo sia significativo, se un modulo sia strutturato logicamente o se un utente possa effettivamente completare un’attività. Ecco perché l’automazione è la Fase 2, non l’intero audit.

Fase 3: Test manuali da parte di esperti

I test manuali condotti da una persona competente — o idealmente da un team — determinano la profondità di un audit. Ciò include:

• Navigazione solo da tastiera. Scollega il mouse e prova a completare ogni percorso utente principale usando solo Tab, Shift+Tab, Invio, Spazio e i tasti freccia. Puoi raggiungere ogni elemento interattivo? L’indicatore di focus è sempre visibile? Il focus scompare mai all’interno di un componente?
• Test con screen reader. Usa NVDA con Chrome o Firefox su Windows e VoiceOver con Safari su macOS e iOS. Naviga per titoli, landmark, link e moduli. La pagina ha senso senza contesto visivo? Tutti gli elementi interattivi vengono annunciati correttamente?
• Revisione visiva e cognitiva. Controlla la gerarchia dei titoli per una struttura logica, verifica che i messaggi di errore siano descrittivi e associati al campo corretto, conferma che i contenuti multimediali temporizzati abbiano sottotitoli e trascrizioni e verifica che le istruzioni non si basino esclusivamente su colore, forma o posizione.
• Ispezione del codice. Esamina la semantica HTML, l’uso di ARIA, la gestione del focus nei widget personalizzati e le regioni landmark. Una finestra modale che non intrappola il focus, o una regione ARIA live che si attiva a ogni pressione di tasto, verrà rilevata solo a questo livello.

Fase 4: Test con tecnologie assistive insieme a utenti reali

Lo standard d’oro — e spesso la fase più rivelatrice — è il test con utenti reali che si affidano quotidianamente alle tecnologie assistive. Le persone che usano screen reader, dispositivi di accesso a interruttore o software di controllo vocale navigano in modi che nemmeno i tester manuali esperti replicano completamente. Coinvolgere utenti con disabilità nella valutazione fa emergere attriti reali che strumenti e checklist semplicemente non possono anticipare.

Fase 5: Documentare e dare priorità ai risultati

Un elenco grezzo di fallimenti non è un rapporto di audit — è un punto di partenza. Un documento di audit utile dovrebbe specificare: l’URL o il componente interessato, il criterio di successo WCAG violato, la gravità (critico, alto, medio, basso), l’impatto sugli utenti interessati e indicazioni specifiche per la remediation con esempi di codice ove applicabile. La priorità dovrebbe essere assegnata in base all’impatto sugli utenti prima che alla convenienza tecnica. Un’etichetta di modulo rotta che impedisce il checkout è più urgente di un livello di intestazione subottimale nella barra laterale di un blog.

Fase 6: Correggere, convalidare e monitorare

Una volta implementate le correzioni, convalidale — non dare per scontato che la remediation abbia funzionato. Ritesta ogni correzione con la stessa combinazione di strumenti e verifiche manuali utilizzata durante l’audit originale. Dopo aver raggiunto un livello di conformità di base, implementa un monitoraggio continuo. Nuovi contenuti, aggiornamenti del CMS e script di terze parti possono introdurre regressioni in qualsiasi momento. Tratta l’accessibilità come la sicurezza: qualcosa che mantieni, non qualcosa che raggiungi una volta e poi dimentichi.

Scansioni automatiche vs. audit completi: capire la differenza

Questa distinzione è estremamente importante, soprattutto in un contesto legale. Una scansione automatica esegue un controllo basato su regole sul tuo HTML renderizzato. Richiede secondi o minuti e restituisce un elenco di violazioni rilevate. È eccellente per individuare i problemi ovvi e ad alto volume e per integrarsi nei flussi di lavoro CI/CD per impedire che nuove regressioni vengano distribuite. Molti prodotti di overlay e widget — inclusi strumenti di accessibilità — offrono dashboard di scansione automatica come parte del loro set di funzionalità, e questi sono davvero utili per il monitoraggio continuo.

Un audit completo, al contrario, valuta il tuo sito rispetto a ogni criterio di successo WCAG applicabile utilizzando una combinazione di scansioni automatiche, revisione manuale da parte di esperti, test con screen reader e navigazione solo da tastiera. Un audit completo che combina metodi automatici e manuali può far emergere oltre il 90% dei problemi di accessibilità, rispetto al limite del 30–40% dell’automazione da sola. Se ti trovi ad affrontare una lettera di diffida legale, un requisito di procurement o un’indagine regolatoria, solo un audit completo produce la documentazione di cui hai bisogno.

Molte organizzazioni utilizzano una strategia ibrida pratica: le scansioni automatiche vengono eseguite continuamente in CI/CD per rilevare le regressioni in anticipo, mentre un audit manuale completo viene condotto annualmente o dopo significativi redesign del sito. Questo bilancia accuratezza ed efficienza e mantiene la conformità gestibile nel tempo.

Nessuno strumento da solo può determinare se un sito soddisfa gli standard di accessibilità. È necessaria una valutazione da parte di persone competenti per stabilire se un sito è realmente accessibile. — W3C Web Accessibility Initiative

Cosa fare con i risultati dell’audit: pianificazione della remediation

Un audit completato è utile solo se genera azioni. Il modo in cui dai priorità al lavoro di remediation è importante quanto l’identificazione dei problemi stessi. Un framework pratico per la priorità della remediation è il seguente:

1. Critico (da correggere immediatamente): Problemi che bloccano completamente gli utenti nel completare le attività principali — un modulo di checkout non funzionante, una finestra modale di login inaccessibile, un menu di navigazione irraggiungibile da tastiera. Rappresentano il rischio legale più elevato e il maggiore impatto sugli utenti.
2. Alto (da correggere nell’attuale sprint o ciclo di rilascio): Problemi che compromettono significativamente l’usabilità per gli utenti con disabilità ma non li bloccano del tutto — testo alternativo mancante sulle immagini dei prodotti, basso contrasto sul testo del corpo, pulsanti a icona senza etichetta in tutta l’interfaccia.
3. Medio (remediation pianificata): Problemi che causano attrito ma hanno soluzioni alternative — indicatori di focus incoerenti, link per saltare la navigazione mancanti, gerarchia dei titoli subottimale.
4. Basso (backlog con responsabile definito): Problemi che rappresentano miglioramenti di best practice ma è improbabile che influiscano sull’usabilità nella maggior parte dei casi — miglioramenti di livello AAA, piccole ottimizzazioni della verbosità ARIA.

Documenta il tuo piano di remediation e la relativa timeline, anche prima che tutte le correzioni siano completate. I regolatori e i tribunali in genere considerano favorevolmente un miglioramento dimostrato, continuo e in buona fede rispetto all’inazione. Se ricevi una lettera di diffida, avere un rapporto di audit più un programma di remediation è una posizione molto più forte rispetto a non avere alcuna documentazione.

Gli overlay widget e gli strumenti SDK — come quello offerto da Accsible — possono svolgere un ruolo significativo nella fase di remediation. Possono fornire correzioni immediate per una parte significativa dei problemi comuni (soprattutto preferenze visive come contrasto, dimensione del font e spaziatura) mentre il tuo team di sviluppo lavora su remediation più profonde a livello di codice. La chiave è capire cosa gli overlay risolvono bene e usarli come parte di una strategia a più livelli, non come sostituti delle correzioni a livello di codice per le barriere critiche.

Con quale frequenza dovresti eseguire un audit di accessibilità?

Un audit una tantum è un’istantanea del tuo sito in un determinato giorno. I siti web sono prodotti vivi — i contenuti cambiano, gli script di terze parti si aggiornano, i componenti vengono sostituiti e vengono rilasciate nuove funzionalità. Ciascuno di questi eventi può introdurre nuove barriere di accessibilità. Un programma di accessibilità sostenibile in genere appare così:

• Scansione automatica continua integrata nella pipeline CI/CD o tramite un dashboard di monitoraggio, per rilevare le regressioni prima che raggiungano la produzione
• Verifiche manuali trimestrali a campione sulle pagine ad alto traffico e ad alto rischio (checkout, login, moduli di contatto, landing page chiave)
• Audit completo annuale condotto da esperti qualificati di accessibilità, soprattutto dopo importanti redesign o migrazioni di piattaforma
• Audit in fase di design per qualsiasi nuova funzionalità principale o redesign — integrare l’accessibilità in fase di progettazione è significativamente più economico che applicarla a posteriori

L’approccio più conveniente è spostare l’accessibilità a sinistra — integrandola nel processo di design e sviluppo fin dal primo giorno, invece di trattarla come un esercizio di conformità post-lancio. Gli sviluppatori che comprendono i requisiti WCAG intercettano i problemi alla fonte. I designer che conoscono il contrasto dei colori e le dimensioni dei target tattili fanno scelte accessibili per impostazione predefinita. L’audit diventa così un gate di qualità piuttosto che un intervento d’emergenza.

Punti chiave

• La maggior parte dei siti web non soddisfa le WCAG. Oltre il 95% delle home page presenta errori di accessibilità rilevabili, e i sei fallimenti più comuni — basso contrasto, testo alternativo mancante, link vuoti, etichette dei moduli mancanti, pulsanti vuoti e lingua del documento mancante — rappresentano la grande maggioranza. Tutti questi problemi sono risolvibili.
• Gli strumenti automatici sono necessari ma non sufficienti. Gli scanner automatici rilevano al massimo il 30–40% dei problemi WCAG. Un audit completo richiede test da tastiera, test con screen reader e revisione esperta del codice e dei flussi UX.
• WCAG 2.2 Livello AA è l’obiettivo. È lo standard richiamato dall’ADA, dall’European Accessibility Act, dalla Section 508 e dalla maggior parte degli altri framework di accessibilità nel mondo. Puntare alla 2.2 AA significa coprire automaticamente tutte le versioni precedenti.
• La remediation ha bisogno di un framework di priorità. Inizia dai problemi che bloccano completamente i percorsi utente principali, poi affronta i problemi ad alto impatto e alta frequenza. Documenta tutto — il tuo rapporto di audit e il piano di remediation sono la tua migliore difesa legale.
• L’accessibilità è continua, non un’attività una tantum. Combina monitoraggio automatico continuo con audit manuali periodici e integra l’accessibilità nel processo di design e sviluppo fin dall’inizio. Un widget di overlay come Accsible può colmare le lacune mentre sono in corso remediation più profonde.