Abbiamo intercettato tutte le richieste provenienti da cinque strumenti di accessibilità. Ecco cosa fanno effettivamente al tuo sito.

Una verifica tecnica indipendente su quattro overlay di accessibilità e una soluzione dedicata esclusivamente al monitoraggio: cosa modificano effettivamente, cosa nascondono agli utenti con disabilità e perché, solo nel 2024, oltre 1.000 aziende che utilizzavano tali overlay sono state citate in giudizio.

Come abbiamo proceduto: la metodologia di ricerca

La maggior parte delle recensioni relative agli overlay per l'accessibilità si basa su affermazioni di marketing, sulla documentazione dei fornitori o su test superficiali. Abbiamo adottato un approccio radicalmente diverso: abbiamo intercettato ogni byte di dati che circolava tra il browser e i server di ciascuno strumento, abbiamo estratto i file di correzione JavaScript effettivi e i dati relativi alle correzioni, e abbiamo analizzato esattamente come ciascuno strumento agisce sul DOM in tempo reale dei siti e-commerce in produzione.

La configurazione tecnica

Abbiamo implementato mitmproxy – un proxy HTTPS open source – configurato per acquisire i corpi completi delle richieste e delle risposte di tutto il traffico diretto ai domini CDN e API degli strumenti. Abbiamo installato il certificato CA radice del proxy nel browser per consentire l'intercettazione HTTPS trasparente, quindi abbiamo avviato un'istanza dedicata di Chrome instradata esclusivamente attraverso il proxy. Abbiamo configurato dei filtri di dominio per acquisire solo il traffico diretto ai server degli strumenti di accessibilità, assicurandoci di analizzare esclusivamente ciò che questi strumenti inseriscono, e non il traffico proprio dei siti.

Abbiamo quindi navigato su 14 siti di e-commerce attivi proprio come farebbe un utente normale: caricando la pagina iniziale, passando alle pagine con l'elenco dei prodotti, visualizzando le pagine dei dettagli dei prodotti, aggiungendo articoli al carrello, procedendo al checkout, visitando le pagine dell'account e di registrazione e interagendo con finestre modali, caroselli e la funzione di ricerca. Ogni sessione di navigazione è stata acquisita come file HTTP Archive (HAR) con i corpi delle risposte completi: lo stesso formato utilizzato internamente dai browser, ma arricchito con il contenuto effettivo di ogni file JavaScript, ogni foglio di stile CSS, ogni configurazione JSON e ogni risposta API fornita dagli strumenti.

Una volta acquisiti i dati, abbiamo scritto degli script di analisi in Python che hanno analizzato il corpo di ogni risposta, classificato ogni file in base allo strumento e alla funzione, estratto ogni selettore CSS dalle definizioni delle correzioni, contato ogni modello di manipolazione del DOM nel codice JavaScript, identificato ogni caso in cui il contenuto era nascosto alle tecnologie assistive e mappato ogni correzione all'area della pagina su cui incide (cassa, carrello, elenco dei prodotti, navigazione, ecc.).

Il proxy ha acquisito 924 richieste HTTP con 579 corpi di risposta completi nel corso di tre sessioni di acquisizione, inclusi tutti gli script di correzione per sito, tutti i file JSON di correzione, tutti i file di configurazione e tutti i payload di analisi. Abbiamo inoltre salvato snapshot DOM completi delle pagine con le modifiche di overlay applicate, consentendoci di ispezionare i valori esatti di aria-label e gli attributi dei dati del fornitore inseriti in fase di esecuzione. Abbiamo quindi scritto script di analisi automatizzati per analizzare il JavaScript, contare ogni modello di modifica DOM, estrarre ogni selettore CSS, classificare ogni correzione per area della pagina e identificare ogni istanza di contenuto nascosto alle tecnologie assistive.

Cosa abbiamo analizzato

I siti riguardavano grandi catene di negozi di moda, marchi di cioccolato di lusso, produttori di valigie, negozi di borse firmate, aziende produttrici di giocattoli, un operatore di telecomunicazioni, una banca nazionale, marchi di bevande, articoli di cartoleria, orologi e dolciumi, coprendo sia il mercato dell'Unione Europea che quello statunitense.

Un'osservazione fondamentale: nessuna delimitazione a livello di pagina in nessuna sovrapposizione di accessibilità

Una delle scoperte più sorprendenti è emersa prima ancora di analizzare le regole di correzione: ogni overlay di accessibilità carica l'intero set di correzioni su ogni singola pagina, indipendentemente dal tipo di pagina. Le correzioni specifiche per il checkout vengono applicate sulla home page. Le regole relative alla quantità nel carrello vengono eseguite sulla pagina "Chi siamo". Le correzioni relative alle schede dei prodotti vengono applicate sul modulo di accesso.

Ciò significa che sul sito dell’operatore di telecomunicazioni ogni visitatore, su ogni pagina, scarica un file JSON da 1,25 MB contenente 4.974 descrizioni di immagini e 2.000 voci di correzione in formato PDF, anche su pagine prive di immagini. Sul sito del rivenditore di borse di marca, ad ogni caricamento della pagina vengono eseguite 383 regole di correzione DOM, nel tentativo di trovare corrispondenze con selettori che esistono solo su tipi di pagina specifici. Quando un selettore specifico per il checkout come #cardNumber non trova corrispondenza sulla homepage, il motore di correzione dell'overlay continua comunque a dedicare cicli di CPU alla sua valutazione; moltiplicato per centinaia di regole, questo crea uno spreco misurabile di prestazioni ad ogni visualizzazione della pagina.

