Hem interceptat totes les sol·licituds de cinc eines d'accessibilitat. Això és el que fan realment al vostre lloc web.

Una auditoria tècnica independent de quatre superposicions d'accessibilitat i una solució només de monitorització: què canvien realment, què amaguen als usuaris amb discapacitat i per què més de 1.000 empreses que utilitzen superposicions van ser demandades només el 2024.

Com ho vam fer: La metodologia de recerca

La majoria de les revisions de les superposicions d'accessibilitat es basen en afirmacions de màrqueting, documentació del proveïdor o proves a nivell superficial. Vam adoptar un enfocament fonamentalment diferent: vam interceptar cada byte de dades que fluïa entre el navegador i els servidors de cada eina, vam extreure els fitxers de correcció de JavaScript i les dades de remediació reals i vam analitzar exactament què fa cada eina al DOM en directe dels llocs web de comerç electrònic de producció.

La configuració tècnica

Vam implementar mitmproxy , un proxy HTTPS de codi obert, configurat per capturar els cossos complets de sol·licitud i resposta de tot el trànsit als dominis CDN i API de les eines. Vam instal·lar el certificat CA arrel del proxy al navegador per habilitar la intercepció HTTPS transparent i, a continuació, vam llançar una instància de Chrome dedicada encaminada exclusivament a través del proxy. Vam configurar filtres de domini per capturar només el trànsit als servidors d'eines d'accessibilitat, assegurant-nos que només analitzàvem el que injecten aquestes eines, no el trànsit dels propis llocs web.

A continuació, vam navegar per 14 llocs de comerç electrònic en directe com ho faria un usuari normal: carregant la pàgina d'inici, navegant a les pàgines de llistat de productes, visualitzant les pàgines de detalls del producte, afegint articles al carretó, procedint al pagament, visitant les pàgines del compte i del registre, i interactuant amb modals, carrusels i cerques. Cada sessió de navegació es va capturar com un fitxer d'arxiu HTTP (HAR) amb cossos de resposta complets, el mateix format que els navegadors utilitzen internament, però enriquit amb el contingut real de cada fitxer JavaScript, cada full d'estil CSS, cada configuració JSON i cada resposta API que les eines servien.

Després de la captura, vam escriure scripts d'anàlisi en Python que analitzaven cada cos de resposta, classificaven cada fitxer per eina i funció, extreien cada selector CSS de les definicions de correccions, comptaven cada patró de manipulació DOM en codi JavaScript, identificaven cada instància de contingut ocult a la tecnologia assistiva i assignaven cada correcció a l'àrea de la pàgina que afecta (pagament, cistella, llistat de productes, navegació, etc.).

El proxy va capturar 924 sol·licituds HTTP amb 579 cossos de resposta complets en tres sessions de captura, incloent-hi tots els scripts de correcció per lloc, tots els JSON de correcció, tots els fitxers de configuració i totes les càrregues analítiques. També vam desar instantànies DOM completes de pàgines amb modificacions de superposició aplicades, cosa que ens va permetre inspeccionar els valors exactes d'aria-etiqueta i els atributs de dades del proveïdor injectats en temps d'execució. A continuació, vam escriure scripts d'anàlisi automatitzats per analitzar el JavaScript, comptar tots els patrons de modificació DOM, extreure tots els selectors CSS, classificar totes les correccions per àrea de la pàgina i identificar totes les instàncias de contingut que s'oculten a la tecnologia assistiva.

Què hem analitzat

Els llocs web abastaven els principals minoristes de moda, marques de xocolata de luxe, fabricants de maletes, botigues de bosses de mà de disseny, empreses de joguines, un proveïdor de telecomunicacions, un banc nacional, marques de begudes, papereria, rellotges i confiteria, cobrint tant els mercats de la UE com dels EUA.

Una observació crítica: no hi ha cap delimitació d'abast a nivell de pàgina en cap superposició d'accessibilitat.

Una de les troballes més sorprenents va sorgir abans que analitzéssim les regles de correcció: cada capa d'accessibilitat carrega tot el seu conjunt de correccions a cada pàgina , independentment del tipus de pàgina. Les correccions específiques del pagament s'activen a la pàgina d'inici. Les regles de quantitat del carretó s'executen a la pàgina "Sobre nosaltres". Les correccions de les tessel·les del producte s'executen al formulari d'inici de sessió.

Això significa que al lloc web del proveïdor de telecomunicacions, cada visitant de cada pàgina descarrega un fitxer JSON d'1,25 MB que conté 4.974 descripcions d'imatges i 2.000 entrades de correcció en PDF, fins i tot en pàgines sense imatges. Al minorista de bosses de mà de disseny, s'executen 383 regles de correcció DOM a cada càrrega de pàgina, intentant que coincideixin selectors que només existeixen en tipus de pàgina específics. Quan un selector específic del pagament com ara #targetaNúmero no coincideix a la pàgina d'inici, el motor de correcció de la superposició encara dedica cicles de CPU a avaluar-lo; multiplicat per centenars de regles, això crea una pèrdua de rendiment mesurable a cada visualització de pàgina.

