Testare l'accessibilità di un sito: strumenti gratuiti e verifiche

Ecco una storia che sentiamo spesso. Qualcuno lancia Lighthouse, ottiene un bel 100 verde per l'accessibilità e passa oltre. Una settimana dopo una cliente scrive che non è riuscita a pagare, perché il modulo della carta non si raggiunge con la tastiera. Sono vere entrambe le cose. Il controllo automatico era superato, e il sito ha comunque lasciato a piedi una persona reale.

Questa guida mostra come testare bene con un budget ridotto: quali strumenti gratuiti usare, una routine manuale di 15 minuti, un primo approccio a uno screen reader e quando pagare un audit.

Uno strumento automatico può dire se un sito è accessibile?

No. Gli strumenti automatici trovano in fretta alcuni problemi, ma molte questioni di accessibilità richiedono la valutazione di una persona. Quando il Government Digital Service britannico ha testato 10 strumenti su una pagina con 143 errori noti, il migliore ne ha trovato il 41%. Il W3C lo dice chiaramente: gli strumenti di valutazione “non possono determinare l'accessibilità, possono solo aiutare a farlo”.

Il test del GDS (si apre in una nuova scheda) risale al febbraio 2017, e il suo 41% (ottenuto da Asqatasun) comprendeva gli inviti dello strumento a fare verifiche manuali. Da allora gli strumenti sono migliorati, ma il divario ha la stessa causa. Un software può capire che un'immagine non ha testo alternativo. Non può capire che “vestito rosso” è la descrizione sbagliata per la foto di un completo blu, né se l'ordine del focus ha senso.

Uno strumento di verifica va quindi considerato un rilevatore di fumo, non una perizia sull'edificio. Vale comunque la pena usarlo: il WebAIM Million 2026 (si apre in una nuova scheda) ha trovato errori rilevabili sul 95,9% delle home page del primo milione di siti, quindi la maggior parte dei siti ha miglioramenti rapidi a portata di mano. Come dice la guida del W3C alla scelta degli strumenti (si apre in una nuova scheda): “Serve il giudizio umano.”

Quali strumenti gratuiti usare per testare l'accessibilità?

Bastano uno o due strumenti automatici, uno strumento per il contrasto e uno screen reader. Gli strumenti applicano regole diverse e presentano i risultati in modo diverso, quindi due di solito trovano più di uno. Ogni strumento qui sotto ha una versione gratuita. Prima di affidarsi a uno di essi conviene controllarne le condizioni attuali, perché nomi, funzioni e prezzi cambiano.

Cosa si può verificare a mano in 15 minuti?

Parecchio. Le Easy Checks (si apre in una nuova scheda) del W3C riguardano titoli delle pagine, testo alternativo, intestazioni, contrasto, link per saltare al contenuto, focus da tastiera visibile, lingua della pagina, zoom, sottotitoli ed etichette dei moduli. Basta scegliere una pagina importante, come una scheda prodotto o il modulo di prenotazione, e dedicare uno o due minuti a ogni verifica. Si troveranno cose che nessuno strumento segnala.

Il W3C precisa che queste verifiche “coprono solo alcuni problemi di accessibilità”, quindi non sono una valutazione completa. Restano comunque il miglior quarto d'ora che si possa dedicare al sito:

1. Titolo della pagina (1 minuto). La scheda del browser dice che pagina è, per esempio “Prenota un tavolo | Trattoria da Rosa”, invece di “Home” ovunque?
2. Immagini (2 minuti). Mostrare i testi alternativi con WAVE o uno strumento simile. Sono accurati? Le immagini decorative vengono saltate?
3. Intestazioni (2 minuti). Elencare le intestazioni e leggerle da sole. Funzionano come un indice?
4. Contrasto (2 minuti). Controllare testo del corpo, testo grigio piccolo, testo dei pulsanti e testo sulle immagini.
5. Tastiera (4 minuti). Mettere da parte il mouse e scorrere la pagina con Tab (vedi la sezione successiva).
6. Zoom (2 minuti). Al 200% e poi al 400%, si riesce ancora a leggere tutto e a usare il menu senza scorrere in orizzontale?
7. Moduli e lingua (2 minuti). Fare clic sull'etichetta di ogni campo: in un modulo ben fatto il cursore si posiziona nel campo. Controllare nel report dello strumento se manca la lingua della pagina.

Come si testa con la tastiera?

Si mette via il mouse. Tab per andare avanti, Maiusc+Tab per tornare indietro, Invio per seguire i link, barra spaziatrice o Invio per premere i pulsanti, e le frecce dentro menu e pulsanti di opzione. Ogni elemento interattivo deve essere raggiungibile, si deve sempre vedere dove ci si trova e non si deve mai restare bloccati.

