Am interceptat toate solicitările provenite de la cinci instrumente de accesibilitate. Iată ce efectele reale pe care le au asupra site-ului tău.

Un audit tehnic independent al patru suprapuneri de accesibilitate și al unei soluții destinate exclusiv monitorizării – ce modifică acestea de fapt, ce ascund de utilizatorii cu dizabilități și de ce peste 1.000 de companii care utilizează suprapuneri au fost date în judecată numai în anul 2024.

Cum am procedat: Metodologia de cercetare

Majoritatea analizelor privind instrumentele de accesibilitate se bazează pe afirmații de marketing, pe documentația furnizorilor sau pe teste superficiale. Noi am adoptat o abordare fundamental diferită: am interceptat fiecare octet de date care circula între browser și serverele fiecărui instrument, am extras fișierele JavaScript de remediere și datele de remediere propriu-zise și am analizat exact ce face fiecare instrument asupra DOM-ului activ al site-urilor de comerț electronic aflate în producție.

Configurația tehnică

Am implementat mitmproxy – un proxy HTTPS open-source – configurat să captureze conținutul complet al cererilor și răspunsurilor pentru întregul trafic către domeniile CDN și API ale instrumentelor. Am instalat certificatul CA rădăcină al proxy-ului în browser pentru a permite interceptarea transparentă a traficului HTTPS, apoi am lansat o instanță dedicată de Chrome redirecționată exclusiv prin proxy. Am configurat filtre de domeniu pentru a captura doar traficul către serverele instrumentelor de accesibilitate – asigurându-ne că analizăm doar ceea ce injectează aceste instrumente, nu traficul propriu al site-urilor.

Apoi am navigat pe 14 site-uri de comerț electronic active, așa cum ar face un utilizator obișnuit: am încărcat pagina de start, am accesat paginile cu lista de produse, am vizualizat paginile cu detalii despre produse, am adăugat articole în coș, am trecut la finalizarea comenzii, am vizitat paginile de cont și de înregistrare și am interacționat cu ferestrele modale, caruselurile și funcția de căutare. Fiecare sesiune de navigare a fost capturată ca fișier HTTP Archive (HAR) cu corpuri de răspuns complete – același format pe care browserele îl utilizează intern, dar îmbogățit cu conținutul real al fiecărui fișier JavaScript, al fiecărei foi de stil CSS, al fiecărei configurații JSON și al fiecărui răspuns API furnizat de instrumente.

După capturare, am creat scripturi de analiză în Python care au analizat conținutul fiecărui răspuns, au clasificat fiecare fișier în funcție de instrument și funcție, au extras fiecare selector CSS din definițiile de remediere, au numărat fiecare tipar de manipulare DOM din codul JavaScript, au identificat fiecare caz în care conținutul era ascuns de tehnologiile de asistență și au asociat fiecare remediere cu zona paginii pe care o afectează (procesul de plată, coșul de cumpărături, lista de produse, navigarea etc.).

Proxy-ul a capturat 924 de solicitări HTTP cu 579 de corpuri complete de răspuns în cadrul a trei sesiuni de captură – incluzând fiecare script de remediere specific site-ului, fiecare fișier JSON de remediere, fiecare fișier de configurare și fiecare încărcătură de date analitice. De asemenea, am salvat instantanee DOM complete ale paginilor cu modificări de suprapunere aplicate, ceea ce ne-a permis să inspectăm valorile exacte ale etichetelor aria și atributele de date ale furnizorilor injectate în timpul rulării. Apoi, am scris scripturi de analiză automatizate pentru a analiza JavaScript-ul, a număra fiecare model de modificare DOM, a extrage fiecare selector CSS, a clasifica fiecare remediere în funcție de zona paginii și a identifica fiecare instanță de conținut ascunsă de tehnologia de asistență.

Ce am analizat

Printre clienții noștri s-au numărat mari lanțuri de magazine de modă, mărci de ciocolată de lux, producători de bagaje, magazine de genți de mână de designer, companii producătoare de jucării, un furnizor de servicii de telecomunicații, o bancă națională, precum și mărci din domeniul băuturilor, al articolelor de papetărie, al ceasurilor și al produselor de cofetărie – acoperind atât piețele din UE, cât și cele din SUA.

O observație importantă: Niciun cadru de aplicare la nivel de pagină în niciun strat de accesibilitate

Una dintre cele mai surprinzătoare constatări a ieșit la iveală înainte chiar de a analiza regulile de remediere: fiecare suprapunere de accesibilitate încarcă întregul set de remedieri pe fiecare pagină în parte, indiferent de tipul paginii. Remediile specifice procesului de plată se activează pe pagina de start. Regulile privind cantitatea din coș se execută pe pagina „Despre noi”. Remediile pentru casetele de produse se execută pe formularul de autentificare.

Aceasta înseamnă că, pe site-ul furnizorului de servicii de telecomunicații, fiecare vizitator al oricărei pagini descarcă un fișier JSON de 1,25 MB care conține 4.974 de descrieri de imagini și 2.000 de intrări de remediere în format PDF – chiar și pe paginile care nu conțin nicio imagine. Pe site-ul retailerului de genți de mână de designer, 383 de reguli de remediere DOM se execută la fiecare încărcare a paginii, încercând să potrivească selectori care există doar pe anumite tipuri de pagini. Când un selector specific procesului de plată, precum #cardNumber, nu se potrivește pe pagina de start, motorul de remediere al overlay-ului continuă să consume resurse CPU pentru a-l evalua – multiplicat cu sute de reguli, acest lucru creează o pierdere măsurabilă de performanță la fiecare vizualizare a paginii.