La superposició A només escaneja el 4,5% de les sessions

Enterrat a les dades analítiques POST de la capa superior A, vam descobrir un camp que revelava la seva taxa de mostreig d'escaneig real:

Una taxa de mostreig de 0,045 significa que només el 4,5% de les sessions de visitants desencadenen una anàlisi de compliment en aquest minorista de moda. En un altre lloc, una marca de xocolata de luxe, la taxa va ser encara més baixa: només l'1,7% . És possible que el proveïdor de la capa superior realitzi una anàlisi inicial més completa durant la incorporació o la configuració i, a continuació, redueixi la taxa de mostreig per a la supervisió contínua. Tanmateix, la implicació per a les operacions diàries continua sent significativa.

El codi del paquet d'inici de la superposició d'accessibilitat confirma tres nivells operatius: ReleaseVersionReport (escaneig complet + informe: el percentatge mostrejat), ShadowVersionReport (escaneig d'ombra, sense acció directa a l'usuari) i RunReleaseFixesNoReport (aplica totes les regles de correcció però no executa cap escaneig). Això significa que durant el funcionament normal, la gran majoria dels visitants reben modificacions del DOM que no es validen durant la seva sessió.

El risc pràctic és aquest: si un desplegament de lloc web canvia l'estructura del DOM i incompleix una o més regles de correcció, la baixa taxa de mostreig contínua significa que la regressió pot passar desapercebuda durant un període prolongat. Amb només un 1,7–4,5% de les sessions escanejades, una correcció incorrecta podria afectar milers de visitants abans que la següent sessió mostrejada s'activi a la pàgina afectada i marqui el problema. Durant aquesta finestra, tots els visitants reben correccions obsoletes o mal dirigides, i ni l'operador del lloc web ni el proveïdor de la capa superior poden ser conscients del problema.

Les troballes: Correcció de regles i modificacions del DOM

Superposició A: Fitxers de correcció de JavaScript per lloc web

Aquesta capa superposada manté un fitxer de correcció de JavaScript separat per a cada lloc web de client, que conté regles que tenen com a objectiu selectors CSS específics. Als cinc llocs web que hem analitzat, hem trobat:

També vam trobar 7 instàncies on la cadena literal "true" es va injectar com a aria-label – un error de codi on es passava un valor booleà en comptes de text descriptiu. Els lectors de pantalla anuncien "botó, cert", sense cap sentit. En un altre lloc, "Cerca" estava mal escrit com a "Cerca" en una etiqueta injectada.

Superposició B: text alternatiu generat per IA a escala

Aquesta capa superposada descarrega fitxers JSON de correcció massiva que contenen descripcions d'imatges generades per IA. En tres llocs:

Exemples reals de les dades de remediació:

323 descripcions superaven els 125 caràcters, cosa que provocava una verbositat del lector de pantalla on el lector s'aturava durant 10-15 segons per imatge. 156 començava redundantment amb "imatge de", un antipatró WCAG, ja que els lectors de pantalla ja anuncien el tipus d'element.

Eina de monitorització: zero modificacions – verificat al codi font

Què significa "Amaga't d'AT" per a usuaris reals

Quan una superposició amaga un element de la tecnologia assistiva, l'element roman visible a la pantalla però esdevé completament invisible per als lectors de pantalla . Hem classificat cada element ocult per l'àrea de la pàgina que afecta:

Dades de fitxers de correcció active.js per lloc reals extretes mitjançant mitmproxy. Cada recompte representa un selector CSS únic al qual s'adreça hideFromAT().

A la pàgina de pagament d'una botiga de luxe, els elements ocults als lectors de pantalla incloïen:

Així és com les eines de superposició d'accessibilitat creen una experiència de compra de dos nivells : els usuaris vidents veuen totes les opcions de pagament i poden triar entre targeta de crèdit, PayPal, Amazon Pay, Shop Pay i Klarna. Els usuaris cecs només poden trobar els mètodes de pagament que la superposició no ha amagat. En una botiga de moda, el botó d'entrada de la quantitat al carretó i el botó d'actualització estaven ocults: un usuari cec podia afegir articles però no podia canviar les quantitats.

Això planteja una pregunta fonamental: una capa que amaga els botons de pagament als usuaris cecs fa que el lloc web sigui més accessible o menys accessible?

Impacte en el rendiment

Què passa després del desplegament d'un lloc web

