Hai appena eseguito un test di accessibilità sul sito di un cliente. Lo strumento restituisce un punteggio — 91 su 100, oppure “2 errori critici, 14 avvisi”. La domanda che segue è quasi sempre la stessa: questo vuol dire che il sito è accessibile?
La risposta breve è: non necessariamente. I punteggi e i report degli strumenti di test automatici sono utili, ma misurano una parte limitata dell’accessibilità reale. Un’agenzia che sa leggere questi risultati in modo corretto — e che sa spiegarli al cliente — ha un vantaggio commerciale concreto rispetto a chi si limita a mostrare un numero.
Cosa misura davvero un test di accessibilità automatico
Un test di accessibilità automatico — che si tratti di Lighthouse, WAVE, axe o altri strumenti equivalenti — analizza il codice HTML della pagina e verifica una lista predefinita di regole tecniche derivate dalle WCAG, le linee guida internazionali per l’accessibilità web.
Controlla cose verificabili in modo binario: le immagini hanno un attributo alt? I campi del form hanno label associate? Il contrasto tra testo e sfondo rispetta il rapporto minimo richiesto? La struttura degli heading è gerarchica e coerente?
Quello che non può fare è capire il contesto. Può verificare che un’immagine abbia un attributo alt — non può verificare se il testo dentro quell’attributo sia utile o no. “img001” e “Screenshot della dashboard di Google Analytics con evidenziato il calo di traffico di giugno” superano entrambi il controllo automatico. Solo il secondo serve a qualcosa per chi usa uno screen reader.
Questo è il limite strutturale degli strumenti automatici: rilevano solo il 30-40% dei problemi totali di accessibilità. Per conformità WCAG completa serve verifica manuale con lettori di schermo, test di usabilità e audit professionale. Un punteggio perfetto garantisce che il 30-40% dei problemi verificabili automaticamente siano stati risolti — non che il sito sia accessibile.
Come si costruisce il punteggio e perché può ingannare
La maggior parte degli strumenti segue questa logica: scansiona la pagina, identifica le violazioni, le categorizza per severità — minore, moderata, seria, critica — e calcola un punteggio pesato in cui i problemi critici abbassano il voto molto più di quelli minori.
Il risultato è che un sito con un difetto critico — ad esempio una navigazione da tastiera completamente rotta su tutte le pagine — può avere un punteggio molto basso anche se tutto il resto è corretto. Al contrario, un sito con molte piccole imperfezioni può avere un punteggio alto che maschera problemi reali per gli utenti.
Ci sono tre scenari frequenti in cui un sito con un punteggio alto crea comunque barriere reali.
Il form con tutti i campi etichettati ma incomprensibile. Lo strumento verifica che ogni campo abbia una label associata — e se ce l’ha, il test passa. Non verifica se le istruzioni sono scritte in modo comprensibile, se i messaggi di errore spiegano cosa correggere, se l’ordine logico dei campi ha senso per chi naviga con la tastiera. Un form tecnicamente corretto può essere un incubo cognitivo.
Il menu completamente navigabile da tastiera ma lentissimo da usare. Un sito con decine di voci di navigazione può superare tutti i controlli automatici sulla navigazione da tastiera — ogni elemento è raggiungibile, non ci sono trappole. Ma se per arrivare al link “Contatti” bisogna premere Tab ottantasei volte, il sito è tecnicamente conforme e praticamente inutilizzabile.
L’alt text generico che supera il controllo. “Immagine del prodotto” o “foto aziendale” passano qualsiasi audit automatico. Non comunicano nulla a chi non vede l’immagine. Come abbiamo già approfondito nell’articolo sui requisiti WCAG per WordPress, la conformità tecnica e l’accessibilità reale sono due cose che si sovrappongono ma non coincidono.
Il test manuale che completa quello automatico
La verifica che completa quella automatica è il test manuale — navigare il sito come lo userebbe una persona con esigenze diverse. Non serve essere esperti di accessibilità per fare test di base utili.
Il test da tastiera è il più accessibile da eseguire: metti da parte il mouse e prova a navigare il sito usando solo Tab, Shift+Tab, Invio, Spazio e le frecce direzionali. Puoi raggiungere ogni elemento interattivo? Il focus è sempre visibile — si vede chiaramente quale elemento è selezionato? L’ordine in cui si sposta il focus ha senso? Puoi uscire da tutti i componenti dove sei entrato?
Questo test da solo rivela problemi che nessuno strumento automatico intercetta e richiede pochi minuti sulle pagine principali. Gli strumenti automatici aiutano a scoprire errori, ma per adeguare davvero un sito servono priorità, correzioni WCAG e verifica manuale sui flussi importanti.
Vale la pena includere questo test nel processo di consegna di ogni sito — insieme all’audit SEO tecnico e alla checklist di performance — perché i problemi che emergono manualmente sono spesso quelli che i clienti notano per primi quando un utente si lamenta.
Come leggere i report degli strumenti più comuni
I tre strumenti più usati producono output molto diversi, ed è utile sapere cosa guardare in ciascuno.
Lighthouse — integrato in Chrome DevTools — produce un punteggio da 0 a 100 e una lista di verifiche con stato pass/fail. Il punteggio è una media pesata: non tutti i controlli valgono uguale. Per interpretarlo correttamente, non guardare il numero ma scorrere la lista dei fallimenti — solo quelli classificati come “Failed” impattano il punteggio, mentre quelli marcati “Not applicable” indicano semplicemente che quella verifica non si applica alla pagina analizzata.
WAVE mostra gli errori direttamente sovrapposti alla pagina, con icone colorate che indicano la posizione del problema nel layout. È più intuitivo di Lighthouse per comunicare i problemi ai clienti — si vede esattamente dove e cosa. Gli “Errors” rossi sono i problemi certi, gli “Alerts” gialli sono elementi da verificare manualmente.
axe DevTools — disponibile come estensione browser — è quello più usato dai team di sviluppo perché distingue chiaramente tra violazioni certe e problemi che richiedono giudizio umano. La colonna “Needs review” è spesso la più interessante: contiene i casi in cui lo strumento ha trovato qualcosa di potenzialmente problematico ma non può determinare automaticamente se è un errore.
Le priorità di intervento per chi parte da zero
Se un sito ha problemi di accessibilità e si vuole capire da dove iniziare, la risposta non è “dal problema che abbassa di più il punteggio” ma “dal problema che crea le barriere più grandi per gli utenti reali”.
In pratica, i problemi che impattano più persone e che sono più facili da correggere su WordPress sono quasi sempre gli stessi: alt text significativo su tutte le immagini non decorative, struttura degli heading corretta con un solo H1 e gerarchia logica, contrasto testo/sfondo conforme ai requisiti WCAG AA con rapporto minimo 4.5:1 per testo normale, label associate correttamente a ogni campo del form, navigazione da tastiera funzionante su tutti gli elementi interattivi.
Questi cinque interventi risolvono la maggioranza dei problemi più frequenti sui siti WordPress. La manutenzione periodica del sito dovrebbe includere una verifica di questi elementi ogni volta che vengono aggiunte nuove pagine o modificate sezioni esistenti, perché i problemi di accessibilità si accumulano nel tempo esattamente come il debito tecnico.
Come usare i risultati del test con i clienti
La domanda pratica per un’agenzia è: come si comunicano questi risultati a un cliente che vuole una risposta semplice?
Il primo passo è non usare il punteggio come punto di arrivo ma come punto di partenza. “Abbiamo raggiunto 91 su Lighthouse” diventa “abbiamo risolto i problemi tecnici rilevabili automaticamente, che coprono circa un terzo dei possibili problemi di accessibilità. Questi sono i passaggi successivi per coprire il resto.”
Il secondo è mostrare i problemi concreti invece dei numeri astratti. Aprire WAVE davanti al cliente e spiegargli cosa significa “3 immagini senza alt text” è molto più efficace di commentare un punteggio. Il cliente capisce immediatamente perché conta e questo rende la conversazione sull’accessibilità concreta invece che formale.
Il terzo è collegare i risultati agli obiettivi di business. Un sito più accessibile raggiunge più persone, ha una struttura più pulita che aiuta il posizionamento SEO, e riduce il rischio di contestazioni ora che il European Accessibility Act è in vigore. Come abbiamo spiegato nell’articolo sull’accessibilità web per agenzie, questi argomenti trasformano l’accessibilità da obbligo a investimento.
Quando presentiamo i risultati di un audit di accessibilità alle agenzie partner, usiamo sempre lo stesso approccio: apriamo WAVE insieme sul sito del cliente durante la call, mostriamo gli errori rossi in tempo reale e spieghiamo cosa significano in termini pratici. Un’agenzia di Firenze con cui lavoriamo abitualmente ci ha detto che dopo aver visto questo processo per la prima volta ha iniziato a proporlo ai propri clienti come servizio aggiuntivo — “audit di accessibilità visivo” — che presenta nella stessa call di consegna del sito. In sei mesi ha chiuso quattro contratti di manutenzione aggiuntivi partendo proprio da quella conversazione.
Blurr include la verifica di accessibilità nel processo di sviluppo per le agenzie partner: scansione automatica, test manuale da tastiera sulle pagine principali e checklist pre-consegna. Per i siti esistenti offriamo anche audit standalone che combinano verifica automatica e manuale, con un report che distingue i problemi tecnici dai problemi di usabilità e indica le priorità di intervento. Prenota una call per capire come integrare questa verifica nel tuo processo.
Se vuoi capire il livello di accessibilità dei siti che gestisci per i tuoi clienti — con una valutazione che va oltre il punteggio automatico — prenota una call con Blurr per vedere come integrare l’audit di accessibilità nel tuo processo di sviluppo.
Domande frequenti
Lighthouse misura i problemi rilevabili automaticamente — circa il 30-40% del totale. Un punteggio alto indica che i problemi tecnici verificabili dal codice sono stati risolti: contrasto, label, alt text presenti. Non dice nulla sulla qualità di quell’alt text, sull’usabilità della navigazione da tastiera o sulla comprensibilità dei contenuti — aspetti che richiedono verifica manuale.
Come minimo, una verifica completa trimestrale e un test automatico mensile. Se il sito ha un CMS e più redattori, è utile integrare controlli automatici nel workflow di pubblicazione — perché ogni nuova pagina o modifica ai contenuti può introdurre nuovi problemi.
No. Lighthouse verifica una sottoinsieme delle regole WCAG — quelle verificabili automaticamente. La conformità WCAG completa richiede anche verifica manuale di navigazione da tastiera, qualità dei contenuti, usabilità per utenti con tecnologie assistive e test con utenti reali. Il punteggio Lighthouse è un indicatore utile, non un certificato di conformità.
Nella maggior parte dei casi sì. I problemi più comuni — alt text mancanti o generici, heading mal strutturati, form senza label, problemi di contrasto — si risolvono con interventi mirati sul codice esistente senza alterare il design. I casi in cui è necessario un intervento più profondo riguardano siti con strutture tematiche non standard o costruiti con strumenti che generano codice non modificabile.