Scanarea Overlay A acoperă doar 4,5% din sesiuni

Analizând datele POST din Overlay A, am descoperit un câmp care indica rata reală de eșantionare a scanării:

O rată de eșantionare de 0,045 înseamnă că doar 4,5% dintre sesiunile vizitatorilor declanșează o scanare de conformitate pe site-ul acestui retailer de modă. Pe un alt site – al unei mărci de ciocolată de lux – rata a fost chiar mai mică: doar 1,7%. Este posibil ca furnizorul de soluții de suprapunere să efectueze o scanare inițială mai cuprinzătoare în timpul procesului de integrare sau configurare, iar apoi să reducă rata de eșantionare pentru monitorizarea continuă. Cu toate acestea, implicațiile pentru operațiunile zilnice rămân semnificative.

Codul pachetului de pornire al suprapunerii de accesibilitate confirmă existența a trei niveluri operaționale: ReleaseVersionReport (scanare completă + raport – procentul eșantionat), ShadowVersionReport (scanare în fundal, fără acțiuni vizibile pentru utilizator) și RunReleaseFixesNoReport (aplicarea tuturor regulilor de remediere, dar fără efectuarea vreunei scanări). Aceasta înseamnă că, în timpul funcționării normale, marea majoritate a vizitatorilor dvs. primesc modificări ale DOM-ului care nu sunt validate pe durata sesiunii lor.

Riscul concret este următorul: dacă o implementare a site-ului modifică structura DOM și încalcă una sau mai multe reguli de remediere, rata redusă de eșantionare continuă înseamnă că această regresie poate rămâne nedetectată pentru o perioadă îndelungată. Având în vedere că sunt scanate doar 1,7–4,5% din sesiuni, o remediere defectuoasă ar putea afecta mii de vizitatori înainte ca următoarea sesiune eșantionată să se declanșeze pe pagina afectată și să semnaleze problema. În acest interval, fiecare vizitator primește remedieri învechite sau direcționate greșit – iar nici operatorul site-ului, nici furnizorul de overlay-uri nu pot fi conștienți de problemă.

Concluziile: Corectarea regulilor și a modificărilor DOM

Suprapunere A: Fișiere de remediere JavaScript pentru fiecare site

Această suprapunere menține un fișier JavaScript separat pentru fiecare site al clientului, care conține reguli destinate anumitor selectori CSS. În cele cinci site-uri pe care le-am analizat, am constatat:

Am constatat, de asemenea, că 7 cazuri unde șirul literal "true" a fost administrat sub formă de aria-label – o eroare de cod în care s-a transmis o valoare booleană în loc de text descriptiv. Cititoarele de ecran anunță „buton, true” – ceea ce nu are absolut niciun sens. Pe un alt site, cuvântul „Search” a fost scris greșit, ca „Seacrh”, într-o etichetă inserată.

Suprapunere B: Text alternativ generat de IA la scară largă

Această suprapunere descarcă fișiere JSON de dimensiuni mari care conțin descrieri ale imaginilor generate de inteligența artificială. De pe trei site-uri:

Exemple concrete din datele privind remedierea:

323 de descrieri depășeau 125 de caractere – ceea ce ducea la o citire excesiv de detaliată din partea cititorului de ecran, care rămânea la o singură frază timp de 10–15 secunde pentru fiecare imagine. 156 dintre ele începeau în mod redundant cu „imaginea lui” – un anti-model conform WCAG, întrucât cititoarele de ecran anunță deja tipul elementului.

Instrument de monitorizare: Fără modificări – verificat în codul sursă

Ce înseamnă „Ascunde de AT” pentru utilizatorii reali

Atunci când o suprapunere ascunde un element de tehnologiile de asistență, elementul rămâne vizibil pe ecran, dar devine complet invizibil pentru cititoarele de ecran. Am clasificat fiecare element ascuns în funcție de zona paginii pe care o afectează:

Date provenite din fișierele de remediere active.js reale, extrase pentru fiecare site prin intermediul mitmproxy. Fiecare valoare reprezintă un selector CSS unic vizat de funcția hideFromAT().

Pe pagina de finalizare a comenzii unui magazin de lux, elementele ascunse de cititoarele de ecran includeau:

Astfel, instrumentele de suprapunere pentru accesibilitate creează o experiență de cumpărături pe două niveluri: utilizatorii văzători văd toate opțiunile de plată și pot alege între card de credit, PayPal, Amazon Pay, Shop Pay și Klarna. Utilizatorii nevăzători pot găsi doar metodele de plată pe care suprapunerea nu le-a ascuns. La un magazin online de modă, câmpul de introducere a cantității din coș și butonul de actualizare erau amândouă ascunse – un utilizator nevăzător putea adăuga articole, dar nu putea modifica cantitățile.

Aceasta ridică o întrebare fundamentală: o suprapunere care ascunde butoanele de plată de utilizatorii nevăzători face site-ul mai accesibil sau mai puțin accesibil?

Impactul asupra performanței

Ce se întâmplă după implementarea unui site