Potser el risc més insidiós de les eines de superposició només es fa visible amb el temps: les correccions es degraden silenciosament . A diferència d'un error de JavaScript que es bloqueja visiblement o d'un disseny trencat que algú nota, una correcció de superposició obsoleta no produeix cap error, cap alerta ni cap canvi visual. Simplement deixa de funcionar i la barrera d'accessibilitat que estava emmascarant reapareix sense que ningú ho sàpiga.

Per entendre això, tingueu en compte com cada tipus de superposició s'acobla a l'estructura DOM del vostre lloc web.

Correccions basades en selectors: un rellotge que fa tic-tac

La capa A, com la majoria de solucions de capa d'accessibilitat, manté fitxers de correcció de JavaScript per lloc que contenen regles com aquesta (reconstruïdes a partir del codi capturat real):

Aquesta regla té com a objectiu el botó de fletxa anterior d'un carrusel de Slick mitjançant tres classes CSS: .js-recommendation_carousel, .slick-prev, i .slick-arrowTotes les parts d'aquest selector són fràgils. Si l'equip del lloc web canvia el nom de la classe del contenidor del carrusel, canvia de Slick a Splide o Swiper, o simplement actualitza la biblioteca Slick a una versió que canvia la convenció de nomenament de les classes, el selector no coincideix amb res. El botó perd l'etiqueta "Diapositiva anterior". Els usuaris del lector de pantalla ja no el poden identificar.

En els cinc llocs que vam analitzar per a la Superposició A, vam trobar El 98% de tots els selectors contenen noms de classe específics del marc de treball – classes amb prefix .js-, .b-, .chakra-, .splide__, o resums CSS-in-JS com ara .css-acuo7nAquests no són identificadors semàntics estables, sinó detalls d'implementació que canvien amb cada actualització del marc de treball, refactorització de components o modificació del sistema de compilació.

En una botiga de bosses de mà de disseny, vam trobar selectors dirigits a components de la interfície d'usuari de Chakra. La interfície d'usuari de Chakra publica canvis importants en les versions principals: els noms de les classes, l'estructura dels components i els patrons ARIA evolucionen. Quan aquest lloc actualitza Chakra, potencialment centenars de regles de correcció de superposició es trencaran silenciosament. El proveïdor de la superposició ha d'auditar manualment la nova estructura DOM, reescriure tots els selectors afectats i implementar fitxers de correcció actualitzats. Durant l'interval entre la implementació del lloc i l'actualització del proveïdor de la superposició, el lloc funciona amb correccions obsoletes: algunes no fan res, altres potencialment s'apliquen als elements incorrectes.

Correccions basades en URL: Encara més fràgil

La correcció de la superposició B enllaça amb la clau JSON de cada entrada de text alternatiu a l'URL exacta de la imatge font. Hem trobat entrades com ara:

Fixeu-vos en la fragilitat: l'URL conté un ID de dispositiu (13555), una dimensió de miniatura (86x86) i un nom de fitxer que inclogui el nom del producte. Qualsevol d'aquests pot canviar independentment. Si el CMS regenera miniatures amb una mida diferent, el thumb_86x86 part de l'URL canvia i l'entrada ja no coincideix. Si l'equip del producte penja una foto nova amb un nom de fitxer diferent, l'entrada queda òrfena. Si el lloc migra els seus continguts multimèdia a una CDN amb un domini diferent, totes les entrades del JSON d'1,17 MB es converteixen en un pes mort i totes les imatges del lloc perden el seu text alternatiu simultàniament.

El pitjor escenari és un error de coincidència parcial: algunes imatges mantenen les seves URL antigues (i reben text alternatiu), mentre que les imatges noves o actualitzades no coincideixen amb cap entrada (i no reben res). El resultat és una experiència inconsistent on algunes imatges es descriuen i d'altres s'ometen silenciosament, cosa molt més confusa per a un usuari de lector de pantalla que una absència consistent de text alternatiu.

Correccions d'abast global: el problema de la cascada

L'enfocament de Overlay C: adjuntar un MutationObserver a tot el document i aplicar correccions genèriques a tots els elements de certs tipus (a, button, input, img, h1) – crea un patró de trencament diferent però igualment perillós. En lloc de fallar silenciosament quan els selectors es tornen obsolets, aquesta superposició lluita activament amb el nou codi.

Imaginem un escenari comú: l'equip del lloc web implementa un nou component de diàleg modal accessible que implementa correctament la captura de focus, l'escapada per tancar i els atributs ARIA. El MutationObserver de la superposició detecta els nous elements DOM, els avalua en funció de les seves regles genèriques i, en trobar elements que coincideixin amb els seus patrons, aplica la seva pròpia gestió del focus, controladors de teclat i atributs ARIA a sobre de la implementació correcta existent del component. El resultat és un focus doblement atrapat, controladors de teclat duplicats i atributs ARIA contradictoris. El modal que funcionava perfectament abans que es carregués la superposició ara es comporta de manera erràtica.

