Perché gli scanner automatici per l’accessibilità rilevano solo il 30% dei problemi (e cosa fare al riguardo)

Esegui una scansione automatizzata dell’accessibilità, la dashboard torna tutta verde e tiri un sospiro di sollievo. Ma ecco una verità scomoda: quel report pulito potrebbe nascondere la maggior parte delle reali barriere di accessibilità del tuo sito. Ricerche e studi indipendenti mostrano costantemente che gli scanner automatici rilevano tra il 30% e il 57% delle effettive violazioni WCAG — il che significa che da metà a due terzi dei problemi che le persone con disabilità incontrano ogni giorno sono completamente invisibili agli strumenti su cui la maggior parte dei team fa affidamento.

Lo stato del testing automatico di accessibilità

Il testing automatico di accessibilità è esploso in popolarità, e per una buona ragione. Sempre più team si rivolgono all’automazione per individuare problemi di accessibilità: il 50% degli intervistati in un sondaggio del 2024 ha dichiarato di usare strumenti automatici di accessibilità per identificare potenziali problemi, rispetto al 40% nel 2023. Il motivo dell’attrattiva è evidente: gli scanner sono veloci, relativamente economici e possono essere integrati direttamente nelle pipeline CI/CD. Individuano in modo massivo le violazioni ovvie, ripetibili e basate su regole: l’attributo alt mancante, il campo di input del form senza etichetta, il pulsante con un nome accessibile vuoto.

Ma il tetto di copertura è un problema ostinato che nessun fornitore di scanner è riuscito a sfondare. Secondo Deque, "in media si può trovare automaticamente il 57% dei problemi WCAG", e anche in quel caso gli strumenti restituiscono componenti come incompleti quando è necessaria una revisione manuale. Quella percentuale del 57% rappresenta l’estremo più ottimistico dello spettro, raggiunto da uno dei motori di accessibilità più maturi e affidabili sul mercato usando una metodologia di misurazione pragmatica e basata sul mondo reale. Altre stime sono considerevolmente più basse. Gli strumenti automatici intercettano circa il 30–40% delle violazioni WCAG, mentre il restante 60–70% richiede test manuali.

La discrepanza tra 30% e 57% dipende da come si definisce il denominatore. Deque è arrivata alla cifra del 57% adottando un approccio pragmatico e reale piuttosto che teorico — campionando un gran numero di siti e misurando quante delle effettive difettosità di accessibilità documentate sarebbero state rilevate usando axe-core. Quando invece i ricercatori misurano la copertura rispetto a tutti i criteri di successo WCAG come insieme teorico, i numeri crollano drasticamente. Al momento in cui si scrive, filtrando per WCAG 2.2 Livelli A e AA per mostrare solo le regole di test automatico approvate, si ottiene copertura parziale o completa per solo 17 dei 55 criteri di successo. In ogni caso la si guardi, il testing automatico lascia un divario significativo — e legalmente pericoloso.

Il problema è aggravato dal fatto che è molto difficile vedere questo divario dall’esterno. Una scansione superata segnala attivamente sicurezza, ed è proprio in quel momento che i team sono più propensi a smettere di cercare. La dashboard è verde. Si va in produzione. Persone reali con disabilità incontrano barriere reali.

In cosa sono davvero bravi gli scanner

Prima di approfondire il divario di copertura, vale la pena chiarire in cosa gli strumenti automatici sono davvero efficaci. Sono veloci, coerenti e instancabili nel controllare ciò che può essere determinato semplicemente leggendo il DOM. L’automazione dell’accessibilità può intercettare in modo affidabile violazioni WCAG comuni come testo alternativo mancante, link vuoti, etichette di form improprie e rapporti di contrasto colore troppo bassi. Si tratta di controlli strutturali e binari: o l’attributo esiste o non esiste, o il rapporto di contrasto supera 4.5:1 o fallisce.

Il report WebAIM Million, che analizza ogni anno le prime un milione di home page, offre un quadro vivido di quanto questi errori rilevabili siano ancora diffusi. Il 95,9% delle home page presentava fallimenti WCAG 2 rilevati. Le sei categorie più comuni — testo a basso contrasto, testo alternativo mancante, etichette di form mancanti, link vuoti, pulsanti vuoti e lingua del documento mancante — rappresentano il 96% di tutti gli errori rilevati, e questi errori più comuni sono gli stessi da sette anni. Gli strumenti automatici sono davvero utili per far emergere su larga scala queste violazioni ad alta frequenza e bassa complessità. Il problema è che correggere solo questi problemi lascia comunque un sito con la maggior parte delle sue barriere reali intatte.

