Un audit di accessibilità è una verifica sistematica di un sito o di un'app rispetto a un insieme di criteri, di solito le WCAG. A differenza di un controllo veloce, produce un quadro documentato: quali problemi ci sono, dove, quanto sono gravi e come si correggono. È il punto di partenza per qualunque piano serio di miglioramento, e in molti casi è anche un'esigenza normativa.
Perché farlo
In Italia la Legge Stanca, del 2004, ha introdotto obblighi di accessibilità per le pubbliche amministrazioni, che devono anche pubblicare una dichiarazione di accessibilità secondo le linee guida dell'AgID. Con l'Atto europeo sull'accessibilità, applicato dal 28 giugno 2025, obblighi simili riguardano anche molti prodotti e servizi privati, come il commercio elettronico, i servizi bancari e alcuni servizi di trasporto, con eccezioni per le microimprese che forniscono servizi. Lo standard tecnico di riferimento in Europa è la norma EN 301 549, che per i contenuti web richiama i criteri delle WCAG.
Al di là degli obblighi, un audit rivela problemi che allontanano clienti e utenti reali, e spesso porta alla luce anche difetti di usabilità generale.
Le fasi di un audit
1. Definire obiettivo e perimetro
Prima di tutto bisogna stabilire rispetto a che cosa si verifica e che cosa. Di solito l'obiettivo è il livello AA delle WCAG 2.1 o 2.2. Il perimetro indica quali parti del servizio rientrano: sito pubblico, area riservata, app mobili, documenti scaricabili.
2. Scegliere un campione di pagine
Su un sito con migliaia di pagine non si può verificare tutto. Si sceglie un campione rappresentativo che includa:
- la pagina iniziale e le pagine di navigazione principali;
- un esempio di ogni modello di pagina, come articolo, scheda prodotto, elenco, ricerca;
- i percorsi completi più importanti, come registrazione, acquisto, contatto, prenotazione;
- pagine con componenti complessi, come mappe, calendari, filtri, finestre modali;
- qualche pagina scelta a caso, per non verificare solo ciò che si conosce già.
I percorsi vanno verificati per intero: una pagina di pagamento accessibile non serve se il carrello che la precede non lo è.
3. Verifiche automatiche
Gli strumenti automatici analizzano il codice e segnalano problemi rilevabili in modo meccanico: immagini senza attributo alt, contrasto insufficiente, campi senza etichetta, attributi ARIA non validi, lingua della pagina non dichiarata. Sono veloci e utili per trovare errori ripetuti in molte pagine.
Il loro limite è importante: rilevano solo una parte dei problemi. Uno strumento verifica che un'immagine abbia un testo alternativo, ma non può dire se quel testo è sensato; verifica che un pulsante abbia un nome, ma non se quel nome descrive davvero l'azione.
4. Verifiche manuali
È la parte più lunga e più preziosa. Comprende:
- navigazione completa con la sola tastiera, controllando ordine e visibilità del focus;
- prova con almeno un lettore di schermo su computer e uno su mobile;
- ingrandimento del testo al 200% e riformattazione a larghezza ridotta, per verificare che nulla si perda o si sovrapponga;
- controllo di titoli, punti di riferimento, testi dei link e struttura delle tabelle;
- verifica di moduli, messaggi di errore e messaggi di stato;
- controllo di video, audio, animazioni e contenuti che si muovono da soli.
5. Documentare i problemi
Ogni problema va registrato in modo che chi deve correggerlo possa farlo senza dover rifare l'analisi:
| Campo | Esempio |
|---|---|
| Pagina o componente | Modulo di registrazione |
| Criterio WCAG | 3.3.1 Identificazione degli errori |
| Descrizione | L'errore sul campo email è indicato solo con un bordo rosso |
| Impatto | Chi non distingue il rosso o usa un lettore di schermo non sa quale campo correggere |
| Gravità | Alta: impedisce di completare la registrazione |
| Correzione suggerita | Aggiungere un messaggio testuale collegato al campo e annunciato |
6. Assegnare le priorità
Non tutti i problemi pesano allo stesso modo. Un criterio pratico considera insieme la gravità per l'utente, quanto è usata la pagina e quanto costa correggere. I problemi che bloccano un compito essenziale vanno per primi. Spesso molti problemi nascono da pochi componenti condivisi, come il menu, i pulsanti o i campi dei moduli: correggere il componente una volta sistema decine di pagine.
Dopo l'audit
Un rapporto che resta in un cassetto non migliora nulla. Il passo successivo è un piano di correzione con responsabili e tempi, seguito da una nuova verifica dei problemi risolti. Conviene anche introdurre l'accessibilità nel lavoro quotidiano: controlli automatici durante lo sviluppo, criteri di accessibilità nelle definizioni delle attività, formazione di progettisti e redattori.
Nel mio lavoro consiglio sempre di affiancare all'audit tecnico almeno una sessione con utenti con disabilità: l'audit dice se il sito rispetta i criteri, gli utenti dicono se riescono davvero a usarlo.
In sintesi
- Un audit verifica in modo documentato un servizio rispetto a criteri precisi, di solito le WCAG di livello AA.
- La Legge Stanca e l'Atto europeo sull'accessibilità rendono l'accessibilità un obbligo per molte organizzazioni.
- Il campione deve includere modelli di pagina diversi e percorsi completi, non solo pagine isolate.
- Gli strumenti automatici sono utili ma parziali: le verifiche manuali sono indispensabili.
- Ogni problema va documentato con criterio, impatto, gravità e correzione, e seguito da un piano concreto.