Això no és una preocupació teòrica. Les biblioteques de components del Framework com Radix UI, Headless UI i Chakra UI inverteixen un esforç d'enginyeria significatiu en la correcta implementació d'ARIA. Una capa superior que aplica de manera general els seus propis atributs ARIA a tots button i a és probable que els elements entrin en conflicte amb aquestes implementacions ben provades, fent que els components siguin correctament accessibles menys accessible.

L'eina de monitorització: Res a trencar

L'eina de monitorització que hem analitzat no té correccions basades en selectors, ni entrades amb clau d'URL, ni MutationObserver ni segmentació d'elements genèrics. Quan el lloc web implementa codi nou, la següent exploració de l'eina de monitorització avalua automàticament el nou DOM en relació amb el conjunt de regles estandarditzades d'axe-core i informa de qualsevol nova infracció, sense modificar res. Els resultats de l'exploració apareixen al tauler de control de l'eina amb els nivells de gravetat, el recompte d'elements afectats i els identificadors de regles WCAG estandarditzades. Els desenvolupadors revisen les troballes i implementen correccions a la seva pròpia base de codi, on les correccions passen per la revisió de codi, les proves automatitzades, la validació per proves i la implementació controlada.

Aquest procés és inherentment resistent al canvi: l'eina escaneja qualsevol DOM existent en el moment de l'escaneig, informa dels problemes que troba i comença de nou en el següent escaneig. No hi ha cap deute tècnic acumulat de definicions de correccions, ni selectors obsolets, ni entrades de text alternatiu orfes, ni possibilitat d'aplicar la correcció incorrecta a l'element incorrecte.

Què es trenca quan es torna a implementar

Cada correcció de superposició d'accessibilitat està acoblada a l'estructura DOM actual del lloc. Vam descobrir que El 98% dels selectors d'una superposició tenen com a objectiu noms de classe específics del marc de treball. – classes com .chakra-, .splide__, .js-, .b-, i hashes CSS-in-JS com ara .css-acuo7n que canvien en cada construcció.

L'eina de monitorització té "Sense afectar" a cada fila perquè no té cap correcció basada en selectors . No hi ha res que esdevingui obsolet, res que apunti a l'element equivocat, res que es trenqui.

RGPD, privadesa i el problema del consentiment

La nostra anàlisi ha confirmat que tres de les quatre capes d'accessibilitat envien dades a servidors externs abans que es pugui interactuar amb qualsevol bàner de consentiment:

Segons la sentència Planet49 del TJUE, el seguiment no essencial requereix un consentiment previ. Dues capes activen identificadors persistents a la primera sol·licitud de xarxa, abans que es pugui activar qualsevol mecanisme de consentiment. Per als llocs web orientats a la UE, això és un incompliment automàtic del RGPD.

El panorama legal

L'abril de 2025, la Comissió Federal de Comerç dels Estats Units va finalitzar un acord d'1 milió de dòlars contra un dels proveïdors de superposició d'accessibilitat del nostre estudi per tergiversar que la seva eina basada en IA podia fer que qualsevol lloc web complís amb les WCAG. La FTC va determinar que l'eina no feia accessibles els components bàsics del lloc web (menús, encapçalaments, taules, imatges i enregistraments) . En un exemple citat, una foto de filet mignon va rebre la descripció generada per IA "Pa integral en un plat de ceràmica blanca".

Segons les dades de seguiment del sector, el 25% de totes les demandes d'accessibilitat digital del 2024 citaven explícitament els widgets superposats com a barreres, no com a solucions. Durant la primera meitat del 2025, les demandes contra empreses que utilitzen la superposició van continuar superant les 100 al mes. Dos dels proveïdors de superposició del nostre estudi han estat directament involucrats en litigis: un de cada tres casos separats de patents/secrets comercials, i un altre s'enfronta a una demanda col·lectiva d'un client de petites empreses que va ser demandat tot i utilitzar la superposició.

L'eina de monitorització del nostre estudi no té antecedents de litigis relacionats amb fallades d'accessibilitat, una conseqüència lògica de la seva arquitectura: com que mai modifica el DOM, no pot introduir barreres d'accessibilitat.

Dins del codi: Què modifiquen realment les superposicions

Per entendre l'escala de la manipulació del DOM, vam comptar tots els patrons de modificació del JavaScript de cada eina. Les diferències són importants:

La capa C mereix una atenció especial. El seu paquet monolític de 794 KB adjunta un MutationObserver a document.documentElement amb la configuració {subtree: true, childList: true, attributes: true, attributeOldValue: true}Això vol dir cada canvi de DOM a tota la pàgina – ja sigui des de la reconciliació DOM virtual de React, un script de proves A/B, un widget de xat o el propi JavaScript del lloc web – activa l'observador de la superposició, que després reavalua i potencialment torna a aplicar les seves correccions. Després d'una redistribució del lloc web, això crea una cascada d'intents de recorrecció en elements que ja poden ser accessibles correctament, i que poden sobreescriure els atributs ARIA correctes per uns d'incorrectes.