Poate că cel mai insidios risc al instrumentelor de suprapunere devine vizibil abia în timp: soluțiile aplicate se deteriorează în tăcere. Spre deosebire de o eroare JavaScript care blochează vizibil aplicația sau de un aspect defectuos pe care cineva îl observă, o soluție de suprapunere învechită nu generează nicio eroare, nicio alertă și nicio schimbare vizuală. Pur și simplu încetează să mai funcționeze – iar bariera de accesibilitate pe care o masca reapare fără ca nimeni să-și dea seama.

Pentru a înțelege acest lucru, ia în considerare modul în care fiecare tip de suprapunere se integrează în structura DOM a site-ului tău.

Soluții bazate pe selector: Timpul trece

Overlay A – la fel ca majoritatea soluțiilor de suprapunere pentru accesibilitate – menține fișiere JavaScript de remediere specifice fiecărui site, care conțin reguli de genul acesta (reconstruite pe baza codului capturat efectiv):

Această regulă vizează butonul cu săgeată de revenire al caruselului Slick, utilizând trei clase CSS: .js-recommendation_carousel, .slick-prevși .slick-arrow. Fiecare componentă a acestui selector este vulnerabilă. Dacă echipa care se ocupă de site redenumește clasa containerului caruselului, trece de la Slick la Splide sau Swiper sau pur și simplu actualizează biblioteca Slick la o versiune care modifică convenția de denumire a claselor, selectorul nu mai găsește nimic. Butonul își pierde eticheta „Slide anterior”. Utilizatorii cititoarelor de ecran nu îl mai pot identifica.

În cele cinci locații pe care le-am analizat pentru Overlay A, am constatat că 98% dintre selectori conțin nume de clase specifice unui anumit framework – cursuri care încep cu .js-, .b-, .chakra-, .splide__, sau hash-uri CSS-în-JS precum .css-acuo7n. Acestea nu sunt identificatori semantici stabili – sunt detalii de implementare care se schimbă la fiecare actualizare a framework-ului, refactorizare a componentelor sau modificare a sistemului de compilare.

La un retailer de genți de mână de designer, am descoperit selectori care vizează componentele Chakra UI. Chakra UI lansează modificări radicale în versiunile majore – numele claselor, structura componentelor și modelele ARIA evoluează toate. Când acest site actualizează Chakra, sute de reguli de remediere a suprapunerilor riscă să nu mai funcționeze fără ca utilizatorul să observe. Furnizorul de overlay-uri trebuie apoi să verifice manual noua structură DOM, să rescrie fiecare selector afectat și să implementeze fișierele de remediere actualizate. În perioada dintre implementarea site-ului și actualizarea furnizorului de overlay-uri, site-ul funcționează cu remedieri învechite – unele fără niciun efect, altele aplicându-se potențial elementelor greșite.

Soluții bazate pe URL: și mai instabile

Suprapuneți cheile JSON de remediere din fișierul B peste fiecare intrare de text alternativ, înlocuind-o cu adresa URL exactă a sursei imaginii. Am găsit intrări de genul:

Observați fragilitatea: adresa URL conține un ID de dispozitiv (13555), dimensiunea miniaturii (86x86), precum și un nume de fișier care include denumirea produsului. Oricare dintre aceste elemente se poate modifica independent. Dacă sistemul CMS regenerează miniaturile la o dimensiune diferită, atunci thumb_86x86 o parte din adresa URL se modifică, iar înregistrarea nu mai corespunde. Dacă echipa de produs încarcă o nouă fotografie cu un nume de fișier diferit, înregistrarea rămâne orfană. Dacă site-ul își migrează fișierele media către un CDN cu un domeniu diferit, fiecare înregistrare din fișierul JSON de 1,17 MB devine o povară inutilă – iar toate imaginile de pe site își pierd simultan textul alternativ.

Cel mai rău scenariu este o potrivire parțială eșuată: unele imagini își păstrează vechile adrese URL (și primesc text alternativ), în timp ce imaginile noi sau actualizate nu corespund niciunei intrări (și nu primesc nimic). Rezultatul este o experiență inconsecventă, în care unele imagini sunt descrise, iar altele sunt omise fără nicio mențiune – ceea ce este mult mai derutant pentru un utilizator de cititor de ecran decât o absență consecventă a textului alternativ.

Remediere la nivel global: problema cascadei

Abordarea Overlay C – atașarea unui MutationObserver la întregul document și aplicarea unor remedieri generice tuturor elementelor de anumite tipuri (a, button, input, img, h1) – generează un tip de eroare diferit, dar la fel de periculos. În loc să se defecteze în tăcere atunci când selectorii devin expirați, această suprapunere lucrează intens la un cod nou.

Să luăm în considerare un scenariu obișnuit: echipa responsabilă de site implementează o nouă componentă de dialog modal accesibilă, care pune în aplicare corect funcțiile de reținere a focalizării, închiderea prin apăsarea tastei Escape și atributele ARIA. MutationObserver-ul suprapunerii detectează noile elemente DOM, le evaluează în raport cu regulile sale generice și – găsind elemente care se potrivesc cu modelele sale – își aplică propriile mecanisme de gestionare a focalizării, propriile rutine de gestionare a tastaturii și propriile atribute ARIA peste implementarea existentă și corectă a componentei. Rezultatul este un focus capturat de două ori, gestionări de tastatură duplicate și atribute ARIA conflictuale. Fereastra modală care funcționa perfect înainte de încărcarea overlay-ului se comportă acum eratic.

