Come verificare l'accessibilità di un sito web: strumenti, test e checklist WCAG

Aggiornato il: 21/07/2026

Come si testa l'accessibilità di un sito web?

Il test di accessibilità combina tre livelli: scansione automatica (WAVE, Axe DevTools, Lighthouse), controlli manuali da tastiera e screen reader, e test con persone con disabilità che usano tecnologie assistive ogni giorno. Ognuno individua barriere che gli altri non rilevano, gli strumenti automatici coprono circa il 30-40% degli errori reali, il resto richiede giudizio umano.

In questo articolo

• Perché i test automatici da soli non bastano per verificare l'accessibilità digitale?

• Quali strumenti usare per la scansione automatica dell'accessibilità?

• Quali controlli manuali bisogna fare su ogni sito?

• Quali criteri WCAG 2.1 AA vengono violati più spesso?

• Come si leggono i risultati e si stabiliscono le priorità di correzione?

• Checklist: cosa verificare su ogni sito prima di dichiarare conformità?

• Domande frequenti

Perché i test automatici da soli non bastano per verificare l'accessibilità digitale?

Gli strumenti automatici trovano in media tra il 30 e il 57% degli errori di accessibilità reali, a seconda della frequenza con cui certi tipi di problemi compaiono nel sito. Il resto richiede giudizio umano.

Uno scanner rileva un'immagine senza alt text ma non rileva un focus che scompare in modo confuso durante la navigazione, per esempio.

Per questo motivo una verifica completa combina sempre tre livelli:

• Scansione automatica: veloce, scalabile, copre gli errori di codice

• Test manuale: tastiera, screen reader, ispezione visiva dei componenti

• Test con persone con disabilità: il livello più utile, perché chi usa tecnologie assistive ogni giorno trova quello che gli altri non cercano

Quali strumenti usare per la scansione automatica dell'accessibilità?

Nessuno strumento trova tutto. Usarne almeno due insieme dà una copertura più ampia e riduce i falsi negativi.

WAVE (wave.webaim.org) Sovrappone gli errori direttamente sulla pagina, con icone colorate che indicano il tipo di problema. È il formato più leggibile per chi non è sviluppatore: si vede subito dove si trova il problema nel contesto della pagina, non solo in un report separato.

Axe DevTools Disponibile come estensione per Chrome e Firefox. Per ogni errore trovato, fornisce la spiegazione del criterio WCAG violato e un link alla documentazione tecnica. Utile per chi deve tradurre i risultati in ticket di correzione.

Lighthouse Integrato in Chrome DevTools, nella scheda "Accessibility". Comodo se lo usi già per audit di performance e SEO: la scheda accessibilità fa parte dello stesso report. Non è lo strumento più completo, ma consente di avere un quadro rapido senza installare nulla.

Cosa fanno e cosa non fanno

Tutti e tre analizzano il codice HTML della pagina e segnalano errori misurabili: rapporti di contrasto, attributi ARIA mancanti, immagini senza alt text, form senza etichette. Non testano il comportamento interattivo, il flusso di focus con la tastiera, né l'esperienza reale con uno screen reader.

Eseguili su più pagine del sito, non solo sulla home page. Le pagine di prodotto, i form di contatto, le pagine di checkout e le aree riservate hanno spesso profili di errori diversi rispetto alla home.

Quali controlli manuali bisogna fare su ogni sito?

I test manuali trovano quello che nessuno scanner rileva. Tre aree vanno sempre verificate a mano: navigazione da tastiera, screen reader, e struttura dei contenuti.

Navigazione da tastiera e focus visibile

Apri il sito e premi Tab.

Ecco quello che dovresti poter fare, senza mai toccare il mouse:

• Raggiungere ogni elemento interattivo: link, pulsanti, campi form, accordion, menu

• Vedere chiaramente quale elemento è attivo: l'indicatore di focus deve essere visibile, non scomparire

• Aprire e chiudere i modal, entrandoci quando si aprono e uscendone con Esc o con un pulsante di chiusura

• Navigare i menu a tendina con i tasti freccia

• Attivare pulsanti con Invio o Spazio

L'errore più comune è outline: none nel CSS, aggiunto per motivi estetici senza sostituire l'anello di focus con nulla di visibile. È uno dei problemi più impattanti per chi naviga da tastiera e uno dei più semplici da correggere.

Test con uno screen reader

Attiva un lettore di schermo e naviga il sito ascoltando quello che viene letto.