La funzione "Overlay A" rileva solo il 4,5% delle sessioni

Analizzando i dati POST delle statistiche di Overlay A, abbiamo scoperto un campo che rivela la sua effettiva frequenza di campionamento della scansione:

Un tasso di campionamento dello 0,045% significa che solo il 4,5% delle sessioni dei visitatori attiva una scansione di conformità su questo sito di vendita al dettaglio di abbigliamento. Su un altro sito – un marchio di cioccolato di lusso – il tasso era ancora più basso: appena l'1,7%. È possibile che il fornitore della soluzione overlay esegua una scansione iniziale più completa durante la fase di onboarding o di configurazione, per poi ridurre il tasso di campionamento per il monitoraggio continuo. Tuttavia, le implicazioni per le operazioni quotidiane rimangono significative.

Il codice del pacchetto di avvio dell'overlay di accessibilità conferma l'esistenza di tre livelli operativi: ReleaseVersionReport (scansione completa + report – la percentuale campionata), ShadowVersionReport (scansione in background, nessuna azione visibile all'utente) e RunReleaseFixesNoReport (applicazione di tutte le regole di correzione senza eseguire alcuna scansione). Ciò significa che, durante il normale funzionamento, la stragrande maggioranza dei visitatori riceve modifiche al DOM che non vengono convalidate durante la loro sessione.

Il rischio concreto è il seguente: se l'implementazione di un sito modifica la struttura DOM e viola una o più regole di correzione, la bassa frequenza di campionamento comporta che il problema possa passare inosservato per un lungo periodo. Poiché viene analizzato solo l'1,7–4,5% delle sessioni, una correzione non funzionante potrebbe interessare migliaia di visitatori prima che la successiva sessione campionata si attivi sulla pagina interessata e segnali il problema. Durante quel lasso di tempo, ogni visitatore riceve correzioni obsolete o non mirate, e né il gestore del sito né il fornitore dell'overlay potrebbero essere a conoscenza del problema.

Risultati: correzione delle regole e delle modifiche al DOM

Overlay A: File di correzione JavaScript specifici per sito

Questo overlay gestisce un file di correzione JavaScript dedicato per ciascun sito cliente, contenente regole che prendono di mira specifici selettori CSS. Analizzando i cinque siti, abbiamo riscontrato che:

Abbiamo inoltre scoperto che 7 casi dove la stringa letterale "true" è stato somministrato per via aria-label – un errore di programmazione per cui è stato passato un valore booleano al posto di un testo descrittivo. Gli screen reader leggono «pulsante, vero» – un messaggio del tutto privo di senso. Su un altro sito, la parola «Search» era stata scritta erroneamente come «Seacrh» in un'etichetta inserita.

Overlay B: Testo alternativo generato dall'intelligenza artificiale su larga scala

Questo overlay scarica file JSON di grandi dimensioni contenenti descrizioni delle immagini generate dall'intelligenza artificiale. Su tre siti:

Esempi reali tratti dai dati di bonifica:

323 descrizioni superavano i 125 caratteri, causando una lettura eccessivamente dettagliata da parte dello screen reader, che si protraeva per 10-15 secondi per ogni immagine. 156 iniziavano in modo ridondante con «immagine di», un anti-modello WCAG poiché gli screen reader annunciano già il tipo di elemento.

Strumento di monitoraggio: nessuna modifica – verificato nel codice sorgente

Cosa significa "Nascondi da AT" per gli utenti reali

Quando un overlay nasconde un elemento alle tecnologie assistive, l'elemento rimane visibile sullo schermo ma diventa completamente invisibile agli screen reader. Abbiamo classificato ogni elemento nascosto in base all'area della pagina che interessa:

Dati ricavati dai file di correzione active.js effettivi per ciascun sito, estratti tramite mitmproxy. Ogni conteggio rappresenta un selettore CSS univoco a cui si rivolge la funzione hideFromAT().

Nella pagina di pagamento di un negozio di articoli di lusso, gli elementi nascosti agli screen reader includevano:

Ecco come gli strumenti di sovrapposizione per l'accessibilità creano un'esperienza di acquisto a due livelli: gli utenti vedenti vedono tutte le opzioni di pagamento e possono scegliere tra carta di credito, PayPal, Amazon Pay, Shop Pay e Klarna. Gli utenti non vedenti, invece, possono visualizzare solo i metodi di pagamento che la sovrapposizione non ha nascosto. Su un sito di vendita al dettaglio di abbigliamento, sia il campo per l'inserimento della quantità nel carrello che il pulsante di aggiornamento erano nascosti: un utente non vedente poteva aggiungere articoli ma non modificare le quantità.

Ciò solleva una domanda fondamentale: un overlay che nasconde i pulsanti di pagamento agli utenti non vedenti rende il sito più accessibile o meno accessibile?

Impatto sulle prestazioni

Cosa succede dopo l'implementazione di un sito

Forse il rischio più insidioso degli strumenti di overlay diventa evidente solo col passare del tempo: le correzioni si deteriorano silenziosamente. A differenza di un errore JavaScript che causa un crash visibile o di un layout danneggiato che qualcuno nota, una correzione di overlay obsoleta non genera alcun errore, nessun avviso e nessun cambiamento visivo. Semplicemente smette di funzionare – e la barriera all’accessibilità che nascondeva riappare senza che nessuno se ne accorga.

Per capirlo, considera come ogni tipo di overlay si integra con la struttura DOM del tuo sito.

Soluzioni basate sul selettore: il tempo stringe

Overlay A – come la maggior parte delle soluzioni di overlay per l'accessibilità – gestisce file di correzione JavaScript specifici per ogni sito contenenti regole come questa (ricostruita a partire dal codice effettivamente acquisito):

Questa regola si applica al pulsante con la freccia indietro di un carosello Slick utilizzando tre classi CSS: .js-recommendation_carousel, .slick-prev, e .slick-arrow. Ogni parte di questo selettore è vulnerabile. Se il team responsabile del sito rinomina la classe del contenitore del carosello, passa da Slick a Splide o Swiper, o semplicemente aggiorna la libreria Slick a una versione che modifica la convenzione di denominazione delle classi, il selettore non trova più alcuna corrispondenza. Il pulsante perde l'etichetta «Diapositiva precedente». Gli utenti di lettori di schermo non sono più in grado di identificarlo.

Nei cinque siti che abbiamo analizzato per l'Overlay A, abbiamo riscontrato Il 98% di tutti i selettori contiene nomi di classi specifici del framework – classi precedute da .js-, .b-, .chakra-, .splide__, oppure hash CSS-in-JS come .css-acuo7n. Non si tratta di identificatori semantici stabili, bensì di dettagli di implementazione che cambiano ad ogni aggiornamento del framework, rifattorizzazione dei componenti o modifica del sistema di compilazione.

In un negozio online di borse di marca abbiamo individuato selettori che puntano a componenti dell’interfaccia utente Chakra. Le versioni principali di Chakra UI introducono modifiche compatibilità – i nomi delle classi, la struttura dei componenti e i modelli ARIA subiscono tutti un’evoluzione. Quando questo sito aggiorna Chakra, potenzialmente centinaia di regole di correzione dell’overlay smetteranno di funzionare senza alcun avviso. Il fornitore dell'overlay deve quindi verificare manualmente la nuova struttura DOM, riscrivere ogni selettore interessato e distribuire i file di correzione aggiornati. Durante l'intervallo tra la distribuzione del sito e l'aggiornamento del fornitore dell'overlay, il sito funziona con correzioni obsolete: alcune non fanno nulla, altre potrebbero applicarsi agli elementi sbagliati.

Correzioni basate sull'URL: ancora più instabili

Sovrapponi le chiavi JSON di correzione di B a ogni voce di testo alternativo, sostituendole con l'URL esatto della fonte dell'immagine. Abbiamo trovato voci come:

Notate la vulnerabilità: l'URL contiene un ID del dispositivo (13555), una dimensione della miniatura (86x86), e un nome file che includa il nome del prodotto. Ognuno di questi elementi può variare in modo indipendente. Se il CMS rigenera le miniature con dimensioni diverse, il thumb_86x86 una parte dell'URL cambia e la voce non corrisponde più. Se il team di prodotto carica una nuova foto con un nome file diverso, la voce rimane orfana. Se il sito trasferisce i propri file multimediali su un CDN con un dominio diverso, ogni singola voce nel file JSON da 1,17 MB diventa un peso morto – e tutte le immagini del sito perdono contemporaneamente il testo alternativo.

Lo scenario peggiore è un errore di corrispondenza parziale: alcune immagini mantengono i loro vecchi URL (e ricevono il testo alternativo), mentre quelle nuove o aggiornate non trovano alcuna corrispondenza (e non ricevono nulla). Il risultato è un'esperienza incoerente in cui alcune immagini vengono descritte mentre altre vengono ignorate senza alcun avviso – il che risulta molto più fonte di confusione per un utente di screen reader rispetto alla semplice assenza del testo alternativo.

Correzioni a livello globale: il problema della cascata

L'approccio di Overlay C: associare un MutationObserver all'intero documento e applicare correzioni generiche a tutti gli elementi di determinati tipi (a, button, input, img, h1) – crea un modello di interruzione diverso ma altrettanto pericoloso. Anziché fallire silenziosamente quando i selettori diventano obsoleti, questa sovrapposizione lavora attivamente al nuovo codice.

Consideriamo uno scenario comune: il team del sito implementa un nuovo componente di finestra modale accessibile che implementa correttamente il focus trapping, la chiusura tramite tasto Esc e gli attributi ARIA. Il MutationObserver dell’overlay rileva i nuovi elementi DOM, li valuta in base alle proprie regole generiche e, individuando elementi che corrispondono ai propri modelli, applica la propria gestione del focus, i propri gestori di tastiera e i propri attributi ARIA sopra l’implementazione esistente e corretta del componente. Il risultato è un focus a doppio trapping, gestori di tastiera duplicati e attributi ARIA in conflitto. Il modale che funzionava perfettamente prima del caricamento dell'overlay ora si comporta in modo irregolare.

Non si tratta di una questione puramente teorica. Le librerie di componenti framework come Radix UI, Headless UI e Chakra UI dedicano notevoli risorse ingegneristiche alla corretta implementazione di ARIA. Un overlay che applica in modo indiscriminato i propri attributi ARIA a tutti button e a è probabile che Elements entri in conflitto con queste implementazioni collaudate, rendendo i componenti non correttamente accessibili meno accessibile.

Lo strumento di monitoraggio: niente da rompere

Lo strumento di monitoraggio che abbiamo analizzato non prevede correzioni basate su selettori, voci legate a URL, MutationObserver né il targeting generico degli elementi. Quando il sito implementa nuovo codice, la scansione successiva dello strumento di monitoraggio valuta automaticamente il nuovo DOM rispetto al set di regole standardizzate di axe-core e segnala eventuali nuove violazioni, senza modificare nulla. I risultati della scansione vengono visualizzati nella dashboard dello strumento con i livelli di gravità, il numero di elementi interessati e gli ID standardizzati delle regole WCAG. Gli sviluppatori esaminano i risultati e implementano le correzioni nel proprio codice, dove queste vengono sottoposte a revisione, test automatizzati, validazione in ambiente di staging e distribuzione controllata.

Questo processo è intrinsecamente resiliente ai cambiamenti: lo strumento analizza il DOM presente al momento della scansione, segnala i problemi rilevati e riparte da zero alla scansione successiva. Non vi è alcun debito tecnico accumulato legato alle definizioni delle correzioni, né selettori obsoleti, né voci di testo alternativo orfane, né alcuna possibilità di applicare la correzione sbagliata all'elemento sbagliato.

Cosa si rompe quando si esegue una nuova distribuzione

Ogni correzione dell'overlay di accessibilità è legata alla struttura DOM attuale del sito. Abbiamo riscontrato che Il 98% dei selettori di un overlay punta a nomi di classi specifici del framework – classi come .chakra-, .splide__, .js-, .b-, e gli hash CSS-in-JS come .css-acuo7n che cambiano ad ogni compilazione.

Lo strumento di monitoraggio riporta "Non interessato" in ogni riga perché non contiene alcuna correzione basata sui selettori. Non c'è nulla che possa diventare obsoleto, nulla che possa puntare all'elemento sbagliato, nulla che possa causare un malfunzionamento.

Il GDPR, la privacy e il problema del consenso

La nostra analisi ha confermato che tre dei quattro overlay di accessibilità inviano dati a server esterni prima ancora che sia possibile interagire con qualsiasi banner di consenso:

In base alla sentenza della Corte di giustizia dell'Unione europea (CGUE) nel caso Planet49, il tracciamento non essenziale richiede il consenso preventivo esplicito. Due overlay inviano identificatori persistenti già alla prima richiesta di rete, prima ancora che possa attivarsi qualsiasi meccanismo di consenso. Per i siti rivolti all'UE, ciò costituisce automaticamente una violazione del GDPR.

Il quadro giuridico

Nell’aprile 2025, la Commissione Federale per il Commercio degli Stati Uniti (FTC) ha concluso un accordo transattivo da 1 milione di dollari nei confronti di uno dei fornitori di soluzioni di accessibilità oggetto del nostro studio, per aver dichiarato in modo fuorviante che il proprio strumento basato sull’intelligenza artificiale fosse in grado di rendere qualsiasi sito web conforme alle WCAG. La FTC ha riscontrato che lo strumento non riusciva a rendere accessibili i componenti di base dei siti web – menu, intestazioni, tabelle, immagini e registrazioni. In un esempio citato, una foto di filet mignon ha ricevuto la descrizione generata dall'IA: "Pane integrale su piatto di ceramica bianca".

Secondo i dati di monitoraggio del settore, nel 2024 il 25% di tutte le cause legali in materia di accessibilità digitale ha citato esplicitamente i widget overlay come ostacoli, non come soluzioni. Nella prima metà del 2025, le cause legali contro le aziende che utilizzano gli overlay hanno continuato a superare le 100 al mese. Due dei fornitori di overlay oggetto del nostro studio sono stati direttamente coinvolti in contenziosi: uno in tre casi distinti relativi a brevetti/segreti commerciali e un altro in una causa collettiva intentata da un cliente di piccole dimensioni che è stato citato in giudizio nonostante utilizzasse l'overlay.

Lo strumento di monitoraggio oggetto del nostro studio non ha mai dato luogo a contenziosi legati a problemi di accessibilità: una conseguenza logica della sua architettura, poiché, non modificando mai il DOM, non può creare barriere all'accessibilità.

Dietro le quinte del codice: cosa modificano effettivamente gli overlay

Per comprendere la portata della manipolazione del DOM, abbiamo contato tutti i modelli di modifica presenti nel codice JavaScript di ciascun strumento. Le differenze sono notevoli:

L'overlay C merita particolare attenzione. Il suo pacchetto monolitico da 794 KB include un MutationObserver a document.documentElement con la configurazione {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Ciò significa ogni singola modifica al DOM nell'intera pagina – che provenga dalla riconciliazione del DOM virtuale di React, da uno script di test A/B, da un widget di chat o dal codice JavaScript del sito stesso – attiva l'osservatore dell'overlay, il quale provvede quindi a rivalutare e, potenzialmente, a riapplicare le proprie correzioni. Dopo una nuova distribuzione del sito, ciò genera una cascata di tentativi di correzione su elementi che potrebbero essere già correttamente accessibili, sovrascrivendo potenzialmente gli attributi ARIA corretti con quelli errati.

Abbiamo verificato che l'Overlay C invia USER-BEHAVIOR-ANALYTICS Richieste POST al proprio ricevitore di log, con payload contenenti il dominio del sito, la versione del widget, la lingua dell'utente e gli eventi di interazione. In combinazione con localStorage persistenza e identificazione dei dispositivi tramite navigator.userAgent e navigator.maxTouchPoints, ciò rappresenta un'operazione di trattamento dei dati di cui la maggior parte dei gestori di siti non è a conoscenza.

Il problema del JSON di correzione

Overlay B scarica un file JSON di grandi dimensioni (fino a 1,17 MB per un sito di telecomunicazioni) contenente tutte le definizioni delle correzioni. Su un sito, abbiamo osservato che veniva scaricato quattro volte in una singola sessione di navigazione: 4,7 MB di larghezza di banda per un file che avrebbe dovuto essere memorizzato nella cache. Il JSON contiene 11 categorie, ma la stragrande maggioranza sono descrizioni di immagini generate dall'intelligenza artificiale: 4.974 su 6.975 voci per un sito. Ciascuna è associata a un URL di immagine specifico: quando il CMS rinomina un file, modifica le dimensioni delle miniature o migra i domini CDN, le voci smettono silenziosamente di corrispondere. Le immagini sostitutive non ricevono alcun testo alternativo, rendendo la pagina meno accessibile rispetto a prima dell'installazione dell'overlay.

Questo overlay implementa anche moduli di runtime che riscrivono attivamente la pagina: un motore di correzione da 110 KB, un componente ausiliario per il menu di navigazione da 23 KB che riorganizza la gestione del menu tramite tastiera, una patch per il carosello da 5,8 KB e uno scanner lato client da 53 KB che utilizza una logica proprietaria anziché il motore axe-core, standard del settore – il che significa che i suoi risultati non possono essere verificati in modo indipendente.

La copertura più trasparente – ma comunque rischiosa

L'overlay D presentava l'architettura più trasparente: file di configurazione JSON di facile lettura con opzioni di attivazione/disattivazione esplicite. Opzioni come addAriaHidden, overwriteAlt, e adjustMetaViewport sono stati impostati esplicitamente su false. Tuttavia, il motore sottostante (649 KB) contiene 216 setAttribute chiamate, 47 aria-hidden riferimenti, 282 addEventListener iscrizioni e 9 MutationObserver casi. Il motore supporta modifiche aggressive al DOM anche se la configurazione attuale è prudente: una modifica alla configurazione da parte del fornitore potrebbe attivare funzionalità rischiose all'insaputa del gestore del sito.

Abbiamo individuato selettori per sito contenenti suffissi hash generati da JavaScript come button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 che cambiano ad ogni nuova versione, e i selettori di URL dei social media che diventano obsoleti quando il sito aggiorna i propri link a Facebook o Instagram.

La legge europea sull'accessibilità: perché gli overlay non soddisfano i requisiti dell'EAA

A partire dal 28 giugno 2025, l’Atto europeo sull’accessibilità (EAA) impone che i prodotti e i servizi digitali venduti nell’UE soddisfino gli standard di accessibilità in linea con la norma EN 301 549, che fa riferimento alle WCAG 2.1 AA. A differenza dell'ADA – che viene applicata principalmente attraverso azioni legali private – l'EAA è applicata dalle autorità nazionali di vigilanza del mercato, che hanno il potere di infliggere multe, ordinare misure correttive e ritirare dal mercato i prodotti non conformi.

Il rifiuto ufficiale da parte della Germania degli strumenti di sovrapposizione

La Germania ha assunto la posizione normativa più chiara tra tutti i paesi in materia di overlay per l'accessibilità. Il BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – l'organismo federale tedesco di controllo per l'accessibilità delle tecnologie dell'informazione – insieme a tutti gli organismi di controllo a livello regionale, ha pubblicato una valutazione congiunta in cui respinge esplicitamente l'uso degli strumenti di overlay ai fini della conformità alle norme di accessibilità:

Il 12 marzo 2025, il Comitato per le tecnologie dell'informazione senza barriere (Ausschuss für barrierefreie Informationstechnik, istituito ai sensi dell'articolo 5 del BITV 2.0) ha ribadito questa posizione nella sua seduta, esprimendo preoccupazione per il fatto che gli enti pubblici continuino a cercare di adempiere ai propri obblighi in materia di accessibilità ricorrendo a strumenti di overlay. Il comitato ha concluso che «una visualizzazione temporaneamente accessibile di un sito web tramite software – eventualmente solo dopo che l’utente ha configurato le impostazioni – per la durata della sua visita non soddisfa i requisiti delle disposizioni di legge applicabili».