Su Mac, Safari salta i link quando si preme Tab finché non si attiva, nelle impostazioni avanzate, l'opzione che fa evidenziare con Tab ogni elemento di una pagina web. Poi si verifica:

• Si vede sempre dove ci si trova? Se il contorno del focus sparisce, chi usa la tastiera si perde.
• L'ordine è logico? Il focus deve seguire l'ordine di lettura.
• Qualcosa viene coperto? Un header fisso o un banner dei cookie che nasconde l'elemento con il focus non rispetta il criterio Focus non nascosto delle WCAG 2.2.
• Si riesce a uscire? Aprire ogni menu, pop-up e selettore della data, poi provare a uscire. Il tasto Esc deve chiudere le finestre di dialogo.
• Funziona tutto il percorso? Aggiungere un prodotto, cambiare la quantità, applicare un codice sconto e arrivare al pagamento senza mouse.

Ogni errore va annotato con precisione: “Il selettore della taglia nella scheda prodotto non si apre né con Invio né con la barra spaziatrice” viene corretto molto più in fretta di “la tastiera non funziona”.

Come si testa con uno screen reader la prima volta?

Si comincia con lo screen reader già presente sul dispositivo, o con NVDA su Windows, e si ascolta una pagina. Non si tratta di usarlo come un esperto. Si verifica che titoli, link, pulsanti, immagini e campi dei moduli vengano annunciati con nomi sensati, e che nulla di importante resti muto.

• Mac: Comando+F5 attiva e disattiva VoiceOver; Ctrl+Opzione+U apre il rotore, un elenco di intestazioni, link e controlli dei moduli.
• Windows: in NVDA, H salta da un'intestazione all'altra e Insert+F7 elenca link e intestazioni.
• Smartphone: attivare VoiceOver (iPhone) o TalkBack (Android) e scorrere verso destra per passare da un elemento all'altro. Prima, imparare come si disattiva.

Conviene ascoltare ciò che conta di più. Nel sondaggio 2024 di WebAIM tra gli utenti di screen reader (si apre in una nuova scheda), il 71,6% degli intervistati ha detto di esplorare una pagina lunga prima di tutto attraverso le intestazioni, quindi si parte da lì. Poi si apre l'elenco dei link: cinque link “Leggi di più” non dicono niente a nessuno. “Aggiungi al carrello, maglione blu navy” è un pulsante utile; “pulsante” no. Infine si compila un modulo e si verifica che ogni campo e ogni errore vengano letti.

Le conclusioni vanno tenute modeste. Se sembra non funzionare, probabilmente non funziona; se sembra a posto, non è una prova. Per capire come lavorano gli utenti esperti c'è la guida su come usano il web le persone con disabilità.

Come si verificano zoom, ricalcolo del flusso e spaziatura del testo?

Si porta lo zoom del browser al 200% e si verifica che il testo si ingrandisca senza essere tagliato o sovrapporsi. Poi si testa il ricalcolo del flusso: con lo zoom al 400% in una finestra larga 1.280 pixel, il contenuto deve stare nella pagina senza scorrimento orizzontale. Infine si aumenta la spaziatura tra lettere, parole, righe e paragrafi, e si controlla che nulla si rompa o sparisca.

Queste verifiche corrispondono ai criteri WCAG Ridimensionamento del testo (1.4.4), Ricalcolo del flusso (1.4.10) (si apre in una nuova scheda) e Spaziatura del testo (1.4.12) (si apre in una nuova scheda). Il ricalcolo del flusso usa una larghezza di 320 pixel CSS, che secondo le WCAG “equivalgono a una finestra iniziale di larghezza 1280 CSS pixel al 400% di ingrandimento”. La spaziatura del testo chiede che non si perda nulla quando un lettore imposta l'interlinea a 1,5 volte la dimensione del carattere, la spaziatura tra paragrafi a 2 volte, quella tra lettere a 0,12 volte e quella tra parole a 0,16 volte.

Un bookmarklet per la spaziatura del testo, un piccolo script salvato come segnalibro, applica tutti e quattro i valori con un clic. Va cercato il testo che esce dai pulsanti e le etichette tagliate ai bordi. Al 400% di zoom un portatile mostra all'incirca ciò che mostra uno smartphone piccolo, quindi un sito responsive ben fatto supera già buona parte di queste verifiche.

Come si verificano moduli, errori e checkout?

Ogni modulo importante va compilato tre volte: una volta correttamente, una volta lasciando vuoti tutti i campi e una volta con errori voluti. Ogni campo deve avere un'etichetta visibile, ogni errore deve essere spiegato a parole accanto al suo campo, e si deve poter incollare nei campi di password e codici di verifica.