• NVDA su Windows con Firefox è la combinazione più usata in Italia. NVDA è gratuito e scaricabile da nvaccess.org.

• VoiceOver su Mac con Safari è integrato nel sistema operativo (si attiva con Cmd + F5).

• TalkBack su Android con Chrome per testare il comportamento su mobile.

Cosa cercare durante il test:

• Le immagini informative vengono lette con una descrizione utile, o solo con il nome del file?

• I link vengono letti con un testo che descrive la destinazione, o con "clicca qui" e "scopri di più"?

• I campi form vengono annunciati con la loro etichetta, o senza contesto?

• I messaggi di errore nei form vengono letti, o sono solo visivi?

• I titoli della pagina (H1, H2, H3) creano una struttura logica quando navigati in sequenza?

Testare con uno strumento solo non basta: NVDA, VoiceOver e TalkBack si comportano in modo diverso con lo stesso codice.

Struttura e contenuti

Questi controlli si fanno con ispezione visiva e con gli strumenti di sviluppo del browser:

• Gerarchia dei titoli:La pagina ha un solo H1? I titoli seguono una gerarchia logica (H1 > H2 > H3) senza salti? Un H3 che appare prima di qualsiasi H2 rompe la struttura.

• Alt text delle immagini: Le immagini informative hanno un attributo alt che descrive il contenuto e il motivo per cui è lì. Le immagini decorative hanno alt="". Controllare anche i nomi dei file: wcag-audit-checklist.webp è indicizzabile, IMG_4523.webp non dice nulla.

• Etichette dei form: Ogni campo ha un <label> associato via for e id, o un aria-label. Il placeholder non è un'etichetta: scompare non appena si inizia a scrivere.

• Testo dei link: "Scarica la checklist WCAG in PDF" funziona. "Clicca qui" no: i link vengono letti in lista dagli screen reader, fuori dal contesto della frase.

• Contrasto dei colori: Il Colour Contrast Analyser di TPGi funziona offline e campiona qualsiasi colore direttamente dallo schermo. Il rapporto minimo per il testo normale è 4,5:1. Per il testo grande (sopra i 18pt, o 14pt grassetto) scende a 3:1.

Quali criteri WCAG 2.1 AA vengono violati più spesso?

Alcuni criteri ricorrono più spesso di altri nei siti che analizziamo, e in gran parte coincidono con i controlli manuali appena visti.

Questi otto criteri appartengono alle Web Content Accessibility Guidelines (WCAG) 2.1 AA, lo standard tecnico che le Linee Guida AgID rendono obbligatorio per la Pubblica Amministrazione italiana, esteso al settore privato dal 28 giugno 2025 con l'Atto Europeo sull'Accessibilità (EAA).

• 1.1.1: l'alt text deve spiegare cosa mostra l'immagine, non limitarsi al nome del file, è il controllo sulle immagini informative visto sopra

• 1.4.3: il testo deve mantenere un contrasto di almeno 4,5:1 rispetto allo sfondo (3:1 per i caratteri più grandi), è il test di contrasto visto sopra

• 1.4.4: il contenuto non deve tagliarsi o sovrapporsi quando la pagina viene ingrandita al 200%

• 2.1.1: il sito deve restare completamente utilizzabile senza mai toccare il mouse, è il test da tastiera visto sopra

• 2.4.4: isolato dal resto della frase, il testo di un link deve comunque far capire dove porta, è il controllo sui link visto sopra

• 2.4.7: durante la navigazione da tastiera, l'elemento attivo deve essere sempre visibile a schermo, stesso test da tastiera

• 3.3.2: ogni campo di un form ha bisogno di un'etichetta collegata al codice, non solo visiva, è il controllo sui form visto sopra

• 4.1.2: un componente interattivo deve dichiarare a uno screen reader cosa è e cosa fa, è il test con screen reader visto sopra

Per le correzioni specifiche di ciascun criterio, leggi come rendere accessibile il tuo sito.

Come si leggono i risultati e si stabiliscono le priorità di correzione?

Dopo scansioni automatiche e test manuali ci si ritrova con una lista di problemi. Non tutti hanno lo stesso peso: tre criteri aiutano a decidere da dove iniziare.

Tre criteri per dare priorità:

1. Impatto sull'utente: un modal che intrappola la navigazione da tastiera blocca completamente chi non usa il mouse. Un nome del file immagine non ottimale è un problema minore.

2. Frequenza: un errore nel componente header appare su ogni pagina del sito. Correggerlo una volta risolve il problema ovunque.

