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.
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:
- 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.
- 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.
- 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:
- Ingrandisci la pagina con Ctrl e più (Mac: Cmd e più) gradualmente fino al 200 per cento.
- Controlla se i testi vengono tagliati, si sovrappongono o se i controlli escono dall'area visibile.
- 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 →