Il comitato ha espressamente avvertito che gli enti pubblici che utilizzano strumenti di overlay rischiano di rendere i propri siti web meno accessibili anziché più accessibili, determinando un peggioramento dell'accessibilità («Verschlechterung der Barrierefreiheit»). Ciò riflette direttamente la nostra constatazione tecnica secondo cui il 26% delle regole di correzione tramite overlay introduce nuove violazioni delle WCAG.

Sigillo di verifica BIK: negato ai siti web che utilizzano overlay

La rete di certificazione BIK tedesca – gli organismi accreditati che valutano i siti web in base alle norme BITV 2.0, EN 301 549 e WCAG 2.1 AA – ha adottato una misura operativa: i siti web che utilizzano strumenti di overlay non possono ottenere il marchio di certificazione BIK. Gli organismi di test hanno dichiarato di non poter effettuare una valutazione di conformità affidabile in presenza di un overlay, poiché quest'ultimo modifica il DOM durante l'esecuzione in modi che rendono inaffidabili i risultati del test. Il sigillo BIK è ampiamente utilizzato in Germania come prova della conformità alla BITV 2.0 – e ora non è più disponibile per nessun sito web che utilizzi un overlay.

Non si tratta di una questione teorica di natura normativa. Ciò significa che un sito di e-commerce tedesco che utilizzi una qualsiasi delle quattro sovrapposizioni da noi testate non può ottenere la certificazione di conformità standard utilizzata sul mercato tedesco.

