Zachytili jsme všechny požadavky od pěti nástrojů pro kontrolu přístupnosti. Zde je přehled toho, jak tyto nástroje ve skutečnosti působí na váš web.

Nezávislý technický audit čtyř překryvných vrstev pro přístupnost a jednoho řešení určeného výhradně k monitorování – co ve skutečnosti mění, co skrývají před uživateli se zdravotním postižením a proč bylo jen v roce 2024 žalováno více než 1 000 firem využívajících tyto překryvné vrstvy.

Jak jsme postupovali: Metodika výzkumu

Většina recenzí nástrojů pro kontrolu přístupnosti se opírá o marketingová tvrzení, dokumentaci výrobců nebo povrchní testování. My jsme zvolili zásadně odlišný přístup: zachytili jsme každý bajt dat proudící mezi prohlížečem a servery jednotlivých nástrojů, extrahovali jsme skutečné soubory oprav v jazyce JavaScript a data o nápravných opatřeních a podrobně jsme analyzovali, jak přesně každý nástroj zasahuje do živého DOMu produkčních e-shopů.

Technické vybavení

Nasadili jsme mitmproxy – open-source HTTPS proxy – nakonfigurovanou tak, aby zachycovala kompletní obsah požadavků a odpovědí u veškerého provozu směřujícího na domény CDN a API těchto nástrojů. Do prohlížeče jsme nainstalovali kořenový certifikát CA tohoto proxy, abychom umožnili transparentní zachycování HTTPS, a poté jsme spustili vyhrazenou instanci prohlížeče Chrome, jejíž provoz byl směrován výhradně přes toto proxy. Nastavili jsme filtry domén tak, aby zachycovaly pouze provoz směřující na servery nástrojů pro přístupnost – tím jsme zajistili, že budeme analyzovat pouze data, která tyto nástroje vkládají, nikoli vlastní provoz daných webů.

Následně jsme procházeli 14 živých e-shopů tak, jak by to udělal běžný uživatel: načítali jsme úvodní stránku, přecházeli na stránky se seznamem produktů, prohlíželi si stránky s podrobnostmi o produktech, přidávali položky do košíku, přecházeli k pokladně, navštěvovali stránky s účtem a registrací a interagovali s modálními okny, karusely a vyhledáváním. Každá relace prohlížení byla zaznamenána jako soubor HTTP Archive (HAR) s úplným tělem odpovědi – ve stejném formátu, jaký prohlížeče používají interně, ale obohacený o skutečný obsah každého souboru JavaScript, každého stylu CSS, každé konfigurace JSON a každé odpovědi API, kterou nástroje poskytly.

Po zachycení dat jsme napsali analytické skripty v jazyce Python, které analyzovaly tělo každé odpovědi, klasifikovaly každý soubor podle nástroje a funkce, extrahovaly všechny selektory CSS z definic oprav, spočítaly všechny vzorce manipulace s DOM v kódu JavaScriptu, identifikovaly všechny případy obsahu skrytého před asistenčními technologiemi a přiřadily každou opravu k části stránky, na kterou má vliv (pokladna, košík, seznam produktů, navigace atd.).

Proxy během tří záznamových relací zachytilo 924 HTTP požadavků s 579 úplnými těly odpovědí – včetně všech opravných skriptů pro jednotlivé weby, všech opravných souborů JSON, všech konfiguračních souborů a všech analytických dat. Uložili jsme také kompletní snímky DOM stránek s aplikovanými úpravami překryvů, což nám umožnilo zkontrolovat přesné hodnoty aria-label a atributy dodavatelských dat vložené za běhu. Poté jsme napsali automatizované analytické skripty, které analyzovaly JavaScript, spočítaly všechny vzory úprav DOM, extrahovaly všechny selektory CSS, klasifikovaly všechny opravy podle oblasti stránky a identifikovaly všechny případy obsahu skrytého před asistenčními technologiemi.

Co jsme analyzovali

Mezi tyto weby patřily stránky významných módních řetězců, luxusních čokoládových značek, výrobců zavazadel, obchodů s designovými kabelkami, výrobců hraček, telekomunikačního operátora, celostátní banky, značek nápojů, papírenského zboží, hodinek a cukrovinek – a to jak na trzích EU, tak i v USA.

Důležitá poznámka: V žádném překryvném panelu pro přístupnost není k dispozici ohraničení na úrovni stránky

Jeden z nejvíce překvapivých zjištění se objevil ještě předtím, než jsme vůbec začali analyzovat pravidla oprav: každá vrstva pro přístupnost načítá celou sadu oprav na každé jednotlivé stránce, bez ohledu na typ stránky. Opravy specifické pro proces platby se spouštějí na úvodní stránce. Pravidla pro množství v košíku se provádějí na stránce „O nás“. Opravy produktových dlaždic se spouštějí na přihlašovacím formuláři.

To znamená, že na webu tohoto telekomunikačního operátora si každý návštěvník každé stránky stáhne soubor JSON o velikosti 1,25 MB, který obsahuje 4 974 popisů obrázků a 2 000 záznamů o nápravných opatřeních ve formátu PDF – a to i na stránkách, kde se nenachází žádný obrázek. U prodejce značkových kabelek se při každém načtení stránky spustí 383 pravidel pro opravu DOM, která se pokoušejí najít selektory, které existují pouze na konkrétních typech stránek. Když se selektor specifický pro pokladnu, jako je #cardNumber, nepodaří najít na domovské stránce, opravný engine překryvu stále vynakládá výpočetní výkon na jeho vyhodnocení – při násobení stovkami pravidel to způsobuje měřitelné plýtvání výkonem při každém zobrazení stránky.