• Errori. “Input non valido” in rosso non basta. “Inserire la data di scadenza nel formato MM/AA”, accanto al campo, sì. Dopo l'invio, il focus deve spostarsi sul riepilogo degli errori o sul primo campo con un problema.
• Login e codici. In base al criterio di autenticazione accessibile (si apre in una nuova scheda) delle WCAG 2.2, impedire di incollare o bloccare i password manager non è conforme, a meno che non ci sia un altro modo per accedere.
• CAPTCHA e limiti di tempo. Nel sondaggio di WebAIM, gli utenti di screen reader hanno indicato il CAPTCHA come l'elemento più problematico del web. Va verificato che esista un'alternativa accessibile e che i limiti di tempo si possano prolungare.

La nostra checklist di accessibilità per siti web contiene un elenco più completo per i negozi online, compresi banner dei cookie e pop-up.

Cosa comprende un audit di accessibilità professionale, e quando serve?

Un audit di accessibilità è una revisione strutturata, fatta da uno specialista, rispetto a uno standard preciso, di solito le WCAG 2.1 o 2.2 livello AA. Combina scansioni automatiche con test manuali e con tecnologie assistive sui template e i percorsi principali, e si conclude con un report ordinato per priorità. Serve quando la legge si applica, prima di un lancio importante o quando i clienti chiedono prove.

Prima di accettare un preventivo, conviene chiedere:

• Rispetto a quale standard, versione e livello verrà fatto il test (le WCAG, o per la pubblica amministrazione le linee guida AgID)?
• Quali template e percorsi sono inclusi? Per un negozio: home, categoria, scheda prodotto, carrello, checkout, pagine dell'account e moduli.
• Si testa a mano con screen reader, tastiera e zoom, e su quali browser e dispositivi?
• Il report ordina i problemi per gravità, li localizza e suggerisce correzioni?
• È compreso un nuovo test dopo le correzioni?

I prezzi variano molto a seconda del fornitore, del Paese e dell'ambito, quindi conviene confrontare cosa è incluso. Se si rientra nell'European Accessibility Act, un audit dà anche fondamento alla dichiarazione pubblica; la nostra guida all'EAA spiega chi rientra nell'ambito.

Perché testare con utenti con disabilità?

Perché rispettare uno standard ed essere facili da usare non sono la stessa cosa. Un checkout può soddisfare tutti i criteri WCAG e richiedere comunque venti minuti a chi usa uno screen reader. Il W3C dice che valutare con utenti con disabilità “individua problemi di usabilità che la sola valutazione della conformità non scopre”, e mostra al team come le persone usano davvero il sito.

Non serve un laboratorio. Qualche sessione sull'attività più importante, come trovare un prodotto e pagare, insegna più di un altro giro di scansioni. Si possono reclutare partecipanti tramite associazioni di persone con disabilità, agenzie di ricerca o tra i propri clienti, e il loro tempo va pagato. Conviene lasciare che usino i propri dispositivi e le proprie impostazioni. La guida del W3C su come coinvolgere gli utenti nella valutazione (si apre in una nuova scheda) tratta gli aspetti pratici.

Cosa fare con i risultati?

Si ordinano i problemi in base a quanto bloccano le persone e a dove si verificano, si correggono nel codice e nei contenuti del sito, si ritesta e si registra ciò che resta da fare. Un campo senza etichetta nel checkout conta più di un contrasto un po' debole nel footer, e una correzione in un template condiviso sistema tutte le pagine che lo usano.

1. Stabilire le priorità. Prima i blocchi sui percorsi principali (checkout, prenotazione, registrazione), poi i template condivisi, poi le pagine singole.
2. Correggere alla fonte. Cambiare il tema, il componente o il contenuto, non solo il sintomo.
3. Ritestare. Ripetere le stesse verifiche, a mano oltre che con gli strumenti.
4. Documentare. Elencare i problemi noti, con le date, nella dichiarazione di accessibilità. La nostra guida alle WCAG 2.2 spiega i criteri più recenti.
5. Ripetere. Aggiungere una verifica da tastiera e una scansione a ogni rilascio.

Chi usa un widget di accessibilità, compreso il nostro, deve testare con il widget chiuso. Un pannello come SiteAccessible offre ai visitatori modi in più per adattare la pagina, ma le WCAG chiedono se la pagina funziona nel suo stato predefinito. Alcuni sistemi di valutazione non esaminano le pagine su cui gira uno script di overlay, quindi è meglio chiedere prima a chi fa l'audit.