Conferma a livello europeo

Questa posizione normativa va oltre i confini della Germania. Nel 2023 il Forum europeo sulla disabilità e l’Associazione internazionale dei professionisti dell’accessibilità hanno rilasciato una dichiarazione congiunta in cui avvertono che gli overlay di accessibilità non rendono i siti web accessibili né conformi alla legislazione europea in materia, compresa la legge europea sull’accessibilità. Anche la Commissione europea si è espressa in merito alle dichiarazioni di conformità relative agli overlay, concludendo che questi ultimi non possono garantire la conformità alle norme applicabili.

Ai sensi della legge tedesca BFSG (Barrierefreiheitsstärkungsgesetz – la trasposizione tedesca dell’EAA, in vigore dal 28 giugno 2025), le autorità di vigilanza sul mercato possono infliggere sanzioni pecuniarie comprese tra 10.000 e 100.000 euro per ogni violazione. La valutazione del BFIT-Bund e il rifiuto della rete di test BIK di certificare i siti che utilizzano overlay significano di fatto che gli strumenti di overlay non offrono alcuna copertura normativa in Germania e possono addirittura aumentare il rischio di azioni di contrasto.

Sicurezza e rischi della catena di approvvigionamento

Ogni strumento di overlay funziona inserendo codice JavaScript di terze parti nell'ambito globale delle pagine di produzione. Questo codice JavaScript viene eseguito con gli stessi privilegi del codice proprio: può leggere e modificare qualsiasi elemento DOM, intercettare l'invio dei moduli, accedere ai cookie, reindirizzare gli utenti ed estrarre dati. Le implicazioni di sicurezza di questa configurazione sono significative e spesso vengono trascurate.

