Perché gli Overlay di Accessibilità sono il problema e non la soluzione

Il giorno in cui Maria ha rinunciato a comprare

Maria usa quotidianamente uno screen reader per navigare il web. Quando arriva su un sito e-commerce che promette "accessibilità completa grazie all'AI", viene immediatamente accolta da una voce sintetica che annuncia: "Questo sito è accessibile con overlay". A ogni cambio pagina, lo stesso messaggio. Il suo screen reader nativo, NVDA, inizia a sovrapporsi con quello integrato nell'overlay. Il pulsante "Aggiungi al carrello" viene letto come "Questo potrebbe essere Carrello, Il Carrello, Carrello Acquisti o Lista Prodotti". Maria chiude il browser. Ha perso quindici minuti e non ha comprato nulla.

Questa non è una storia inventata. È un'esperienza documentata da utenti reali e rappresenta perfettamente il paradosso degli accessibility overlay: strumenti venduti come soluzione all'accessibilità che diventano essi stessi delle barriere.

L'illusione della soluzione rapida

Gli overlay di accessibilità promettono il miracolo: "Una riga di codice e il tuo sito è conforme WCAG all'istante". Per un'azienda che riceve una lettera di diffida o scopre che i competitor sono stati citati in giudizio, questa promessa sembra la salvezza. È veloce, economico (spesso meno di €500/anno) e soprattutto non richiede toccare il codice esistente e sistemare il proprio sito.

Il marketing è aggressivo e persuasivo:

• "AI-powered accessibility"
• "Conformità WCAG 2.1 AA garantita"
• "Protezione legale inclusa"
• "Installazione in pochi minuti"

Ma qui sta il primo problema fondamentale: l'accessibilità non può essere "aggiunta sopra" un sito mal costruito. Non è un layer CSS che modifica l'aspetto visivo. L'accessibilità riguarda la struttura semantica, l'architettura dei componenti, le decisioni di design e usabilità prese fin dall'inizio.

Anatomia tecnica del fallimento

Il limite dell'automazione

Gli strumenti automatizzati, anche quelli più sofisticati, possono identificare solo il 30-40% dei problemi di accessibilità definiti dalle WCAG. Questo non è un'opinione: è un limite tecnico riconosciuto dall'industria.

Perché questa limitazione? Prendiamo un esempio concreto:

< div onclick="submitForm()" >Invia< /div >

Un overlay potrebbe:

• Aggiungere un attributo role="button"
• Rendere l'elemento focusabile con tabindex="0"
• Magari aggiungere un'etichetta ARIA

Ma non può sapere:

• Se quel pulsante dovrebbe essere disabilitato in certi contesti
• Quale feedback dare all'utente dopo il clic
• Se l'ordine di tabulazione è logico nel contesto del form
• Se il form ha una validazione lato client che non è accessibile
• Se i messaggi di errore sono associati correttamente ai campi

Questo genere di valutazione richiede comprensione del contesto, dell'intento progettuale, dell'esperienza utente. Richiede un essere umano per valutarlo.

L'interferenza con le tecnologie assistive

Gli overlay non si limitano ad aggiungere attributi ARIA o alt text. Molti includono un proprio screen reader "potenziato dall'AI". Il risultato? Due screen reader che competono per la stessa pagina.

Gli utenti esperti di screen reader hanno passato anni a padroneggiare JAWS, NVDA o VoiceOver. Hanno configurazioni personalizzate, scorciatoie da tastiera memorizzate, modalità di navigazione ottimizzate per le loro esigenze specifiche. L'overlay invece, gli chiede di disabilitare tutto questo e usare un lettore imposto, senza configurazioni, che si comporta in modo completamente diverso.

È come chiedere a un pilota professionista di buttare via i comandi dell'aereo e pilotare con un joystick da videogioco.

Il problema delle performance e della latency

Gli overlay operano tramite JavaScript che:

1. Scansiona il DOM ad ogni caricamento e rendering della pagina
2. Modifica dinamicamente elementi
3. Intercetta eventi
4. Aggiunge listener multipli

È un fatto ben noto nel web development che l'esecuzione di JavaScript (JS) può rallentare significativamente il caricamento e l'interattività delle pagine web. Spesso si riscontrano tempi di caricamento eccessivamente lunghi (a volte superiori ai 30 secondi) a causa di diversi fattori, tra cui:

• L'uso massiccio di plugin e librerie di terze parti, ognuno dei quali contribuisce al blocco del thread principale e richiede tempo per l'analisi (parsing) e l'esecuzione.
• L'integrazione di soluzioni di accessibility overlay (sovrapposizioni per l'accessibilità) che, per funzionare, spesso devono scansionare e manipolare dinamicamente il Document Object Model (DOM), un processo che consuma risorse e può effettivamente "ricreare" o modificare ampie porzioni della pagina dopo il caricamento iniziale.

Analogia in Sintesi: Questo processo è paragonabile a mettere un'auto in vetrina e doverla rimontare o riverniciare da capo ogni singola volta che entra un nuovo potenziale cliente anziché averla pronta per essere ammirata immediatamente.

Il risultato è un lag percettibile tra l'azione dell'utente e il feedback dello screen reader. In un'interfaccia visuale, solo 200ms di ritardo sono fastidiosi. Per chi usa uno screen reader, significa perdere il filo di dove si trova nella pagina, dover ripetere azioni e avere frustrazioni crescenti.

Le "magie" dell'AI che non funzionano

I widget "AI-powered" promettono di generare automaticamente alt text per le immagini usando tecnologie come computer vision. Sembra rivoluzionario, ma nella pratica:

Immagine: Una foto di un'insegnante che spiega la matematica a studenti in aula, con equazioni alla lavagna sullo sfondo.

Alt text generato dall'AI: "Persone in una stanza, lavagna"

Alt text utile: "Lezione di matematica: l'insegnante spiega equazioni quadratiche agli studenti del terzo anno"

L'AI non capisce il contesto, lo scopo dell'immagine, cosa è rilevante per l'utente, cosa intende comunicare l'autore. E soprattutto, non sa quando un'immagine è puramente decorativa e dovrebbe essere impostata con alt="".

La realtà legale: overlay come bandiera rossa

Qui i dati sono inequivocabili e devastanti.

Nel 2024, il 25% di tutte le cause per accessibilità digitale ha citato esplicitamente gli overlay come parte del problema, non come soluzione. Sono stati 1.023 casi su 4.187 totali. Gli avvocati specializzati in cause ADA sanno identificare i siti con overlay - usando tool come BuiltWith rendono banale trovare tutti i siti che usano accessiBe, UserWay, AudioEye ecc...

Alcune aziende hanno scoperto a proprie spese che:

1. Installano l'overlay credendo di essere protetti
2. Ricevono comunque una causa
3. Scoprono che l'overlay stesso viene citato nella denuncia come barriera aggiuntiva
4. Finiscono per pagare le spese legali e rimuovere l'overlay

Il caso accessiBe: quando l'FTC interviene

Nel 2025, la Federal Trade Commission ha multato accessiBe per €1 milione per pubblicità ingannevole. L'azienda ha dovuto ammettere che il suo widget:

• Non rendeva i siti conformi WCAG come promesso
• Conteneva recensioni false e pagate
• Faceva promesse non supportate realmente

L'ordine finale, approvato ad aprile 2025, proibisce all'azienda di affermare che i suoi prodotti automatizzati possono rendere qualsiasi sito conforme alle WCAG o garantire conformità nel tempo, a meno che non abbia prove concrete.

È la prima volta che un'agenzia federale statunitense interviene così pesantemente contro un vendor di overlay. Il messaggio è chiaro: le promesse miracolose non sono più accettabili.

Le class action si moltiplicano

A gennaio 2024, Tribeca Skin Care ha intentato una class action contro accessiBe. Nonostante pagasse per l'overlay, è stata comunque citata in giudizio da un utente non vedente. Quando ha chiesto supporto legale ad accessiBe (incluso nel servizio), le è stato richiesto l'upgrade a un abbonamento annuale. Anche dopo l'upgrade, il supporto si è limitato a una guida generica.

UserWay sta affrontando una situazione simile con Bloomsybox, che sostiene che l'overlay non solo non ha garantito conformità, ma in alcuni casi ha reso il sito più difficile da usare per persone con disabilità.

Il pattern è chiaro: gli overlay non offrono protezione legale. Anzi, possono aumentare l'esposizione al rischio.

Perché le aziende continuano a comprarli?

La risposta è comprensibile: disinformazione.

Molti dirigenti non hanno background tecnico in accessibilità. Quando vedono una soluzione che promette:

• "Conformità immediata"
• "Un plugin da €6/mese invece di un audit da €10.000"
• "Protezione legale inclusa"

...è naturale pensare: "Perché pagare di più?"

