← Blog NormHarbor

Gli overlay per l'accessibilità ti rendono conforme? Cosa significa il caso FTC contro accessiBe

I widget overlay promettono conformità istantanea con una sola riga di codice. Ecco cosa fanno davvero, cosa non possono fare, e perché i regolatori hanno iniziato a reagire.

Cos'è un overlay per l'accessibilità?

Un overlay per l'accessibilità è un widget JavaScript di terze parti — prodotti come accessiBe, UserWay e AudioEye sono gli esempi più noti — che aggiungi al tuo sito con un singolo frammento di codice. Viene eseguito nel browser e cerca di modificare la pagina al volo: aggiungendo attributi ARIA, generando testo alternativo per le immagini, modificando il contrasto o offrendo una barra degli strumenti flottante con controlli per dimensione del testo e movimento.

La promessa è allettante: nessun tempo di sviluppo, nessuna revisione del codice, installi una volta e (secondo il marketing) diventi accessibile e legalmente conforme. È proprio questa promessa ad aver attirato l'attenzione dei regolatori.

Cosa possono fare davvero gli overlay

In tutta onestà, gli overlay non sono inutili. Uno ben costruito può offrire reali comodità per l'utente: dimensione del testo e interlinea regolabili, un interruttore per ridurre il movimento, una modalità ad alto contrasto o un contorno del focus più visibile. Alcune di queste funzioni aiutano davvero alcuni utenti, e non c'è nulla di sbagliato nell'offrirle come aggiunta a un sito già accessibile.

Ciò con cui faticano è tutto ciò che richiede di comprendere il significato e la struttura reale del tuo contenuto — che è la maggior parte di ciò che la conformità WCAG richiede.

Cosa non possono fare in modo affidabile

Gli overlay vengono eseguiti dopo che la pagina è già stata caricata, modificando il DOM a runtime invece di correggere il markup sottostante. Questo approccio non regge sulle cose che contano di più per un'accessibilità reale: il testo alternativo generato automaticamente per le immagini è spesso sbagliato o privo di senso — un'ipotesi di riconoscimento immagini non equivale a una persona che descrive cosa significa un'immagine nel suo contesto; una gerarchia di titoli rotta o una struttura del documento mancante non può essere ricostruita in modo affidabile da uno script aggiunto in seguito; i widget interattivi personalizzati come selettori di data, menu a tendina e finestre modali, costruiti senza supporto da tastiera, restano di solito non funzionanti, perché l'overlay non conosce il comportamento previsto del tuo componente; e la manipolazione del DOM da parte dell'overlay può entrare in conflitto con gli screen reader, rendendo talvolta una pagina più difficile da usare rispetto a prima dell'installazione dell'overlay. Quest'ultimo punto è stato sollevato in modo costante e pubblico per anni da attivisti per la disabilità e utenti di screen reader.

Nulla di tutto ciò significa che chi sviluppa prodotti overlay agisca in malafede riguardo alla tecnologia sottostante — correggere l'accessibilità per pattern-matching a runtime è un problema davvero difficile. Il problema riguarda ciò che viene dichiarato sul risultato.

Il caso della FTC contro accessiBe

Nel gennaio 2025, la Federal Trade Commission statunitense ha annunciato un accordo con accessiBe, uno dei maggiori fornitori di overlay, che ha imposto all'azienda il pagamento di 1 milione di dollari. L'azione della FTC riguardava principalmente le accuse secondo cui accessiBe avrebbe rilasciato dichiarazioni ingannevoli sulla capacità del proprio overlay di rendere i siti web conformi agli standard e alle leggi sull'accessibilità, e avrebbe usato recensioni false o fuorvianti a sostegno di tali affermazioni.

L'accordo è un segnale regolatorio, non una sentenza che dichiara illegale l'uso degli overlay — ma conferma che promuovere un overlay come garanzia di conformità legale è il tipo di affermazione che un regolatore esaminerà attentamente. Se stai valutando un qualsiasi prodotto per l'accessibilità, vale la pena ricordarlo: diffida di qualsiasi fornitore — overlay o altro — che prometta piena conformità legale con una singola installazione.

Perché correggere alla fonte è la soluzione duratura

La conformità WCAG è una proprietà del tuo contenuto e codice reale, non di uno script che gira sopra di esso. Una pagina con HTML semantico corretto, testo alternativo reale, una struttura dei titoli logica e componenti personalizzati accessibili funziona correttamente su tutta la gamma di combinazioni di tecnologie assistive — diversi screen reader, diversi browser, diverse impostazioni utente — perché non c'è nulla di fragile sovrapposto che possa rompersi o entrare in conflitto.

Le correzioni a livello di codice sono anche verificabili: uno sviluppatore, un auditor o un regolatore può ispezionare il tuo markup reale e verificarlo. Il comportamento a runtime di un overlay è molto più difficile da verificare in modo coerente, perché può comportarsi diversamente a seconda dei tempi di caricamento, delle particolarità del browser e di come il JavaScript della tua pagina interagisce con lo script dell'overlay stesso.

Il ruolo onesto degli overlay

Se apprezzi già alcune funzioni di preferenza utente di un overlay — ridimensionamento del testo, riduzione del movimento, interruttori di contrasto — c'è un ragionevole motivo per mantenerle come aggiunta su un sito già davvero accessibile e corretto alla fonte. Ciò che non regge è usare un overlay al posto della correzione del codice, o promuoverlo come garanzia di conformità.

Questo articolo è un'informazione generale, non consulenza legale. Se un determinato approccio all'accessibilità soddisfi una specifica legge nella tua giurisdizione dipende dalla tua situazione — consulta un legale per una valutazione vincolante.

Guida UE (EAA) · Overlay vs correzione codice · Alternativa a accessiBe · Alternativa a UserWay · Alternativa a AudioEye · Metodologia · European Accessibility Act (EAA) 2025: la guida completa · BFSG: cosa devono fare le aziende tedesche