Indice
Perché gli scanner automatici trovano solo il 30% degli errori (e cosa fare per il resto)
Il nostro team analizza centinaia di siti web ogni mese per verificarne l’accessibilità. La maggior parte passa i test automatici con score superiori a 90/100. Ma quando li testiamo con script di automation che simulano comportamenti utente reali, aggiungere prodotti al carrello, compilare form, navigare tra sezioni, scopriamo che il 70% degli errori critici era invisibile agli scanner tradizionali. Come è possibile?
La risposta è semplice, anche se scomoda. Gli scanner automatici sono ottimi per validare sintassi, ma ciechi di fronte a problemi logici e di user experience. Un sito può essere sintatticamente perfetto secondo gli standard WCAG e al tempo stesso rappresentare un labirinto invalicabile per chi naviga con uno screen reader. L’attributo ARIA è presente e corretto, ma il flusso di navigazione non ha senso. Il contrasto colori passa i test, ma l’utente rimane intrappolato in un modal dialog senza via d’uscita.
Questo articolo nasce da anni di esperienza sul campo con accessibilitadigitale.com, dall’analisi di migliaia di progetti e da una convinzione profonda. L’accessibilità digitale vera richiede un approccio olistico in quattro pilastri consecutivi. Partiamo dal problema, cosa trovano e cosa non trovano gli scanner, per poi risalire alla soluzione, come costruire accessibilità dal codice al design, invertendo il paradigma del fix a posteriori.
Test automatici: il 30% è meglio di niente, ma non basta
Gli scanner automatici tradizionali rilevano circa il 30% degli errori di accessibilità. È un dato documentato dal WebAIM Million Report 2024, che analizza annualmente il milione di homepage più visitate. Il 96,3% presenta errori WCAG rilevabili automaticamente, con una media di 56,8 errori per pagina. Ma questi sono solo i problemi sintattici, quelli che un parser può identificare leggendo il codice statico.
Cosa trovano bene gli scanner tradizionali. Alt text presente o assente (95% accuracy), contrasto colori insufficiente (95%), attributi ARIA sintatticamente errati (90%), semantic HTML scorretto come heading hierarchy (90%). Sono check oggettivi, misurabili, binari. O l’attributo c’è o non c’è, o il contrasto supera 4.5:1 o non lo supera. Per questi problemi l’automation è eccellente, veloce, consistente, zero errore umano.
Ma cosa non trovano. Tutto ciò che richiede esecuzione, interazione, contesto. Un keyboard trap in un carousel, sintatticamente corretto, tutti gli attributi ARIA presenti, ma l’utente entra e non riesce più a uscire. Tab order perfetto nel DOM ma visivamente confuso perché il layout CSS riordina gli elementi. Form validation che tecnicamente annuncia errori ma con messaggi incomprensibili. Skip links presenti ma che puntano a un anchor element che non esiste più dopo un refactoring. Modal dialog con focus management implementato ma che si rompe quando apri due modal consecutivi.
Il problema fondamentale degli scanner tradizionali è che analizzano snapshot statici. Caricano la pagina, leggono il DOM, applicano regole WCAG, generano report. Non cliccano bottoni, non compilano form, non simulano user journey reali. Perciò non vedono errori che emergono solo durante l’interazione.
Con accessibilitadigitale.com abbiamo sviluppato un approccio diverso. Script di automation che eseguono azioni reali sul sito prima di scansionare. Aggiungono prodotti al carrello, completano checkout flow, inviano form, aprono modal, navigano tra tab. Poi analizzano lo stato risultante con un multi-engine approach, quattro-cinque scanner indipendenti, Tabbable di Stark per WCAG 2.1, Wave per WebAIM engine, regole proprietarie personalizzate, check dello standard europeo EN 301549, più virtual screen reader che simula navigazione keyboard-only. Detection rate circa 70% degli errori complessivi, contro il 30% dei tradizionali. Non è 100%, e va bene così, ma è un salto significativo.
Alcuni check critici che l’automation avanzata rileva. Keyboard traps con detection 80-85%, tab order illogico 65-75%, skip links mancanti o rotti 90-95%, focus invisibile 80-85%, form validation errors non annunciati 75-80%. Quando due o più scanner concordano, confidence supera il 95%.
Ma sii realistici sui limiti. Anche il nostro approccio ha un ceiling intrinseco. Alt text significativo (l’attributo esiste ma contiene “image123.jpg”), linguaggio chiaro per cognitive accessibility, pronuncia corretta screen reader in contesti ambigui, quality of experience. Sono problemi che richiedono giudizio umano, empatia, comprensione del contesto. I test automatici sono la prima linea di difesa, ma sono solo una parte della storia, quella misurabile, oggettiva, scalabile. Per il resto serve altro.
Test con utenti reali: la verità che solo un utente ipovedente può dirti
Anche con automation avanzata che rileva il 70% degli errori, resta un 20-30% che solo utenti reali possono identificare. E qui nessuna intelligenza artificiale, per quanto sofisticata, può sostituire una persona con disabilità che usa assistive technology ogni giorno.
Alessandro usa NVDA per navigare il web da quindici anni. Due mesi fa ha testato per noi un sito e-commerce che aveva passato tutti i nostri check automatici con score 92/100. Il team era convinto di aver fatto tutto giusto. Alessandro ha abbandonato nella pagina prodotto dopo dodici minuti di frustrazione, impossibile procedere al checkout. Il mini cart semplicemente non era raggiungibile tramite tab navigation.
Il gap tra tecnicamente corretto e usabile nella realtà emerge solo con i test con utenti reali. L’accessibilità non è compliance con checklist, è user experience per persone. E le persone scoprono problemi invisibili all’automation.
Problemi di pronuncia. Lo screen reader legge male abbreviazioni, acronimi, parole straniere in base al contesto. “Dr.” viene letto come “doctor” o “drive” e se il contesto non è chiaro la pronuncia è ambigua e confonde l’utente. Cognitive load eccessivo, troppi annunci ARIA live regions che si sovrappongono, utente perso tra informazioni contraddittorie. Touch gestures mobile, il mobile screen reader funziona completamente diverso da desktop, swipe, double tap, rotor, e spesso questi pattern non sono mai testati. Performance issues, page load lenta significa timeout screen reader, content dinamico caricato asincrono che arriva dopo che l’utente ha già navigato oltre.
L’approccio che consigliamo prevede tre fasi progressive. Phase 1, automated testing avanzato, script di automation che simulano comportamenti reali rilevano circa 70% di problemi sintattici e logici. Phase 2, expert manual review, accessibility specialist umano che esamina manualmente casi edge, flussi complessi, validazione qualitativa, rileva ulteriore 10-15% di problemi che automation ha mancato. Phase 3, user testing, utenti reali con disabilità che rilevano l’ultimo 10-20% di problemi più tutti gli UX issues che solo loro possono validare, usabilità reale, comprensibilità, efficacia dell’esperienza.
Perché questo ordine. Non sprecare tempo di utenti reali su problemi banali che automation trova in trenta secondi. Concentra user testing su ciò che solo loro possono validare. Il sito funziona davvero per completare task reali. L’esperienza è fluida o frustrante. Il linguaggio è chiaro. Le interazioni hanno senso.
Chi coinvolgere. Mix di disabilità, cieco totale, ipovedente, disabilità motoria con keyboard only, cognitiva. Mix di esperienza, power user che usa screen reader da anni e beginner che sta ancora imparando. Mix di tecnologie, NVDA su Windows, JAWS per utenti enterprise, VoiceOver su macOS e iOS. Cosa testare, task realistici completi come “completa un acquisto”, “trova informazione X e contattaci”, “confronta due prodotti e scegli”, non singole pagine isolate.
Dopo il fixing basato su user feedback di Marco e altri quattro utenti, lo score automated del sito è rimasto pressoché identico, 92/100. Ma la user experience si è trasformata. 5/5 utenti completano checkout con successo, average time to purchase ridotto del 40%, conversion rate aumentato del 25% per utenti assistive technology. Lo score automation non cambia, ma l’impatto sul business è misurabile e concreto.
Investimento user testing, da duemila a cinquemila euro per progetto medio, cinque-dieci utenti, due-tre ore ciascuno. ROI documentato, ogni euro speso in accessibilità ritorna quattro-sette euro in valore business secondo Forrester Research. Customer lifetime value aumenta del 30% per utenti con disabilità grazie a maggiore loyalty. E dal giugno 2025, con l’European Accessibility Act in vigore, le multe per non-compliance vanno da cinquantamila a cinquecentomila euro, rendendo l’accessibilità non solo etica ma economicamente necessaria.
Se vuoi veramente sapere se il tuo sito è accessibile, chiedi a chi usa assistive technology ogni giorno. La risposta cambierà il tuo modo di vedere il web.
Accessibilità by code: dove l’automation guida ma il developer decide
Anche sapendo cosa testare e come validare, l’implementazione resta il momento critico. L’automation può guidarti, indicare errori sintattici, suggerire correzioni, ma i developer devono comprendere cosa stanno facendo e perché.
Il 40% degli errori WCAG che rileviamo sono low-hanging fruit. Problemi facilmente evitabili con markup corretto e ARIA usato consapevolmente. Alt text mancante, heading hierarchy sbagliata, form label non associati ai rispettivi input, contrasto insufficiente, attributi ARIA in conflitto. Errori che costano minuti per essere corretti ma ore per essere individuati, testati e risolti in produzione.
Scenario tipico. Il designer specifica focus management esplicito nel prototipo, il developer sotto pressione di deadline lo dimentica. Oppure implementa uno shortcut che sembra funzionare visivamente ma rompe la keyboard navigation. Un div onclick invece di un button produce lo stesso risultato visivo, ma per uno screen reader user la differenza è abissale. Il primo è un elemento generico senza semantica, ruolo o comportamento predefinito. Il secondo è un controllo nativo che funziona automaticamente con tastiera, screen reader e assistive technology.
E qui emerge un paradosso dell’era AI. Tutti ormai usano intelligenza artificiale per sviluppare, Cursor, Claude, Gemini assistono nella scrittura del codice. Ma anche facendo generare tutto l’HTML da un AI, non si arriva al punto. L’AI genera sintassi corretta ma non comprende contesto, user journey, priorità di informazione, flusso logico dell’esperienza. Sa che serve un role button ma non sa quando usarlo rispetto a un button nativo. Genera alt text ma non sa quali dettagli sono rilevanti per comprendere quell’immagine in quel contesto. Implementa ARIA ma non valida se il pattern ha senso per l’utente finale.
Best practices per developer nell’era AI. Usa l’AI per generare una base syntactically correct, poi valida manualmente logica e user experience. Semantic HTML first, ARIA only when needed, senza usare ARIA per ricreare comportamenti che l’HTML nativo già offre. Testa con keyboard navigation durante lo sviluppo, non a fine progetto. Tab attraverso ogni interazione che implementi e verifica che abbia senso. La code review checklist per accessibilità diventa un controllo sistematico, non il pensiero dell’ultimo minuto. E soprattutto, l’automation ti dice dove sono gli errori, ma tu devi capire perché sono errori e come fixarli nel contesto specifico del tuo progetto.
In IRIDE facciamo dell’experience il nostro mantra. E l’accessibilità è esperienza utente per tutti. Non è una feature separata da aggiungere, è qualità intrinseca del codice. Codice semantico è codice accessibile. Codice accessibile è codice che funziona per 1,3 miliardi di persone con disabilità, ma anche per chi naviga da mobile in movimento, per chi usa controlli vocali, per chi ha connessione lenta. Accessibilità migliora UX, UX migliore genera più conversioni. È un circolo virtuoso che parte dalla qualità del codice.
Il codice accessibile non è più difficile da scrivere. È solo diverso. E l’AI può guidarti, indicarti gli errori sintattici, suggerirti le correzioni, ma non può sostituire la tua comprensione di cosa stai costruendo e per chi.
Accessibilità by design: il vero game-changer è pensarci prima
Ma anche il codice più corretto, validato con automation avanzata e testato con utenti reali, non salva un progetto con decisioni di design sbagliate. E qui arriviamo al vero game-changer, il paradigm shift dal fix a posteriori all’accessibility by design, quello che in ambito software engineering si chiama left-shift approach.
I numeri parlano chiaro. Secondo uno studio Forrester del 2023, correggere un problema di accessibilità dopo il launch costa mediamente 10-15 volte rispetto a risolverlo in fase di design. Un dato confermato anche da ricerca IBM. Il 60-70% dei problemi di accessibilità sono decisioni di design, non bug di codice. Questo significa che la maggior parte degli errori che rilevi nei test nasce prima che venga scritta una riga di codice.
Esempio concreto. Modal dialog senza focus management. Se scopri il problema in produzione, non puoi fixarlo con una patch. Devi riprogettare l’intera interazione, modificare gli stati del componente, ridefinire il flusso di apertura e chiusura, implementare keyboard shortcuts, gestire focus trap e return focus. Ore di lavoro di developer, designer, QA. Se invece il focus management fosse stato specificato nel primo wireframe, modal apre, focus va su close button, Esc chiude e ritorna focus all’elemento trigger, l’implementazione sarebbe stata diretta, lineare, senza rework.
Il left-shift approach significa portare considerazioni di accessibilità nelle primissime fasi del progetto. User journey che considerano diversi tipi di disabilità, visiva, motoria, cognitiva, uditiva. Scelte progettuali cruciali come skip links, landmark navigation, focus management esplicito per ogni interazione. Design system con componenti accessibili by default, dove l’accessibilità non è opzione ma comportamento standard.
Cosa significa nel concreto. Wireframe che includono tab order e keyboard navigation paths. Prototipi che specificano ARIA labels e semantic structure. Design review checklist che verifica se il flusso ha senso per uno screen reader user, se il form è compilabile con sola tastiera, se i colori hanno contrasto sufficiente. Decisioni che prese al momento giusto costano zero, sono semplicemente il modo corretto di progettare.
Confronta due scenari reali. Sito A, e-commerce progettato senza considerare accessibilità, poi fixato con intervento a posteriori. Costo remediation circa quindicimila euro tra analisi, redesign parziale, reimplementazione, testing. Risultato, score WCAG 90/100 ma navigazione ancora subottimale, conversion rate per utenti assistive tech inferiore del 20% rispetto a utenti non-assistiti. Sito B, stesso settore, stesso budget iniziale, ma accessibilità considerata dal primo meeting. Menu sempre accessibile invece di hamburger menu problematico, form con label esplicite e error handling chiaro fin dal wireframe, checkout flow pensato per screen reader user. Costo incrementale in fase design circa duemila euro. Risultato, score WCAG 92/100, conversion rate per utenti assistive tech allineato a media generale, zero costo remediation, zero rework.
Il ROI del left-shift è documentato. Secondo Forrester, ogni dollaro investito in accessibility-first design fa risparmiare da quattro a sette dollari in remediation, support e legal compliance. IBM conferma. Progetti che integrano accessibilità da subito riducono del 40-50% il tempo complessivo di development e testing rispetto a progetti che la aggiungono dopo. Non è solo questione etica, è efficienza economica misurabile.
E dal punto di vista business, accessibility by design apre mercati. Il 15% della popolazione mondiale ha disabilità, 1,3 miliardi di persone. In Europa, lo spending power di persone con disabilità e loro familiari è stimato in trecentocinquanta miliardi di euro annui. Un sito accessibile non è “anche per disabili”, è per tutti, in contesti diversi. Chi usa screen reader per necessità, chi naviga da mobile con una mano occupata, chi ha connessione lenta in treno, chi è stanco a fine giornata e la cognitive load lo affatica. Accessibilità è qualità dell’esperienza. E qualità dell’esperienza genera conversioni.
In IRIDE lavoriamo su progetti per brand come Smeg, Nespresso, Borbonese, marchi dove l’experience è il prodotto stesso. E l’accessibilità è parte integrante di quell’experience. Non un vincolo da soddisfare, ma un’opportunità per migliorare usabilità complessiva. I nostri clienti vedono risultati misurabili, riduzione bounce rate, aumento time on site, crescita conversion rate. Perché un sito accessibile è un sito che funziona meglio per tutti.
Prima di scrivere una riga di codice, chiediti. Un utente cieco riuscirebbe a completare questo task. Un utente con disabilità motoria può navigare con sola tastiera. Un utente con disabilità cognitiva capisce questo linguaggio. Se la risposta non è un sì immediato e convinto, il problema non è nel codice che scriverai. È nel design che non hai ancora fatto correttamente.
La sfida continua: automation sempre più intelligente, ma l’umano resta insostituibile
Quattro pilastri consecutivi. Test automatici avanzati, automation che simula comportamenti reali rileva circa 70% degli errori, un salto significativo rispetto al 30% dei tradizionali, ma ancora lontano dal 100%. Test con utenti reali, validation con persone con disabilità per quel 20-30% che automation non può trovare, UX, cognitive load, contesto, pronuncia. Codice corretto, implementazione semantica guidata da automation ma compresa da developer, nell’era AI dove generare sintassi è facile ma capire contesto resta critico. Design consapevole, left-shift approach che sposta accessibilità nelle fasi iniziali, riducendo costi di remediation del 90% e aprendo mercati da trecentocinquanta miliardi di euro.
Con accessibilitadigitale.com stiamo spingendo i limiti dell’automation. Script che simulano user journey reali, multi-engine approach con cross-validation, virtual screen reader per check logici. Detection rate 70% è un risultato concreto, miglioramento documentato. Ma siamo onesti, non è 100%, e forse non lo sarà mai. L’automation eccelle su sintassi, regole oggettive, pattern riconoscibili. Ma l’accessibilità è anche, soprattutto, esperienza umana, contesto, empatia, comprensione di bisogni individuali. Cose che un algoritmo, per quanto sofisticato, non può misurare completamente.
La sfida continua. Stiamo lavorando per andare oltre, integrare approcci sempre più avanzati, ridurre ulteriormente il gap tra automation e human testing. Lo facciamo con realismo. L’obiettivo non è sostituire l’umano, è amplificarlo. Automation scalabile che libera tempo per concentrarsi su problemi complessi che richiedono giudizio, creatività, empatia. È un viaggio, non una destinazione.
Per i decision makers. Investire in accessibilità digitale non è compliance, è business strategy. Il 15% della popolazione mondiale ha disabilità. Con l’European Accessibility Act in vigore da giugno 2025, multe da cinquantamila a cinquecentomila euro rendono l’accessibilità economicamente necessaria. Ma al di là della compliance, accessibilità migliora UX, UX genera conversioni, conversioni sono revenue. È un investimento con ROI documentato di 4-7x.
Per developer e designer. Inizia oggi. Testa il tuo ultimo progetto con keyboard navigation, Tab attraverso la pagina, verifica che ogni interazione sia raggiungibile. Poi chiudi gli occhi e prova con screen reader, NVDA è gratuito, installalo. Cinque minuti che ti apriranno gli occhi su un mondo che non vedevi. E la prossima volta che progetti, chiediti. Funziona per tutti.
L’accessibilità digitale non è feature nice-to-have. È diritto umano fondamentale, qualità dell’esperienza, vantaggio competitivo misurabile. E con l’approccio giusto, design consapevole, codice corretto, automation intelligente, human validation, è assolutamente raggiungibile.
La prossima volta che usi un sito web, chiudi gli occhi per trenta secondi. Prova a navigare. Ora immagina di farlo per sempre. L’accessibilità non è un problema di codice. È un problema di empatia. E l’empatia richiede esseri umani, l’automation può guidarli, supportarli, accelerarli, ma non sostituirli.
Raccontaci il tuo progetto e costruiamo insieme la strategia giusta per la tua azienda
Scopri come possiamo aiutarti a crescere.
FAQ
Quanto sono affidabili gli scanner automatici per testare l’accessibilità?
Gli scanner automatici rilevano circa il 30% degli errori di accessibilità totali. Sono precisi su problemi sintattici oggettivi come alt text mancante, contrasto colori insufficiente e attributi ARIA errati. Risultano invece inefficaci su tutto ciò che emerge solo durante l’interazione reale: keyboard trap, tab order illogico, focus management assente nei modal, form validation che non annuncia correttamente gli errori. Un sito può ottenere uno score superiore a 90/100 negli scanner tradizionali e al tempo stesso risultare inaccessibile per chi naviga con uno screen reader.
Cosa rileva l’automation avanzata che i test tradizionali non vedono?
Un approccio multi-engine che simula comportamenti utente reali, come aggiungere prodotti al carrello, compilare form o navigare tra sezioni, porta il tasso di rilevamento a circa il 70% degli errori complessivi. In questo modo diventano visibili keyboard trap, skip link rotti, focus invisibile e messaggi di errore non annunciati correttamente. Rimane comunque un 20-30% di problemi che solo utenti reali con disabilità sono in grado di identificare, in particolare quelli legati alla qualità dell’esperienza, alla comprensibilità del linguaggio e alle interazioni su mobile con screen reader.
Perché i test con utenti reali sono indispensabili?
Perché l’accessibilità non è compliance con una checklist: è esperienza d’uso per persone. Problemi di pronuncia degli screen reader, cognitive load eccessivo generato da ARIA live region sovrapposti, gesture mobile mai testate e performance lente che causano timeout sono tutti aspetti che nessun algoritmo può valutare con precisione. Un utente che usa NVDA da anni individua criticità che automation avanzata non ha mai incontrato, e lo fa in pochi minuti di sessione reale.
Quanto costa intervenire sull’accessibilità a progetto già avviato?
Secondo uno studio Forrester del 2023, correggere un problema di accessibilità dopo il lancio costa mediamente tra le dieci e le quindici volte rispetto a risolverlo in fase di design. Il 60-70% degli errori rilevati nei test è il risultato di decisioni progettuali prese prima che venisse scritta una riga di codice. Riprogettare un modal dialog in produzione, ad esempio, richiede ore di lavoro tra developer, designer e QA; specificarne il focus management in fase di wireframe costa invece qualche riga di documentazione.
Cosa cambia con l’European Accessibility Act in vigore da giugno 2025?
L’European Accessibility Act rende obbligatoria l’accessibilità digitale per la maggior parte dei servizi e prodotti commerciali rivolti ai consumatori nell’Unione Europea. Le sanzioni per non conformità variano da cinquantamila a cinquecentomila euro. Al di là dell’obbligo normativo, un sito accessibile apre l’accesso a un mercato stimato in trecentocinquanta miliardi di euro di spending power tra persone con disabilità e loro familiari in Europa, con un ritorno documentato tra i quattro e i sette euro per ogni euro investito.
L’intelligenza artificiale può sostituire la revisione umana nell’accessibilità?
No. I modelli di AI generano sintassi corretta, suggeriscono correzioni e accelerano la fase di sviluppo, ma non comprendono contesto, flusso logico dell’esperienza o priorità informativa. Sanno che serve un attributo role=”button” ma non distinguono quando sia preferibile usare un elemento button nativo. Generano alt text ma non valutano quali dettagli siano rilevanti in quel contesto specifico. L’automation, per quanto avanzata, amplifica il giudizio umano; non lo sostituisce.