Perché esiste il divario: cosa gli scanner non possono valutare

Il tetto di copertura non è un fallimento dell’ingegneria — è un limite fondamentale di ciò che una macchina può valutare senza giudizio umano. Il divario esiste perché le macchine non possono comprendere il contesto, l’intento dell’utente o questioni soggettive come se la gerarchia dei titoli abbia senso o se il testo alternativo sia accurato. Uno scanner può confermare che un’immagine ha un attributo alt. Non può dirti se quell’attributo recita "photo-123-final-v2.jpg" o una descrizione davvero utile. Gli strumenti possono segnalare che un’immagine ha del testo alternativo, ma solo una persona può giudicare se quel testo descrive davvero bene l’immagine.

Ecco le principali categorie di problemi che sfuggono costantemente al rilevamento automatico:

• Esperienza con screen reader: Gli strumenti automatici non possono ascoltare come uno screen reader annuncia i contenuti. Possono verificare la validità degli attributi ARIA ma non possono determinare se gli annunci risultanti abbiano senso per gli utenti. Un campo di form potrebbe avere un aria-label tecnicamente valido che viene letto come una stringa confusa di caratteri per un vero utente NVDA o JAWS.
• Ordine logico di lettura e di focus: In pratica, l’ordine di lettura spesso non ha senso quando gli utenti di screen reader accedono a informazioni che visivamente possono sembrare perfettamente leggibili. In un layout a colonne, uno screen reader legge la prima riga della colonna 1, poi la colonna 2, generando confusione. Gli scanner analizzano l’ordine del DOM in isolamento, senza il contesto di come il layout visivo trasformi quell’ordine per un utente vedente.
• Testo significativo di link e pulsanti nel contesto: Gli strumenti automatici possono verificare se esiste un link e se include del testo, ma non possono sempre giudicare se lo scopo di quel link sia chiaro. Cinque link "Leggi di più" sulla stessa pagina superano tutti i controlli automatici e falliscono tutti per gli utenti reali che hanno bisogno di capire dove porta ciascuno.
• Contenuti dinamici e live region: Gli strumenti automatici non riusciranno a intercettare problemi con contenuti caricati dinamicamente. Bisognerà eseguire di nuovo il test dopo che l’aggiornamento dinamico è stato aggiunto — ma anche allora, lo strumento non può dire se uno screen reader lo leggerà o meno.
• Accessibilità cognitiva e linguaggio semplice: L’automazione può rilevare problemi strutturali come l’ordine dei titoli o la presenza di etichette, ma non può valutare leggibilità, chiarezza o se le istruzioni siano facili da seguire. Un complesso checkout multi-step con messaggi di errore confusi può essere strutturalmente "pulito" pur essendo profondamente inaccessibile per utenti con disabilità cognitive.
• Navigazione da tastiera in interazioni complesse: L’automazione può testare il focus da tastiera di base e l’operabilità, ma non può validare completamente interazioni complesse multi-step, gesture personalizzate o dispositivi di input alternativi. Un widget di selezione data personalizzato può essere in teoria completamente utilizzabile da tastiera e in pratica una trappola totale.
• Elementi visivi sovrapposti e contrasto nei gradienti: Gli strumenti automatici possono valutare i rapporti di contrasto, ma non tengono sempre conto di elementi sovrapposti, immagini dietro il testo o contenuti che cambiano dinamicamente e interferiscono con la leggibilità.

Una scansione automatica pulita significa che hai affrontato il 30–40% dei problemi che l’automazione può intercettare. Il restante 60–70% non è testato. Non dichiarare mai conformità WCAG basandoti esclusivamente su test automatici.

Un dato particolarmente significativo: in uno studio, sostenitori dell’accessibilità del governo del Regno Unito hanno creato intenzionalmente una pagina web con 142 barriere di accessibilità, quindi hanno analizzato la pagina con 13 strumenti automatici di accessibilità. Lo strumento con le prestazioni migliori è stato in grado di identificare solo il 40% delle barriere. Quello con le prestazioni peggiori ne ha trovate appena il 13%. Anche quando il mazzo era truccato a favore degli strumenti — usando una pagina controllata con problemi noti e documentati — i risultati sono stati sconfortanti. E combinare strumenti non risolve del tutto: anche usando sei strumenti in parallelo, metà di tutti i criteri di successo WCAG 2 non è coperta e 6 violazioni su 10 vengono mancate.

Il rischio legale di affidarsi troppo all’automazione