3. Sforzo di correzione: alcuni interventi richiedono cinque minuti (aggiungere un alt text), altri richiedono una ristrutturazione del codice. Inizia dagli errori ad alto impatto e basso sforzo.

Gli errori su componenti riutilizzabili (header, footer, form globali, navigazione principale) vanno in cima alla lista. Corretti una volta, migliorano l'esperienza su tutto il sito.

Per i team che vogliono strutturare questo processo in modo continuativo, la piattaforma per l'accessibilità digitale di Accessiway combina scansione automatica e revisione umana, con un sistema di priorità e monitoraggio integrato.

Checklist: cosa verificare su ogni sito prima di dichiarare conformità?

Usa questa lista come punto di partenza per ogni audit. Copre gli errori più frequenti, ma non sostituisce una verifica completa con screen reader reali e test con persone con disabilità.

Scansione automatica

☐Eseguita con almeno due strumenti (WAVE + Axe DevTools consigliati)

☐Testato su più pagine: home, pagina prodotto/servizio, form di contatto, checkout se presente

☐Nessun errore critico nei risultati (non solo avvisi)

Tastiera

☐Tutti gli elementi interattivi raggiungibili con Tab

☐Indicatore di focus visibile su ogni elemento attivo

☐Modal e dialog apribili e chiudibili da tastiera

☐Menu a tendina navigabili con i tasti freccia

☐Nessun focus trap involontario

Screen reader

☐Le immagini informative vengono lette con una descrizione utile

☐I link hanno testo descrittivo della destinazione

☐I campi form vengono annunciati con la loro etichetta

☐I messaggi di errore vengono letti, non solo visualizzati

☐La struttura dei titoli è logica e navigabile

Contenuti

☐Un solo H1 per pagina, gerarchia titoli senza salti

☐Contrasto testo/sfondo verificato con uno strumento di campionamento

☐Alt text presente su tutte le immagini informative, alt="" su quelle decorative

☐Tutti i campi form hanno etichette programmatiche (non solo placeholder)

☐Testo dei link descrittivo della destinazione, non "clicca qui"

Multimedia

☐Video con audio: sottotitoli sincronizzati presenti

☐Contenuti in movimento: possibilità di pausa disponibile

Domande frequenti

Quando un sito web può essere considerato accessibile?

Un sito web è accessibile quando tutte le persone, comprese quelle con disabilità visive, motorie, uditive o cognitive, possono usarlo senza barriere. Il riferimento tecnico sono le WCAG 2.1 livello AA: soddisfare tutti i criteri di quel livello è la definizione operativa di conformità. In pratica, la conformità si misura con la combinazione di test automatici, manuali e con screen reader reali.

Quali strumenti usare per testare l'accessibilità del sito?

Per la scansione automatica: WAVE, Axe DevTools e Lighthouse sono i più usati. Per il test con screen reader: NVDA su Windows con Firefox, VoiceOver su Mac con Safari. Per il contrasto: Colour Contrast Analyser di TPGi. Per la tastiera: non serve nessuno strumento, bastano Tab, Shift+Tab, Enter, Spazio e i tasti freccia.

Come testare l'accessibilità con la tastiera?

Apri il sito, metti via il mouse, e premi Tab ripetutamente. Verifica che ogni elemento interattivo sia raggiungibile, che l'indicatore di focus sia sempre visibile, e che i modal possano essere aperti e chiusi senza mouse. Annota ogni punto dove il focus scompare o dove non riesci ad attivare un elemento.

Quanto spesso bisogna ripetere il test di accessibilità?

Ogni volta che vengono rilasciati aggiornamenti significativi al sito: nuovi componenti, nuove pagine, modifiche al CMS o al sistema di design. Le correzioni di accessibilità si rompono facilmente con i deploy successivi. Chi integra i test di accessibilità nella pipeline CI/CD evita di dover eseguire audit correttivi dopo ogni rilascio.

I test automatici bastano per dichiarare conformità alle WCAG?

No. I test automatici coprono circa il 30-40% dei criteri WCAG verificabili. La Dichiarazione di Accessibilità richiede una verifica che includa test manuali e, dove possibile, test con persone con disabilità. Una dichiarazione basata solo su scansioni automatiche non è considerata credibile in sede di controllo.

Se stai organizzando una verifica completa del tuo sito, il audit accessibilità digitale di Accessiway combina scansione automatica e revisione umana per coprire entrambi i livelli. Puoi partire da un audit gratuito per avere un quadro iniziale.