Vi har opfanget alle anmodninger fra fem tilgængelighedsværktøjer. Her kan du se, hvad de rent faktisk gør ved din hjemmeside.

En uafhængig teknisk undersøgelse af fire tilgængeligheds-overlays og én løsning, der udelukkende overvåger – hvad de rent faktisk ændrer, hvad de skjuler for brugere med handicap, og hvorfor over 1.000 virksomheder, der bruger overlays, blev sagsøgt alene i 2024.

Sådan gjorde vi: Forskningsmetodologien

De fleste anmeldelser af tilgængeligheds-overlays bygger på markedsføringspåstande, leverandørers dokumentation eller overfladiske tests. Vi valgte en helt anderledes tilgang: Vi opfangede hver eneste byte data, der blev udvekslet mellem browseren og de enkelte værktøjers servere, udtrak de faktiske JavaScript-rettelsesfiler og data om afhjælpningen og analyserede nøje, hvad hvert værktøj gør ved det aktive DOM på e-handelswebsteder i produktion.

Det tekniske setup

Vi implementerede mitmproxy – en open source-HTTPS-proxy – konfigureret til at indsamle hele indholdet af anmodninger og svar for al trafik til værktøjernes CDN- og API-domæner. Vi installerede proxyens rod-CA-certifikat i browseren for at muliggøre transparent HTTPS-aflytning og startede derefter en dedikeret Chrome-instans, der udelukkende blev dirigeret gennem proxyen. Vi konfigurerede domænefiltre til kun at indsamle trafik til serverne for tilgængelighedsværktøjerne – hvilket sikrede, at vi kun analyserede det, disse værktøjer indsatte, og ikke webstederne egen trafik.

Derefter gennemgik vi 14 aktive e-handelswebsteder, som en almindelig bruger ville gøre: vi indlæste startsiden, navigerede til produktoversigtssider, så produktdetaljesider, lagde varer i indkøbskurven, gik til kassen, besøgte konto- og registreringssider og interagerede med modalvinduer, karruseller og søgefunktionen. Hver browsersession blev gemt som en HTTP Archive (HAR)-fil med fulde responstekster – det samme format, som browsere bruger internt, men beriget med det faktiske indhold af hver JavaScript-fil, hvert CSS-stylesheet, hver JSON-konfiguration og hvert API-svar, som værktøjerne leverede.

Efter indsamlingen udarbejdede vi Python-analyseskripter, der gennemgik hver enkelt responstekst, klassificerede hver fil efter værktøj og funktion, udtrak alle CSS-selektorer fra rettelsesdefinitionerne, tællede alle mønstre for DOM-manipulation i JavaScript-koden, identificerede alle tilfælde, hvor indhold var skjult for hjælpemidler, og kortlagde hver rettelse i forhold til det område på siden, den vedrørte (kasse, indkøbskurv, produktoversigt, navigation osv.).

Proxyen indsamlede 924 HTTP-anmodninger med 579 komplette svartekster fordelt på tre indsamlingssessioner – herunder alle rettelsesskripter pr. websted, alle JSON-filer med rettelser, alle konfigurationsfiler og alle analyse-payloads. Vi gemte også komplette DOM-snapshots af sider med anvendte overlay-ændringer, hvilket gjorde det muligt for os at inspicere de nøjagtige aria-label-værdier og leverandørdataattributter, der blev indsat under kørsel. Derefter skrev vi automatiserede analyseskripter til at parse JavaScript, tælle hvert DOM-ændringsmønster, udtrække hver CSS-selektor, klassificere hver rettelse efter sideområde og identificere hver forekomst af indhold, der blev skjult for hjælpemidler.

Hvad vi har analyseret

Kunderne omfattede store modekæder, luksuschokolademærker, kuffertproducenter, butikker med designerhåndtasker, legetøjsvirksomheder, en telekommunikationsudbyder, en national bank samt mærker inden for drikkevarer, papirvarer, ure og konfekt – med aktiviteter på både EU- og det amerikanske marked.

En vigtig bemærkning: Der er ingen afgrænsning på sideniveau i nogen form for tilgængelighedsoverlay

Et af de mest overraskende fund dukkede op, allerede før vi overhovedet havde analyseret rettelsesreglerne: Hvert tilgængelighedsoverlay indlæser hele sit sæt af rettelser på hver eneste side, uanset sidetype. Rettelser, der er specifikke for betalingsprocessen, udløses på hjemmesiden. Regler for antal i indkøbskurven udføres på siden »Om os«. Rettelser til produktfliser kører på login-formularen.

Det betyder, at på teleleverandørens hjemmeside henter hver besøgende på hver side en JSON-fil på 1,25 MB, der indeholder 4.974 billedbeskrivelser og 2.000 PDF-korrekturer – selv på sider uden billeder. Hos forhandleren af designerhåndtasker udføres 383 DOM-rettelsesregler ved hver sideindlæsning i et forsøg på at matche selektorer, der kun findes på bestemte sidetyper. Når en betalingsspecifik selektor som #cardNumber ikke kan matches på hjemmesiden, bruger overlayets rettelsesmotor stadig CPU-cyklusser på at evaluere den – ganget med hundredvis af regler skaber dette et mærkbart tab af ydeevne ved hver sidevisning.