Funkce Overlay A zaznamenává pouze 4,5 % relací

Při prozkoumávání analytických dat POST v Overlay A jsme narazili na pole, které odhaluje skutečnou vzorkovací frekvenci skenování:

Vzorkovací míra 0,045 znamená, že u tohoto prodejce módy spustí kontrolu dodržování předpisů pouze 4,5 % návštěvnických relací. Na jiném webu – u luxusní čokoládové značky – byla tato míra ještě nižší: pouhých 1,7 %. Je možné, že dodavatel overlay řešení provádí při zprovoznění nebo nastavení komplexnější úvodní kontrolu a následně pro průběžné monitorování vzorkovací míru sníží. Důsledky pro každodenní provoz však zůstávají značné.

Kód spouštěcího balíčku vrstvy pro přístupnost potvrzuje existenci tří provozních úrovní: ReleaseVersionReport (úplná kontrola + zpráva – procentuální podíl vzorku), ShadowVersionReport (stínová kontrola, bez akcí viditelných pro uživatele) a RunReleaseFixesNoReport (aplikace všech opravných pravidel, ale bez provedení jakékoli kontroly). To znamená, že během běžného provozu se u drtivé většiny vašich návštěvníků provádějí úpravy DOM, které nejsou během jejich relace ověřovány.

Praktické riziko spočívá v tom, že pokud nasazení na webu změní strukturu DOM a poruší jedno nebo více pravidel oprav, nízká průběžná frekvence vzorkování znamená, že tato chyba může zůstat po dlouhou dobu nezjištěna. Vzhledem k tomu, že se skenuje pouze 1,7–4,5 % relací, může nefunkční oprava ovlivnit tisíce návštěvníků, než se na dané stránce náhodou spustí další vzorkovaná relace a problém nahlásí. Během této doby každý návštěvník obdrží zastaralé nebo nesprávně zacílené opravy – a ani provozovatel webu, ani dodavatel překryvů si nemusí být tohoto problému vědom.

Závěry: Oprava pravidel a úprav DOM

Překryv A: Soubory oprav JavaScriptu pro jednotlivé weby

Tento overlay spravuje pro každý klientský web samostatný soubor s opravami v jazyce JavaScript, který obsahuje pravidla zaměřená na konkrétní selektory CSS. Při analýze pěti webů jsme zjistili:

Zjistili jsme také, že 7 případů kde řetězec "true" byl podán jako aria-label – chyba v kódu, kdy byla namísto popisného textu předána logická hodnota. Čtečky obrazovky oznamují „tlačítko, true“ – což je zcela nesmyslné. Na jiné stránce bylo slovo „Search“ ve vloženém popisku chybně napsáno jako „Seacrh“.

Vrstva B: Hromadné generování alternativního textu pomocí umělé inteligence

Tento doplněk stahuje rozsáhlé soubory JSON s opravami, které obsahují popisy obrázků vygenerované umělou inteligencí. A to na třech webech:

Konkrétní příklady z dat o sanacích:

323 popisů překročilo délku 125 znaků – což vedlo k nadměrnému výstupu čtečky obrazovky, která u každého obrázku četla 10–15 sekund. 156 popisů zbytečně začínalo slovy „obrázek…“ – což je v rozporu s doporučeními WCAG, protože čtečky obrazovky již typ prvku oznamují.

Monitorovací nástroj: Žádné úpravy – ověřeno ve zdrojovém kódu

Co výraz „Skrýt před AT“ znamená pro skutečné uživatele

Pokud překryvná vrstva skryje prvek před asistenční technologií, zůstává tento prvek na obrazovce viditelný, ale pro čtečky obrazovky se stává zcela neviditelným. Každý skrytý prvek jsme zařadili podle oblasti stránky, na kterou má vliv:

Údaje pocházejí ze skutečných opravných souborů active.js jednotlivých webů, extrahovaných pomocí nástroje mitmproxy. Každý počet představuje jedinečný selektor CSS, na který se zaměřuje funkce hideFromAT().

Na stránce pokladny jednoho prodejce luxusního zboží patřily mezi prvky skryté před čtečkami obrazovky:

Nástroje pro překryvné zobrazení tak vytvářejí dvojí nákupní zážitek: vidoucí uživatelé vidí všechny platební možnosti a mohou si vybrat mezi kreditní kartou, PayPal, Amazon Pay, Shop Pay a Klarna. Nevidomí uživatelé však vidí pouze ty platební metody, které překryvné zobrazení nezakrylo. U jednoho prodejce módy byly skryté jak pole pro zadání počtu kusů v košíku, tak tlačítko pro aktualizaci – nevidomý uživatel mohl přidávat položky, ale nemohl měnit jejich množství.

To vyvolává zásadní otázku: zvyšuje překryv, který skryje platební tlačítka před nevidomými uživateli, přístupnost webu, nebo ji naopak snižuje?

Dopad na výkon