Non si tratta solo di una preoccupazione teorica sull’esperienza utente. Le poste in gioco legali per la non conformità all’accessibilità stanno aumentando rapidamente, e una scansione automatica superata offre quasi nessuna protezione in una causa. Nel 2024, sono state intentate più di 4.000 cause nei tribunali statunitensi per barriere all’accessibilità di siti web o app mobili. La sola prima metà del 2025 ha visto 2.014 cause ADA relative a siti web — un aumento del 37% rispetto al 2024.

Gli accordi extragiudiziali si attestano in media sui $30.000, mentre le sentenze in tribunale si aggirano in media sugli $85.000. In tutti i casi si aggiungono spese legali di difesa tra $30.000 e $175.000. Peggio ancora, chiudere una volta una causa non garantisce sicurezza: il 45–46% delle cause federali del 2025 sulla accessibilità digitale ha preso di mira aziende che erano già state citate in giudizio in passato. Essere citati in giudizio e correggere solo ciò che gli strumenti automatici segnalano, senza affrontare i divari strutturali più ampi, significa semplicemente dipingersi un bersaglio sulla schiena per il prossimo ricorrente.

Vale anche la pena affrontare un malinteso comune sui widget e overlay di accessibilità come scorciatoia verso la conformità. I dati del 2025 mostrano che 456 cause ADA sono state intentate contro siti web che avevano installato widget di accessibilità, pari al 22,64% del totale delle cause — a dimostrazione che aggiungere semplicemente un widget di accessibilità non è una soluzione completa. Gli strumenti automatici possono rilevare solo il 30% dei problemi WCAG, il che significa che qualsiasi strumento o widget che si basi esclusivamente sul rilevamento automatico lascia per definizione la maggior parte dei problemi irrisolti. Ciò che distingue un SDK di accessibilità davvero prezioso — come Accsible — dai prodotti di overlay che hanno affrontato reazioni legali e regolatorie è la combinazione di correzione automatica con un impegno verso una strategia di conformità onesta e stratificata, piuttosto che false garanzie.

Una strategia di testing a livelli che funziona davvero

La risposta al divario di copertura non è abbandonare gli scanner automatici — è usarli correttamente, come primo livello di una strategia completa, non come ultimo. Degli 86 criteri di successo WCAG 2.2, il settanta percento richiede una revisione umana per interpretare correttamente i criteri e applicarli alle aree grigie al di fuori della portata della tecnologia di accessibilità automatica. Ciò significa che il giudizio umano non è opzionale — è strutturalmente richiesto dallo standard stesso.

Un programma di testing di accessibilità robusto in genere funziona su tre livelli:

1. Scansione automatica (continua): Integra scanner come axe-core nella tua pipeline CI/CD ed eseguili su ogni build. Intercetta le violazioni strutturali e binarie prima che raggiungano la produzione. Imposta soglie e fai fallire le build in caso di nuove violazioni critiche. Questo è la tua rete di sicurezza per i problemi ovvi — veloce, scalabile ed economica. Esegui gli strumenti automatici presto e spesso durante lo sviluppo. Integra axe o WAVE nella tua pipeline CI/CD in modo che i problemi vengano intercettati prima che il codice raggiunga il QA. Questo sposta il testing di accessibilità a sinistra, intercettando i problemi quando è più economico risolverli.
2. Audit manuale esperto (periodico): Conduci audit manuali strutturati rispetto all’intera checklist WCAG, eseguiti da persone con profonda conoscenza dell’accessibilità. I test manuali di accessibilità sono eseguiti da esperti formati che usano attivamente i siti web con tecnologie assistive come screen reader, navigazione da tastiera o software di ingrandimento. Valutano contesto ed esperienza utente — l’ordine logico del focus e la sensazione intuitiva della navigazione, la chiarezza dei form e dei messaggi di errore, la leggibilità all’interno di contenuti complessi. Gli audit manuali in genere avvengono trimestralmente o quando vengono rilasciate funzionalità importanti, e dovrebbero coprire end-to-end i percorsi utente a maggior traffico. Gli audit manuali guidati di accessibilità si collocano tra il testing completamente manuale e quello completamente automatico, riducendo il divario di copertura, con alcune stime che indicano una copertura fino all’80% con questo approccio.
3. Test con tecnologie assistive e utenti (continuo): Non puoi fare affidamento solo sugli strumenti automatici per determinare i problemi di accessibilità sul tuo sito. Ogni progetto web ha bisogno di una strategia di user testing, ed è altamente raccomandato includere gruppi di utenti per l’accessibilità — utenti di screen reader, utenti che usano solo la tastiera, utenti non udenti, utenti con disabilità motorie. Utenti reali con disabilità trovano problemi che nessuna checklist prevede. Testa con NVDA e JAWS su Windows, VoiceOver su macOS e iOS e TalkBack su Android. Naviga l’intero flusso di checkout o registrazione usando solo la tastiera. Ascolta davvero come suonano i tuoi contenuti quando vengono letti ad alta voce.

