Come testare l'accessibilità del tuo sito, passo dopo passo

Gli scanner automatici da soli non bastano: con questo piano di test in 7 passi controlli il tuo sito in modo sistematico, dalla tastiera allo screen reader.

Aggiornato il 20 luglio 2026 · Redazione Wave Tools · 9 min di lettura

Perché un piano di test è meglio di un singolo strumento

Molti responsabili di siti lanciano una scansione automatica, vedono qualche messaggio di errore e considerano il tema chiuso. È troppo poco: l'accessibilità si può verificare automaticamente solo in parte. Se una pagina si può davvero usare con la tastiera, se uno screen reader legge i contenuti in modo sensato o se i messaggi di errore dei moduli si capiscono, devi verificarlo tu stesso.

Per questo il piano che segue combina strumenti automatici e controlli manuali. Non ti serve attrezzatura speciale: un browser aggiornato, una tastiera e lo screen reader già installato nel tuo sistema operativo bastano per iniziare. Come riferimento valgono le WCAG 2.2, lo standard internazionale per i contenuti web accessibili.

Passo 1: gli scanner automatici come punto di partenza

Gli strumenti automatici trovano gli errori tecnici tipici in modo rapido e affidabile: attributi alt mancanti, contrasti insufficienti, campi modulo senza etichetta, attributi ARIA sbagliati. Tre strumenti gratuiti e collaudati:

  • Lighthouse: integrato in Chrome ed Edge. Apri gli strumenti per sviluppatori (F12), vai alla scheda «Lighthouse», seleziona la categoria «Accessibility» e genera il report.
  • axe DevTools: estensione per browser di Deque. Dopo l'installazione trovi negli strumenti per sviluppatori una scheda dedicata che segnala i risultati direttamente nel codice.
  • WAVE: uno strumento di verifica dell'organizzazione statunitense WebAIM (nessun legame con Wave Tools: la somiglianza del nome è casuale). Sovrappone simboli direttamente alla tua pagina e rende i problemi molto visibili.

Non controllare solo la home, ma ogni tipo di pagina: home, pagina di contenuto, pagina con modulo, pagina prodotto o articolo, risultati di ricerca.

Importante: secondo gli studi più diffusi, gli scanner automatici rilevano solo una parte di tutte le barriere: spesso si parla del 30–40 per cento. Una scansione senza errori non significa quindi che il tuo sito sia accessibile. Significa solo che i punti verificabili dalla macchina sono a posto. I passi successivi non sono un extra, ma obbligatori.

Passo 2: il test da tastiera

Metti da parte il mouse e usa il tuo sito solo con la tastiera. Con il tasto Tab avanzi tra tutti gli elementi interattivi, con Maiusc+Tab torni indietro, e con Invio o la barra spaziatrice li attivi. Fai attenzione a tre cose:

  1. Ordine: il focus dovrebbe muoversi in un ordine logico, di regola dall'alto a sinistra verso il basso a destra, seguendo la struttura visibile. Se salta qua e là senza senso, qualcosa non va nella struttura del documento.
  2. Visibilità: devi poter riconoscere in ogni momento quale elemento ha il focus. Se manca la cornice di focus (spesso eliminata dal CSS con outline), chi naviga con la tastiera è perso.
  3. Nessuna trappola: devi poter uscire da ogni elemento. Le trappole classiche sono i widget incorporati, i banner dei cookie e le finestre di dialogo modali che non si chiudono con Esc.

Prova anche i menu, le fisarmoniche, gli slider e i selettori di data: proprio lì falliscono molti siti.

Passo 3: test di base con lo screen reader

Uno screen reader legge la pagina ad alta voce così come la percepiscono le persone cieche o con grave ipovisione. Per un test di base non devi comprare nulla:

  • Windows: NVDA è gratuito e molto diffuso. Dopo l'avvio legge automaticamente ad alta voce; con il tasto H salti da un'intestazione all'altra, con Tab percorri gli elementi interattivi.
  • macOS e iOS: VoiceOver è integrato. Sul Mac lo avvii con Cmd+F5; su iPhone dalle impostazioni di accessibilità.

Mentre ascolti, fatti tre domande: la pagina ha senso anche senza schermo? Le immagini vengono annunciate con testi alternativi utili o solo con nomi di file? Nei pulsanti e nei link sai cosa succederà attivandoli, o senti solo «link» e «clicca qui»? Già dieci minuti con uno screen reader ti insegnano sul tuo sito più di qualsiasi report.

Passo 4: zoom al 200 per cento e reflow