Il problema è che stanno confrontando mele con arance. Un overlay non è un'alternativa a un audit e correzione alla radice. È come confrontare un cerotto con una chirurgia: a volte va bene il cerotto, ma se hai bisogno della chirurgia, il cerotto non solo non aiuta, ma nasconde il problema.

La vera soluzione: accessibilità nativa

L'accessibilità reale si costruisce in quattro fasi:

1. Audit completo

Non un tool automatizzato che spunta checkbox, ma:

• Scansione automatizzata per identificare problemi evidenti
• Revisione manuale del codice da esperti
• Testing con tecnologie assistive
• Valutazione UX con focus su diverse disabilità
• Testing con utenti reali che hanno disabilità

Un audit serio costa tra €5.000 e €20.000+ a seconda della complessità del sito, ma fornisce una roadmap precisa di cosa va sistemato.

2. Remediazione strutturale

Affrontare i problemi alla radice. Ecco un esempio:

< !-- SBAGLIATO -- >
< div class="button" onclick="submit()" >
  < img src="/icon.png" >
< /div >

< !-- CORRETTO -- >
< button type="submit" aria-label="Invia modulo" >
  < svg aria-hidden="true" focusable="false" >
    < !-- icon SVG -- >
  < /svg >
< /button >

Questo significa:

• Refactoring del markup esistente
• Implementazione corretta di ARIA dove necessario (ma non in eccesso)
• Strutturazione semantica dei contenuti
• Gestione corretta del focus e della navigazione da tastiera
• Design accessibile fin dall'inizio

3. Formazione del team

Accessibility by design significa che:

• I designer creano mockup con sufficiente contrasto cromatico
• I developer scrivono markup semantico dalla prima riga
• I content creator forniscono contenuti accessibili
• Il QA testa con screen reader e navigazione da tastiera

4. Monitoraggio continuo

L'accessibilità non è un progetto con una data di fine. È un processo:

• Testing automatizzato e manuale
• Audit annuali completi
• Revisione di ogni nuovo componente
• Aggiornamento per nuove versioni WCAG
• Feedback e dialogo con utenti reali

Il ROI dell'accessibilità vera

Investire in accessibilità nativa non è solo etico e legalmente prudente. Ha un ROI misurabile:

SEO migliorato: Uno studio di SEMrush su 10.000 siti ha rilevato un aumento del 23% nel ranking SEO per siti conformi WCAG. Perché? Perché le stesse ottimizzazioni che aiutano gli screen reader aiutano i bot di Google: markup semantico, heading strutturati, testo alternativo, link descrittivi.

Mercato ampliato: milioni di persone hanno diverse disabilità, con un potere d'acquisto di centinaia di miliardi. È un mercato enorme che molte aziende ignorano.

Esperienza utente migliorata: Le best practice di accessibilità migliorano l'usabilità per tutti. Ad esempio, un contrasto sufficiente aiuta chi legge sotto il sole, la navigazione da tastiera aiuta quando non si riesce a usare il mouse, un testo di facile lettura aiuta chi non ha una laurea...

Riduzione del rischio legale: Le aziende che affrontano l'accessibilità seriamente, anche se non perfettamente (ad oggi non è ancora possibile), dimostrano il loro impegno. Quelle con overlay dimostrano di aver cercato la scorciatoia più economica.

Conclusione: non esistono scorciatoie

Il web è fondamentalmente accessibile. Il codice HTML semantico, correttamente usato, è già largamente accessibile. Il problema non è che l'accessibilità sia troppo complessa - è che abbiamo costruito layer di complessità (JavaScript framework, SPA, UI library) senza preservare l'accessibilità di base.

Gli overlay promettono di compensare anni di decisioni architetturali sbagliate con una riga di JavaScript. È una promessa impossibile da mantenere. Non puoi automatizzare la comprensione del contesto. Non puoi usare l'AI per capire l'intento dell'utente. Non puoi fare reverse-engineering di un'interfaccia complessa e renderla accessibile senza capirne la logica.

La vera accessibilità richiede:

• Investimento di tempo
• Competenza specializzata
• Commitment organizzativo
• Testing con utenti reali
• Manutenzione continua

È più costoso degli overlay? Nel breve termine, sì. Nel lungo termine, considerando cause evitate, brand reputation, e mercato ampliato, è l'unica scelta sensata.

E soprattutto: è l'unica scelta che rispetta veramente le persone con disabilità, invece di trattarle come un problema da risolvere con un plugin da €6/mese.