Co se stane po nasazení webu

Snad nejzáludnější riziko nástrojů pro překryvné vrstvy se projeví až s odstupem času: opravy se tiše zhoršují. Na rozdíl od chyby v JavaScriptu, která způsobí viditelný pád aplikace, nebo nefunkčního rozvržení, které si někdo všimne, zastaralá oprava v překryvné vrstvě nevyvolá žádnou chybu, žádné upozornění ani žádnou vizuální změnu. Prostě přestane fungovat – a bariéra přístupnosti, kterou zakrývala, se znovu objeví, aniž by si toho někdo všiml.

Abyste tomu porozuměli, zamyslete se nad tím, jak se jednotlivé typy překryvů propojují se strukturou DOM vašeho webu.

Opravy založené na selektoru: Čas neúprosně běží

Overlay A – stejně jako většina řešení typu overlay pro přístupnost – spravuje soubory s opravami v jazyce JavaScript pro jednotlivé weby, které obsahují pravidla tohoto typu (rekonstruováno na základě skutečně zachyceného kódu):

Toto pravidlo se vztahuje na tlačítko se šipkou zpět v karuselu Slick a využívá tři třídy CSS: .js-recommendation_carousel, .slick-preva .slick-arrow. Každá část tohoto selektoru je velmi citlivá. Pokud tým spravující web přejmenuje třídu kontejneru karuselu, přejde z knihovny Slick na Splide nebo Swiper, nebo jednoduše aktualizuje knihovnu Slick na verzi, která mění konvenci pojmenování tříd – selektor již nic nenajde. Tlačítko ztratí svůj popisek „Předchozí snímek“. Uživatelé čteček obrazovky jej již nebudou moci identifikovat.

Na pěti lokalitách, které jsme analyzovali v rámci projektu Overlay A, jsme zjistili, že 98 % všech selektorů obsahuje názvy tříd specifické pro daný framework – třídy, jejichž název začíná předponou .js-, .b-, .chakra-, .splide__nebo hashové hodnoty CSS-in-JS, jako například .css-acuo7n. Nejedná se o stabilní sémantické identifikátory – jde o implementační detaily, které se mění s každou aktualizací frameworku, refaktoringem komponent nebo úpravou systému sestavování.

U jednoho prodejce značkových kabelek jsme objevili selektory zaměřené na komponenty Chakra UI. Chakra UI vydává v hlavních verzích zásadní změny – názvy tříd, struktura komponent i vzory ARIA se neustále vyvíjejí. Jakmile tento web provede aktualizaci Chakry, mohou se tiše přestat fungovat potenciálně stovky pravidel oprav překryvů. Dodavatel overlaye pak musí ručně zkontrolovat novou strukturu DOM, přepsat každý dotčený selektor a nasadit aktualizované soubory oprav. Během období mezi nasazením webu a aktualizací dodavatele overlaye běží web se zastaralými opravami – některé nefungují vůbec, jiné se potenciálně aplikují na nesprávné prvky.

Opravy založené na URL: Ještě méně spolehlivé

Překryjte klíče JSON nástroje Remediation B tak, aby každý záznam alternativního textu odpovídal přesné URL zdroje obrázku. Našli jsme záznamy jako:

Všimněte si této zranitelnosti: adresa URL obsahuje identifikátor zařízení (13555), rozměry miniatury (86x86) a název souboru, který obsahuje název produktu. Každý z těchto údajů se může měnit samostatně. Pokud systém CMS vygeneruje miniatury v jiné velikosti, thumb_86x86 část adresy URL se změní a záznam již neodpovídá. Pokud produktový tým nahraje novou fotografii s jiným názvem souboru, záznam se stane osamoceným. Pokud web přesune svá média na CDN s jinou doménou, každý jednotlivý záznam v souboru JSON o velikosti 1,17 MB se stane zbytečnou zátěží – a zároveň každý obrázek na webu ztratí svůj alternativní text.

Nejhorším scénářem je částečné selhání přiřazení: některé obrázky si zachovají své původní URL adresy (a dostanou alternativní text), zatímco nové nebo aktualizované obrázky se k žádnému záznamu nepřiradí (a nedostanou nic). Výsledkem je nejednotné zobrazení, kdy jsou některé obrázky popsány a jiné jsou bez upozornění vynechány – což je pro uživatele čtečky obrazovky mnohem matoucí než jednotná absence alternativního textu.

Opravy v globálním rozsahu: Problém kaskádování

Přístup Overlay C – připojení objektu MutationObserver k celému dokumentu a provedení obecných oprav u všech prvků určitých typů (a, button, input, img, h1) – vytváří odlišný, ale stejně nebezpečný typ selhání. Namísto toho, aby se při zastaralosti selektorů potichu zhroutil, tento overlay aktivně bojuje s novým kódem.

Představme si běžný scénář: tým vývojářů webu nasadí novou komponentu přístupného modálního dialogového okna, která správně implementuje zachycení fokusu, zavření stisknutím klávesy Esc a atributy ARIA. MutationObserver překryvného prvku detekuje nové prvky DOM, vyhodnotí je podle svých obecných pravidel a – pokud najde prvky odpovídající jeho vzorcům – aplikuje své vlastní řízení fokusu, obslužné rutiny klávesnice a atributy ARIA nad stávající správnou implementací komponenty. Výsledkem je dvojitě zachycený fokus, duplicitní obslužné rutiny klávesnice a konfliktní atributy ARIA. Modální okno, které před načtením overlaye fungovalo perfektně, se nyní chová nepředvídatelně.