Overlay A registrerer kun 4,5 % af sessionerne

I Overlay A’s analytiske POST-data fandt vi et felt, der afslørede den faktiske scanningfrekvens:

En stikprøvefrekvens på 0,045 betyder, at kun 4,5 % af besøgsessionerne udløser en overholdelsesscanning hos denne modebutik. På et andet websted – et luksuschokolademærke – var frekvensen endnu lavere: kun 1,7 %. Det er muligt, at leverandøren af overlay-løsningen foretager en mere omfattende indledende scanning under onboarding eller opsætning og derefter reducerer stikprøvefrekvensen til den løbende overvågning. Konsekvenserne for den daglige drift er dog stadig betydelige.

Koden i startpakken til tilgængelighedsoverlayet bekræfter tre driftsniveauer: ReleaseVersionReport (fuld scanning + rapport – den angivne procentdel), ShadowVersionReport (skygge-scanning, ingen brugerrettede handlinger) og RunReleaseFixesNoReport (anvend alle rettelsesregler, men udfør slet ingen scanning). Det betyder, at langt størstedelen af dine besøgende under normal drift modtager DOM-ændringer, der ikke valideres i løbet af deres session.

Den praktiske risiko er følgende: Hvis en opdatering af webstedet ændrer DOM-strukturen og bryder en eller flere rettelsesregler, betyder den lave løbende stikprøvefrekvens, at fejlen kan forblive uopdaget i længere tid. Da kun 1,7–4,5 % af sessionerne scannes, kan en fejlramt rettelse påvirke tusindvis af besøgende, før den næste session i stikprøven tilfældigvis udløses på den berørte side og markerer problemet. I dette tidsrum modtager alle besøgende forældede eller forkert målrettede rettelser – og hverken webstedsoperatøren eller overlay-leverandøren er muligvis klar over problemet.

Resultaterne: Korrigering af regler og ændringer i DOM

Overlay A: JavaScript-rettelsesfiler pr. websted

Dette overlay har en separat JavaScript-rettelsesfil for hvert enkelt kundesite, som indeholder regler rettet mod bestemte CSS-selektorer. På de fem websteder, vi har analyseret, fandt vi:

Vi fandt også 7 tilfælde hvor den bogstavelige streng "true" blev indsprøjtet som en aria-label – en fejl i koden, hvor der blev overført en boolsk værdi i stedet for beskrivende tekst. Skærmlæsere læser op: »knap, true« – hvilket er fuldstændig meningsløst. På et andet websted var »Search« stavet forkert som »Seacrh« i en indsat etiket.

Overlay B: AI-genereret alternativ tekst i stor skala

Dette overlay henter store JSON-filer med rettelser, der indeholder AI-genererede billedbeskrivelser. På tre websteder:

Konkrete eksempler fra saneringsdataene:

323 beskrivelser overskred 125 tegn – hvilket medførte, at skærmlæserne læste dem op i detaljer, hvor læseren talte i 10–15 sekunder pr. billede. 156 begyndte unødvendigt med »billede af« – et WCAG-anti-mønster, da skærmlæsere allerede angiver elementtypen.

Overvågningsværktøj: Ingen ændringer – verificeret i kildekoden

Hvad »Skjul for AT« betyder for almindelige brugere

Når et overlay skjuler et element for hjælpemidler, forbliver elementet synligt på skærmen, men bliver fuldstændig usynligt for skærmlæsere. Vi har klassificeret alle skjulte elementer efter det område af siden, de påvirker:

Data fra de faktiske active.js-rettelsesfiler for de enkelte websteder, udtrukket via mitmproxy. Hvert tal repræsenterer en unik CSS-selektor, der er målrettet af hideFromAT().

På en luksusforhandlers betalingsside omfattede de elementer, der var skjult for skærmlæsere, følgende:

Sådan skaber overlay-værktøjer til tilgængelighed en todelt shoppingoplevelse: Seende brugere kan se alle betalingsmuligheder og vælge mellem kreditkort, PayPal, Amazon Pay, Shop Pay og Klarna. Blinde brugere kan kun se de betalingsmetoder, som overlayet ikke har skjult. Hos en modebutik var både feltet til angivelse af antal i indkøbskurven og opdateringsknappen skjult – en blind bruger kunne tilføje varer, men ikke ændre antallet.

Dette rejser et grundlæggende spørgsmål: Gør et overlay, der skjuler betalingsknapper for blinde brugere, hjemmesiden mere eller mindre tilgængelig?

Indvirkning på ydeevnen

Hvad sker der efter en implementering af et websted?

Den måske mest snigende risiko ved overlay-værktøjer bliver først synlig med tiden: rettelserne forringes i al stilhed. I modsætning til en JavaScript-fejl, der synligt får siden til at gå ned, eller et ødelagt layout, som nogen lægger mærke til, giver en forældet overlay-rettelse ingen fejlmeddelelse, ingen advarsel og ingen synlig ændring. Den holder simpelthen op med at virke – og den tilgængelighedsbarrier, den skjulte, dukker op igen, uden at nogen opdager det.