Quando i team implementano tutti e tre i livelli, la copertura combinata può avvicinarsi all’80–90% dei problemi del mondo reale — un miglioramento drastico rispetto al tetto del 30–57% dell’automazione da sola. L’obiettivo non è la perfezione dal primo giorno; è un processo sistematico e documentato che dimostri un reale impegno in buona fede e riduca continuamente il divario.

Integrare l’accessibilità nel flusso di lavoro di sviluppo

Il cambiamento culturale più importante è spostare l’accessibilità da una checklist pre-lancio a una pratica continua. Molte organizzazioni commettono l’errore di trattarla come un audit una tantum che commissionano quando temono una causa, invece che come uno standard di qualità integrato in ogni sprint. Quando un audit rivela problemi in un sistema in produzione, il costo per risolverli è da cinque a dieci volte superiore rispetto a quanto sarebbe stato in fase di design.

Inizia rendendo i criteri di accessibilità parte della tua definition of done. Quando uno sviluppatore rilascia un nuovo componente, un rapido controllo automatico dovrebbe essere eseguito automaticamente. Quando un designer crea un nuovo pattern, il contrasto dei colori e gli stati di focus dovrebbero essere rivisti prima ancora che il design venga consegnato. Quando un content editor aggiunge una nuova immagine, dovrebbe avere una chiara comprensione di cosa sia un testo alternativo significativo — non solo che il testo alternativo è richiesto.

Per i responsabili della conformità, l’implicazione pratica è la documentazione. Alcuni team eseguono test automatici ma non affrontano mai i risultati. Questo non fornisce alcun valore e crea documentazione che dimostra che eravate a conoscenza dei problemi ma non li avete risolti — una situazione problematica in ambito legale. Un programma di accessibilità è difendibile solo se puoi mostrare un processo ragionevole e in buona fede di miglioramento continuo: scansioni regolari, risultati documentati, una roadmap di correzione e prove che stai agendo in base a ciò che impari. La conformità WCAG non è un binario che raggiungi una volta per tutte — è una postura che mantieni.

Strumenti come Accsible esistono per supportare questo approccio a livelli — fornendo un SDK che incorpora i miglioramenti di accessibilità direttamente nell’esperienza utente, facendo emergere problemi in tempo reale e completando il processo di audit manuale invece di tentare di sostituirlo. Il giusto overlay o SDK non è uno scudo magico contro le cause; è un componente di un programma ponderato che riconosce ciò che l’automazione può e non può fare.

Key Takeaways

• Gli scanner automatici sono un punto di partenza, non il traguardo. Anche i migliori strumenti rilevano tra il 30% e il 57% delle reali violazioni WCAG. Un report di scansione pulito non significa che il tuo sito sia accessibile — significa che il sottoinsieme rilevabile dei problemi è stato affrontato.
• La maggior parte dei criteri di successo WCAG richiede giudizio umano. Esperienza con screen reader, ordine logico di lettura, testo significativo dei link nel contesto, chiarezza cognitiva e interazioni complesse da tastiera sono tutte aree in cui l’automazione è strutturalmente incapace di darti una risposta affidabile.
• L’ambiente legale è ostile alla compiacenza. Oltre 5.100 cause federali ADA relative a siti web sono state intentate nel 2025, gli accordi si attestano regolarmente tra $30.000 e $85.000 più le spese di difesa, e quasi la metà dei convenuti era già stata citata in giudizio in passato — il che suggerisce che le correzioni superficiali non bastano.
• Una strategia a tre livelli — scansione automatica, audit manuali esperti e test reali con tecnologie assistive — può spingere la copertura verso l’80–90% e ti offre la postura di conformità documentata e in buona fede che tribunali e autorità di regolamentazione si aspettano di vedere.
• Sposta l’accessibilità a sinistra. Intercettare i problemi in fase di design e sviluppo costa una frazione di quanto costa la correzione dopo il lancio. Integra i controlli automatici nel CI/CD, rendi l’accessibilità parte della tua definition of done e conduci audit manuali regolari sui percorsi utente a maggior traffico.