Nejde zde o pouhou teoretickou otázku. Knihovny komponent pro vývojové rámce, jako jsou Radix UI, Headless UI a Chakra UI, věnují značné úsilí správné implementaci standardu ARIA. Překryv, který plošně aplikuje své vlastní atributy ARIA na všechny button a a prvky budou pravděpodobně v rozporu s těmito osvědčenými implementacemi, což znemožní správnou přístupnost komponent méně dostupné.

Monitorovací nástroj: Nic, co by se mohlo pokazit

Monitorovací nástroj, který jsme analyzovali, nepoužívá opravy založené na selektorech, záznamy vázané na URL, MutationObserver ani obecné zacílení na prvky. Jakmile web nasadí nový kód, při dalším skenování monitorovací nástroj automaticky vyhodnotí nový DOM podle standardizované sady pravidel axe-core a nahlásí veškerá nová porušení – aniž by cokoli měnil. Výsledky skenování se zobrazí na řídicím panelu nástroje spolu s úrovněmi závažnosti, počtem ovlivněných prvků a standardizovanými ID pravidel WCAG. Vývojáři zkontrolují zjištění a implementují opravy do své vlastní kódové základny, kde opravy procházejí revizí kódu, automatizovaným testováním, ověřením na testovacím prostředí a řízeným nasazením.

Tento proces je ze své podstaty odolný vůči změnám: nástroj prohledá DOM v takovém stavu, v jakém se právě nachází, nahlásí zjištěné problémy a při dalším prohledávání začne od začátku. Nevzniká žádný nahromaděný technický dluh v podobě definic oprav, neexistují zastaralé selektory ani osamocené záznamy alternativního textu a nehrozí, že by byla nesprávná oprava aplikována na nesprávný prvek.

Co se pokazí při opětovném nasazení

Každá oprava v rámci překryvného prvku pro přístupnost je vázána na aktuální strukturu DOM daného webu. Zjistili jsme, že 98 % selektorů jednoho overlaye cílí na názvy tříd specifické pro daný framework – předměty jako .chakra-, .splide__, .js-, .b-a hashové hodnoty CSS-in-JS, jako například .css-acuo7n které se mění při každém sestavení.

Monitorovací nástroj vykazuje v každém řádku stav „Není ovlivněno“, protože neobsahuje žádné opravy založené na selektorech. Není zde nic, co by mohlo zastarat, nic, co by se mohlo zaměřit na nesprávný prvek, a nic, co by mohlo způsobit chybu.

GDPR, ochrana osobních údajů a problém se souhlasem

Naše analýza potvrdila, že tři ze čtyř překryvných oken pro přístupnost odesílají data na externí servery ještě předtím, než je možné s jakýmkoli bannerem pro udělení souhlasu jakkoli interagovat:

Podle rozsudku Soudního dvora Evropské unie ve věci Planet49 vyžaduje sledování, které není nezbytně nutné, předchozí výslovný souhlas. Dvě překryvná okna odesílají trvalé identifikátory již při prvním síťovém požadavku – ještě předtím, než se může spustit jakýkoli mechanismus pro získání souhlasu. U webů zaměřených na EU se tím automaticky porušuje nařízení GDPR.

Právní prostředí

V dubnu 2025 uzavřela americká Federální obchodní komise (FTC) dohodu o vyrovnání ve výši 1 milionu dolarů s jedním z dodavatelů nástrojů pro vylepšení přístupnosti, který byl předmětem naší studie, a to kvůli klamavému tvrzení, že jeho nástroj využívající umělou inteligenci dokáže zajistit soulad jakékoli webové stránky s WCAG. FTC zjistila , že tento nástroj nedokázal zajistit přístupnost základních prvků webových stránek – nabídek, nadpisů, tabulek, obrázků a nahrávek. V jednom z uvedených příkladů byla fotografie filetu mignon opatřena popisem generovaným umělou inteligencí: „Hnědý chléb na bílém keramickém talíři.“

Podle údajů z průzkumu v oboru bylo v roce 2024 v 25 % všech soudních sporů týkajících se digitální přístupnosti výslovně uvedeno, že widgety typu overlay představují překážku, nikoli řešení. V první polovině roku 2025 pokračovaly soudní spory proti společnostem využívajícím overlay v počtu přesahujícím 100 případů měsíčně. Dva z dodavatelů překryvných prvků v naší studii byli přímo zapojeni do soudních sporů: jeden v třech samostatných případech týkajících se patentů a obchodního tajemství a druhý čelil hromadné žalobě od zákazníka z řad malých podniků, který byl žalován navzdory tomu, že překryvné prvky používal.

Monitorovací nástroj použitý v naší studii nemá v minulosti žádné soudní spory související s porušením zásad přístupnosti – což je logický důsledek jeho architektury: jelikož nikdy nemění DOM, nemůže vytvářet překážky přístupnosti.

Podíváme se do kódu: Co přesně tyto překryvy mění