La superficie di attacco

Consideriamo la catena di fornitura: quando si integra un componente di accessibilità nel proprio sito, si concede a un fornitore terzo un accesso in scrittura continuo e illimitato al DOM di produzione attivo. Il CDN del fornitore distribuisce il codice JavaScript, il team del fornitore si occupa della manutenzione del codice e la pipeline di distribuzione del fornitore invia gli aggiornamenti direttamente al sito, senza alcuna revisione del codice, senza alcun processo di controllo qualità e senza alcuna approvazione da parte vostra.

Se la CDN del fornitore dell'overlay viene compromessa, l'autore dell'attacco acquisisce la capacità di iniettare codice dannoso in ogni sito che utilizza tale overlay. Se un dipendente del fornitore distribuisce un aggiornamento difettoso, tutti i siti dei clienti ne risentono contemporaneamente. Se l'endpoint API del fornitore viene dirottato, il file JSON di correzione o i dati di configurazione forniti al tuo sito possono essere manipolati per modificare i campi dei moduli, reindirizzare i link o inserire contenuti di phishing.

L'entità di questo rischio è direttamente proporzionale all'impronta DOM dell'overlay:

L'overlay B presenta la superficie di rischio più ampia della catena di fornitura: 228 chiamate API per sessione su 3 domini esterni, con un payload JSON di 1,17 MB che definisce come deve essere modificato il DOM. Una risposta API compromessa potrebbe istruire il motore di correzione a inserire contenuti arbitrari in qualsiasi elemento della pagina. Il bundle monolitico da 1.285 KB dell'overlay C è il payload JavaScript singolo più grande e, poiché è minificato e offuscato, né il gestore del sito né un revisore della sicurezza possono esaminare in modo significativo ciò che esegue in fase di esecuzione.