Hem confirmat que Overlay C envia USER-BEHAVIOR-ANALYTICS Sol·licituds POST al seu propi receptor de registre, amb càrregues útils que contenen el domini del lloc, la versió del widget, l'idioma de l'usuari i els esdeveniments d'interacció. Combinat amb localStorage persistència i empremta digital del dispositiu mitjançant navigator.userAgent i navigator.maxTouchPoints, això representa una operació de processament de dades que la majoria dels operadors de llocs web desconeixen que s'està produint.

El problema de remediació de JSON

La superposició B descarrega un fitxer JSON massiu (fins a 1,17 MB per a un lloc de telecomunicacions) que conté totes les definicions de correccions. En un lloc, vam observar que s'obtenia quatre vegades diferents en una sola sessió de navegació : 4,7 MB d'ample de banda per a un fitxer que s'hauria d'haver desat a la memòria cau. El JSON conté 11 categories, però la gran majoria són descripcions d'imatges generades per IA: 4.974 de 6.975 entrades per a un lloc. Cadascuna està vinculada a una URL d'imatge específica: quan el CMS canvia el nom d'un fitxer, canvia les dimensions de la miniatura o migra dominis CDN, les entrades deixen de coincidir silenciosament. Les imatges de reemplaçament no reben cap text alternatiu, cosa que fa que la pàgina sigui menys accessible que abans d'instal·lar la superposició.

Aquesta superposició també desplega mòduls d'execució que reescriuen activament la pàgina: un motor de remediació de 110 KB, un auxiliar de menú de navegació de 23 KB que reestructura el maneig del teclat del menú, un pegat de carrusel de 5,8 KB i un escàner del costat del client de 53 KB que utilitza lògica pròpia en lloc del motor axe-core estàndard de la indústria, cosa que significa que les seves troballes no es poden verificar de manera independent.

La capa més transparent, encara arriscada

La capa D tenia l'arquitectura més transparent: fitxers de configuració JSON llegibles per humans amb interruptors d'activació/desactivació explícits. Opcions com ara addAriaHidden, overwriteAlt, i adjustMetaViewport es van configurar explícitament per a false. Tanmateix, el motor subjacent (649 KB) conté 216 setAttribute trucades, 47 aria-hidden referències, 282 addEventListener registres i 9 MutationObserver instàncies. El motor admet mutacions DOM agressives fins i tot si la configuració actual és conservadora; un canvi de configuració del proveïdor podria activar funcions de risc sense el coneixement de l'operador del lloc.

Hem trobat selectors per lloc que contenien sufixos hash generats per JavaScript com ara button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 que canvien en cada compilació, i selectors d'URL de xarxes socials que es tornen obsolets quan el lloc actualitza els seus enllaços de Facebook o Instagram.

La Llei Europea d'Accessibilitat: Per què les superposicions no satisfaran la Llei Europea d'Accessibilitat

A partir del 28 de juny de 2025, la Llei Europea d'Accessibilitat (EAA) exigeix ​​que els productes i serveis digitals venuts a la UE compleixin els estàndards d'accessibilitat d'acord amb la norma EN 301 549, que fa referència a la WCAG 2.1 AA. A diferència de l'ADA, que s'aplica principalment a través de demandes privades, l'EAA l'apliquen les autoritats nacionals de vigilància del mercat, amb la facultat d'imposar multes, ordenar mesures correctores i retirar del mercat els productes no conformes.

Rebuig oficial d'Alemanya a les eines de superposició

Alemanya ha adoptat la posició reguladora més clara de qualsevol país sobre les eines de superposició d'accessibilitat. El BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik), l'organisme federal de supervisió de l'accessibilitat de les tecnologies de la informació d'Alemanya, juntament amb tots els organismes de supervisió a nivell estatal, van emetre una avaluació conjunta rebutjant explícitament les eines de superposició per al compliment de les normes d'accessibilitat:

El 12 de març de 2025 , el Comitè per a la Tecnologia de la Informació Accessible (Ausschuss für barrierefreie Informationstechnik, establert en virtut de l'article 5 BITV 2.0) va reafirmar aquesta posició en la seva sessió, afirmant amb preocupació que els organismes públics continuen intentant complir les seves obligacions d'accessibilitat mitjançant la integració d'eines de superposició. El comitè va concloure que "una representació accessible temporal d'un lloc web mitjançant programari, possiblement només després que l'usuari configure els paràmetres, durant la seva visita no compleix els requisits de les disposicions legals aplicables".

El comitè va advertir explícitament que els organismes públics que utilitzen eines de superposició corren el risc de fer que els seus llocs web siguin menys accessibles , no més, sinó que creïn un empitjorament de l'accessibilitat ("Verschlechterung der Barrierefreiheit"). Això reflecteix directament la nostra conclusió tècnica que el 26% de les regles de correcció de superposició introdueixen noves infraccions de les WCAG.

Segell de prova BIK: denegat per a llocs web que utilitzen superposicions

La xarxa de proves BIK d'Alemanya (els organismes acreditats que avaluen els llocs web segons BITV 2.0, EN 301 549 i WCAG 2.1 AA) ha pres una mesura operativa: els llocs web que utilitzen eines de superposició no poden rebre el segell de prova BIK . Els organismes de proves van declarar que no poden fer una avaluació de conformitat fiable quan hi ha una superposició, perquè la superposició modifica el DOM en temps d'execució de manera que els resultats de la prova no són fiables. El segell BIK s'utilitza àmpliament a tota Alemanya com a prova de compliment de BITV 2.0, i ara no està disponible per a cap lloc web que utilitzi una superposició.

Això no és una preocupació política teòrica. Significa que un lloc web de comerç electrònic alemany que utilitzi qualsevol de les quatre capes que hem provat no pot obtenir la certificació de compliment estàndard que s'utilitza a tot el mercat alemany.

Confirmació a nivell europeu

Aquesta posició reguladora s'estén més enllà d'Alemanya. El Fòrum Europeu de la Discapacitat i l'Associació Internacional de Professionals de l'Accessibilitat van emetre una declaració conjunta el 2023 advertint que les superposicions d'accessibilitat no fan que els llocs web siguin accessibles ni compleixin la legislació europea sobre accessibilitat, inclosa la Llei Europea d'Accessibilitat. La Comissió Europea també ha comentat les afirmacions de conformitat de les superposicions, concloent que les superposicions no poden garantir el compliment de les normes aplicables.

Segons la BFSG (Barrierefreiheitsstärkungsgesetz) d'Alemanya, la transposició alemanya de la Llei d'Aplicacions Econòmiques i Empresarials (EAA), en vigor des del 28 de juny de 2025, les autoritats de vigilància del mercat poden imposar multes de 10.000 a 100.000 euros per infracció . L'avaluació del BFIT-Bund i la negativa de la xarxa de proves BIK a certificar llocs web que utilitzen eines de superposició signifiquen que les eines de superposició no proporcionen cap cobertura reguladora a Alemanya i poden augmentar activament el risc de mesures coercitives.

Risc de seguretat i cadena de subministrament

Cada eina de superposició funciona injectant JavaScript de tercers a l'abast global de les vostres pàgines de producció. Aquest JavaScript s'executa amb els mateixos privilegis que el vostre propi codi: pot llegir i modificar qualsevol element DOM, interceptar enviaments de formularis, accedir a cookies, redirigir usuaris i exfiltrar dades. Les implicacions de seguretat d'aquesta disposició són significatives i sovint es passen per alt.

La superfície d'atac

Tingueu en compte la cadena de subministrament: quan afegiu una capa d'accessibilitat al vostre lloc web, esteu concedint a un proveïdor extern accés d'escriptura continu i sense restriccions al vostre DOM de producció en directe . La CDN del proveïdor serveix el JavaScript, l'equip del proveïdor manté el codi i el pipeline de desplegament del proveïdor envia les actualitzacions directament al vostre lloc web, sense la vostra revisió de codi, sense el vostre procés de control de qualitat i sense la vostra aprovació.

Si la CDN del proveïdor de la capa superposada es veu compromesa, l'atacant obté la capacitat d'injectar codi maliciós a tots els llocs que utilitzen aquesta capa superposada. Si un empleat del proveïdor envia una actualització incorrecta, tots els llocs del client es veuen afectats simultàniament. Si el punt final de l'API del proveïdor és segrestat, les dades JSON o de configuració de correcció que es serveixen al vostre lloc es poden manipular per modificar camps de formulari, redirigir enllaços o injectar contingut de phishing.

L'escala d'aquest risc es correlaciona directament amb la petjada DOM de la capa superior:

La capa B presenta la superfície de risc de la cadena de subministrament més gran: 228 crides a l'API per sessió en 3 dominis externs, amb una càrrega útil JSON d'1,17 MB que defineix com s'ha de modificar el DOM. Una resposta de l'API compromesa podria instruir el motor de remediació perquè injectés contingut arbitrari a qualsevol element de la pàgina. El paquet monolític d'1.285 KB de la capa C és la càrrega útil de JavaScript individual més gran i, com que està minimitzada i ofuscada, ni l'operador del lloc ni un auditor de seguretat poden revisar de manera significativa el que executa en temps d'execució.

Compliment de la norma PCI DSS: un conflicte directe

Per a qualsevol lloc de comerç electrònic que processi pagaments amb targeta de crèdit, el compliment de la norma PCI DSS no és opcional. I les nostres troballes revelen un conflicte directe entre l'arquitectura de l'eina de superposició d'accessibilitat i els requisits de la norma PCI DSS.

El requisit 6.4.3 de la norma PCI DSS (introduït a la versió 4.0 de la norma PCI DSS, obligatori a partir del 31 de març de 2025) exigeix ​​que tots els scripts de les pàgines de pagament que es carreguen i s'executen al navegador del consumidor es gestionin de la manera següent: s'ha d'implementar un mètode per confirmar que cada script està autoritzat, s'ha de garantir la integritat de cada script i s'ha de mantenir un inventari de tots els scripts amb una justificació escrita de per què cadascun és necessari.

La nostra anàlisi va confirmar que les regles de correcció de superposició s'orienten activament als elements DOM de la pàgina de pagament en diversos llocs:

Això no és un risc teòric: són regles de correcció reals que hem extret dels llocs de producció , modificant activament els camps del número de targeta de crèdit, els selectors d'adreça de facturació, els botons del proveïdor de pagaments i els contenidors del formulari de pagament. Segons la norma PCI DSS 6.4.3, tots aquests scripts de tercers requereixen una autorització documentada, verificació de la integritat i una justificació escrita.

Tingueu en compte què pot fer un script d'un proveïdor de superposició a la vostra pàgina de pagament:

L'eina de monitorització, en canvi, no té capacitat d'escriptura DOM. El seu script de 4,2 KB no pot modificar els camps del formulari, no pot interceptar esdeveniments d'entrada i no pot accedir ni alterar els elements de pagament. Fins i tot si la CDN del proveïdor de monitorització es veiés compromesa, l'atacant obtindria accés a un script que només pot llegir l'URL de la pàgina i el tipus de dispositiu, no un que pugui reescriure el formulari de pagament. A efectes de l'abast de PCI DSS, l'eina de monitorització no crea cap superfície de risc addicional a les pàgines de pagament.

La qüestió de la discriminació

Aquest és el problema de discriminació que hi ha al cor de totes les estratègies d'accessibilitat: la troballa més preocupant no és un defecte tècnic, sinó un patró de negar sistemàticament als usuaris amb discapacitat l'accés a funcionalitats que els usuaris vidents donen per fetes.

Quan una capa superposada amaga un botó d'Amazon Pay de l'arbre d'accessibilitat, un usuari cec veu menys opcions de pagament que un usuari vident. Quan s'amaga la quantitat introduïda al carretó de la compra, un usuari cec no pot ajustar la seva comanda. Quan s'amaguen els enllaços dels resultats de la cerca, es dificulta la descoberta de productes. Quan s'amaguen les qualificacions amb estrelles, un usuari cec no pot avaluar la qualitat del producte de la mateixa manera que ho pot fer un usuari vident.

No es tracta de casos límit, sinó de fluxos de treball bàsics del comerç electrònic que es veuen afectats per les mateixes eines que prometen fer-los accessibles.

La comunitat de persones amb discapacitat fa anys que ho denuncia obertament. La fitxa informativa sobre la superposició, signada per centenars de professionals de l'accessibilitat, adverteix que les superposicions d'accessibilitat "no reparen l'HTML subjacent" i "sovint interfereixen activament amb les persones amb discapacitat". La nostra anàlisi tècnica proporciona les proves: 141 elements funcionals ocults als lectors de pantalla, 7 etiquetes sense sentit injectades i 5.066 descripcions d'IA no revisades desplegades a la producció, en només 14 llocs web.

Per als operadors de llocs web, la qüestió no és si les superposicions són "prou bones", sinó si es pot justificar la implementació d'una eina que crea una experiència de dos nivells: una versió per a usuaris vidents que obtenen totes les funcions, i una versió filtrada, defectuosa i de vegades sense sentit per a usuaris amb discapacitat.

Impacte en el compliment de l'ADA: realment ajuden aquestes solucions?

La promesa principal de cada capa superior és que millora el compliment de l'ADA mitjançant la correcció de les infraccions de les WCAG en temps d'execució. Però la nostra anàlisi revela una paradoxa inquietant: un percentatge significatiu de les correccions de la capa superior introdueixen activament noves infraccions de les WCAG mentre intenten corregir les existents.

Vam assignar cada regla de correcció capturada de la Superposició A al criteri d'èxit específic de les WCAG 2.1 a què es dirigeix. De les 776 regles que es podien assignar, els resultats es van dividir en dues categories: correccions que realment solucionen un problema de les WCAG i correccions que creen una nova violació de les WCAG en el procés.

Per ser justos, tres quartes parts de les correccions assignades són millores genuïnes: afegir etiquetes de botons que falten, corregir jerarquies d'encapçalament, corregir atributs d'autocompletar i implementar trampes de focus modals. Però la quarta part restant és activament perjudicial, i el dany recau de manera desproporcionada sobre els mateixos usuaris que l'eina pretén ajudar.

Com cada patró de risc infringeix les WCAG

El problema no és només que aquestes solucions fallen, sinó que introdueixen violacions de criteris d'èxit específics de les WCAG que no existien abans que s'apliqués la superposició. En una demanda de l'ADA, l'expert d'un demandant pot assenyalar aquestes violacions creades per la superposició com a prova que el lloc web discrimina les persones amb discapacitat.

Superposició B: text alternatiu d'IA i WCAG 1.1.1

La WCAG 1.1.1 exigeix ​​que el contingut no textual tingui una "alternativa de text que serveixi per a un propòsit equivalent". Un text alternatiu generat per IA que descriu el logotip d'una empresa com "un símbol blau i groc" no serveix per a un propòsit equivalent: el propòsit d'un logotip és la identificació de la marca, no la descripció del color. Un text alternatiu de "text" per a un bàner promocional, o "ciutat" per a una imatge estrella, no compleix el mateix criteri d'una manera diferent: és tan vague que no serveix per a res.

Dels 5.068 textos alternatius generats per IA que vam capturar de la Superposició B, 241 tenien menys de 15 caràcters (massa vagues per ser útils), 323 superaven els 125 caràcters (violant les millors pràctiques per a la usabilitat del lector de pantalla) i 156 començaven amb "imatge de" o "foto de" (redundant perquè els lectors de pantalla ja anuncien el tipus d'element). Només 2 havien estat aprovats per un revisor humà.

Segons les normes de litigi de l'ADA, l'expert en accessibilitat d'un demandant els marcaria com a incompliments de les WCAG 1.1.1, el criteri més citat en les demandes d'accessibilitat web de l'ADA. La superposició no resol la violació; substitueix una forma d'incompliment (text alternatiu que falta) per una altra (text alternatiu inexacte o vague), alhora que crea una falsa sensació de compliment per a l'operador del lloc web.

Superposició B: Injecció d'etiquetes de formulari en temps d'execució: quan "arreglar-ho" empitjora la situació

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.

Amb el motor de correcció de la capa B actiu, un lector de pantalla va anunciar:

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”).

El resultat és pitjor que el formulari original sense etiquetar . Abans de la superposició, un usuari de lector de pantalla es trobava amb set camps sense etiquetar, cosa que resultava confusa, però almenys de manera consistent. Podrien utilitzar l'ordre de tabulació i el context per endevinar quin camp és quin. Després de la intervenció de la superposició, l'usuari es troba amb dos camps amb la mateixa etiqueta ("Nom" tant per al nom com per al cognom), dos camps amb etiquetes d'estil de validació fabricades que no coincideixen amb el text visible i tres camps amb noms basats en el tipus sense sentit. L'etiquetatge parcial i incorrecte és més desorientador que cap etiquetatge, perquè crea una falsa impressió que el formulari s'ha fet accessible quan els camps crítics romanen sense etiquetar o mal etiquetats.

Aquesta troballa també revela el punt cec de remediació del JSON de la superposició B. El JSON contenia 87 entrades de text alternatiu generades per IA i entrades de remediació de forma zero per a aquest lloc. La injecció d'etiquetes del formulari es produeix completament en temps d'execució a través del controlador de regles EmptyControls: no és visible al JSON de remediació consolidat, no es fa un seguiment en cap tauler de control que l'operador del lloc pugui revisar i no està subjecta a aprovació humana. L'operador del lloc no té manera de saber que el seu formulari de contacte està mal etiquetat tret que ho provi ell mateix amb un lector de pantalla.

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'efecte net de compliment de l'ADA

El problema fonamental és que les eines de superposició confonen la cobertura amb el compliment normatiu . Una superposició pot apuntar a 1.058 regles de correcció i afirmar que aborda més de 40 criteris d'èxit de les WCAG. Però quan el 26% d'aquestes correccions introdueixen noves infraccions, incloses les fallades de nivell A creades per ocultar elements funcionals, la posició neta de compliment normatiu pot ser pitjor que la del lloc web sense modificar.

Un lloc web sense una superposició que tingui 50 infraccions de les WCAG està en una posició legal més clara que un lloc web amb una superposició que tingui 30 infraccions originals més 203 infraccions introduïdes per la superposició, perquè les infraccions introduïdes per la superposició demostren que l'operador del lloc web va implementar una eina que discrimina activament els usuaris amb discapacitat, cosa que soscava qualsevol defensa de bona fe.

La conclusió