Abychom pochopili rozsah manipulace s DOM, spočítali jsme všechny vzorce úprav v kódu JavaScriptu každého nástroje. Rozdíly jsou markantní:

Zvláštní pozornost si zaslouží Overlay C. Jeho monolitický balíček o velikosti 794 KB obsahuje MutationObserver až document.documentElement s konfigurací {subtree: true, childList: true, attributes: true, attributeOldValue: true}. To znamená každá jednotlivá změna DOM na celé stránce – ať už jde o synchronizaci virtuálního DOMu v Reactu, skript pro A/B testování, widget chatu nebo vlastní JavaScript webu – spustí pozorovatele překryvného prvku, který následně přehodnotí a případně znovu aplikuje své opravy. Po opětovném nasazení webu to vyvolá řetězovou reakci pokusů o opravy prvků, které již mohou být správně přístupné, což může vést k přepsání správných atributů ARIA nesprávnými.

Potvrdili jsme, že Overlay C odesílá USER-BEHAVIOR-ANALYTICS POST požadavky na vlastní přijímač protokolů, přičemž užitečná data obsahují doménu webu, verzi widgetu, jazyk uživatele a události interakce. V kombinaci s localStorage trvalé ukládání a identifikace zařízení prostřednictvím navigator.userAgent a navigator.maxTouchPoints… jedná se o operaci zpracování údajů, o které většina provozovatelů webových stránek ani neví, že k ní dochází.

Řešení problému s JSON

Overlay B stahuje obrovský soubor JSON (až 1,17 MB u jednoho telekomunikačního webu), který obsahuje všechny definice oprav. Na jednom webu jsme zaznamenali, že byl tento soubor během jedné relace prohlížení stažen celkem čtyřikrát – což představuje 4,7 MB přenesených dat pro soubor, který měl být uložen do mezipaměti. Soubor JSON obsahuje 11 kategorií, ale drtivá většina z nich jsou popisy obrázků generované umělou inteligencí: 4 974 z 6 975 záznamů pro jednu lokalitu. Každý z nich je přiřazen ke konkrétní URL obrázku – když CMS přejmenuje soubor, změní rozměry miniatury nebo migruje domény CDN, záznamy přestanou tiše odpovídat. Náhradní obrázky nemají vůbec žádný alternativní text, což činí stránku méně přístupnou než před instalací overlaye.

Tento overlay také nasazuje moduly běžící za běhu, které stránku aktivně přepisují: opravný modul o velikosti 110 KB, pomocný modul pro navigační menu o velikosti 23 KB, který přebudovává zpracování klávesových zkratek v menu, opravu karuselu o velikosti 5,8 KB a skener na straně klienta o velikosti 53 KB, který využívá vlastní logiku namísto standardního modulu axe-core – což znamená, že jeho zjištění nelze nezávisle ověřit.

Nejtransparentnější překryv – stále riskantní

Overlay D měl nejtransparentnější architekturu: konfigurační soubory ve formátu JSON srozumitelné pro člověka, obsahující explicitní přepínače pro zapnutí a vypnutí. Možnosti jako addAriaHidden, overwriteAlta adjustMetaViewport byly výslovně nastaveny na false. Základní modul (649 KB) však obsahuje 216 setAttribute hovory, 47 aria-hidden odkazy, 282 addEventListener registrací a 9 MutationObserver případy. Engine podporuje agresivní úpravy DOM i v případě, že je aktuální konfigurace konzervativní – změna konfigurace ze strany poskytovatele by mohla aktivovat rizikové funkce bez vědomí provozovatele webu.

Našli jsme selektory pro jednotlivé stránky, které obsahují hashové přípony generované JavaScriptem, jako například button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 které se mění při každém sestavení, a selektory URL sociálních sítí, které přestanou fungovat, jakmile web aktualizuje své odkazy na Facebook nebo Instagram.

Evropský zákon o přístupnosti: Proč překryvné vrstvy nesplňují požadavky EAA

Od 28. června 2025 vyžaduje Evropský zákon o přístupnosti (EAA), aby digitální produkty a služby prodávané v EU splňovaly normy přístupnosti v souladu s normou EN 301 549, která odkazuje na WCAG 2.1 AA. Na rozdíl od ADA – který je prosazován především prostřednictvím soukromých žalob – je EAA prosazován vnitrostátními orgány dozoru nad trhem, které mají pravomoc ukládat pokuty, nařizovat nápravná opatření a stahovat produkty, které nesplňují požadavky, z trhu.

Oficiální odmítnutí nástrojů pro překrývání ze strany Německa

Německo zaujalo ze všech zemí nejjasnější regulační postoj k nástrojům pro přístupnost typu „overlay“. Federální dozorový orgán pro přístupnost informačních technologií ( BFIT-Bund – Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) společně se všemi dozorovými orgány na úrovni spolkových zemí vydal společné stanovisko, v němž výslovně odmítá používání nástrojů typu „overlay“ pro zajištění souladu s požadavky na přístupnost:

Dne 12. března 2025 Výbor pro bezbariérové informační technologie (Ausschuss für barrierefreie Informationstechnik, zřízený podle § 5 BITV 2.0) na svém zasedání tento postoj znovu potvrdil a s obavami konstatoval, že veřejné orgány se i nadále pokoušejí plnit své povinnosti v oblasti přístupnosti prostřednictvím vkládání překryvných nástrojů. Výbor dospěl k závěru, že „dočasné zpřístupnění webové stránky pomocí softwaru – případně až po konfiguraci nastavení uživatelem – po dobu trvání jeho návštěvy nesplňuje požadavky platných právních předpisů.“