Conformità allo standard PCI DSS: un conflitto diretto

Per qualsiasi sito di e-commerce che gestisce pagamenti con carta di credito, la conformità allo standard PCI DSS non è facoltativa. Inoltre, dai nostri risultati emerge un conflitto diretto tra l'architettura degli strumenti di overlay per l'accessibilità e i requisiti dello standard PCI DSS.

Il requisito 6.4.3 dello standard PCI DSS (introdotto nella versione 4.0 dello standard PCI DSS, obbligatorio a partire dal 31 marzo 2025) prevede che tutti gli script delle pagine di pagamento caricati ed eseguiti nel browser dell'utente siano gestiti come segue: occorre implementare una procedura per verificare l'autorizzazione di ciascuno script, garantire l'integrità di ciascuno script e mantenere un inventario di tutti gli script corredato di una motivazione scritta che ne giustifichi la necessità.

La nostra analisi ha confermato che le regole di correzione degli overlay prendono di mira in modo mirato gli elementi DOM delle pagine di pagamento su diversi siti:

Non si tratta di un rischio teorico: si tratta di regole concrete che abbiamo individuato nei siti di produzione, dove vengono attivamente modificati i campi relativi ai numeri delle carte di credito, i selettori dell'indirizzo di fatturazione, i pulsanti dei fornitori di servizi di pagamento e i contenitori dei moduli di checkout. Ai sensi della norma PCI DSS 6.4.3, ciascuno di questi script di terze parti richiede un'autorizzazione documentata, una verifica dell'integrità e una giustificazione scritta.