Nu este vorba doar de o preocupare teoretică. Bibliotecile de componente de tip framework, precum Radix UI, Headless UI și Chakra UI, dedică eforturi tehnice considerabile implementării corecte a standardului ARIA. O suprapunere care aplică în mod generalizat propriile atribute ARIA tuturor button și a este probabil ca aceste elemente să intre în conflict cu aceste implementări bine testate, ceea ce face ca componentele să fie accesibile în mod corect mai puțin accesibil.

Instrumentul de monitorizare: Nu există nimic de stricat

Instrumentul de monitorizare pe care l-am analizat nu conține remedieri bazate pe selectori, intrări legate de URL-uri, MutationObserver și nici țintirea elementelor generice. Atunci când site-ul implementează cod nou, următoarea scanare a instrumentului de monitorizare evaluează automat noul DOM în raport cu setul standardizat de reguli al axe-core și raportează orice încălcări noi – fără a modifica nimic. Rezultatele scanării apar în tabloul de bord al instrumentului, împreună cu nivelurile de gravitate, numărul de elemente afectate și ID-urile standardizate ale regulilor WCAG. Dezvoltatorii examinează rezultatele și implementează remedierile în propria bază de cod, unde acestea trec prin revizuirea codului, testarea automată, validarea în mediul de testare și implementarea controlată.

Acest proces este, prin natura sa, adaptabil la schimbări: instrumentul analizează structura DOM existentă în momentul scanării, semnalează problemele identificate și începe de la zero la următoarea scanare. Nu există o „datorie tehnică” acumulată legată de definițiile soluțiilor, nici selectori învechiți, nici intrări de text alternativ orfane și nici posibilitatea de a aplica o soluție greșită unui element greșit.

Ce se strică atunci când reinstalezi

Fiecare remediere a suprapunerii de accesibilitate este legată de structura DOM actuală a site-ului. Am constatat că 98% dintre selectorii unui overlay vizează nume de clase specifice cadrului – cursuri precum .chakra-, .splide__, .js-, .b-și hash-uri CSS-in-JS precum .css-acuo7n care se modifică la fiecare compilare.

Instrumentul de monitorizare afișează „Neafectat” în fiecare rând, deoarece nu conține nicio remediere bazată pe selectori. Nu există nimic care să devină învechit, nimic care să vizeze un element greșit, nimic care să provoace erori.

GDPR, confidențialitatea și problema consimțământului

Analiza noastră a confirmat că trei dintre cele patru ferestre de accesibilitate transmit date către servere externe înainte ca utilizatorul să poată interacționa cu orice banner de consimțământ:

Conform hotărârii CJUE în cauza Planet49, urmărirea neesențială necesită consimțământul prealabil expres. Două ferestre pop-up transmit identificatori permanenți încă de la prima solicitare de rețea – înainte ca vreun mecanism de obținere a consimțământului să poată fi activat. Pentru site-urile destinate utilizatorilor din UE, aceasta constituie o încălcare automată a RGPD.

Cadrul juridic

În aprilie 2025, Comisia Federală pentru Comerț din SUA (FTC) a finalizat o înțelegere în valoare de 1 milion de dolari împotriva unuia dintre furnizorii de soluții de accesibilitate incluși în studiul nostru, pentru că a afirmat în mod eronat că instrumentul său bazat pe IA ar putea asigura conformitatea oricărui site web cu standardele WCAG. FTC a constatat că instrumentul nu a reușit să asigure accesibilitatea componentelor de bază ale site-ului web – meniuri, titluri, tabele, imagini și înregistrări. Într-un exemplu citat, o fotografie a unui filet mignon a primit descrierea generată de IA „Pâine neagră pe farfurie de ceramică albă”.

Conform datelor de monitorizare din sector, 25% din totalul proceselor privind accesibilitatea digitală din 2024 au menționat în mod explicit widgeturile de tip overlay ca fiind bariere – nu soluții. În prima jumătate a anului 2025, procesele împotriva companiilor care utilizează overlay-uri au continuat să depășească 100 pe lună. Doi dintre furnizorii de overlay din studiul nostru au fost implicați direct în litigii: unul în trei cazuri separate de brevete/secrete comerciale, iar altul confruntându-se cu o acțiune colectivă din partea unui client de tip întreprindere mică care a fost dat în judecată în ciuda utilizării overlay-ului.

Instrumentul de monitorizare utilizat în studiul nostru nu are antecedente de litigii legate de probleme de accesibilitate – o consecință logică a arhitecturii sale: întrucât nu modifică niciodată DOM-ul, nu poate crea bariere de accesibilitate.

În detaliu: Ce modifică de fapt suprapunerile

Pentru a înțelege amploarea manipulării DOM, am numărat toate tipurile de modificări din codul JavaScript al fiecărui instrument. Diferențele sunt semnificative:

Overlay C merită o atenție specială. Pachetul său monolitic de 794 KB include un MutationObserver spre document.documentElement cu configurația {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Asta înseamnă fiecare modificare DOM de pe întreaga pagină – fie că provine din reconcilierea DOM-ului virtual al React, dintr-un script de testare A/B, dintr-un widget de chat sau din propriul cod JavaScript al site-ului – declanșează observatorul suprapunerii, care apoi reevaluează și, eventual, reaplică corecțiile sale. După o redeployare a site-ului, acest lucru generează o serie de încercări de corectare a elementelor care ar putea fi deja accesibile în mod corect, existând riscul ca atributele ARIA corecte să fie suprascrise cu unele incorecte.

Am confirmat că Overlay C transmite USER-BEHAVIOR-ANALYTICS Trimite cereri POST către propriul receptor de jurnale, cu date utile care conțin domeniul site-ului, versiunea widgetului, limba utilizatorului și evenimentele de interacțiune. În combinație cu localStorage persistența și identificarea dispozitivelor prin intermediul navigator.userAgent și navigator.maxTouchPoints, aceasta reprezintă o operațiune de prelucrare a datelor de care majoritatea operatorilor de site-uri nu sunt conștienți.

Rezolvarea problemei cu fișierul JSON

Overlay B descarcă un fișier JSON de dimensiuni mari (până la 1,17 MB pentru un singur site de telecomunicații) care conține toate definițiile de remediere. Pe unul dintre site-uri, am observat că acesta a fost descărcat de patru ori în cadrul aceleiași sesiuni de navigare – 4,7 MB de lățime de bandă pentru un fișier care ar fi trebuit să fie stocat în cache. Fișierul JSON conține 11 categorii, dar marea majoritate sunt descrieri de imagini generate de IA: 4.974 din 6.975 de intrări pentru un singur site. Fiecare este asociată cu o adresă URL specifică a imaginii – când CMS-ul redenumește un fișier, modifică dimensiunile miniaturilor sau migrează domeniile CDN, intrările încetează să mai corespundă fără ca utilizatorul să observe. Imaginile de înlocuire nu primesc deloc text alternativ, ceea ce face ca pagina să fie mai puțin accesibilă decât înainte de instalarea overlay-ului.

Această suprapunere implementează, de asemenea, module de execuție care rescriu în mod activ pagina: un motor de remediere de 110 KB, un modul auxiliar pentru meniul de navigare de 23 KB care restructurează gestionarea meniului prin tastatură, un patch pentru carusel de 5,8 KB și un scaner pe partea clientului de 53 KB care utilizează o logică proprie în locul motorului standard din industrie, axe-core – ceea ce înseamnă că rezultatele sale nu pot fi verificate independent.

Cea mai transparentă suprapunere – totuși riscantă

Overlay D avea cea mai transparentă arhitectură: fișiere de configurare JSON ușor de înțeles, cu comenzi explicite de activare/dezactivare. Opțiuni precum addAriaHidden, overwriteAltși adjustMetaViewport au fost setate în mod explicit la false. Cu toate acestea, motorul de bază (649 KB) conține 216 setAttribute apeluri, 47 aria-hidden referințe, 282 addEventListener înregistrări și 9 MutationObserver instanțe. Motorul acceptă modificări agresive ale DOM chiar și în cazul în care configurația actuală este conservatoare – o modificare a configurației efectuată de furnizor ar putea activa funcții riscante fără știrea administratorului site-ului.

Am găsit selectori specifici pentru fiecare site care conțin sufixe hash generate de JavaScript, cum ar fi button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 care se modifică la fiecare versiune, precum și selectorii de URL-uri pentru rețelele sociale, care devin nevalide atunci când site-ul își actualizează linkurile către Facebook sau Instagram.

Legea europeană privind accesibilitatea: De ce suprapunerile nu vor îndeplini cerințele EAA

Începând cu 28 iunie 2025, Legea europeană privind accesibilitatea (EAA) impune ca produsele și serviciile digitale comercializate în UE să respecte standardele de accesibilitate aliniate la EN 301 549, care face referire la WCAG 2.1 AA. Spre deosebire de ADA – care este aplicată în principal prin acțiuni în justiție inițiate de persoane fizice – EAA este aplicată de autoritățile naționale de supraveghere a pieței, care au competența de a aplica amenzi, de a dispune măsuri corective și de a retrage de pe piață produsele neconforme.

Respingerea oficială de către Germania a instrumentelor de suprapunere

Germania a adoptat cea mai clară poziție legislativă dintre toate țările în ceea ce privește instrumentele de accesibilitate de tip overlay. BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – organismul federal german de monitorizare a accesibilității tehnologiei informației – împreună cu toate organismele de monitorizare de la nivel de land, a emis o evaluare comună prin care respinge în mod explicit utilizarea instrumentelor de tip overlay pentru asigurarea conformității cu standardele de accesibilitate:

La 12 martie 2025, Comitetul pentru Tehnologia Informației Accesibile (Ausschuss für barrierefreie Informationstechnik, înființat în temeiul articolului 5 din BITV 2.0) și-a reafirmat această poziție în cadrul ședinței sale, exprimându-și îngrijorarea cu privire la faptul că organismele publice continuă să încerce să își îndeplinească obligațiile în materie de accesibilitate prin integrarea unor instrumente de suprapunere. Comitetul a concluzionat că „o redare temporară accesibilă a unui site web prin intermediul unui software – eventual numai după ce setările sunt configurate de utilizator – pe durata vizitei acestuia nu îndeplinește cerințele dispozițiilor legale aplicabile.”

Comitetul a avertizat în mod explicit că organismele publice care utilizează instrumente de suprapunere riscă să facă site-urile lor web mai puțin accesibile, nu mai accesibile – ceea ce duce la o deteriorare a accesibilității („Verschlechterung der Barrierefreiheit”). Acest lucru reflectă în mod direct constatarea noastră tehnică conform căreia 26 % dintre regulile de remediere prin suprapunere introduc noi încălcări ale WCAG.

Sigiliul de testare BIK: respins pentru site-urile web care utilizează suprapuneri

Rețeaua germană de testare BIK – organismele acreditate care evaluează site-urile web în conformitate cu BITV 2.0, EN 301 549 și WCAG 2.1 AA – a luat o măsură concretă: site-urile web care utilizează instrumente de suprapunere nu pot primi sigiliul de testare BIK. Organismele de testare au declarat că nu pot efectua o evaluare fiabilă a conformității atunci când este prezent un overlay, deoarece acesta modifică DOM-ul în timpul rulării în moduri care fac ca rezultatele testului să fie nesigure. Sigiliul BIK este utilizat pe scară largă în Germania ca dovadă a conformității cu BITV 2.0 – și acum nu mai este disponibil pentru niciun site web care utilizează un overlay.

Nu este vorba de o problemă teoretică de natură politică. Aceasta înseamnă că un site german de comerț electronic care utilizează oricare dintre cele patru ferestre suprapuse pe care le-am testat nu poate obține certificarea de conformitate standard utilizată pe piața germană.

Confirmare la nivel european

Această poziție normativă depășește granițele Germaniei. Forumul European al Persoanelor cu Dizabilități și Asociația Internațională a Profesioniștilor în Accesibilitate au emis o declarație comună în 2023, în care avertizau că suprapunerile de accesibilitate nu fac site-urile web accesibile și nici nu le asigură conformitatea cu legislația europeană în materie de accesibilitate, inclusiv cu Actul european privind accesibilitatea. Comisia Europeană s-a pronunțat, de asemenea, cu privire la afirmațiile privind conformitatea suprapunerilor, concluzionând că acestea nu pot asigura respectarea standardelor aplicabile.

În conformitate cu Legea germană privind consolidarea accesibilității (BFSG – Barrierefreiheitsstärkungsgesetz), care transpune în legislația germană Acordul privind accesibilitatea electronică (EAA) și este în vigoare din 28 iunie 2025, autoritățile de supraveghere a pieței pot aplica amenzi cuprinse între 10.000 și 100.000 de euro pentru fiecare încălcare. Evaluarea BFIT-Bund și refuzul rețelei de testare BIK de a certifica site-urile care utilizează overlay-uri înseamnă, în practică, că instrumentele de overlay nu oferă nicio acoperire normativă în Germania – și pot crește în mod activ riscul de a face obiectul unor măsuri de aplicare a legii.

Securitatea și riscurile legate de lanțul de aprovizionare

Fiecare instrument de suprapunere funcționează prin inserarea de cod JavaScript de la terți în domeniul global al paginilor dvs. de producție. Acest cod JavaScript rulează cu aceleași privilegii ca și codul dvs. propriu – poate citi și modifica orice element DOM, poate intercepta trimiterile de formulare, poate accesa cookie-urile, poate redirecționa utilizatorii și poate sustrage date. Implicațiile de securitate ale acestei configurații sunt semnificative și adesea trecute cu vederea.

Suprafața de atac

Luați în considerare lanțul de aprovizionare: atunci când adăugați un modul de accesibilitate pe site-ul dvs., acordați unui furnizor terț acces continuu și nelimitat de scriere la DOM-ul dvs. de producție activ. CDN-ul furnizorului găzduiește fișierul JavaScript, echipa furnizorului se ocupă de întreținerea codului, iar fluxul de implementare al furnizorului trimite actualizările direct pe site-ul dvs. – fără revizuirea codului de către dvs., fără procesul dvs. de control al calității și fără aprobarea dvs.

Dacă rețeaua CDN a furnizorului de servicii de overlay este compromisă, atacatorul capătă posibilitatea de a injecta cod rău intenționat în fiecare site care utilizează acel overlay. Dacă un angajat al furnizorului lansează o actualizare defectuoasă, toate site-urile clienților sunt afectate simultan. Dacă punctul final al API-ului furnizorului este deturnat, fișierul JSON de remediere sau datele de configurare furnizate site-ului dumneavoastră pot fi manipulate pentru a modifica câmpurile formularelor, a redirecționa linkurile sau a injecta conținut de phishing.

Amploarea acestui risc este direct proporțională cu amprenta DOM a suprapunerii:

Overlay B prezintă cea mai mare suprafață de risc din lanțul de aprovizionare: 228 de apeluri API pe sesiune, distribuite pe 3 domenii externe, cu o încărcătură JSON de 1,17 MB care definește modul în care trebuie modificat DOM-ul. Un răspuns API compromis ar putea instrui motorul de remediere să injecteze conținut arbitrar în orice element de pe pagină. Pachetul monolitic de 1.285 KB al suprapunerii C este cea mai mare sarcină utilă JavaScript unică – și, deoarece este minificat și ofuscat, nici operatorul site-ului, nici un auditor de securitate nu pot examina în mod semnificativ ce execută acesta în timpul rulării.

Conformitatea cu standardul PCI DSS: Un conflict direct

Pentru orice site de comerț electronic care procesează plăți cu cardul de credit, conformitatea cu standardul PCI DSS nu este opțională. Iar concluziile noastre evidențiază un conflict direct între arhitectura instrumentelor de accesibilitate de tip overlay și cerințele standardului PCI DSS.

Cerința 6.4.3 din PCI DSS (introdusă în PCI DSS v4.0, obligatorie începând cu 31 martie 2025) prevede ca toate scripturile paginilor de plată care se încarcă și se execută în browserul consumatorului să fie gestionate după cum urmează: trebuie implementată o metodă pentru a confirma că fiecare script este autorizat, trebuie asigurată integritatea fiecărui script și trebuie menținut un inventar al tuturor scripturilor, însoțit de o justificare scrisă a necesității fiecăruia.

Analiza noastră a confirmat că regulile de remediere a suprapunerilor vizează în mod activ elementele DOM ale paginilor de plată de pe mai multe site-uri:

Nu este vorba de un risc teoretic – acestea sunt reguli concrete pe care le-am identificat în mediile de producție, care modifică în mod activ câmpurile pentru numerele de carduri de credit, selectorii de adrese de facturare, butoanele furnizorilor de servicii de plată și elementele care conțin formularele de finalizare a comenzii. Conform standardului PCI DSS 6.4.3, fiecare dintre aceste scripturi ale unor terți necesită o autorizare documentată, o verificare a integrității și o justificare scrisă.

Gândiți-vă la ce poate face scriptul unui furnizor de suprapuneri pe pagina dvs. de finalizare a comenzii:

În schimb, instrumentul de monitorizare nu are nicio capacitate de scriere în DOM. Scriptul său de 4,2 KB nu poate modifica câmpurile formularelor, nu poate intercepta evenimentele de introducere a datelor și nu poate accesa sau modifica elementele din procesul de finalizare a comenzii. Chiar dacă rețeaua CDN a furnizorului de servicii de monitorizare ar fi compromisă, atacatorul ar avea acces doar la un script care poate citi doar adresa URL a paginii și tipul dispozitivului – nu la unul care poate rescrie formularul de finalizare a comenzii. În ceea ce privește stabilirea domeniului de aplicare PCI DSS, instrumentul de monitorizare nu creează nicio suprafață de risc suplimentară pe paginile de plată.

Problema discriminării

Aceasta este problema discriminării care stă la baza oricărei soluții de accesibilitate: cea mai îngrijorătoare constatare nu este un defect tehnic, ci un model de refuz sistematic al accesului utilizatorilor cu dizabilități la funcționalități pe care utilizatorii fără dizabilități le consideră de la sine înțelese.

Atunci când o fereastră suprapusă ascunde butonul Amazon Pay din arborele de accesibilitate, un utilizator nevăzător vede mai puține opțiuni de plată decât un utilizator văzător. Atunci când câmpul de introducere a cantității din coș este ascuns, un utilizator nevăzător nu își poate modifica comanda. Atunci când linkurile către rezultatele căutării sunt ascunse, găsirea produselor este îngreunată. Atunci când evaluările cu stele sunt ascunse, un utilizator nevăzător nu poate evalua calitatea produsului la fel ca un utilizator văzător.

Nu este vorba de cazuri marginale – ci de fluxuri de lucru esențiale din domeniul comerțului electronic, care sunt afectate tocmai de instrumentele care promit să le facă accesibile.

Comunitatea persoanelor cu dizabilități atrage atenția asupra acestui aspect de ani de zile. Fișa informativă privind suprapunerile – semnată de sute de specialiști în accesibilitate – avertizează că suprapunerile de accesibilitate „nu remediază codul HTML de bază” și „adesea constituie un obstacol real pentru persoanele cu dizabilități”. Analiza noastră tehnică oferă dovezi: 141 de elemente funcționale ascunse de cititoarele de ecran, 7 etichete fără sens inserate și 5.066 de descrieri AI neverificate implementate în producție – pe doar 14 site-uri.

Pentru administratorii de site-uri, întrebarea nu este dacă suprapunerile sunt „suficient de bune”, ci dacă se poate justifica implementarea unui instrument care creează o experiență pe două niveluri: o versiune pentru utilizatorii văzători, care beneficiază de funcționalitate completă, și o versiune filtrată, defectuoasă și, uneori, fără sens pentru utilizatorii cu dizabilități.

Impactul asupra conformității cu ADA: Aceste remedieri sunt cu adevărat utile?

Promisiunea fundamentală a oricărei suprapuneri este aceea că îmbunătățește conformitatea cu ADA prin remedierea încălcărilor WCAG în timpul rulării. Însă analiza noastră relevă un paradox îngrijorător: un procent semnificativ dintre remediile oferite de suprapuneri introduc în mod activ noi încălcări ale WCAG în timp ce încearcă să le remedieze pe cele existente.

Am corelat fiecare regulă de remediere identificată din Overlay A cu criteriul de succes specific din WCAG 2.1 pe care îl vizează. Din cele 776 de reguli care au putut fi corelate, rezultatele s-au împărțit în două categorii: remedieri care rezolvă efectiv o problemă WCAG și remedieri care generează o nouă încălcare a WCAG în acest proces.

Ca să fim corecți, trei sferturi dintre modificările identificate reprezintă îmbunătățiri reale – adăugarea etichetelor butoanelor lipsă, corectarea ierarhiilor titlurilor, rectificarea atributelor de completare automată și implementarea mecanismelor de captare a focalizării în ferestrele modale. Însă restul de un sfert are un efect dăunător, iar acest efect se răsfrânge în mod disproporționat asupra tocmai a acelor utilizatori pe care instrumentul pretinde că îi ajută.

Modul în care fiecare model riscant încalcă WCAG

Problema nu este doar că aceste soluții nu funcționează, ci că ele generează încălcări ale anumitor criterii de conformitate WCAG care nu existau înainte de aplicarea suprapunerii. Într-un proces intentat în temeiul ADA, expertul reclamantului poate invoca aceste încălcări generate de suprapunere ca dovadă a faptului că site-ul discriminează persoanele cu dizabilități.

Suprapunere B: Text alternativ generat de IA și WCAG 1.1.1

WCAG 1.1.1 prevede ca conținutul non-textual să aibă o „alternativă text care să îndeplinească același scop”. Un text alternativ generat de IA care descrie logo-ul unei companii ca „un semn albastru și galben” nu servește scopului echivalent – scopul unui logo este identificarea mărcii, nu descrierea culorii. Un text alternativ de tipul „text” pentru un banner promoțional sau „oraș” pentru o imagine principală nu îndeplinește același criteriu într-un mod diferit – este atât de vag încât devine inutil.

Dintre cele 5.068 de texte alternative generate de IA pe care le-am capturat din Overlay B, 241 aveau mai puțin de 15 caractere (prea vagi pentru a fi utile), 323 depășeau 125 de caractere (încălcând bunele practici privind accesibilitatea cititoarelor de ecran), iar 156 începeau cu „imaginea” sau „fotografia” (redundante, deoarece cititoarele de ecran anunță deja tipul elementului). Doar 2 au fost aprobate de un evaluator uman.

Conform standardelor procesuale prevăzute de ADA, un expert în accesibilitate al reclamantului ar identifica aceste aspecte ca fiind încălcări ale criteriului WCAG 1.1.1 – cel mai frecvent invocat criteriu în procesele privind accesibilitatea web în temeiul ADA. Suprapunerea nu remediază încălcarea; aceasta înlocuiește o formă de neconformitate (lipsa textului alternativ) cu o alta (text alternativ inexact sau vag), creând în același timp o falsă impresie de conformitate pentru operatorul site-ului.

Suprapunere B: Injectarea etichetelor de formular în timpul rulării – când „repararea” agravează situația

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.

Cu motorul de remediere al Overlay B activat, un cititor de ecran a anunțat:

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

Rezultatul este mai prost decât formularul inițial fără etichete. Înainte de aplicarea suprapunerii, un utilizator de cititor de ecran se confrunta cu șapte câmpuri fără etichete – o situație confuză, dar cel puțin consecventă. Acesta putea folosi ordinea de navigare cu tasta Tab și contextul pentru a ghici care câmp este care. După intervenția suprapunerii, utilizatorul întâlnește două câmpuri cu aceeași etichetă („Nume” atât pentru Prenume, cât și pentru Nume de familie), două câmpuri cu etichete fabricate în stil de validare care nu se potrivesc cu textul vizibil și trei câmpuri cu nume fără sens, bazate pe tipul de caractere. Etichetarea parțială și incorectă este mai dezorientantă decât lipsa totală a etichetării, deoarece creează o impresie falsă că formularul a fost făcut accesibil, în timp ce câmpurile critice rămân neetichetate sau etichetate greșit.

Această constatare evidențiază, de asemenea, o lacună în fișierul JSON de remediere al Overlay B. Fișierul JSON conținea 87 de intrări de text alternativ generate de IA și zero intrări de remediere a formularelor pentru acest site. Injectarea etichetelor formularului are loc în întregime în timpul rulării prin intermediul handlerului de reguli EmptyControls – nu este vizibilă în fișierul JSON de remediere consolidat, nu este urmărită în niciun tablou de bord pe care operatorul site-ului îl poate verifica și nu este supusă aprobării umane. Operatorul site-ului nu are nicio modalitate de a ști că formularul său de contact este etichetat greșit, cu excepția cazului în care îl testează el însuși cu un cititor de ecran.

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.

Efectul net al conformității cu ADA

Problema fundamentală este că instrumentele de suprapunere confundă acoperirea cu conformitatea. O suprapunere poate indica 1.058 de reguli de remediere și poate susține că acoperă peste 40 de criterii de succes WCAG. Însă, atunci când 26% dintre aceste remedieri introduc noi încălcări – inclusiv nerespectări de nivel A generate prin ascunderea elementelor funcționale –, nivelul net de conformitate poate fi mai slab decât în cazul site-ului nemodificat.

Un site fără fereastră suprapusă care prezintă 50 de încălcări ale standardelor WCAG se află într-o situație juridică mai clară decât un site cu fereastră suprapusă care prezintă 30 de încălcări inițiale plus 203 de încălcări generate de fereastra suprapusă – deoarece încălcările generate de fereastra suprapusă demonstrează că operatorul site-ului a implementat un instrument care discriminează în mod activ utilizatorii cu dizabilități, ceea ce subminează orice apărare bazată pe bună-credință.

Concluzia