Výbor výslovně varoval, že veřejné orgány, které používají nástroje typu overlay, riskují, že přístupnost svých webových stránek zhorší, nikoli zlepší – což vede ke zhoršení přístupnosti („Verschlechterung der Barrierefreiheit“). To přímo odráží náš technický zjištění, že 26 % pravidel pro opravu pomocí overlayů vede k novým porušením WCAG.

Pečeť BIK: Zamítnuto u webových stránek využívajících překryvné vrstvy

Německá testovací síť BIK – akreditované orgány, které hodnotí webové stránky podle norem BITV 2.0, EN 301 549 a WCAG 2.1 AA – přijala praktické opatření: webové stránky využívající nástroje typu overlay nemohou získat testovací pečeť BIK. Testovací orgány uvedly, že nemohou provést spolehlivé posouzení shody, pokud je přítomna překryvná vrstva, protože tato vrstva mění DOM během běhu takovým způsobem, který činí výsledky testů nespolehlivými. Pečeť BIK je v Německu široce používána jako důkaz shody s normou BITV 2.0 – a nyní není k dispozici pro žádné webové stránky, které používají překryvnou vrstvu.

Nejde zde o pouhou teoretickou politickou otázku. Znamená to, že německý e-shop, který využívá některý ze čtyř námi testovaných překryvných prvků, nemůže získat certifikát o shodě s normami, který je na německém trhu běžně vyžadován.

Potvrzení na evropské úrovni

Tento regulační postoj přesahuje hranice Německa. Evropské fórum pro osoby se zdravotním postižením a Mezinárodní asociace odborníků na přístupnost vydaly v roce 2023 společné prohlášení, v němž varují, že překryvné vrstvy nezajišťují přístupnost webových stránek ani jejich soulad s evropskými právními předpisy v oblasti přístupnosti, včetně evropského zákona o přístupnosti. K tvrzením o shodě překryvných vrstev se vyjádřila také Evropská komise, která dospěla k závěru, že překryvné vrstvy nemohou zajistit soulad s platnými normami.

Podle německého zákona BFSG (Barrierefreiheitsstärkungsgesetz – německá transpozice směrnice EAA, platná od 28. června 2025) mohou orgány dozoru nad trhem ukládat pokuty ve výši 10 000 až 100 000 EUR za každý případ porušení. Hodnocení BFIT-Bund a odmítnutí certifikace webů využívajících overlay ze strany testovací sítě BIK v praxi znamenají, že overlay nástroje v Německu neposkytují žádnou regulační ochranu – a mohou aktivně zvyšovat riziko vynucovacích opatření.

Bezpečnost a rizika v dodavatelském řetězci

Každý nástroj pro vkládání překryvů funguje tak, že do globálního rozsahu vašich produkčních stránek vkládá JavaScript od třetích stran. Tento JavaScript běží se stejnými oprávněními jako váš vlastní kód – může číst a upravovat libovolné prvky DOM, zachycovat odeslaná data z formulářů, přistupovat k souborům cookie, přesměrovávat uživatele a odcizovat data. Bezpečnostní důsledky tohoto postupu jsou značné a často se přehlížejí.

Útočná plocha

Zamyslete se nad dodavatelským řetězcem: když na svůj web přidáte modul pro zajištění přístupnosti, udělujete externímu dodavateli trvalý a neomezený přístup s právem zápisu k vašemu živému produkčnímu DOM. CDN tohoto dodavatele poskytuje skripty JavaScript, jeho tým se stará o údržbu kódu a jeho nasazovací proces zasílá aktualizace přímo na váš web – bez vaší kontroly kódu, bez vašeho procesu kontroly kvality a bez vašeho schválení.

Pokud dojde k narušení bezpečnosti CDN poskytovatele overlay sítě, útočník získá možnost vkládat škodlivý kód do všech webů, které tuto overlay síť využívají. Pokud zaměstnanec poskytovatele nasadí chybnou aktualizaci, jsou tím současně zasaženy všechny weby zákazníků. Pokud dojde k únosu koncového bodu API poskytovatele, lze manipulovat s opravným JSON souborem nebo konfiguračními daty zasílanými na váš web tak, aby došlo ke změně polí formulářů, přesměrování odkazů nebo vložení phishingového obsahu.

Rozsah tohoto rizika přímo souvisí s velikostí DOM kódu překryvného prvku:

Overlay B představuje největší rizikovou plochu v dodavatelském řetězci: 228 volání API na relaci napříč 3 externími doménami, s datovou náplní JSON o velikosti 1,17 MB, která definuje, jak má být DOM upraven. Kompromitovaná odpověď API by mohla nařídit nápravnému modulu, aby vložil libovolný obsah do jakéhokoli prvku na stránce. Monolitický balíček Overlay C o velikosti 1 285 KB představuje největší jednotlivý JavaScriptový payload – a protože je minimalizovaný a zamaskovaný, ani provozovatel webu, ani bezpečnostní auditor nemohou smysluplně zkontrolovat, co se při běhu provádí.