Pensa a cosa può fare lo script di un fornitore di overlay sulla tua pagina di checkout:

Lo strumento di monitoraggio, al contrario, non ha alcuna capacità di scrittura nel DOM. Il suo script da 4,2 KB non può modificare i campi dei moduli, non può intercettare gli eventi di input e non può accedere né alterare gli elementi della procedura di checkout. Anche se la CDN del fornitore dello strumento di monitoraggio venisse compromessa, l’autore dell’attacco otterrebbe l’accesso a uno script in grado solo di leggere l’URL della pagina e il tipo di dispositivo, non a uno in grado di riscrivere il modulo di checkout. Ai fini della definizione dell’ambito di applicazione dello standard PCI DSS, lo strumento di monitoraggio non crea alcuna superficie di rischio aggiuntiva sulle pagine di pagamento.

La questione della discriminazione

Questo è il problema della discriminazione che sta alla base di ogni soluzione di accessibilità: l'aspetto più preoccupante non è un difetto tecnico, bensì una pratica sistematica che nega agli utenti con disabilità l'accesso a funzionalità che gli utenti vedenti danno per scontate.

Quando un overlay nasconde il pulsante Amazon Pay dall'albero di accessibilità, un utente non vedente vede meno opzioni di pagamento rispetto a un utente vedente. Quando il campo per l'inserimento della quantità nel carrello è nascosto, un utente non vedente non può modificare il proprio ordine. Quando i link dei risultati di ricerca sono nascosti, la ricerca dei prodotti risulta compromessa. Quando le valutazioni a stelle sono nascoste, un utente non vedente non può valutare la qualità dei prodotti come fa un utente vedente.

Non si tratta di casi isolati: sono i flussi di lavoro fondamentali dell’e-commerce a essere compromessi proprio dagli strumenti che promettono di renderli accessibili.

La comunità delle persone con disabilità lo sottolinea da anni. Il documento informativo sugli overlay – firmato da centinaia di professionisti dell’accessibilità – avverte che gli overlay di accessibilità «non correggono il codice HTML sottostante» e «spesso ostacolano attivamente le persone con disabilità». La nostra analisi tecnica ne fornisce la prova: 141 elementi funzionali nascosti agli screen reader, 7 etichette prive di significato inserite e 5.066 descrizioni AI non revisionate implementate in produzione – in soli 14 siti.

Per i gestori dei siti, la questione non è se gli overlay siano «sufficientemente validi», bensì se sia giustificabile l'utilizzo di uno strumento che crea un'esperienza a due livelli: una versione per gli utenti vedenti, che beneficiano di tutte le funzionalità, e una versione filtrata, incompleta e talvolta priva di senso per gli utenti con disabilità.

Impatto sulla conformità all'ADA: queste correzioni sono davvero utili?

La promessa fondamentale di ogni overlay è quella di migliorare la conformità alle linee guida ADA risolvendo le violazioni delle WCAG durante l'esecuzione. Tuttavia, la nostra analisi rivela un paradosso preoccupante: una percentuale significativa di correzioni apportate dagli overlay introduce attivamente nuove violazioni delle WCAG proprio mentre cerca di risolvere quelle esistenti.

Abbiamo associato ogni regola di correzione rilevata nell'Overlay A al criterio di successo specifico delle WCAG 2.1 a cui si riferisce. Delle 776 regole che è stato possibile associare, i risultati si dividono in due categorie: correzioni che risolvono effettivamente un problema relativo alle WCAG e correzioni che, nel farlo, generano una nuova violazione delle WCAG.

A dire il vero, tre quarti delle correzioni segnalate rappresentano dei veri e propri miglioramenti: l'aggiunta di etichette mancanti ai pulsanti, la correzione delle gerarchie dei titoli, la rettifica degli attributi di completamento automatico e l'implementazione di meccanismi di blocco del focus nei modal. Il restante quarto, invece, è decisamente dannoso, e il danno ricade in modo sproporzionato proprio sugli utenti che lo strumento sostiene di aiutare.

In che modo ogni modello a rischio viola le WCAG

Il problema non è solo che queste soluzioni non funzionano, ma che introducono violazioni di specifici criteri di successo delle WCAG che non esistevano prima dell’applicazione dell’overlay. In una causa legale ai sensi dell’ADA, un perito del ricorrente può indicare queste violazioni causate dall’overlay come prova del fatto che il sito discrimina le persone con disabilità.

Sovrapposizione B: testo alternativo generato dall'IA e WCAG 1.1.1

Le WCAG 1.1.1 richiedono che i contenuti non testuali abbiano un «testo alternativo che svolga la stessa funzione». Un testo alternativo generato dall'intelligenza artificiale che descrive il logo di un'azienda come "un segno blu e giallo" non serve allo scopo equivalente: lo scopo di un logo è l'identificazione del marchio, non la descrizione del colore. Un testo alternativo come "testo" per un banner promozionale, o "città" per un'immagine hero, non soddisfa lo stesso criterio in modo diverso: è talmente vago da risultare inutile.

Dei 5.068 testi alternativi generati dall'IA che abbiamo raccolto da Overlay B, 241 contenevano meno di 15 caratteri (troppo vaghi per essere utili), 323 superavano i 125 caratteri (violando le migliori pratiche per l'usabilità con gli screen reader) e 156 iniziavano con «immagine di» o «foto di» (ridondante poiché gli screen reader annunciano già il tipo di elemento). Solo 2 erano stati approvati da un revisore umano.