For at forstå dette skal du overveje, hvordan de enkelte overlay-typer integreres i dit websteds DOM-struktur.

Løsninger baseret på selektorer: Tiden rinder ud

Overlay A – ligesom de fleste overlay-løsninger til tilgængelighed – opbevarer JavaScript-rettelsesfiler for hvert enkelt websted, der indeholder regler som denne (rekonstrueret ud fra den faktisk indsamlede kode):

Denne regel er rettet mod pileknappen til forrige billede i et Slick-karrusel ved hjælp af tre CSS-klasser: .js-recommendation_carousel, .slick-prev, og .slick-arrow. Hver eneste del af denne selektor er sårbar. Hvis webstedsteamet omdøber karruselens containerklasse, skifter fra Slick til Splide eller Swiper eller blot opdaterer Slick-biblioteket til en version, der ændrer klassens navngivningskonvention – vil selektoren ikke længere matche noget. Knappen mister sin tekst »Forrige slide«. Brugere af skærmlæsere kan ikke længere genkende den.

På de fem lokaliteter, vi analyserede i forbindelse med Overlay A, fandt vi 98 % af alle selektorer indeholder rammespecifikke klassernavne – klasser, der begynder med .js-, .b-, .chakra-, .splide__, eller CSS-i-JS-hash-koder som .css-acuo7n. Dette er ikke stabile, semantiske identifikatorer – det er implementeringsdetaljer, der ændrer sig ved hver opdatering af rammeværket, hver omstrukturering af komponenter eller hver ændring af build-systemet.

Hos en forhandler af designerhåndtasker fandt vi selektorer, der var rettet mod Chakra UI-komponenter. Chakra UI introducerer ændringer, der bryder kompatibiliteten, i større versioner – klassernavne, komponentstruktur og ARIA-mønstre ændres alle. Når denne hjemmeside opgraderer til Chakra, vil potentielt hundredvis af overlay-rettelsesregler ophøre med at fungere uden varsel. Overlay-leverandøren skal derefter manuelt gennemgå den nye DOM-struktur, omskrive alle berørte selektorer og implementere opdaterede rettelsesfiler. I perioden mellem webstedets implementering og overlay-leverandørens opdatering kører webstedet med forældede rettelser – nogle uden effekt, andre potentielt anvendt på de forkerte elementer.

URL-baserede løsninger: Endnu mere ustabile

Overlay B's oprydnings-JSON-nøgler knytter hver enkelt alt-tekst-post til den nøjagtige billedkilde-URL. Vi fandt poster som:

Bemærk, hvor sårbar den er: URL'en indeholder et enheds-id (13555), en miniaturebilledstørrelse (86x86), samt et filnavn, der indeholder produktnavnet. Disse elementer kan ændres uafhængigt af hinanden. Hvis CMS'et genererer nye miniaturer i en anden størrelse, vil thumb_86x86 En del af URL-adressen ændres, og posten stemmer ikke længere overens. Hvis produktteamet uploader et nyt billede med et andet filnavn, bliver posten forældet. Hvis webstedet flytter sine mediefiler til et CDN med et andet domæne, bliver hver eneste post i den 1,17 MB store JSON-fil overflødig – og alle billeder på webstedet mister samtidig deres alt-tekst.

Det værste scenarie er en delvis fejl i matchningen: Nogle billeder beholder deres gamle URL-adresser (og får alternativ tekst), mens nye eller opdaterede billeder ikke matcher nogen post (og derfor ikke får noget). Resultatet er en inkonsekvent oplevelse, hvor nogle billeder beskrives, mens andre uden varsel springes over – hvilket er langt mere forvirrende for en bruger af en skærmlæser end en konsekvent mangel på alternativ tekst.

Løsninger på globalt plan: Kaskadeproblemet

Overlay C’s fremgangsmåde – at knytte en MutationObserver til hele dokumentet og anvende generiske rettelser på alle elementer af bestemte typer (a, button, input, img, h1) – skaber et anderledes, men lige så farligt fejlmønster. I stedet for at fejle uden varsel, når selektorer bliver forældede, vil dette overlay arbejder aktivt med ny kode.

Tænk på et typisk scenarie: Webstedsteamet implementerer en ny, tilgængelig modal dialogkomponent, der korrekt implementerer fokuslåsning, lukning ved at trykke på Esc og ARIA-attributter. Overlayets MutationObserver registrerer de nye DOM-elementer, vurderer dem i forhold til sine generiske regler og – når den finder elementer, der matcher dens mønstre – anvender den sin egen fokusstyring, tastaturhåndteringer og ARIA-attributter oven på komponentens eksisterende, korrekte implementering. Resultatet er dobbeltfanget fokus, duplikerede tastaturhåndteringer og modstridende ARIA-attributter. Den modale dialog, der fungerede perfekt, før overlayet blev indlæst, opfører sig nu uregelmæssigt.