Soulad s normou PCI DSS: Přímý rozpor

Pro jakýkoli e-shop, který zpracovává platby kreditními kartami, není dodržování standardu PCI DSS volitelnou záležitostí. Naše zjištění však ukazují, že mezi architekturou nástrojů pro přístupnost a požadavky standardu PCI DSS existuje přímý rozpor.

Požadavek PCI DSS 6.4.3 (zavedený ve verzi PCI DSS v4.0, povinný od 31. března 2025) vyžaduje, aby všechny skripty na platebních stránkách, které se načítají a spouštějí v prohlížeči zákazníka, byly spravovány následovně: musí být zavedena metoda pro ověření, že každý skript je autorizován, musí být zajištěna integrita každého skriptu a musí být veden seznam všech skriptů s písemným odůvodněním, proč je každý z nich nezbytný.

Naše analýza potvrdila, že pravidla pro opravu překryvů se aktivně zaměřují na prvky DOM platebních stránek na řadě webů:

Nejedná se o teoretické riziko – jde o konkrétní skripty, které jsme získali z produkčních webů a které aktivně mění pole pro zadávání čísel kreditních karet, výběr fakturační adresy, tlačítka platebních poskytovatelů a kontejnery platebních formulářů. Podle normy PCI DSS 6.4.3 vyžaduje každý z těchto skriptů třetích stran zdokumentované povolení, ověření integrity a písemné odůvodnění.

Zamyslete se nad tím, co může skript poskytovatele overlayů na vaší stránce pro dokončení objednávky dokázat:

Monitorovací nástroj naproti tomu nemá vůbec žádnou schopnost zapisovat do DOM. Jeho skript o velikosti 4,2 KB nemůže měnit pole formuláře, zachycovat události zadávání dat ani přistupovat k prvkům platebního formuláře či je měnit. I kdyby došlo k narušení bezpečnosti CDN poskytovatele monitorovacích služeb, útočník by získal přístup pouze ke skriptu, který dokáže přečíst pouze URL stránky a typ zařízení – nikoli ke skriptu, který by mohl přepsat platební formulář. Z hlediska rozsahu certifikace PCI DSS nevytváří monitorovací nástroj na platebních stránkách žádnou dodatečnou bezpečnostní zranitelnost.

Otázka diskriminace

Toto je problém diskriminace, který je jádrem každého systému pro usnadnění přístupu: Nejznepokojivějším zjištěním není technická vada – je jím systémové odepírání přístupu k funkcím, které vidoucí uživatelé považují za samozřejmost, uživatelům se zdravotním postižením.

Pokud překryvná vrstva zakryje tlačítko Amazon Pay ve stromu přístupnosti, vidí nevidomý uživatel méně platebních možností než uživatel s normálním zrakem. Pokud je pole pro zadání počtu kusů v košíku skryté, nevidomý uživatel nemůže upravit svou objednávku. Pokud jsou odkazy na výsledky vyhledávání skryté, je vyhledávání produktů ztížené. Pokud jsou hodnocení hvězdičkami skryté, nevidomý uživatel nemůže posoudit kvalitu produktu tak, jak to dokáže uživatel s normálním zrakem.

Nejde o ojedinělé případy – jedná se o základní pracovní postupy v e-commerce, které narušují právě ty nástroje, které slibují jejich zpřístupnění.

Komunita osob se zdravotním postižením na tento problém upozorňuje již řadu let. Informační list o překryvných vrstvách – podepsaný stovkami odborníků na přístupnost – varuje, že překryvné vrstvy „neopravují základní HTML kód“ a „často osobám se zdravotním postižením aktivně překážejí“. Naše technická analýza poskytuje důkazy: 141 funkčních prvků skrytých před čtečkami obrazovky, 7 vložených nesmyslných popisků a 5 066 nekontrolovaných popisů generovaných umělou inteligencí nasazených do produkčního prostředí – a to pouze na 14 webech.

Pro provozovatele webových stránek není otázkou, zda jsou překryvné vrstvy „dostatečně dobré“ – jde o to, zda lze ospravedlnit nasazení nástroje, který vytváří dvojí uživatelský zážitek: jednu verzi pro vidoucí uživatele, kteří mají k dispozici plnou funkčnost, a druhou – filtrovanou, nefunkční a někdy i nesmyslnou – pro uživatele se zdravotním postižením.

Dopad na dodržování zákona ADA: Pomáhají tyto opravy skutečně?

Základním slibem každého overlaye je, že zlepšuje soulad s normou ADA tím, že opravuje porušení WCAG během běhu aplikace. Naše analýza však odhalila znepokojivý paradox: značná část oprav prováděných overlayem při pokusu o nápravu stávajících porušení WCAG ve skutečnosti aktivně zavádí nová porušení.

Každé zaznamenané pravidlo opravy z Overlay A jsme přiřadili ke konkrétnímu kritériu úspěšnosti WCAG 2.1, na které se vztahuje. Ze 776 pravidel, která bylo možné přiřadit, se výsledky rozdělily do dvou kategorií: opravy, které skutečně řeší problém podle WCAG, a opravy, které při tom způsobují nové porušení WCAG.