In base agli standard processuali dell'ADA, un esperto di accessibilità chiamato dal ricorrente segnalerebbe questi casi come violazioni del criterio WCAG 1.1.1 – il criterio più comunemente citato nelle cause legali relative all'accessibilità web ai sensi dell'ADA. L'overlay non risolve la violazione; sostituisce semplicemente una forma di non conformità (mancanza del testo alternativo) con un'altra (testo alternativo impreciso o vago), creando al contempo un falso senso di conformità per il gestore del sito.

Overlay B: Inserimento di etichette nei moduli durante l'esecuzione – quando il tentativo di "risolvere" il problema lo aggrava

Beyond the consolidated JSON, Overlay B runs a 110 KB remediation engine (remediation-tool.js) that performs 24 distinct DOM mutation rules at runtime on every page load. One of these rules – the EmptyControls handler – targets unlabeled form fields and attempts to inject accessible names by finding nearby <label> elements.

The mechanism works as follows: for each form control without an accessible name, the engine calls a label-finder function that searches for <label for=”id”> elements matching the input’s ID. If found, it injects the label’s text content as an aria-label:

We verified this behavior on a live site – a web agency’s contact page with six form fields. The original HTML had visible labels (“First Name”, “Company Name”, “Last Name”, “Work Email”, “Phone Number”, “Message”) but they were not programmatically associated with their inputs via <label for> or aria-label. Without the overlay, a screen reader would announce each field with no name at all.

Con il motore di correzione di Overlay B attivo, uno screen reader ha annunciato:

We verified this by examining the saved HTML source with the overlay’s modifications baked in. Every modified element carries a vendor-specific data-*-form=”fx” attribute – the overlay’s own marker confirming it injected the aria-label. The original HTML has <label> elements with correct text (“First Name”, “Last Name”, “Work Email”, etc.) but they have no for attribute and the inputs are not nested inside the labels – so there is no programmatic association. The overlay’s label-finder function only looks for label[for=id], and since the inputs have no id attribute at all, it returns null for every field. The engine then falls back to constructing labels from the name attribute (“first-name” → “Name”, “last-name” → “Name”), input validation type (“email” → “Please enter email address”), or the raw element type (“text” → “Text field”, “select” → “Single select”, “textarea” → “Text area”).

Il risultato è peggiore rispetto al modulo originale privo di etichette. Prima dell’overlay, un utente di uno screen reader si trovava di fronte a sette campi senza etichetta: una situazione confusa, ma almeno coerente. Poteva ricorrere all’ordine di tabulazione e al contesto per indovinare a quale campo corrispondesse ciascuno. Dopo l'intervento dell'overlay, l'utente si trova di fronte a due campi con la stessa etichetta ("Nome" sia per il nome che per il cognome), due campi con etichette inventate in stile convalida che non corrispondono al testo visibile e tre campi con nomi privi di significato basati sul tipo. L'etichettatura parziale e errata è più disorientante della totale assenza di etichette, perché crea la falsa impressione che il modulo sia stato reso accessibile quando i campi critici rimangono senza etichetta o con etichette errate.

Questo risultato mette in luce anche un punto debole nel JSON di correzione dell'Overlay B. Il JSON conteneva 87 voci di testo alternativo generate dall'IA e zero voci di correzione dei moduli per questo sito. L'inserimento dell'etichetta del modulo avviene interamente in fase di esecuzione tramite il gestore di regole EmptyControls: non è visibile nel JSON di correzione consolidato, non viene monitorato in nessuna dashboard che l'operatore del sito possa controllare e non è soggetto ad approvazione umana. L'operatore del sito non ha modo di sapere che il proprio modulo di contatto è stato etichettato in modo errato a meno che non lo testi personalmente con uno screen reader.

The remediation engine’s 24 rule handlers collectively perform: aria-label injection on form fields, links, images, and dialogs; aria-hidden toggling; role modification (heading, presentation, menuitem, button, img); tabindex injection to make non-interactive elements focusable; alt text from the AI JSON; style overrides to make hidden elements visible; aria-required injection; aria-describedby associations between fields and error messages; heading text rewrites; broken link URL corrections; <meta viewport> modification; and <html lang> changes. All of this executes at runtime in the visitor’s browser on every page load – none of it is visible in the consolidated remediation JSON.

L'effetto netto della conformità all'ADA

Il problema fondamentale è che gli strumenti di overlay confondono la copertura con la conformità. Un overlay può indicare 1.058 correzioni e affermare di soddisfare oltre 40 criteri di successo delle WCAG. Tuttavia, quando il 26% di tali correzioni introduce nuove violazioni – tra cui non conformità di Livello A causate dall’occultamento di elementi funzionali – il livello netto di conformità potrebbe risultare peggiore rispetto a quello del sito non modificato.

Un sito privo di overlay che presenta 50 violazioni delle WCAG si trova in una posizione giuridica più chiara rispetto a un sito con overlay che presenta 30 violazioni originarie più 203 violazioni introdotte dall'overlay, poiché queste ultime dimostrano che il gestore del sito ha implementato uno strumento che discrimina attivamente gli utenti con disabilità, il che compromette qualsiasi difesa basata sulla buona fede.

In conclusione