Audit di accessibilità: come verificare gratis se il tuo sito è a norma
Un audit di accessibilità è la verifica sistematica di un sito web rispetto agli standard WCAG 2.1/2.2 livello AA: i requisiti tecnici internazionali che definiscono cosa significa un sito accessibile a persone con disabilità visive, motorie, cognitive e uditive.
Questa guida spiega come funziona un audit, perché gli strumenti automatici da soli non bastano, quali sono le violazioni più comuni e come fare una prima verifica gratuita del tuo sito in meno di 60 secondi.
1. Che cos'è un audit di accessibilità
L'audit è il processo di valutazione della conformità di un sito rispetto ai criteri WCAG. Il risultato è un report strutturato che elenca le violazioni trovate, la loro gravità (critica, seria, moderata, minore), i criteri WCAG violati e — nei report di qualità — indicazioni su come correggerle.
L'audit serve a tre cose distinte:
- Conoscere lo stato reale del sito: quante barriere ci sono e quanto sono gravi.
- Prioritizzare le correzioni: non tutto può essere fatto insieme; serve sapere da dove cominciare.
- Fondare la dichiarazione di accessibilità: il documento pubblico che certifica il livello di conformità non può essere compilato correttamente senza un audit che ne supporti il contenuto.
2. I tre livelli dell'audit: automatico, Lighthouse e manuale
2.1 Verifica automatica (motori come axe-core)
I motori di verifica automatica — come axe-core, il motore open source alla base di molti tool commerciali e del browser DevTools — analizzano il DOM della pagina e verificano una serie di regole codificabili algoritmicamente: presenza di attributi alt, etichette <label> sui campi form, contrasto dei colori misurato numericamente, struttura del documento.
Il vantaggio è la velocità e la riproducibilità: lo stesso strumento sullo stesso URL produce risultati coerenti. Lo svantaggio è il limite intrinseco: gli strumenti automatici verificano in modo significativo solo circa un terzo dei criteri WCAG (indicativamente 15-16 dei 50 criteri di livello AA). Misurata sul volume degli errori la copertura può sembrare più alta — secondo uno studio di Deque, l'azienda che sviluppa axe-core, il motore automatico individua in media circa il 57% degli errori: una percentuale gonfiata dall'altissima frequenza di problemi auto-rilevabili come il contrasto. In entrambe le letture il messaggio non cambia: una quota rilevante dei criteri — e proprio quelli più legati all'esperienza reale d'uso — richiede giudizio umano e non è rilevabile da un algoritmo.
2.2 Performance e best practice (Lighthouse)
Google Lighthouse include un audit di accessibilità che si sovrappone parzialmente ad axe-core ma aggiunge controlli su prestazioni percepite, best practice HTML e attributi SEO che hanno impatto indiretto sull'accessibilità (ad esempio, la presenza di un attributo lang nel tag <html> che permette agli screen reader di selezionare la voce corretta).
Il punteggio Lighthouse sull'accessibilità è utile come indicatore di tendenza ma non equivale alla conformità WCAG: un sito con Lighthouse 90 può avere violazioni WCAG AA non rilevate.
2.3 Verifica manuale (i criteri che richiedono giudizio umano)
Alcuni criteri WCAG non possono essere valutati algoritmicamente. Richiedono che un revisore umano verifichi il sito con occhi e tastiera. I principali:
- Ordine di lettura e flusso logico: la sequenza in cui lo screen reader legge il contenuto ha senso? Un layout a colonne con
floatogridpuò sembrare corretto visivamente ma essere letto in ordine sbagliato. - Testi alternativi semanticamente significativi: un'immagine con
alt="foto"supera il test automatico (l'attributo esiste), ma fallisce quello manuale (non descrive nulla di utile). - Navigazione da tastiera completa: ogni funzione del sito — menu, form, dialog, carousel — deve essere utilizzabile senza mouse. Un test automatico non può sapere se una funzionalità è nascosta o bloccata in pratica.
- Focus visibile e ordine coerente: il focus da tastiera deve essere visibile e seguire un ordine logico; alcune implementazioni CSS nascondono l'outline senza che lo strumento automatico lo segnali.
- Contrasto in contesto: il contrasto può essere calcolato automaticamente solo se i colori sono definiti in modo statico; sfumature, immagini di sfondo e testo sovrapposto a foto richiedono valutazione manuale.
La conseguenza pratica è importante: un sito che supera tutti i test automatici non è necessariamente conforme. E, specularmente, un sito con qualche segnalazione automatica può essere più accessibile di uno con zero alert ma pieno di barriere non rilevabili algoritmicamente.
3. Perché un widget non può sostituire l'audit
I widget di accessibilità — script JavaScript che promettono di "correggere" il sito in automatico — si posizionano esattamente come alternativa all'audit e alla remediation. La promessa è attraente: installi un tag, il widget aggiusta tutto.
Il problema è strutturale: un widget può intervenire sul rendering lato client, ma non può correggere il codice sorgente. Le barriere che richiedono verifica manuale — ordine di lettura sbagliato, form senza label significativa, navigazione da tastiera bloccata — non sono correggibili da uno script che non conosce l'intento del contenuto.
Approfondisci le ragioni tecniche e legali in Perché non usare un widget di accessibilità.
4. Le violazioni più comuni nei siti italiani
Dai report generati su ConformeWeb, le categorie di violazione più frequenti sono:
- Contrasto insufficiente (WCAG 1.4.3): testo grigio su sfondo bianco, link colorati senza abbastanza contrasto. È la violazione più diffusa — spesso introdotta da designer che ottimizzano per l'estetica senza verificare il rapporto di contrasto (minimo 4.5:1 per testo normale, 3:1 per testo grande).
- Immagini senza testo alternativo (WCAG 1.1.1): immagini informative senza
alt, o conaltvuoto quando il testo alternativo sarebbe necessario. - Form senza label (WCAG 1.3.1, 4.1.2): campi input non associati a un'etichetta leggibile da screen reader. Placeholder non è un sostituto della label.
- Link non descrittivi (WCAG 2.4.4): testi come "clicca qui" o "leggi di più" che non comunicano la destinazione fuori contesto.
- Struttura heading disordinata (WCAG 1.3.1): salti di livello (da
<h1>a<h4>senza<h2>e<h3>), o più<h1>sulla stessa pagina. - Focus non visibile (WCAG 2.4.7):
outline: nonenel CSS rimuove l'indicatore di focus da tastiera, rendendo la navigazione senza mouse impossibile.
5. Come fare un audit gratuito con ConformeWeb in 3 passi
ConformeWeb offre un audit automatico WCAG 2.2 AA gratuito, senza registrazione. Ecco come funziona.
Passo 1 — Avvia la scansione
Vai su /audit-gratis, inserisci l'URL del tuo sito e avvia la scansione. In meno di 60 secondi il motore analizza la pagina rispetto ai criteri WCAG 2.2 AA e produce un report.
Passo 2 — Leggi il report per severità
Le violazioni sono classificate in quattro livelli di gravità:
- Critica: barriere che rendono una funzionalità completamente inaccessibile (es. form completamente unusabile da screen reader).
- Seria: barriere significative che rendono difficile l'uso per utenti con disabilità.
- Moderata: problemi che causano difficoltà ma hanno workaround.
- Minore: best practice non rispettate, impatto limitato.
Per ogni violazione il report indica il criterio WCAG violato, la posizione nel DOM e una descrizione del problema.
Passo 3 — Dalla verifica alla remediation e alla dichiarazione
Il report è il punto di partenza, non il punto di arrivo. I passi successivi sono: correggere le violazioni nel codice sorgente (partendo dalle critiche), riverificare, e — una volta raggiunto un livello di conformità documentabile — generare la dichiarazione di accessibilità.
Verifica il tuo sito adesso — gratis
Audit automatico WCAG 2.2 AA in meno di 60 secondi. Nessuna registrazione, nessun dato di carta di credito. Ottieni il report completo con tutte le violazioni suddivise per severità.
Avvia audit gratuito — nessuna registrazione richiesta6. Cosa fare dopo l'audit
L'audit da solo non cambia nulla. Il valore è nell'azione che ne consegue.
Prioritizzare per gravità
Inizia dalle violazioni critiche e serie: sono quelle che rendono il sito inutilizzabile per qualcuno. Le violazioni moderate e minori possono essere pianificate in sprint successivi. Un sito senza violazioni critiche e serie è già in una posizione molto migliore della media.
Correggere il codice, non nascondere le barriere
La remediation corretta significa modificare il codice sorgente: aggiungere alt significativi, associare label ai form, correggere i colori, riorganizzare la struttura heading. Non significa installare un overlay che nasconde il problema senza risolverlo.
Riverificare e documentare
Dopo ogni ciclo di correzioni, riverifica con un nuovo audit. Quando il livello di conformità è documentabile, genera la dichiarazione di accessibilità che certifica lo stato reale del sito — ed è richiesta dall'European Accessibility Act per gli operatori non microimpresa.
Monitoraggio continuo
L'accessibilità non è uno stato permanente: ogni aggiornamento del sito può introdurre nuove barriere. Un audit automatico periodico — almeno mensile per siti che cambiano spesso — è il modo più pratico per tenere traccia dello stato reale senza attendere una segnalazione o una contestazione.
7. Domande frequenti sull'audit di accessibilità
L'audit gratuito è davvero gratis?
Sì. L'audit automatico WCAG 2.2 AA su /audit-gratis è gratuito, senza registrazione e senza carta di credito. Il report completo con tutte le violazioni per severità è disponibile immediatamente. Le funzionalità avanzate (monitoraggio continuo, scan multipli, dichiarazione di accessibilità) sono nei piani a pagamento.
Gli strumenti automatici bastano?
No. Gli strumenti automatici sono il punto di partenza indispensabile — veloci, riproducibili, economici — ma rilevano solo una parte dei criteri WCAG. I criteri che richiedono giudizio sul contesto (testi alternativi significativi, ordine di lettura, navigazione da tastiera) richiedono verifica umana. Per una conformità certificabile, l'audit automatico va integrato con una revisione manuale.
Quanto spesso rifare l'audit?
Dipende dalla frequenza di aggiornamento del sito. Per siti che cambiano spesso (blog, ecommerce), un audit mensile è il minimo ragionevole. Per siti più statici, uno trimestrale può bastare. In ogni caso, ogni modifica significativa dovrebbe innescare un nuovo scan. La dichiarazione di accessibilità va aggiornata almeno ogni anno.
Questa guida ha finalità informative. I riferimenti agli standard WCAG sono basati sulla specifica W3C WCAG 2.1 e 2.2 (livello AA). Le percentuali di rilevamento degli strumenti automatici sono stime di settore; per dati precisi si rimanda agli studi di ricerca disponibili pubblicamente (es. WebAIM, Deque Systems). Non sostituisce una consulenza tecnica o legale per la tua situazione specifica.
« Dichiarazione di accessibilità — guida completa · European Accessibility Act — panoramica »