Abychom byli spravedliví, tři čtvrtiny zaznamenaných oprav představují skutečná vylepšení – doplnění chybějících popisků tlačítek, úprava hierarchie nadpisů, oprava atributů automatického doplňování a implementace mechanismů zachycení fokusu v modálních oknech. Zbývající čtvrtina však působí aktivní škodu, která neúměrně dopadá právě na ty uživatele, kterým má tento nástroj údajně pomáhat.

Jak každý rizikový vzorec porušuje zásady WCAG

Problém nespočívá pouze v tom, že tyto opravy selhávají – jde o to, že způsobují porušení konkrétních kritérií úspěšnosti WCAG, která před použitím překryvné vrstvy neexistovala. V soudním sporu podle zákona ADA může znalec žalobce poukázat na tato porušení způsobená překryvnou vrstvou jako na důkaz toho, že webová stránka diskriminuje osoby se zdravotním postižením.

Vrstva B: Alternativní text generovaný umělou inteligencí a WCAG 1.1.1

WCAG 1.1.1 vyžaduje, aby netextový obsah měl „textovou alternativu, která plní stejnou funkci“. Alternativní text generovaný umělou inteligencí, který popisuje logo společnosti jako „modro-žlutý znak“, neslouží stejnému účelu – účelem loga je identifikace značky, nikoli popis barvy. Alternativní text „text“ pro propagační banner nebo „město“ pro hlavní obrázek nesplňuje stejné kritérium jiným způsobem – je tak vágní, že je k ničemu.

Z celkových 5 068 alternativních textů vygenerovaných umělou inteligencí, které jsme zaznamenali v Overlay B, mělo 241 méně než 15 znaků (což je příliš vágní na to, aby byly užitečné), 323 přesahovalo 125 znaků (což je v rozporu s osvědčenými postupy pro použitelnost čteček obrazovky) a 156 začínalo slovy „obrázek“ nebo „fotografie“ (což je zbytečné, protože čtečky obrazovky již typ prvku oznamují). Pouze 2 byly schváleny lidským recenzentem.

Podle standardů pro soudní spory v rámci zákona ADA by znalec žalobce v oblasti přístupnosti tyto případy označil za porušení kritéria WCAG 1.1.1 – což je nejčastěji zmiňované kritérium v soudních sporech týkajících se přístupnosti webových stránek podle zákona ADA. Překryvné okno toto porušení neřeší; nahrazuje jednu formu nesouladu (chybějící alternativní text) jinou (nepřesný nebo vágní alternativní text) a zároveň u provozovatele webu vyvolává falešný dojem, že požadavky jsou splněny.

Vrstva B: Vkládání popisků formulářů za běhu – když „oprava“ situaci ještě zhorší

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.

Když byl nápravný modul Overlay B aktivní, čtečka obrazovky oznámila:

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

Výsledek je horší než původní formulář bez popisků. Před zobrazením překryvného prvku se uživatel čtečky obrazovky setkal se sedmi poli bez popisků – bylo to sice matoucí, ale alespoň to bylo konzistentní. Mohl se spolehnout na pořadí tabulek a kontext, aby odhadl, které pole je které. Po zásahu překryvu se uživatel setká se dvěma poli se stejným popiskem („Jméno“ pro křestní jméno i příjmení), dvěma poli s vymyšlenými popisky ve stylu validace, které neodpovídají viditelnému textu, a třemi poli s nesmyslnými názvy založenými na typu. Částečné a nesprávné popisky jsou více matoucí než žádné popisky, protože vytvářejí falešný dojem, že formulář byl zpřístupněn, zatímco kritická pole zůstávají bez popisků nebo jsou nesprávně označena.

Tento nález také odhaluje slabinu v JSON souboru s nápravnými opatřeními pro Overlay B. Soubor JSON obsahoval 87 záznamů alternativního textu generovaných umělou inteligencí a žádný záznam o opravě formulářů pro tento web. Vkládání popisků do formulářů probíhá výhradně za běhu prostřednictvím obslužné rutiny pravidla EmptyControls – není viditelné v konsolidovaném souboru JSON s opravami, není sledováno v žádném panelu, který by mohl provozovatel webu zkontrolovat, a nepodléhá lidskému schválení. Provozovatel webu nemá žádný způsob, jak zjistit, že jeho kontaktní formulář je nesprávně označen, pokud to sám nevyzkouší pomocí čtečky obrazovky.

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.

Čistý dopad na dodržování předpisů ADA

Základním problémem je, že nástroje pro překryv zaměňují pokrytí s dodržováním standardů. Překryv může odkazovat na 1 058 opravných pravidel a tvrdit, že řeší více než 40 kritérií úspěšnosti WCAG. Pokud však 26 % těchto oprav vede k novým porušením – včetně nesplnění kritérií úrovně A způsobených skrytím funkčních prvků –, může být výsledný stav dodržování standardů horší než u neupraveného webu.

Web bez překryvného prvku, který obsahuje 50 porušení směrnice WCAG, je z právního hlediska v jasnější situaci než web s překryvným prvkem, který obsahuje 30 původních porušení a navíc 203 porušení způsobených tímto překryvným prvkem – protože porušení způsobená překryvným prvkem dokazují, že provozovatel webu nasadil nástroj, který aktivně diskriminuje uživatele se zdravotním postižením, což podkopává jakoukoli obhajobu založenou na dobré víře.

Závěrem