Kép leírása: Egy kéz, amely feltárja az „Overlay tools revealed” feliratot, jelezve az akadálymentesítési átfedő eszközök megjelenítését.
Öt akadálymentesítési eszköz összes kérését megfigyeltük. Íme, mit is tesznek valójában a webhelyeddel.
Öt akadálymentesítési eszköz összes kérését megfigyeltük. Íme, mit is tesznek valójában a webhelyeddel.
Négy akadálymentesítő overlay és egy kizárólag megfigyelésre szolgáló megoldás független műszaki vizsgálata – mit változtatnak valójában, mit rejtenek el a fogyatékkal élő felhasználók elől, és miért perelték be csak 2024-ben több mint 1000 olyan vállalatot, amelyek overlay-eket használnak.
Amit találtunk, amikor belenéztünk
Minden eredmény a rögzített termelési forgalom alapján készült – 924 kérés, 579 teljes válaszszöveg, 14 aktív e-kereskedelmi webhelyről, valamint a beépített átfedési módosításokat tartalmazó, elmentett DOM-pillanatképek alapján.
Hogyan jártunk el: A kutatási módszertan
Az akadálymentesítési kiegészítőkről szóló legtöbb értékelés marketinges állításokra, a gyártók dokumentációjára vagy felületes tesztelésre támaszkodik. Mi egy alapvetően eltérő megközelítést alkalmaztunk: minden egyes adatbájtot rögzítettünk, amely a böngésző és az egyes eszközök szerverei között áramlott, kivontuk a tényleges JavaScript-javítófájlokat és a javítási adatokat, majd pontosan elemeztük, hogy az egyes eszközök mit tesznek az élesben működő e-kereskedelmi weboldalak DOM-jával.
A műszaki felépítés
Telepítettük a mitmproxy-t – egy nyílt forráskódú HTTPS-proxyt –, amelyet úgy konfiguráltunk, hogy rögzítse az eszközök CDN- és API-domainjei felé irányuló összes forgalom teljes kérés- és válaszadattestét. A böngészőbe telepítettük a proxy gyökér CA-tanúsítványát az átlátszó HTTPS-lehallgatás lehetővé tétele érdekében, majd elindítottunk egy külön Chrome-példányt, amely kizárólag a proxyn keresztül irányult. Domain-szűrőket állítottunk be úgy, hogy azok csak az akadálymentesítési eszközök szervereire irányuló forgalmat rögzítsék – így biztosítva, hogy kizárólag az eszközök által beillesztett adatokat elemezzük, nem pedig a webhelyek saját forgalmát.
Ezt követően 14 aktív e-kereskedelmi webhelyet böngésztünk úgy, ahogyan egy átlagos felhasználó tenné: betöltöttük a kezdőlapot, átnavigáltunk a termékek listáját tartalmazó oldalakra, megtekintettük a termékleírásokat, termékeket tettünk a kosárba, továbbhaladtunk a pénztárhoz, felkerestük a fiók- és regisztrációs oldalakat, valamint kipróbáltuk a felugró ablakokat, a karusszeleket és a keresőt. Minden böngészési munkamenetet HTTP Archive (HAR) fájlként rögzítettünk a teljes válaszszöveggel – ugyanabban a formátumban, amelyet a böngészők belsőleg használnak, de kiegészítve minden JavaScript-fájl, minden CSS-stíluslap, minden JSON-konfiguráció és minden API-válasz tényleges tartalmával, amelyet az eszközök szolgáltattak.
Az adatok begyűjtése után Python-elemző szkripteket írtunk, amelyek feldolgozták az összes válasz testét, eszköz és funkció szerint osztályozták az egyes fájlokat, kivonták az összes CSS-szelektort a javítások leírásaiból, megszámolták az összes DOM-manipulációs mintát a JavaScript-kódban, azonosították az összes olyan tartalmat, amelyet a segítő technológiák elől elrejtettek, és minden javítást hozzárendeltünk ahhoz az oldalrészhez, amelyre hatással van (pénztár, kosár, terméklista, navigáció stb.).
A mitmproxy a teljes válaszadatokkal együtt fogja el a HTTPS-forgalmat
14 webhelyet böngésztem át, minden oldaltípusból
Kivontam az összes JS-, CSS- és JSON-fájlt a válaszokból
A javítási szabályok, szelektorok és ARIA-módosítások elemzése
Oldalrész, kockázati szint és törésveszély szerint csoportosítva
A proxy három rögzítési munkamenet során 924 HTTP-kérelmet rögzített, amelyekhez 579 teljes válaszszöveg tartozott – ideértve az egyes webhelyekhez tartozó összes javító szkriptet, minden javító JSON-fájlt, minden konfigurációs fájlt és minden elemzési adatcsomagot. Emellett elmentettük az átfedéses módosításokkal ellátott oldalak teljes DOM-pillanatképeit is, ami lehetővé tette számunkra, hogy megvizsgáljuk a futásidőben beillesztett pontos aria-label értékeket és gyártói adatattribútumokat. Ezután automatizált elemző szkripteket írtunk a JavaScript elemzésére, az összes DOM-módosítási minta számlálására, az összes CSS-szelektor kivonására, az összes javítás oldalrész szerinti osztályozására, valamint a segítő technológiák elől elrejtett tartalom minden példányának azonosítására.
Mit elemeztünk
| Szerszámtípus | JS-fájlok | CSS | JSON/Adatok | Összesen elemzett | Webhelyek |
|---|---|---|---|---|---|
| A réteg | 20 | 7 | 1 | 8 633 KB | 5 (divat, csokoládé, bőröndök, kézitáskák) |
| B réteg | 10 | 4 | 30 | 6 739 KB | 3 (telekommunikáció, webügynökség, banki szektor) |
| C réteg | 2 | 0 | 5 | 4 713 KB | 3 (divat, órák, édességek) |
| D réteg | 11 | 1 | 0 | 3 320 KB | 3 (játékok, italok, írószerek) |
| Felügyeleti eszköz | 23 | 0 | 4 | 2 334 KB | 8 projekt |
A weboldalak között szerepeltek nagy divatáruházak, luxuscsokoládé-márkák, bőröndgyártók, designer táskaboltok, játékgyártók, egy távközlési szolgáltató, egy nemzeti bank, valamint ital-, írószer-, óra- és édességmárkák – mind az uniós, mind az amerikai piacot lefedve.
Egy fontos észrevétel: Egyetlen akadálymentesítési felületen sem alkalmaznak oldalszintű hatályt
Az egyik legmeglepőbb eredmény még a javítási szabályok elemzése előtt kiderült: minden akadálymentesítési overlay az összes javítási szabályát betölti minden egyes oldalon, függetlenül az oldal típusától. A fizetési folyamatra vonatkozó javítások már a kezdőlapon is működésbe lépnek. A kosárban szereplő mennyiségre vonatkozó szabályok a „Rólunk” oldalon hajtódnak végre. A termékcsempékre vonatkozó javítások pedig a bejelentkezési űrlapon futnak.
| Eszköz | Mi töltődik be minden oldalon | Oldalhatályú? | Elpazarolt kivégzés |
|---|---|---|---|
| A réteg | Mind a 383 javítási szabály (a legnagyobb webhely) | Nem | A pénztár, a kosár és a termékekkel kapcsolatos javítások a kezdőlapon, a GYIK-oldalon és a kapcsolatfelvételi oldalakon is érvényesek |
| B réteg | A teljes 1,25 MB-os javító JSON-fájl | Nem | 4 974 kép alternatív szövege + 2 000 PDF-bejegyzés töltődik be minden oldalon |
| C réteg | 794 KB-os monolitikus csomag | Nem | Ugyanaz a kód, ugyanazok a megfigyelők, ugyanazok az általános szelektorok – minden oldalon |
| D réteg | Teljes konfiguráció + 649 KB-os motor | Nem | Minden szelektor kiértékelésre kerül, még akkor is, ha a célelemek nem szerepelnek az adott oldalon |
| Monitoring | 4,2 KB-os szkript + 1 jeladó | N/A – nincs javítás | Nincs – a szkennelés csak kérésre történik, nem minden látogató esetében |
Ez azt jelenti, hogy a távközlési szolgáltató webhelyén minden oldalra látogató felhasználó letölt egy 1,25 MB-os JSON-fájlt, amely 4 974 képleírást és 2 000 PDF-javítási bejegyzést tartalmaz – még azokon az oldalakon is, ahol egyáltalán nincs kép. A designer táskák kiskereskedőjénél minden oldal betöltésekor 383 DOM-javítási szabály fut le, megkísérelve olyan szelektorokat illeszteni, amelyek csak bizonyos oldaltípusokon léteznek. Amikor egy fizetéshez kapcsolódó szelektor, mint például a #cardNumber, nem talál egyezést a kezdőlapon, az átfedés javító motorja mégis CPU-ciklusokat fordít annak értékelésére – ez több száz szabályra szorozva mérhető teljesítményveszteséget okoz minden oldal megtekintésekor.
Az Overlay A a munkamenetek mindössze 4,5%-át vizsgálja
Az Overlay A elemzési POST-adatai között rábukkantunk egy mezőre, amely feltárta a rendszer tényleges szkennelési mintavételi gyakoriságát:
A 0,045-ös mintavételi arány azt jelenti, hogy ennél a divatkereskedőnél a látogatói munkamenetek mindössze 4,5%-a vált ki megfelelőségi vizsgálatot. Egy másik webhelyen – egy luxus csokoládémárkánál – ez az arány még alacsonyabb volt: csupán 1,7%. Lehetséges, hogy az overlay-szolgáltató a bevezetés vagy a beállítás során átfogóbb kezdeti vizsgálatot hajt végre, majd a folyamatos figyelemmel kísérés során csökkenti a mintavételi arányt. Ez azonban a napi működés szempontjából továbbra is jelentős következményekkel jár.
Az akadálymentességi overlay indítócsomag kódja három működési szintet erősít meg: ReleaseVersionReport (teljes vizsgálat + jelentés – a mintavételi arány), ShadowVersionReport (árnyékvizsgálat, a felhasználó számára nem látható művelet) és RunReleaseFixesNoReport (az összes javítási szabály alkalmazása, de vizsgálat nélkül). Ez azt jelenti, hogy normál működés közben a látogatók túlnyomó többsége olyan DOM-módosításokat kap, amelyek a munkamenetük során nem kerülnek érvényesítésre.
A gyakorlati kockázat a következő: ha egy webhely frissítése megváltoztatja a DOM-szerkezetet, és ezzel egy vagy több javítási szabályt megszeg, az alacsony folyamatos mintavételi arány miatt a hiba hosszú ideig észrevétlen maradhat. Mivel a munkamenetek csupán 1,7–4,5%-át vizsgálják át, egy hibás javítás több ezer látogatót érinthet, mire a következő mintavételi munkamenet véletlenül az érintett oldalon fut le, és jelzi a problémát. Ebben az időintervallumban minden látogató elavult vagy rosszul célzott javításokat kap – és sem a webhely üzemeltetője, sem az overlay-szolgáltató nem feltétlenül vesz észre a problémát.
Az eredmények: A szabályok és a DOM-módosítások kijavítása
(Overlay A, 5 webhely)
(B réteg, 3 helyszín)
” (felügyeleti eszköz) alkalmazásban
A. réteg: Helyszínenkénti JavaScript-javítófájlok
Ez az overlay minden ügyfélwebhelyhez külön JavaScript-javítófájlt tart fenn, amely bizonyos CSS-szelektorokra vonatkozó szabályokat tartalmaz. Az általunk elemzett öt webhelyen a következőket állapítottuk meg:
| A webhely típusa | Szabályok módosítása | hideFromAT | role=pres/none | alt=”” | Mindig bekapcsolva |
|---|---|---|---|---|---|
| Divatkiskereskedő | 59 | 12 | 1 | 3 | 42 |
| Csokoládémárka | 45 | 2 | 3 | 4 | 45 |
| Poggyásggyártó | 176 | 6 | 27 | 7 | 176 |
| Dizájner táskák (Egyesült Királyság) | 360 | 57 | 30 | 15 | 358 |
| Dizájner táskák (EU) | 383 | 64 | 54 | 34 | 381 |
| Összesen | 1,023 | 141 | 115 | 63 | 1,002 |
Ez az egyik legkárosabb viselkedésmód az akadálymentességi átfedő eszközöknél: a hideFromAT() Ez a függvény teljesen eltávolítja az elemeket a hozzáférhetőségi fából. Az elem továbbra is látható marad a képernyőn, de egy képernyőolvasót használó vak személy számára nem létezik. Megállapítottuk, hogy a fizetési gombok, a kosárvezérlők, a termékhivatkozások, a keresési eredmények, a csillagokkal jelzett értékelések, a navigációs nyomvonalak és a fizetési űrlapok el vannak rejtve.
Azt is megállapítottuk, hogy 7 eset ahol a karakterlánc "true" -t injekció formájában adták be aria-label – egy programhibát, amelynek következtében leíró szöveg helyett egy logikai érték került átadásra. A képernyőolvasók ezt így olvassák fel: „gomb, igaz” – ami teljesen értelmetlen. Egy másik webhelyen a „Search” szót egy beillesztett címkében „Seacrh”-nak írták.
B. réteg: Mesterséges intelligenciával generált alternatív szöveg nagy léptékben
Ez a kiegészítő hatalmas méretű, javító intézkedéseket tartalmazó JSON-fájlokat tölt le, amelyek mesterséges intelligenciával generált képleírásokat tartalmaznak. Három webhelyről:
0,04%
(„szöveg”, „fájl”, „város”)
Valódi példák a kármentesítési adatokból:
323 leírás haladta meg a 125 karaktert – ami miatt a képernyőolvasó túlzottan részletesen olvas fel, és képeknél 10–15 másodpercig monoton hangon olvas fel. 156 leírás feleslegesen az „image of” kifejezéssel kezdődött – ez a WCAG szerint nem megfelelő gyakorlat, mivel a képernyőolvasók már eleve bejelentik az elem típusát.
Ellenőrző eszköz: Nincs módosítás – a forráskódban ellenőrizve
Kivontuk a monitorozó eszköz teljes, 4,2 KB méretű szkriptjét, és minden egyes függvényét elemeztük. Eredmény: nulla aria-hidden, nulla innerHTML, nulla MutationObserver, nulla szerepkör-módosítás, nulla billentyűzetesemény-lehallgatás. Csak az oldal URL-jét és az eszköz típusát küldi el – sem felhasználói azonosítókat, sem munkamenet-tokent, sem ujjlenyomat-adatokat.
Mit jelent a „Hide from AT” a valódi felhasználók számára
Amikor egy átfedés elrejti egy elemet a segítő technológiák elől, az elem a képernyőn látható marad, de a képernyőolvasók számára teljesen láthatatlanná válik. Minden elrejtett elemet az általa érintett oldalrész szerint osztályoztunk:
Az adatok a mitmproxy segítségével kivont, az egyes webhelyekhez tartozó active.js javítófájlokból származnak. Minden szám egy-egy egyedi CSS-szelektort jelöl, amelyet a hideFromAT() függvény célba vesz.
Egy luxusáru-kiskereskedő fizetési oldalán a képernyőolvasók elől elrejtett elemek a következők voltak:
Az akadálymentesítési átfedő eszközök így hoznak létre kétrétegű vásárlási élményt: a látó felhasználók minden fizetési lehetőséget látnak, és választhatnak hitelkártya, PayPal, Amazon Pay, Shop Pay és Klarna között. A vak felhasználók viszont csak azokat a fizetési módokat találják meg, amelyeket az átfedő nem rejtett el. Egy divatkereskedő weboldalán a kosárba helyezett termékek mennyiségének beírási mezője és a frissítés gombja egyaránt el volt rejtve – a vak felhasználó termékeket tudott hozzáadni, de a mennyiségeket nem tudta módosítani.
Ez egy alapvető kérdést vet fel: egy olyan átfedés, amely elrejti a fizetési gombokat a vak felhasználók elől, valóban javítja-e a weboldal akadálymentességét, vagy éppen rontja azt?
A teljesítményre gyakorolt hatás
Minden AI-alapú alternatív szöveg API-hívás CORS-előzetes ellenőrzést indít el, ami megduplázza a kérések számát. Ezen a rétegen a teljes hálózati idő 46%-át pusztán a protokoll által okozott terhelés teszi ki.
Az eladó elemzési végpontjára irányuló 58 nyomkövető POST-kérés 25,5 másodpercet vett igénybe – az átfedés teljes időtartamának háromnegyede viselkedésfigyelésre fordult, nem pedig az akadálymentességre.
| A domain célja | Eszköz | Kérések | Idő | Mire szolgál |
|---|---|---|---|---|
| Mesterséges intelligencia alapú alternatív szöveg API | B réteg | 135 | 43.1s | Képleírások generálása + CORS előzetes ellenőrzések |
| Link/hangolások API | B réteg | 98 | 35.8s | Megszakadt linkek ellenőrzése, konfiguráció, hozzájárulási felhívások |
| Elemzési végpont | A réteg | 60 | 25.5s | Viselkedésalapú nyomkövető bejegyzések – nem az akadálymentességről |
| Widget CDN | D réteg | 111 | 10.2s | Widget JS, CSS, több mint 20 SVG ikonfájl |
| Szkript-CDN | A réteg | 153 | 6.9s | Minden JS-csomag, szkennelő, webhelyenkénti javítások |
| Mérőjeladó | Monitoring | 29 | 3.3s | Rövid oldal-látogatási POST (csak URL és eszköztípus) |
Mi történik a webhely telepítése után?
Az átfedő eszközök talán legveszélyesebb kockázata csak idővel válik nyilvánvalóvá: a javítások észrevétlenül romlanak. Ellentétben a láthatóan összeomlást okozó JavaScript-hibákkal vagy a valaki által észrevett hibás elrendezéssel, egy elavult átfedő javítás nem eredményez hibát, figyelmeztetést vagy vizuális változást. Egyszerűen csak nem működik tovább – és az általa elrejtett akadálymentességi korlát senki tudomása nélkül újra megjelenik.
Ahhoz, hogy ezt megértsd, gondold át, hogy az egyes overlay-típusok hogyan kapcsolódnak a webhelyed DOM-szerkezetéhez.
Választóalapú javítások: Ketyeg az óra
Az Overlay A – a legtöbb akadálymentesítési overlay-megoldáshoz hasonlóan – webhelyenkénti JavaScript-javítófájlokat tart fenn, amelyek ilyen szabályokat tartalmaznak (a ténylegesen rögzített kód alapján rekonstruálva):
Ez a szabály három CSS-osztály segítségével a Slick karusszel „Vissza” gombját célozza meg: .js-recommendation_carousel, .slick-prev, és .slick-arrow. A szelektor minden egyes eleme rendkívül érzékeny. Ha a weboldal fejlesztőcsapata átnevezi a karusszel-tartály osztálynevét, átáll a Slick-ről a Splide-ra vagy a Swiper-re, vagy egyszerűen csak olyan Slick-könyvtárverzióra frissít, amely megváltoztatja az osztálynevezési konvenciót – a szelektor már semmire sem fog illeszkedni. A gomb elveszíti az „Előző dia” feliratát. A képernyőolvasó-használók már nem tudják azonosítani.
Az A réteg esetében elemzett öt helyszínen a következőket állapítottuk meg Az összes szelektor 98%-a keretrendszer-specifikus osztályneveket tartalmaz – az előtaggal ellátott osztályok .js-, .b-, .chakra-, .splide__, vagy olyan CSS-in-JS hash-ek, mint .css-acuo7n. Ezek nem stabil, szemantikai azonosítók – hanem olyan megvalósítási részletek, amelyek minden keretrendszer-frissítés, komponens-átalakítás vagy fordítási rendszer-módosítás alkalmával változnak.
Egy divatos kézitáska-kereskedő webhelyén olyan szelektorokat találtunk, amelyek a Chakra UI komponenseire irányulnak. A Chakra UI főverziói kompatibilitást megszakító változásokat tartalmaznak – az osztálynevek, a komponensszerkezet és az ARIA-minták egyaránt átalakulnak. Amikor ez a webhely frissíti a Chakrát, potenciálisan több száz overlay-javító szabály működése csendben megszakadhat. Az overlay-szolgáltatónak ezután manuálisan kell ellenőriznie az új DOM-struktúrát, átírnia minden érintett szelektort, és telepítenie a frissített javítófájlokat. A webhely telepítése és az overlay-szolgáltató frissítése közötti időszakban a webhely elavult javításokkal működik – amelyek közül néhány semmit sem tesz, mások pedig potenciálisan rossz elemekre vonatkoznak.
URL-alapú javítások: még bizonytalanabbak
Az Overlay B minden alternatív szövegbejegyzésnél a kép pontos forrás-URL-jét adja meg a JSON-kulcsokban. Olyan bejegyzéseket találtunk, mint:
Figyeljük meg a bizonytalanságot: az URL tartalmaz egy eszközazonosítót (13555), a miniatűr mérete (86x86), valamint egy olyan fájlnév, amely tartalmazza a termék nevét. Ezek bármelyike önállóan változhat. Ha a CMS más méretben generálja újra a miniatűröket, akkor a thumb_86x86 az URL egy része megváltozik, és a bejegyzés már nem egyezik meg vele. Ha a termékfejlesztő csapat egy új fotót tölt fel eltérő fájlnévvel, a bejegyzés elárvulttá válik. Ha a webhely a médiát egy másik domainnel rendelkező CDN-re migrálja, az 1,17 MB-os JSON-fájl minden egyes bejegyzése felesleges terheléssé válik – és a webhelyen található összes kép egyszerre elveszíti az alt szövegét.
A legrosszabb esetben csak részleges egyezés jön létre: egyes képek megtartják a régi URL-címüket (és kapnak alternatív szöveget), míg az új vagy frissített képek egyetlen bejegyzéssel sem egyeznek meg (és nem kapnak semmit). Ennek eredményeként inkonzisztens felhasználói élmény alakul ki, ahol egyes képek leírással rendelkeznek, másokat pedig észrevétlenül kihagynak – ami a képernyőolvasó-használók számára sokkal zavaróbb, mint az alternatív szöveg következetes hiánya.
Átfogó javítások: A kaszkádprobléma
Az Overlay C megközelítése – egy MutationObserver hozzáadása a teljes dokumentumhoz, majd általános javítások végrehajtása bizonyos típusú összes elemen (a, button, input, img, h1) – egy másfajta, de ugyanolyan veszélyes hibamintát eredményez. Ahelyett, hogy a szelektorok elavulása esetén észrevétlenül meghibásodna, ez az átfedés aktívan dolgozik az új kódon.
Vegyünk egy gyakori esetet: a webhely fejlesztőcsapata bevezet egy új, akadálymentes modális párbeszédablak-összetevőt, amely helyesen valósítja meg a fókusz-visszatartást, az „escape-to-close” funkciót és az ARIA-attribútumokat. Az átfedés MutationObserver-je felismeri az új DOM-elemeket, összehasonlítja őket az általános szabályaival, és – miután megtalálja a mintáknak megfelelő elemeket – saját fókuszkezelését, billentyűzetkezelőit és ARIA-attribútumait alkalmazza a komponens meglévő, helyes megvalósítására. Az eredmény: kettős fókuszcsapda, duplikált billentyűzetkezelők és egymással ütköző ARIA-attribútumok. A modális ablak, amely az overlay betöltése előtt tökéletesen működött, most hibásan viselkedik.
Ez nem csupán elméleti kérdés. Az olyan keretkomponens-könyvtárak, mint a Radix UI, a Headless UI és a Chakra UI, jelentős fejlesztői erőfeszítéseket fordítanak az ARIA helyes megvalósítására. Egy olyan overlay, amely saját ARIA-attribútumait minden elemre egyformán alkalmazza button és a az elemek valószínűleg ütközni fognak ezekkel a jól bevált megvalósításokkal, ami megnehezíti a komponensek megfelelő elérhetőségét kevesebb hozzáférhető.
A felügyeleti eszköz: Semmi sem romolhat el
Az általunk elemzett felügyeleti eszköz nem tartalmaz szelektor alapú javításokat, URL-alapú bejegyzéseket, MutationObserver-t, sem általános elemcélzást. Amikor a webhely új kódot telepít, a felügyeleti eszköz következő vizsgálata automatikusan összehasonlítja az új DOM-ot az axe-core szabványos szabálykészletével, és jelentést készít az esetleges új szabályszegésekről – anélkül, hogy bármit is módosítana. A vizsgálati eredmények a szerszám irányítópultján jelennek meg a súlyossági szintekkel, az érintett elemek számával és a szabványosított WCAG-szabályazonosítókkal együtt. A fejlesztők áttekintik az eredményeket, és a javításokat a saját kódbázisukban hajtják végre, ahol a javítások kódfelülvizsgálaton, automatizált tesztelésen, staging-ellenőrzésen és ellenőrzött telepítésen mennek keresztül.
Ez a folyamat természeténél fogva rugalmasan alkalmazkodik a változásokhoz: az eszköz a vizsgálat pillanatában fennálló DOM-ot vizsgálja át, jelenti az észlelt problémákat, majd a következő vizsgálatkor tiszta lappal indul. Nincs felhalmozódott technikai adósság a javítások definiálása terén, nincsenek elavult szelektorok, nincsenek elhagyott alt-szöveg bejegyzések, és nem áll fenn annak a veszélye, hogy rossz javítást alkalmazzunk a rossz elemre.
Mi romlik el az újratelepítéskor?
Minden akadálymentesítési átfedés-javítás a webhely aktuális DOM-szerkezetéhez van kötve. Megállapítottuk, hogy Egy overlay szelektorainak 98%-a keretrendszer-specifikus osztályneveket céloz meg – olyan osztályok, mint .chakra-, .splide__, .js-, .b-, valamint a CSS-in-JS-ben használt hash-ek, mint például .css-acuo7n amelyek minden összeállításkor változnak.
| Amikor a webhely… | Felületi rétegek | Felügyeleti eszköz |
|---|---|---|
| A CSS-osztálynevek módosítása | Minden szelektoron alapuló javítás megszakad | Nem érintett |
| A karusszel-könyvtár frissítései | A karusszel minden javítása megszakad | Nem érintett |
| A fizetési folyamat átalakítása | 68 veszélyeztetett pénztári javítás | Nem érintett |
| A termékek képeinek frissítése | Az alternatív szövegbejegyzések elszigetelődtek | Nem érintett |
| CMS-átállás | Minden fix definíció elavult | Nem érintett |
| Frissítések: React/Vue/Angular | A CSS-in-JS hash-értékek változása | Nem érintett |
A figyelőeszköz minden sorában az „Unaffected” (Nem érintett) felirat szerepel, mivel nincs egyetlen szelektor alapú javítás sem. Nincs semmi, ami elavulhatna, nincs semmi, ami rossz elemet célozna meg, és nincs semmi, ami meghibásodhatna.
Az Általános adatvédelmi rendelet (GDPR), az adatvédelem és a hozzájárulás kérdése
Elemzésünk megerősítette, hogy a négy akadálymentességi réteg közül három adatokat küld külső szervereknek, még mielőtt a felhasználó bármilyen módon reagálhatna a hozzájárulási felugró ablakra:
| Eszköz | Felhasználók nyomon követése | Tárolás | Ujjlenyomatvétel | Adatcél |
|---|---|---|---|---|
| A réteg | Munkamenet-azonosító + oldalbetöltési azonosító | — | — | amerikai szerver |
| B réteg | Minden oldalon változatlan UUID | — | — | Izrael/USA |
| C réteg | FELHASZNÁLÓI MAGATARTÁS-ELEMZÉS | localStorage (3 kulcs) | userAgent + maxTouchPoints | Izrael |
| D réteg | Nem figyelhető meg | localStorage (16 hivatkozás) | 16 navigációs hivatkozás | Németország (EU) |
| Monitoring | Nincs | 1 hibakeresési jelző | Nincs | Bulgária (EU) |
Az Európai Unió Bíróságának (CJEU) Planet49-ügyben hozott ítélete értelmében a nem alapvetően szükséges nyomkövetéshez előzetes, kifejezett hozzájárulás szükséges. Két felugró ablak már az első hálózati kéréskor – még mielőtt bármilyen hozzájárulási mechanizmus aktiválódhatna – állandó azonosítókat helyez el. Az EU-ban működő webhelyek esetében ez automatikusan a GDPR megsértését jelenti.
A jogi környezet
ellen 2024-ben pert indítottak az ADA megsértése miatt
” nevű overlay-szolgáltatóra az AI-képességek hamis bemutatása miatt
-t (+20% az előző évhez képest)
2025 áprilisában az Egyesült Államok Szövetségi Kereskedelmi Bizottsága (FTC) 1 millió dolláros peren kívüli egyezséget kötött a tanulmányunkban szereplő egyik akadálymentesítő szoftvergyártóval szemben, amiért az hamisan állította, hogy mesterséges intelligencián alapuló eszköze bármely weboldalt WCAG-kompatibilissé tud tenni. Az FTC megállapította , hogy az eszköz nem tette akadálymentessé a weboldalak alapvető elemeit – a menüket, a címsorokat, a táblázatokat, a képeket és a hangfelvételeket. Az egyik idézett példában egy filet mignon fotóhoz az AI a következő leírást generálta: „Barna kenyér fehér kerámia tányéron.”
Az iparági nyomonkövetési adatok szerint 2024-ben az összes digitális akadálymentességi per 25%-ában kifejezetten az overlay-widgeteket nevezték meg akadályként – nem pedig megoldásként. 2025 első felében havonta több mint 100 per indult az overlay-t használó vállalatok ellen. Kutatásunkban szereplő overlay-szolgáltatók közül kettő közvetlenül érintett volt peres eljárásokban: az egyik három különálló szabadalmi/üzleti titok ügyben, a másik pedig egy kisvállalkozói ügyfél által indított csoportos perben, akit az overlay használata ellenére pereltek be.
A tanulmányunkban szereplő felügyeleti eszköznek nincs olyan peres ügye, amely az akadálymentességi hiányosságokhoz kapcsolódna – ez az architektúrájának logikus következménye: mivel soha nem módosítja a DOM-ot, nem okozhat akadálymentességi korlátokat.
A kód belsejében: Mit módosítanak valójában az overlayek
A DOM-manipuláció mértékének megértése érdekében megszámoltuk az egyes eszközök JavaScript-kódjában előforduló összes módosítási mintát. A különbségek drámaiak:
| Kódminta | Monitoring | C réteg | D réteg | A réteg | B réteg |
|---|---|---|---|---|---|
setAttribute | 1 | 227 | 216 | Helyszínenként | Motoron keresztül |
aria-hidden | 0 | 21 | 47 | 141 hívás | 69 díszítő |
aria-label | 0 | 128 | 49 | Helyszínenként | 5 068 AI |
role | 0 | 82 | 2 | 115 | N/A |
MutationObserver | 0 | 2 (az egész dokumentumban) | 9 | A motorban | A motorban |
localStorage | 1 hibakeresés | 14 | 16 | — | — |
navigator ujjlenyomat | 0 | 9 | 16 | — | — |
keydown/keyup | 0 | 47 | A motorban | Helyszínenként | navigációs segéd |
Az Overlay C különös figyelmet érdemel. A 794 KB-os monolitikus csomagja egy MutationObserver hogy document.documentElement a konfigurációval {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Ez azt jelenti, hogy az oldal teljes tartalmában bekövetkező minden egyes DOM-változás – legyen szó a React virtuális DOM-jának összehangolásáról, egy A/B-tesztelő szkriptről, egy csevegőmodulról vagy a webhely saját JavaScript-jéről – elindítja az átfedés megfigyelőjét, amely ezután újraértékeli és adott esetben újraalkalmazza a javításait. A webhely újratelepítése után ez olyan elemeknél, amelyek már eleve megfelelően elérhetők, javítási kísérletek sorozatát indítja el, ami azt eredményezheti, hogy a helyes ARIA-attribútumokat helytelenekkel írják felül.
Megerősítettük, hogy az Overlay C küld USER-BEHAVIOR-ANALYTICS POST-kéréseket küld a saját naplófogadójának, amelyek hasznos adatai között szerepel a webhely domainje, a widget verziója, a felhasználó nyelve és az interakciós események. Összevonva a localStorage kitartás és eszközazonosítás a következő eszközökön keresztül navigator.userAgent és navigator.maxTouchPointsez egy olyan adatkezelési műveletet jelent, amelynek létezéséről a legtöbb webhely-üzemeltető nem is tud.
A JSON-fájlok javításával kapcsolatos probléma
Az Overlay B egy hatalmas JSON-fájlt tölt le (egy telekommunikációs webhely esetében akár 1,17 MB-ot is), amely az összes javítási definíciót tartalmazza. Egy webhelyen azt tapasztaltuk, hogy egy böngészési munkamenet során négy alkalommal töltötték le – 4,7 MB sávszélességet igénybe véve egy olyan fájlért, amelyet cache-be kellett volna tárolni. A JSON 11 kategóriát tartalmaz, de ezek túlnyomó többsége AI által generált képleírás: egy webhely esetében 6975 bejegyzésből 4974. Mindegyik egy adott kép URL-jéhez van rendelve – amikor a CMS átnevezi a fájlt, megváltoztatja a miniatűr méreteit vagy áttelepíti a CDN-domaineket, a bejegyzések észrevétlenül elveszítik az egyezésüket. A helyettesítő képek egyáltalán nem kapnak alternatív szöveget, ami miatt az oldal kevésbé hozzáférhető, mint az overlay telepítése előtt.
Ez az overlay olyan futásidejű modulokat is telepít, amelyek aktívan átírják az oldalt: egy 110 KB-os javító modult, egy 23 KB-os navigációs menü-segédprogramot, amely átalakítja a menü billentyűzetes kezelését, egy 5,8 KB-os karusszel-javítást, valamint egy 53 KB-os kliensoldali szkennert, amely az iparági szabványnak számító axe-core motor helyett saját fejlesztésű logikát használ – ami azt jelenti, hogy az eredményei nem ellenőrizhetők függetlenül.
A legátláthatóbb átfedés – még mindig kockázatos
A D overlay rendelkezett a legátláthatóbb felépítéssel: ember számára olvasható JSON konfigurációs fájlok, kifejezett engedélyezési/letiltási kapcsolókkal. Olyan beállítások, mint addAriaHidden, overwriteAlt, és adjustMetaViewport kifejezetten beállították, hogy false. Az alapul szolgáló motor (649 KB) azonban 216 setAttribute hívások, 47 aria-hidden hivatkozások, 282 addEventListener regisztrációk, valamint 9 MutationObserver esetek. A motor támogatja az agresszív DOM-módosítást akkor is, ha az aktuális beállítás konzervatív – egy gyártói oldalon végrehajtott beállítási módosítás a webhely üzemeltetőjének tudta nélkül aktiválhatja a kockázatos funkciókat.
Találtunk olyan, webhelyenkénti szelektorokat, amelyek JavaScript által generált hash-kiterjesztéseket tartalmaznak, például button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 amelyek minden új verziónál változnak, valamint a közösségi média URL-választók, amelyek elavulnak, amikor a webhely frissíti a Facebook- vagy Instagram-linkjeit.
Az európai akadálymentességi törvény: Miért nem felelnek meg az átfedések az EAA követelményeinek?
2025. június 28-tól az Európai Akadálymentességi Törvény (EAA) előírja, hogy az EU-ban forgalmazott digitális termékeknek és szolgáltatásoknak meg kell felelniük az EN 301 549 szabványnak, amely a WCAG 2.1 AA irányelvre hivatkozik. Az ADA-val ellentétben – amelyet elsősorban magánjogi perek útján érvényesítenek – az EAA-t a nemzeti piacfelügyeleti hatóságok hajtják végre, amelyek jogosultak bírságok kiszabására, korrekciós intézkedések elrendelésére és a nem megfelelő termékek forgalomból való kivonására.
Németország hivatalos elutasítása az átfedő eszközökkel kapcsolatban
Németország foglalt a legegyértelműbb szabályozási álláspontot az akadálymentesítő overlay-ekkel kapcsolatban az összes ország közül. A BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – az információs technológia akadálymentességéért felelős német szövetségi felügyeleti szerv – az összes tartományi szintű felügyeleti szervvel közösen kiadott egy közös értékelést, amelyben kifejezetten elutasította az akadálymentességi előírásoknak való megfelelés érdekében használt overlay-eszközöket:
„Az overlay eszközök jelenleg nem képesek teljesen akadálymentessé tenni azokat a weboldalakat, amelyek már eleve tartalmaznak akadályokat. Gyakran előfordul, hogy ezeknek az eszközöknek a használata további akadályokat hoz létre a weboldalon, amelyek az eszköz nélkül nem léteztek volna.”
– A szövetségi és tartományi felügyeleti szervek közös értékelése az információs technológia akadálymentességéről az overlay-eszközök használata tekintetében
2025. március 12-én az Akadálymentes Információs Technológiai Bizottság (Ausschuss für barrierefreie Informationstechnik, a BITV 2.0 5. §-a alapján létrehozva) ülésén megerősítette ezt az álláspontját, és aggodalommal állapította meg, hogy a közintézmények továbbra is overlay-eszközök beépítésével próbálnak eleget tenni akadálymentességi kötelezettségeiknek. A bizottság arra a következtetésre jutott, hogy „a weboldal szoftver általi ideiglenes akadálymentes megjelenítése – esetleg csak a felhasználó által végzett beállítások után – a látogatás időtartamára nem felel meg az alkalmazandó jogszabályi rendelkezések követelményeinek.”
A bizottság kifejezetten figyelmeztetett arra, hogy az átfedő eszközöket alkalmazó közintézmények azzal a kockázattal járnak, hogy weboldalaik hozzáférhetősége nem javul, hanem romlik – ami a hozzáférhetőség romlását („Verschlechterung der Barrierefreiheit”) eredményezi. Ez közvetlenül megegyezik azzal a technikai megállapításunkkal, miszerint az átfedő javítási szabályok 26%-a új WCAG-megsértéseket eredményez.
BIK tesztelési pecsét: elutasítva az átfedést alkalmazó webhelyek esetében
A német BIK tesztelési hálózat – amelynek akkreditált szervezetei a weboldalakat a BITV 2.0, az EN 301 549 és a WCAG 2.1 AA szabványok alapján értékelik – egy gyakorlati lépést tett: azok a weboldalak, amelyek overlay-eszközöket használnak, nem kaphatják meg a BIK tesztpecsétet. A tesztelő szervezetek kijelentették, hogy overlay jelenléte esetén nem tudnak megbízható megfelelőségi értékelést készíteni, mivel az overlay futásidőben olyan módon módosítja a DOM-ot, ami a teszt eredményeit megbízhatatlanná teszi. A BIK pecsétet Németország-szerte széles körben használják a BITV 2.0-nak való megfelelés bizonyítékaként – és mostantól nem érhető el azoknak a weboldalaknak, amelyek overlay-t használnak.
Ez nem csupán elméleti politikai kérdés. Ez azt jelenti, hogy egy német e-kereskedelmi webhely, amely a általunk tesztelt négy felületből bármelyiket használja, nem szerezheti meg a német piacon általánosan elvárt szabványmegfelelési tanúsítványt.
európai szintű megerősítés
Ez a szabályozási álláspont Németországon túlmutat. Az Európai Fogyatékossággal Élők Fóruma és a Nemzetközi Akadálymentesítési Szakemberek Szövetsége 2023-ban közös nyilatkozatot adott ki, amelyben arra figyelmeztettek, hogy az akadálymentesítő overlayek nem teszik a weboldalakat akadálymentessé, és nem biztosítják azoknak az európai akadálymentességi jogszabályokkal – többek között az európai akadálymentességi törvénnyel – való összhangját. Az Európai Bizottság is nyilatkozott az overlayek megfelelőségére vonatkozó állításokról, és arra a következtetésre jutott, hogy az overlayek nem tudják garantálni az alkalmazandó szabványoknak való megfelelést.
A német BFSG (Barrierefreiheitsstärkungsgesetz – az EAA német átültetési törvénye, amely 2025. június 28-tól hatályos) értelmében a piacfelügyeleti hatóságok jogsértésenként 10 000–100 000 euró összegű bírságot szabhatnak ki. A BFIT-Bund értékelése és a BIK tesztelési hálózat elutasítása az overlay-t használó webhelyek tanúsítását illetően gyakorlatilag azt jelenti, hogy az overlay-eszközök Németországban semmilyen szabályozási védelmet nem nyújtanak – sőt, aktívan növelhetik a jogérvényesítési intézkedések kockázatát.
2025. június 28.: Az EAA végrehajtása megkezdődik az EU valamennyi tagállamában. A termékeknek és szolgáltatásoknak meg kell felelniük az EN 301 549 szabvány akadálymentességi követelményeinek.
2030. június 28.: Lezárul az átmeneti időszak a 2025. június előtt már szerződéssel rendelkező szolgáltatások esetében. Ezen időpont után minden digitális szolgáltatásnak meg kell felelnie a követelményeknek, függetlenül a szerződés megkötésének időpontjától.
Azok a vállalkozások, amelyek az ADA-előírásoknak való megfelelés érdekében overlay-ekre támaszkodnak, nem feltételezhetik, hogy ez a megközelítés az EAA követelményeinek is eleget tesz. Az európai szabályozó hatóságok a termék tényleges akadálymentességét értékelik, nem pedig egy harmadik féltől származó modul jelenlétét.
Biztonsági és ellátási lánc kockázatok
Minden overlay-eszköz úgy működik, hogy harmadik féltől származó JavaScript-kódot illeszt be a termelési oldalak globális hatókörébe. Ez a JavaScript ugyanolyan jogosultságokkal fut, mint a saját kódod – bármely DOM-elemet elolvashat és módosíthat, elfoghatja az űrlapküldéseket, hozzáférhet a cookie-khoz, átirányíthatja a felhasználókat, és adatokat szivárogtathat ki. Ennek a megoldásnak jelentős biztonsági következményei vannak, amelyeket gyakran figyelmen kívül hagynak.
A támadási felület
Vegyük szemügyre az ellátási láncot: amikor hozzáadsz egy akadálymentesítési réteget a webhelyedhez, azzal folyamatos, korlátlan írási hozzáférést biztosítasz egy külső szolgáltatónak az éles környezetben futó DOM-odhoz. A szolgáltató CDN-je szolgáltatja a JavaScriptet, a szolgáltató csapata karbantartja a kódot, és a szolgáltató telepítési folyamatán keresztül a frissítéseket közvetlenül a webhelyedre töltik fel – anélkül, hogy a kódot átnéznéd, minőségbiztosítási folyamaton átmenne, vagy jóváhagynád.
Ha az overlay-szolgáltató CDN-je támadásnak esik áldozatul, a támadó képes lesz rosszindulatú kódot bejuttatni minden olyan webhelyre, amely ezt az overlay-t használja. Ha a szolgáltató egyik alkalmazottja hibás frissítést töltenek fel, az minden ügyfél webhelyét egyszerre érinti. Ha a szolgáltató API-végpontját eltérítik, a webhelyednek kiszolgált javító JSON- vagy konfigurációs adatokat manipulálhatják úgy, hogy űrlapmezőket módosítsanak, linkeket átirányítsanak vagy adathalász tartalmat juttassanak be.
Ennek a kockázatnak a mértéke közvetlenül összefügg az overlay DOM-lábnyomával:
| Eszköz | JS globális hatókörben | DOM írási hozzáférés | Külső domainnevek | API-adatfüggőség |
|---|---|---|---|---|
| A réteg | ~1 240 KB (aktív) | Az egyes webhelyekre vonatkozó javítási szabályok minden egyező elemet módosítanak | 3 domain | Az active.js fájl webhelyenként |
| B réteg | ~500 KB (aktív) | A javító modul minden megtalált elemet módosít | 3 domain, 228 API-hívás | 1,17 MB JSON |
| C réteg | 1 285 KB (monolitikus) | 227 setAttribute, 82 szerepkör-módosítás | 3 domain | Konfigurációs és elemzési POST-kérések |
| D réteg | ~740 KB (aktív) | 216 setAttribute, 47 aria-hidden hivatkozás | 2 domain | JS-fájlok konfigurálása |
| Monitoring | 4,2 KB (passzív) | Nincs – nulla DOM-írás | 2 domain | Nincs |
Az Overlay B jelenti a legnagyobb kockázati felületet az ellátási láncban: munkamenetenként 228 API-hívás 3 külső domainen keresztül, 1,17 MB-os JSON-adatcsomaggal, amely meghatározza, hogyan kell módosítani a DOM-ot. Egy kompromittált API-válasz utasíthatja a javító motort, hogy tetszőleges tartalmat illesszen be az oldal bármely elemébe. A C átfedés 1285 KB-os monolitikus csomagja a legnagyobb egyetlen JavaScript-hasznos teher – és mivel minifikált és elrejtett, sem a webhely üzemeltetője, sem a biztonsági ellenőr nem tudja érdemben ellenőrizni, hogy mit hajt végre futásidőben.
PCI DSS-megfelelés: Közvetlen ellentmondás
Bármely hitelkártyás fizetéseket feldolgozó e-kereskedelmi webhely számára a PCI DSS-előírások betartása nem opcionális. Megállapításaink szerint pedig közvetlen ellentmondás áll fenn az akadálymentesítési overlay-eszközök felépítése és a PCI DSS-követelmények között.
A PCI DSS 6.4.3. pontja (amelyet a PCI DSS v4.0 vezetett be, és amely 2025. március 31-től kötelező) előírja, hogy az ügyfél böngészőjében betöltődő és futó összes fizetési oldal szkriptjét a következőképpen kell kezelni: be kell vezetni egy eljárást annak ellenőrzésére, hogy minden szkript engedélyezett-e, biztosítani kell az egyes szkriptek integritását, valamint nyilvántartást kell vezetni az összes szkriptről, amelyben írásban indokolni kell azok szükségességét.
Elemzésünk megerősítette, hogy az overlay-javítási szabályok több webhelyen is kifejezetten a fizetési oldal DOM-elemeit célozzák meg:
Ez nem csupán elméleti kockázat – ezek olyan konkrét szabályok, amelyeket termelő környezetből gyűjtöttünk össze, és amelyek aktívan módosítják a hitelkártyaszám mezőket, a számlázási cím kiválasztókat, a fizetési szolgáltató gombjait és a fizetési űrlapot tartalmazó elemeket. A PCI DSS 6.4.3 előírásai szerint ezeknek a harmadik féltől származó szkripteknek mindegyike iratban rögzített engedélyezést, integritás-ellenőrzést és írásbeli indoklást igényel.
Gondoljon csak bele, mire képes egy overlay-szolgáltató szkriptje a fizetési oldalon:
| PCI DSS követelmény | Mit követel meg | Kiterjesztett valóság |
|---|---|---|
| 6.4.3 Szkriptkezelés | Az összes fizetési oldal szkriptjének leltározása, engedélyezése és integritásának biztosítása | Az overlayek több mint 400 KB-nyi, harmadik féltől származó JavaScript-kódot töltenek be, amely a kereskedő jóváhagyása nélkül frissül |
| 6.4.3 A szkript igazolása | Írásbeli indoklás arról, hogy miért szükséges az egyes szkriptek | Az overlay szkriptek hozzáférhetőségi javításokat, elemzési nyomon követést és viselkedésfigyelést szolgálnak – ez azonban csak részben indokolt |
| 11.6.1 Változásérzékelés | Vezessen be változás- és manipulációérzékelő mechanizmust a fizetési oldalakon | Az overlay-szolgáltatók a kereskedő értesítése nélkül töltenek fel kódfrissítéseket a CDN-jükre – a szkript tartalma észrevétlenül változik |
| 6.2.4 A szoftver integritása | Védelem a saját fejlesztésű és harmadik féltől származó szoftverekkel kapcsolatos visszaélések és hibák ellen | Az Overlay JS módosítja #cardNumber, #billingState, valamint a fizetési gomb elemei – bizonyították, hogy írási hozzáférésük van a kártyatulajdonosok adatmezőihez |
A British Airways-t (380 000 ellopott kártya), a Ticketmastert (40 000 kártya) és a Newegget érintő Magecart-támadások mind ugyanazt a mintát követték: a fizetési oldalakon található harmadik féltől származó JavaScript-kódokat feltörték a hitelkártyaadatok ellopása céljából. Az overlay eszközök pontosan ugyanazon a technikai felületen működnek – harmadik féltől származó, teljes DOM-hozzáféréssel rendelkező JavaScript fut a fizetési oldalakon, amely bizonyítottan képes olvasni és módosítani a fizetési űrlap mezőit. A különbség az, hogy a Magecart szkripteket titokban juttatták be, míg az overlay szkripteket meghívják. A támadási felület azonos.
Elemzésünk bebizonyította, hogy az átfedés-javítási szabályok célja #cardNumber és #billingState név szerint – vagyis az overlay kódja programozási úton hozzáférhet azokhoz az elemekhez, ahol az ügyfelek megadják hitelkártyaszámukat és számlázási címüket. Egy feltört overlay CDN módosíthatja ezeket a beállításokat, hogy egyszerre minden ügyfél webhelyéről ellopja a kártyatulajdonosok adatait.
Ezzel szemben a felügyeleti eszköz egyáltalán nem képes írási műveleteket végrehajtani a DOM-ban. A 4,2 KB méretű szkriptje nem módosíthatja az űrlapmezőket, nem foghatja le a bevitelhez kapcsolódó eseményeket, és nem érheti el, illetve nem módosíthatja a fizetési folyamat elemeit. Még abban az esetben sem, ha a felügyeleti szolgáltató CDN-je támadásnak lenne kitéve, a támadó csak egy olyan szkripthez jutna hozzá, amely kizárólag az oldal URL-jét és az eszköz típusát tudja kiolvasni – nem pedig olyasmihez, amely átírhatná a fizetési űrlapot. A PCI DSS hatályának meghatározása szempontjából a felügyeleti eszköz nem jelent további kockázati felületet a fizetési oldalakon.
A diszkrimináció kérdése
Ez az a diszkriminációs probléma, amely minden akadálymentesítő felület középpontjában áll: a legaggasztóbb megállapítás nem egy technikai hiba, hanem az a gyakorlat, hogy a fogyatékkal élő felhasználókat szisztematikusan megfosztják olyan funkciók használatától, amelyeket a látó felhasználók természetesnek vesznek.
Ha egy felugró ablak elrejti az Amazon Pay gombot a hozzáférhetőségi fából, a látássérült felhasználó kevesebb fizetési lehetőséget lát, mint a látó felhasználó. Ha a kosár mennyiségének beviteli mezője el van rejtve, a látássérült felhasználó nem tudja módosítani a megrendelését. Ha a keresési eredmények linkjei el vannak rejtve, az megnehezíti a termékek megtalálását. Ha a csillagokkal jelzett értékelések el vannak rejtve, a látássérült felhasználó nem tudja úgy értékelni a termék minőségét, ahogyan azt a látó felhasználó megteheti.
Ezek nem szélsőséges esetek – hanem az e-kereskedelem alapvető munkafolyamatai, amelyeket éppen azok az eszközök zavarnak meg, amelyek hozzáférhetővé tételét ígérik.
A fogyatékossággal élők közössége évek óta hangoztatja ezt a problémát. Az Overlay Fact Sheet – amelyet több száz akadálymentesítési szakember írt alá – arra figyelmeztet, hogy az akadálymentesítő overlayek „nem javítják ki az alapul szolgáló HTML-kódot”, és „gyakran aktívan akadályozzák a fogyatékossággal élőket”. Műszaki elemzésünk bizonyítja ezt: 141, a képernyőolvasók elől elrejtett funkcionális elem, 7 értelmetlen címke beillesztése és 5066 felülvizsgálat nélküli AI-leírás került bevezetésre – mindössze 14 webhelyen.
A webhelyüzemeltetők számára nem az a kérdés, hogy az átfedések „elég jók-e” – hanem az, hogy indokolt-e olyan eszköz bevezetése, amely kétrétegű felhasználói élményt eredményez: egy verziót a látó felhasználók számára, akik a teljes funkcionalitást élvezhetik, és egy szűrt, hibás, olykor értelmetlen verziót a fogyatékkal élő felhasználók számára.
Hatása az ADA-előírások betartására: Valóban segítenek ezek a javítások?
Minden overlay alapvető ígérete az, hogy futásidőben kijavítva a WCAG-megsértéseket javítja az ADA-megfelelést. Elemzésünk azonban egy aggasztó ellentmondásra derít fényt: az overlay-k jelentős hányada a meglévő WCAG- megsértések kijavítására tett kísérlet során aktívan új megsértéseket okoz.
Az Overlay A-ból rögzített összes javítási szabályt hozzárendeltük ahhoz a konkrét WCAG 2.1-es sikerkritériumhoz, amelyre azok vonatkoznak. A 776 hozzárendelhető szabály közül az eredmények két kategóriába sorolhatók: olyan javítások, amelyek valóban megoldanak egy WCAG-problémát, és olyanok, amelyek a folyamat során új WCAG-megsértést eredményeznek.
| WCAG sikerességi kritérium | Javítások összesen | Eredeti | hideFromAT | szerep=elnök | alt=”” | Hiba |
|---|---|---|---|---|---|---|
| 4.1.2 Név, szerep, érték | 292 | 260 | 13 | 14 | 2 | 3 |
| 2.4.4 A link célja (a kontextusban) | 158 | 108 | 45 | 5 | 1 | 0 |
| 1.3.1 Információk és kapcsolatok | 109 | 92 | 1 | 16 | 0 | 0 |
| 1.1.1 Nem szöveges tartalom | 108 | 28 | 52 | 5 | 28 | 0 |
| 4.1.3 Állapotüzenetek | 44 | 43 | 1 | 0 | 0 | 0 |
| 2.1.1 Billentyűzet | 36 | 22 | 6 | 6 | 0 | 2 |
| Egyéb (6 kritérium) | 29 | 26 | 1 | 2 | 0 | 0 |
| ÖSSZESEN | 776 | 579 (75%) | 119 | 48 | 31 | 5 |
oldalon találhatóak oldják meg a WCAG-problémát
oldalon feltüntetett javításokrontják a weboldal akadálymentességét
webhelyen új WCAG-megfelelési problémákat okoznak
Az igazsághoz hozzátartozik, hogy a feltérképezett javítások háromnegyede valódi fejlesztés: hiányzó gombfeliratok hozzáadása, a fejléc-hierarchiák rendezése, az automatikus kiegészítés attribútumainak javítása, valamint a modális fókuszcsapdák beépítése. A fennmaradó egynegyed azonban kifejezetten káros, és ez a kár aránytalanul éppen azokat a felhasználókat érinti, akiknek az eszköz állítólag segíteni kíván.
Hogyan sérti meg az egyes kockázatos minták a WCAG-szabványt
A probléma nem csupán abban rejlik, hogy ezek a javítások nem működnek – hanem abban is, hogy olyan, a WCAG sikerességi kritériumainak való megsértéseket eredményeznek, amelyek az átfedés alkalmazása előtt nem léteztek. Egy ADA-perben a felperes szakértője hivatkozhat ezekre az átfedés által okozott szabályszegésekre annak bizonyítékaként, hogy a webhely hátrányosan megkülönbözteti a fogyatékossággal élő személyeket.
Amikor hideFromAT() ha egy olyan funkcionális elemre alkalmazzák, mint például egy fizetési gomb vagy egy termékhivatkozás, akkor a következőket eredményezi:
WCAG 1.1.1 (Nem szöveges tartalom, A szint) – A rejtett képeknél az alternatív szöveghez való hozzáférés teljesen megszűnik.
WCAG 1.3.1 (Információ és összefüggések, A szint) – A szerkezeti jelentés elveszik; az elem szerepe az oldal hierarchiájában megszűnik.
WCAG 2.1.1 (Billentyűzet, A szint) – A rejtett interaktív elemek nem kaphatnak fókuszt, és nem kezelhetők billentyűzetről.
WCAG 2.4.4 (Link célja, A szint) – A rejtett linkeket a segítő technológiák nem tudják megkeresni vagy azonosítani.
WCAG 4.1.2 (Név, szerep, érték, A szint) – A rejtett elemeknek nincs programozási úton meghatározható nevük vagy szerepük.
Ezek mind az öt eset A-szintű kritérium – a WCAG szerinti minimális akadálymentességi szint. A hideFromAT() függvény minden egyes alkalmazása egy funkcionális elemen öt egyidejű A-szintű meg nem felelést eredményez. Öt webhelyen összesen 141 ilyen esetet találtunk – ami azt jelenti, hogy a felugró ablak önmagában potenciálisan 705 új A-szintű szabályszegést okoz.
Amikor role="presentation" Ha egy táblázatra alkalmazzák, a képernyőolvasók már nem tudnak sorok és oszlopok szerint navigálni. A táblázat szerkezete láthatatlanná válik. Ez közvetlenül megsérti WCAG 1.3.1 (Információk és kapcsolatok) és 1.3.2 (Értelmes sorozat). 115 olyan esetet találtunk, ahol a role attribútum értéke „presentation” vagy „none” volt – ideértve az adattáblákra, fejlécekre és tájékozódási pontokra alkalmazott elemeket is.
A „true” szöveges karakterlánc, mint hozzáférhető név, megsérti a WCAG 4.1.2 (Név, szerep, érték) irányelvet, mivel a név nem írja le az elem rendeltetését, valamint a WCAG 2.4.6 (Fejlécek és címkék) ir ányel vet is, mivel a címke nem leíró jellegű. A képernyőolvasó felhasználója a „gomb, true” szöveget hallja – nem tudja megállapítani, hogy a gomb mire szolgál, így az funkcionálisan hozzáférhetetlen. 3 webhelyen 7 ilyen esetet találtunk.
B. réteg: AI által generált alternatív szöveg és a WCAG 1.1.1
A WCAG 1.1.1 előírja, hogy a nem szöveges tartalmaknak rendelkezniük kell egy „azonos célt szolgáló szöveges alternatívával”. Egy olyan, mesterséges intelligenciával generált alternatív szöveg, amely egy vállalati logót „kék és sárga jelként” ír le, nem szolgálja az azonos célt – a logó célja a márka azonosítása, nem pedig a szín leírása. Egy promóciós banner esetében a „szöveg”, vagy egy kiemelt kép esetében a „város” alternatív szöveg ugyanazon kritériumnak nem felel meg, csak más módon – annyira homályos, hogy használhatatlan.
Az Overlay B-ből rögzített 5 068 mesterséges intelligenciával generált alternatív szöveg közül 241 kevesebb volt 15 karakternél (túl homályos ahhoz, hogy hasznos legyen), 323 meghaladta a 125 karaktert (megszegve ezzel a képernyőolvasók használhatóságára vonatkozó bevált gyakorlatokat), 156 pedig „kép” vagy „fotó” szóval kezdődött (felesleges, mivel a képernyőolvasók már így is bejelentik az elem típusát). Csak 2-t hagyott jóvá emberi lektor.
Az ADA-peres eljárások szabályai szerint a felperes akadálymentességi szakértője ezeket a WCAG 1.1.1 szabvány megsértéseként jelölné meg – ez az ADA-alapú webes akadálymentességi perekben a leggyakrabban hivatkozott kritérium. Az átfedés nem orvosolja a szabályszegést; csupán az egyik szabályszegési formát (az alternatív szöveg hiánya) cseréli fel egy másikra (pontatlan vagy homályos alternatív szöveg), miközben a webhely üzemeltetőjében hamis megfelelés érzetét kelti.
B. melléklet: Címkék beillesztése futásidőben – amikor a „javítás” csak ront a helyzeten
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.
Az Overlay B javító motorjának bekapcsolásakor a képernyőolvasó a következőket mondta:
| Látható címke | Beírandó név= | Overlay aria-label= | Probléma |
|---|---|---|---|
| Keresztnév | keresztnév | „Név” | Csonkított – az „Első” elveszett. Ugyanaz a címke, mint az alábbi Vezetéknévnél |
| Vezetéknév | vezetéknév | „Név” | Ugyanaz a címke, mint a keresztnév – a felhasználó nem tudja megkülönböztetni a mezőket |
| Munkahelyi e-mail-cím | e-mail-cím | „Kérjük, adja meg e-mail-címét” | A beviteli érvényesítési típus alapján generálva, nem a látható „Munkahelyi e-mail” címke alapján |
| Telefonszám | telefon | „Kérjük, adja meg a telefonszámát” | A beviteli típus alapján generálva, nem a látható „Telefonszám” felirat alapján |
| Cégnév | vállalat | „Szövegmező” | Címke nem található – a rendszer az általános elemtípusra vált át |
| Miben segíthetünk? | menu-627 | „Egyetlen elem kiválasztása” | Címke nem található – csak az elem típusa |
| Üzenet | az üzeneted | „Szövegmező” | Címke nem található – csak az elem típusa |
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”).
Az eredmény rosszabb, mint az eredeti, címkézetlen űrlapé. Az átfedés megjelenése előtt a képernyőolvasó-használó hét címkézetlen mezővel találkozott – ez ugyan zavaró volt, de legalább következetes. A felhasználók a tabulátor-sorrend és a kontextus alapján meg tudták tippelni, melyik mező melyik. Az átfedés beavatkozása után a felhasználó két, azonos címkével ellátott mezővel találkozik (mind a keresztnév, mind a vezetéknév esetében „Név”), két, kitalált, érvényesítési stílusú címkével ellátott mezővel, amelyek nem egyeznek a látható szöveggel, valamint három, értelmetlen, típusalapú névvel ellátott mezővel. A részleges, helytelen címkézés még inkább zavaró, mint a címkézés teljes hiánya, mert hamis benyomást kelt, hogy az űrlap akadálymentessé vált, miközben a kritikus mezők címkézetlenek vagy helytelenül vannak címkézve maradnak.
Ez az eredmény rávilágít az Overlay B javítási JSON-jának egy hiányosságára is. A JSON 87 AI által generált alt szöveg bejegyzést tartalmazott , és egyetlen űrlap-javítási bejegyzést sem tartalmazott ehhez a webhelyhez. Az űrlapcímke-beillesztés teljes egészében futásidőben történik az EmptyControls szabálykezelőn keresztül – nem látható az összevont javítási JSON-ban, nem követhető nyomon egyetlen olyan irányítópulton sem, amelyet a webhely üzemeltetője áttekinthetne, és nem is kell emberi jóváhagyáson átesnie. A webhely üzemeltetőjének nincs módja megtudni, hogy a kapcsolatfelvételi űrlapja hibásan van címkézve, hacsak nem teszteli azt saját maga egy képernyőolvasóval.
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.
Az ADA-megfelelés nettó hatása
Az alapvető probléma az, hogy az átfedő eszközök összekeverik a lefedettséget a szabályoknak való megfeleléssel. Egy átfedő eszköz 1058 javítási szabályra hivatkozhat, és azt állíthatja, hogy több mint 40 WCAG-sikerkritériumot teljesít. Ha azonban ezeknek a javításoknak 26%-a új szabályszegéseket eredményez – beleértve az A-szintű hibákat is, amelyek funkcionális elemek elrejtéséből adódnak –, akkor a nettó megfelelési helyzet rosszabb lehet, mint a módosítatlan webhelyé.
Egy olyan webhely, amelyen nincs felugró ablak, de 50 WCAG-megsértés található, jogilag egyértelműbb helyzetben van, mint egy olyan webhely, amelyen felugró ablak van, és amelyen 30 eredeti megsértés mellett további 203, a felugró ablak által okozott megsértés is fennáll – mivel a felugró ablak által okozott megsértések azt bizonyítják, hogy a webhely üzemeltetője olyan eszközt alkalmazott, amely aktívan hátrányosan megkülönbözteti a fogyatékkal élő felhasználókat, ami aláássa a jóhiszeműségre alapuló védekezést.
A felügyeleti eszköz nem okozhat WCAG-megsértéseket, mivel soha nem módosítja a DOM-ot. Ehelyett az axe-core-t használja – ugyanazt a motort, amelyet az Igazságügyi Minisztérium, az Európai Bizottság és a legtöbb akadálymentességi tesztelő szakember is alkalmaz –, hogy szabványos szabályazonosítók és súlyossági szintek segítségével azonosítsa a valódi megsértéseket. A fejlesztők ezeket a megsértéseket a forráskódban javítják ki, ahol a javítások kódfelülvizsgálaton, automatizált tesztelésen (beleértve az akadálymentességi CI/CD-ellenőrzéseket) és ellenőrzött telepítésen mennek keresztül. Minden javítás a kódbázis állandó fejlesztése, nem pedig ideiglenes futásidejű javítás, amely elavulhat, rossz elemre vonatkozhat, vagy elrejtheti a tartalmat a fogyatékkal élő felhasználók elől.
A lényeg
Az átfedések elrejtik a tartalmat a fogyatékkal élő felhasználók elől (141 elem 5 webhelyen). Hibákat okoznak az éles környezetben (7 „aria-label=”true”” példány). Minden webhely-frissítéskor meghibásodnak (a szelektorok 98%-a keretrendszer-specifikus osztályokat céloz meg). A hozzájárulás megadása előtt nyomon követik a felhasználókat (állandó UID-k és munkamenet-azonosítók). Hálózati forgalmuk 75%-át a gyártói elemzésekre fordítják, nem pedig az akadálymentesítésre. Azokat a vállalatokat pedig, amelyek ezeket használják, évente több mint 1000 per indítják ellenük.
Egy olyan felügyeleti eszköz, amely – a DOM módosítása nélkül – átvizsgálja és jelentést készít, egyszerre kiküszöböli mindezeket a kockázatokat. A javításokat a webhely saját fejlesztői hajtják végre a szokásos kódellenőrzési, tesztelési és telepítési folyamatok keretében. A javítások tartósak, mivel a forráskód részét képezik, nem pedig egy párhuzamos, külső réteget alkotnak. Maga az eszköz pedig nem okozhat meghibásodást a webhelyen, nem követheti nyomon a felhasználókat, és nem hozhat létre akadálymentességi korlátokat, mivel soha nem érinti az oldalt.
Az akadálymentességi overlayeket értékelő e-kereskedelmi vállalkozások számára három kérdést javaslunk: Először is, módosítja-e ez az eszköz az élő DOM-ot? Ha igen, akkor minden javítás potenciális hibaforrás lehet a következő telepítéskor. Másodszor, nyomon követi-e ez az eszköz a felhasználókat? Ha igen, akkor GDPR-nek megfelelő adatvédelmi megállapodásra (DPA) és hozzájárulási mechanizmusra van szükség, és az adatvédelmi irányelvekben nyilvánosságra kell hozni a nyomon követést. Harmadszor: ellenőrizni tudja, hogy mit csinál ez az eszköz? Ha a válasz egy egyetlen, 794 KB-os minifikált fájl, amelyben a teljes dokumentumra MutationObserver van beállítva, akkor az őszinte válasz: nem.
Az overlay architektúrát eredetileg gyors megoldásként tervezték. Kutatásaink azonban azt mutatják, hogy ez a megoldás jogi felelősségre vonáshoz, a felhasználók megkülönböztetéséhez, a teljesítmény romlásához és technikai adóssághoz vezet. A felügyeleti megközelítés – vizsgálat, jelentés, javítás a forráskódban – az egyetlen olyan architektúra, amely új problémák keletkezése nélkül skálázható.