Dette er ikke blot et teoretisk problem. Rammeværksbiblioteker som Radix UI, Headless UI og Chakra UI bruger betydelige tekniske ressourcer på at sikre en korrekt implementering af ARIA. Et overlay, der automatisk anvender sine egne ARIA-attributter på alle button og a elementer vil sandsynligvis komme i konflikt med disse gennemprøvede implementeringer, hvilket gør det vanskeligt at skabe komponenter, der fungerer korrekt mindre tilgængelig.

Overvågningsværktøjet: Intet, der kan gå i stykker

Det overvågningsværktøj, vi har analyseret, indeholder ingen selektorbaserede rettelser, ingen URL-baserede poster, ingen MutationObserver og ingen generisk elementmålretning. Når webstedet implementerer ny kode, vurderer overvågningsværktøjets næste scanning automatisk det nye DOM i forhold til axe-cores standardiserede regelsæt og rapporterer eventuelle nye overtrædelser – uden at ændre noget. Scanningsresultaterne vises i værktøjets dashboard med alvorlighedsniveauer, antal berørte elementer og standardiserede WCAG-regel-ID'er. Udviklere gennemgår resultaterne og implementerer rettelser i deres egen kodebase, hvor rettelserne gennemgår kodegennemgang, automatiseret test, staging-validering og kontrolleret implementering.

Denne proces er i sagens natur modstandsdygtig over for ændringer: Værktøjet scanner det DOM, der findes på scannetidspunktet, rapporterer de fundne problemer og starter forfra ved den næste scanning. Der opbygges ingen teknisk gæld i form af rettelsesdefinitioner, ingen forældede selektorer, ingen forældreløse alt-tekst-indtastninger og ingen risiko for, at den forkerte rettelse anvendes på det forkerte element.

Hvad går i stykker, når du geninstallerer?

Hver rettelse af tilgængelighedsoverlayet er knyttet til webstedets aktuelle DOM-struktur. Vi har konstateret, at 98 % af selektorerne i et overlay er rettet mod rammespecifikke klassernavne – fag som .chakra-, .splide__, .js-, .b-, og CSS-i-JS-hash-koder som .css-acuo7n der ændrer sig ved hver eneste build.

Overvågningsværktøjet viser »Uændret« i hver række, da det ikke indeholder nogen selektorbaserede rettelser. Der er intet, der kan blive forældet, intet, der kan ramme det forkerte element, og intet, der kan gå i stykker.

GDPR, privatlivsbeskyttelse og spørgsmålet om samtykke

Vores analyse bekræftede, at tre af de fire tilgængeligheds-overlays sender data til eksterne servere, før man overhovedet kan interagere med et samtykkebanner:

I henhold til EU-Domstolens afgørelse i Planet49-sagen kræver ikke-væsentlig sporing forudgående samtykke. To pop-up-vinduer indsætter permanente identifikatorer ved den første netværksanmodning – før nogen samtykkemekanisme kan aktiveres. For websteder rettet mod EU udgør dette automatisk en overtrædelse af GDPR.

Det juridiske landskab

I april 2025 indgik den amerikanske Federal Trade Commission (FTC) et forlig på 1 million dollars med en af de udbydere af tilgængeligheds-overlays, der indgik i vores undersøgelse, fordi virksomheden fejlagtigt havde påstået, at dens AI-baserede værktøj kunne gøre enhver hjemmeside WCAG-kompatibel. FTC konstaterede, at værktøjet ikke formåede at gøre grundlæggende hjemmesidekomponenter – menuer, overskrifter, tabeller, billeder og optagelser – tilgængelige. I et af de nævnte eksempler fik et foto af filet mignon den AI-genererede beskrivelse: "Brunt brød på en hvid keramisk tallerken."

Ifølge brancheundersøgelser blev overlay-widgets i 2024 i 25 % af alle retssager om digital tilgængelighed udtrykkeligt nævnt som hindringer – ikke som løsninger. I første halvdel af 2025 fortsatte antallet af retssager mod virksomheder, der anvender overlay, med at ligge på over 100 om måneden. To af overlay-leverandørerne i vores undersøgelse har været direkte involveret i retssager: den ene i tre separate sager om patenter/erhvervshemmeligheder, og den anden i en gruppesøgsmål fra en mindre erhvervskunde, der blev sagsøgt på trods af, at vedkommende anvendte overlayet.

Overvågningsværktøjet i vores undersøgelse har ingen historik med retssager vedrørende manglende tilgængelighed – hvilket er en logisk følge af dets arkitektur: Da det aldrig ændrer DOM, kan det ikke skabe hindringer for tilgængeligheden.

Et kig ind i koden: Hvad ændrer overlays egentlig?

For at få et indtryk af omfanget af DOM-manipulation har vi talt alle ændringsmønstre i hvert værktøjs JavaScript-kode. Forskellene er markante:

Overlay C fortjener særlig opmærksomhed. Dets 794 KB store monolitiske pakke indeholder en MutationObserver til document.documentElement med konfigurationen {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Det betyder hver eneste ændring i DOM på hele siden – uanset om det skyldes React’s virtuelle DOM-synkronisering, et A/B-testskript, en chat-widget eller webstedets eget JavaScript – udløser overlayets observer, som derefter genvurderer og eventuelt genanvender sine rettelser. Efter en genudrulning af webstedet skaber dette en kaskade af gentagne rettelsesforsøg på elementer, der muligvis allerede er korrekt tilgængelige, hvilket potentielt kan overskrive korrekte ARIA-attributter med forkerte.

Vi har bekræftet, at Overlay C sender USER-BEHAVIOR-ANALYTICS POST-anmodninger til sin egen logmodtager, hvor datapakkerne indeholder webstedets domæne, widgetversionen, brugerens sprog og interaktionshændelser. Kombineret med localStorage persistens og enhedsidentifikation via navigator.userAgent og navigator.maxTouchPoints... dette udgør en databehandling, som de fleste webstedsoperatører ikke er klar over finder sted.

Problemet med JSON-korrektionen

Overlay B henter en enorm JSON-fil (op til 1,17 MB for et enkelt telekommunikationswebsted), der indeholder alle fejlrettelsesdefinitioner. På et websted observerede vi, at den blev hentet fire gange i løbet af en enkelt browsersession – 4,7 MB båndbredde til en fil, der burde have været gemt i cachen. JSON-filen indeholder 11 kategorier, men langt størstedelen er AI-genererede billedbeskrivelser: 4.974 af 6.975 poster for et enkelt websted. Hver post er knyttet til en specifik billed-URL – når CMS omdøber en fil, ændrer miniaturestørrelser eller migrerer CDN-domæner, holder posterne pludselig op med at matche. De nye billeder får slet ingen alt-tekst, hvilket gør siden mindre tilgængelig end før overlayet blev installeret.

Dette overlay implementerer også runtime-moduler, der aktivt omskriver siden: en 110 KB stor fejlrettelsesmotor, en 23 KB stor hjælper til navigationsmenuen, der omstrukturerer menustastaturhåndteringen, en 5,8 KB stor karrusel-patch samt en 53 KB stor klient-side-scanner, der anvender proprietær logik i stedet for den brancheførende axe-core-motor – hvilket betyder, at dens resultater ikke kan verificeres uafhængigt.

Det mest gennemsigtige overlay – stadig risikabelt

Overlay D havde den mest gennemsigtige arkitektur: menneskeligt læselige JSON-konfigurationsfiler med eksplicitte aktiverings-/deaktiveringsindstillinger. Indstillinger som addAriaHidden, overwriteAlt, og adjustMetaViewport blev udtrykkeligt indstillet til false. Den underliggende motor (649 KB) indeholder dog 216 setAttribute opkald, 47 aria-hidden referencer, 282 addEventListener registreringer og 9 MutationObserver tilfælde. Motoren understøtter aggressive ændringer af DOM, selvom den aktuelle konfiguration er konservativ – en ændring af konfigurationen fra leverandørens side kan aktivere risikable funktioner uden webstedsadministratorens viden.

Vi fandt selektorer pr. side, der indeholdt JavaScript-genererede hash-endelser som f.eks. button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 som ændrer sig ved hver eneste build, og URL-selektorer til sociale medier, der bliver forældede, når hjemmesiden opdaterer sine Facebook- eller Instagram-links.

Den europæiske lov om tilgængelighed: Hvorfor overlay-løsninger ikke opfylder kravene i EAA

Fra den 28. juni 2025 kræver den europæiske tilgængelighedslov (EAA), at digitale produkter og tjenester, der sælges i EU, skal opfylde tilgængelighedsstandarder, der er i overensstemmelse med EN 301 549, som henviser til WCAG 2.1 AA. I modsætning til ADA – som primært håndhæves gennem private retssager – håndhæves EAA af nationale markedsovervågningsmyndigheder, der har beføjelse til at pålægge bøder, påbyde korrigerende foranstaltninger og trække produkter, der ikke overholder kravene, tilbage fra markedet.

Tysklands officielle afvisning af overlay-værktøjer

Tyskland har indtaget den klareste holdning blandt alle lande, hvad angår overlay-værktøjer til tilgængelighed. BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – Tysklands føderale tilsynsmyndighed for tilgængelighed inden for informationsteknologi – har sammen med alle tilsynsmyndigheder på delstatsniveau udsendt en fælles udtalelse, hvor man udtrykkeligt afviser brugen af overlay-værktøjer som middel til at opfylde tilgængelighedskravene:

Den 12. marts 2025 bekræftede Udvalget for Tilgængelig Informationsteknologi (Ausschuss für barrierefreie Informationstechnik, nedsat i henhold til § 5 i BITV 2.0) denne holdning på sit møde og udtrykte bekymring over, at offentlige organer fortsat forsøger at opfylde deres forpligtelser vedrørende tilgængelighed ved at integrere overlay-værktøjer. Udvalget konkluderede, at "en midlertidig tilgængelig gengivelse af et websted ved hjælp af software – muligvis først efter at brugeren har konfigureret indstillingerne – i løbet af brugerens besøg ikke opfylder kravene i de gældende lovbestemmelser."

Udvalget advarede udtrykkeligt om, at offentlige organer, der bruger overlay-værktøjer, risikerer at gøre deres hjemmesider mindre tilgængelige i stedet for mere – hvilket medfører en forringelse af tilgængeligheden („Verschlechterung der Barrierefreiheit“). Dette stemmer nøjagtigt overens med vores tekniske konstatering af, at 26 % af reglerne til korrektion af overlay-problemer medfører nye overtrædelser af WCAG.

BIK-testmærke: Afvist for websteder, der anvender overlay

Tysklands BIK-testnetværk – de akkrediterede organer, der vurderer hjemmesider i forhold til BITV 2.0, EN 301 549 og WCAG 2.1 AA – har taget et praktisk skridt: Hjemmesider, der bruger overlay-værktøjer, kan ikke modtage BIK-testmærket. Testorganerne har udtalt, at de ikke kan foretage en pålidelig overensstemmelsesvurdering, når der er et overlay til stede, fordi overlayet ændrer DOM under kørsel på måder, der gør testresultaterne upålidelige. BIK-mærket er udbredt i hele Tyskland som bevis på overholdelse af BITV 2.0 – og det er nu utilgængeligt for alle hjemmesider, der bruger et overlay.

Dette er ikke blot et teoretisk politisk anliggende. Det betyder, at en tysk e-handelsside, der anvender et af de fire overlay-programmer, vi har testet, ikke kan opnå den standardcertificering, der kræves på det tyske marked.

Bekræftelse på europæisk plan

Denne holdning går ud over Tysklands grænser. Det Europæiske Handicapforum og Den Internationale Sammenslutning af Tilgængelighedseksperter udsendte i 2023 en fælles erklæring, hvor de advarede om, at tilgængelighedsoverlay ikke gør hjemmesider tilgængelige eller i overensstemmelse med den europæiske lovgivning om tilgængelighed, herunder den europæiske tilgængelighedslov. Europa-Kommissionen har ligeledes udtalt sig om påstande om, at overlay overholder lovgivningen, og konkluderet, at overlay ikke kan sikre overholdelse af de gældende standarder.

I henhold til den tyske BFSG (Barrierefreiheitsstärkungsgesetz – den tyske gennemførelseslov til EAA, der trådte i kraft den 28. juni 2025) kan markedstilsynsmyndighederne pålægge bøder på mellem 10.000 og 100.000 euro pr. overtrædelse. BFIT-Bunds vurdering og BIK-testnetværkets afvisning af at certificere websteder, der bruger overlay, betyder i praksis, at overlay-værktøjer ikke giver nogen lovmæssig dækning i Tyskland – og kan aktivt øge risikoen for håndhævelsesforanstaltninger.

Sikkerhed og risici i forsyningskæden

Alle overlay-værktøjer fungerer ved at indsætte tredjeparts-JavaScript i det globale omfang på dine produktionssider. Dette JavaScript kører med de samme rettigheder som din egen kode – det kan læse og ændre ethvert DOM-element, opfange formularindsendelser, få adgang til cookies, omdirigere brugere og stjæle data. De sikkerhedsmæssige konsekvenser af denne fremgangsmåde er betydelige og overses ofte.

Angrebsfladen

Tænk på forsyningskæden: Når du integrerer et tilgængeligheds-plugin på din hjemmeside, giver du en tredjepartsleverandør kontinuerlig og ubegrænset skriveadgang til dit live-DOM. Leverandørens CDN leverer JavaScript-koden, leverandørens team vedligeholder koden, og leverandørens implementeringspipeline sender opdateringer direkte til din hjemmeside – uden din kodegennemgang, uden din kvalitetssikringsproces og uden din godkendelse.

Hvis overlay-udbyderens CDN kompromitteres, får angriberen mulighed for at indsætte ondsindet kode på alle websteder, der bruger det pågældende overlay. Hvis en medarbejder hos udbyderen udsender en fejlbehæftet opdatering, påvirkes alle kundernes websteder samtidigt. Hvis udbyderens API-endpoint kapres, kan de JSON-filer eller konfigurationsdata, der leveres til dit websted, manipuleres med henblik på at ændre formularfelter, omdirigere links eller indsætte phishing-indhold.

Omfanget af denne risiko hænger direkte sammen med overlayets pladsbehov i DOM:

Overlay B udgør den største risiko i forsyningskæden: 228 API-kald pr. session fordelt på 3 eksterne domæner, med en JSON-payload på 1,17 MB, der definerer, hvordan DOM skal ændres. Et kompromitteret API-svar kunne instruere afhjælpningsmotoren om at indsætte vilkårligt indhold i ethvert element på siden. Overlay C's 1.285 KB monolitiske bundt er den største enkeltstående JavaScript-payload – og fordi den er minimeret og tilsløret, kan hverken webstedsoperatøren eller en sikkerhedsrevisor på meningsfuld vis gennemgå, hvad den udfører ved kørsel.

Overholdelse af PCI DSS: En direkte konflikt

For enhver e-handelswebside, der behandler kreditkortbetalinger, er overholdelse af PCI DSS ikke noget valg. Vores undersøgelser viser, at der er en direkte konflikt mellem arkitekturen i overlay-værktøjer til tilgængelighed og kravene i PCI DSS.

PCI DSS-krav 6.4.3 (indført i PCI DSS v4.0, obligatorisk fra 31. marts 2025) kræver, at alle scripts på betalingssider, der indlæses og udføres i forbrugerens browser, administreres på følgende måde: Der skal implementeres en metode til at bekræfte, at hvert script er godkendt, hvert scripts integritet skal sikres, og der skal føres en oversigt over alle scripts med en skriftlig begrundelse for, hvorfor hvert enkelt script er nødvendigt.

Vores analyse bekræftede, at reglerne for overlay-rettelser aktivt retter sig mod DOM-elementer på betalingssider på flere forskellige websteder:

Dette er ikke en teoretisk risiko – det drejer sig om konkrete scripts, som vi har fundet på produktionswebsteder, hvor de aktivt ændrer felter til kreditkortnumre, valg af faktureringsadresse, knapper til betalingsudbydere og felter i betalingsformularer. I henhold til PCI DSS 6.4.3 kræver hvert eneste af disse tredjeparts-scripts dokumenteret godkendelse, integritetskontrol og en skriftlig begrundelse.

Overvej, hvad en overlay-udbyders script kan gøre på din betalingsside:

Overvågningsværktøjet har derimod ingen mulighed for at skrive til DOM. Dets 4,2 KB store script kan ikke ændre formularfelter, kan ikke opfange input-hændelser og kan ikke få adgang til eller ændre betalingselementer. Selv hvis overvågningsudbyderens CDN blev kompromitteret, ville angriberen kun få adgang til et script, der udelukkende kan læse sidens URL og enhedstype – ikke et script, der kan omskrive betalingsformularen. I forbindelse med fastlæggelse af PCI DSS-omfanget skaber overvågningsværktøjet ingen yderligere risiko på betalingssiderne.

Spørgsmålet om diskrimination

Dette er det diskrimineringsproblem, der ligger til grund for alle tilgængeligheds-overlay: Det mest bekymrende er ikke en teknisk fejl – det er en tendens til systematisk at nægte brugere med handicap adgang til funktioner, som seende brugere tager for givet.

Når et overlay skjuler en Amazon Pay-knap i tilgængelighedsstrukturen, får en blind bruger færre betalingsmuligheder at vælge imellem end en seende bruger. Når indtastningsfeltet for antal i indkøbskurven er skjult, kan en blind bruger ikke ændre sin ordre. Når links til søgeresultater er skjult, bliver det sværere at finde produkter. Når stjernebedømmelser er skjult, kan en blind bruger ikke vurdere produktkvaliteten på samme måde som en seende bruger.

Dette er ikke sjældne undtagelser – det er centrale e-handelsprocesser, der brydes af netop de værktøjer, der lover at gøre dem tilgængelige.

Handicapmiljøet har i årevis gjort opmærksom på dette. Faktaarket om overlay-løsninger – underskrevet af hundredvis af tilgængelighedseksperter – advarer om, at overlay-løsninger »ikke retter den underliggende HTML« og »ofte aktivt er til hinder for mennesker med handicap«. Vores tekniske analyse leverer beviset: 141 funktionelle elementer skjult for skærmlæsere, 7 meningsløse etiketter indsat og 5.066 ikke-gennemgåede AI-beskrivelser implementeret i produktion – på blot 14 websteder.

For webstedsoperatører handler det ikke om, hvorvidt overlay-funktioner er »gode nok« – spørgsmålet er snarere, om det kan retfærdiggøres at indføre et værktøj, der skaber en todelt brugeroplevelse: én version til seende brugere, der får fuld funktionalitet, og en filtreret, mangelfuld og til tider meningsløs version til brugere med handicap.

Indvirkning på overholdelsen af ADA: Hjælper disse rettelser egentlig?

Det centrale løfte ved alle overlay-løsninger er, at de forbedrer ADA-overholdelsen ved at rette WCAG-overtrædelser under kørsel. Men vores analyse afslører et foruroligende paradoks: En betydelig andel af overlay-løsningerne indfører aktivt nye WCAG-overtrædelser, mens de forsøger at rette de eksisterende.

Vi har kortlagt hver eneste registreret rettelsesregel fra Overlay A og knyttet den til det specifikke WCAG 2.1-succeskriterium, den vedrører. Af de 776 regler, der kunne kortlægges, kan resultaterne inddeles i to kategorier: rettelser, der reelt løser et WCAG-problem, og rettelser, der i stedet skaber en ny overtrædelse af WCAG.

For at være retfærdig skal det siges, at tre fjerdedele af de kortlagte rettelser er reelle forbedringer – tilføjelse af manglende knaptekster, korrektion af overskriftshierarkier, rettelse af attributter til autofuldførelse og implementering af modale fokusfælder. Men den sidste fjerdedel er direkte skadelig, og skaden rammer uforholdsmæssigt hårdt netop de brugere, som værktøjet hævder at hjælpe.

Hvordan hvert risikabelt mønster strider mod WCAG

Problemet er ikke blot, at disse rettelser ikke virker – det er, at de medfører overtrædelser af specifikke WCAG-succeskriterier, som ikke fandtes, før overlayet blev anvendt. I en retssag i henhold til ADA kan sagsøgerens ekspert henvise til disse overtrædelser, der er skabt af overlayet, som bevis for, at hjemmesiden diskriminerer mennesker med handicap.

Overlay B: AI-alternativtekst og WCAG 1.1.1

WCAG 1.1.1 kræver, at indhold, der ikke består af tekst, skal have en »tekstalternativ, der opfylder det samme formål«. En AI-genereret alt-tekst, der beskriver et firmalogo som "et blåt og gult skilt", tjener ikke det samme formål – formålet med et logo er brandidentifikation, ikke farvebeskrivelse. En alt-tekst som "tekst" til et reklamebanner eller "by" til et hero-billede opfylder ikke det samme kriterium på en anden måde – den er så vag, at den er ubrugelig.

Af de 5.068 AI-genererede alt-tekster, vi indsamlede fra Overlay B, var 241 på under 15 tegn (for vage til at være brugbare), 323 oversteg 125 tegn (hvilket strider mod de bedste praksis for brugervenlighed med skærmlæsere), og 156 begyndte med »billede af« eller »foto af« (overflødigt, da skærmlæsere allerede angiver elementtypen). Kun 2 var blevet godkendt af en menneskelig korrekturlæser.

I henhold til retspraksis i sager om ADA vil en sagsøgers ekspert i tilgængelighed påpege disse som overtrædelser af WCAG 1.1.1 – det kriterium, der oftest henvises til i retssager om webtilgængelighed i henhold til ADA. Overlayet løser ikke overtrædelsen; det erstatter blot én form for manglende overholdelse (manglende alt-tekst) med en anden (unøjagtig eller vag alt-tekst), samtidig med at det skaber en falsk fornemmelse af, at webstedsoperatøren overholder reglerne.

Overlay B: Indsættelse af formularetiketter under kørsel – når en ”rettelse” gør det værre

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.

Da Overlay B’s tilpasningsmotor var aktiveret, meddelte en skærmlæser:

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

Resultatet er værre end den oprindelige formular uden etiketter. Før overlejringen stødte en bruger af en skærmlæser på syv felter uden etiketter – forvirrende, men i det mindste konsekvent. Brugeren kunne bruge tabulatorrækkefølgen og konteksten til at gætte, hvilket felt der var hvilket. Efter overlejringens indgriben støder brugeren på to felter med samme etiket ("Navn" for både fornavn og efternavn), to felter med opdigtede etiketter i valideringsstil, der ikke stemmer overens med den synlige tekst, og tre felter med meningsløse typebaserede navne. Den delvise, forkerte mærkning er mere desorienterende end slet ingen mærkning, fordi den skaber et falsk indtryk af, at formularen er blevet gjort tilgængelig, når vigtige felter forbliver umærkede eller forkert mærkede.

Dette fund afslører også en blind vinkel i Overlay B’s JSON-korrektionsdata. JSON-filen indeholdt 87 AI-genererede alt-tekstposter og ingen formkorrektionsposter for dette websted. Indsættelsen af formetiketter sker udelukkende ved kørsel via EmptyControls-regelhåndteringen – den er ikke synlig i den konsoliderede JSON-fil med korrektioner, spores ikke i noget dashboard, som webstedsoperatøren kan gennemgå, og er ikke underlagt menneskelig godkendelse. Webstedsoperatøren har ingen mulighed for at vide, at deres kontaktformular er forkert mærket, medmindre de selv tester den med en skærmlæser.

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.

Den samlede effekt af overholdelsen af ADA

Det grundlæggende problem er, at overlay-værktøjer forveksler dækning med overholdelse. Et overlay kan henvise til 1.058 rettelsesregler og hævde, at det opfylder over 40 WCAG-succeskriterier. Men når 26 % af disse rettelser medfører nye overtrædelser – herunder niveau A-fejl, der opstår ved at skjule funktionelle elementer – kan den samlede overholdelsesstatus ende med at være dårligere end på det uændrede websted.

Et websted uden et overlay, der indeholder 50 overtrædelser af WCAG, befinder sig i en mere entydig juridisk situation end et websted med et overlay, der indeholder 30 oprindelige overtrædelser plus 203 overtrædelser forårsaget af overlayet – fordi de overtrædelser, der skyldes overlayet, viser, at webstedsoperatøren har taget et værktøj i brug, der aktivt diskriminerer brugere med handicap, hvilket undergraver ethvert forsvar baseret på god tro.

Konklusionen