Molte persone ipovedenti ingrandiscono i contenuti nel browser. Le WCAG richiedono che il testo resti utilizzabile con uno zoom del 200 per cento, senza perdita di contenuti o di funzioni. Ecco come lo verifichi:

  1. Ingrandisci la pagina con Ctrl e più (Mac: Cmd e più) gradualmente fino al 200 per cento.
  2. Controlla se i testi vengono tagliati, si sovrappongono o se i controlli escono dall'area visibile.
  3. Riduci inoltre la finestra del browser a circa 320 pixel di larghezza oppure fai zoom al 400 per cento: ora il contenuto dovrebbe riorganizzarsi su una sola colonna (reflow), senza che tu debba scorrere in orizzontale.

Se il tuo sito è costruito in modo responsive e pulito, di solito supera questo test senza ritocchi; altrimenti vedrai subito dove si inceppa.

Passo 5: verificare i contrasti

I contrasti troppo deboli sono tra le barriere più frequenti in assoluto. Le WCAG richiedono per il testo normale un rapporto di contrasto di almeno 4,5:1 con lo sfondo, e per il testo grande (da circa 24 pixel, o 19 in grassetto) almeno 3:1. Anche i controlli e i simboli grafici hanno bisogno di almeno 3:1.

Per misurare servono il Contrast Checker di WebAIM, il contagocce degli strumenti per sviluppatori del browser o programmi desktop come il Colour Contrast Analyser. Controlla di proposito i candidati critici: testo grigio chiaro su bianco, testi segnaposto nei campi dei moduli, testo sopra le foto e pulsanti nei colori del brand. Non fidarti dell'impressione sul tuo monitor ben calibrato: misura.

Passo 6: moduli e messaggi di errore

I moduli sono il punto in cui le barriere costano di più: lì si perdono ordini e richieste. Compila ogni modulo importante una volta per intero, una volta con errori voluti e una volta solo con la tastiera. Fai attenzione a questo:

  • Ogni campo ha un'etichetta visibile e collegata a livello di codice: un testo segnaposto dentro il campo non sostituisce l'etichetta, perché sparisce quando scrivi.
  • I campi obbligatori sono segnalati come tali, e non solo con il colore.
  • I messaggi di errore compaiono come testo accanto al campo interessato e spiegano concretamente cosa è sbagliato e come correggerlo: un semplice «Inserimento non valido» non aiuta nessuno.
  • Dopo un invio con errori, quanto già inserito viene conservato.
  • I limiti di tempo, per esempio nei processi di prenotazione, si possono estendere o disattivare.

Passo 7: controllare i contenuti: testi alternativi, intestazioni, testi dei link

Per finire tocca al piano redazionale, che nessuno strumento può valutare:

  • Testi alternativi: il testo alternativo descrive cosa si vede nell'immagine e quale funzione ha? Le immagini puramente decorative hanno un attributo alt vuoto? Come si scrivono buoni testi alternativi te lo mostra il nostro articolo Come scrivere buoni testi alternativi.
  • Gerarchia delle intestazioni: esattamente un H1 per pagina e, a seguire, una struttura senza salti (H2 e, sotto, H3). Le intestazioni sono struttura, non un espediente grafico: chi sceglie un H4 perché sta bene in piccolo sabota la navigazione con lo screen reader.
  • Testi dei link: ogni link dovrebbe capirsi da solo. «Maggiori informazioni» e «qui» non lo fanno; «Scarica il listino prezzi in PDF», sì.

Dare priorità, documentare e non mollare

Dopo i sette passi hai una lista di risultati. Ordinala per impatto: prima vengono i blocchi che impediscono del tutto l'uso (trappole da tastiera, moduli senza etichette, navigazione inutilizzabile), poi i grandi ostacoli, come testi alternativi mancanti nelle pagine centrali e contrasti deboli, e alla fine i dettagli di rifinitura.

Documenta ogni risultato con la pagina, la descrizione, il criterio WCAG interessato e la soluzione prevista. Questa documentazione rende doppiamente: è la base di lavoro per il tuo team e fornisce i dati per la tua dichiarazione di accessibilità, in cui devi comunque menzionare le limitazioni note e le misure previste.

Consiglio: l'accessibilità non è un progetto una tantum. Ogni aggiornamento, ogni nuovo plugin e ogni nuovo contenuto può introdurre nuove barriere. Pianifica un breve test a ogni rilascio importante e una revisione completa almeno una volta all'anno: così lo sforzo resta piccolo e lo stato, aggiornato.

Wave Access verifica il tuo sito WordPress direttamente nel pannello di amministrazione, ti guida attraverso i controlli manuali e genera un report di revisione in PDF: la base ideale per la tua documentazione e la tua dichiarazione di accessibilità.

Scopri Wave Access →