Vi har fångat upp alla förfrågningar från fem tillgänglighetsverktyg. Här kan du se vad de faktiskt gör med din webbplats.

En oberoende teknisk granskning av fyra tillgänglighetsöverlägg och en lösning avsedd enbart för övervakning – vad de faktiskt förändrar, vad de döljer för användare med funktionsnedsättning, och varför över 1 000 företag som använder överlägg stämdes enbart under 2024.

Hur vi gick tillväga: Forskningsmetodiken

De flesta recensioner av tillgänglighetsöverlägg baseras på marknadsföringspåståenden, leverantörsdokumentation eller ytliga tester. Vi valde en helt annan metod: vi fångade upp varje byte av data som flödade mellan webbläsaren och varje verktygs servrar, extraherade de faktiska JavaScript-korrigeringsfilerna och åtgärdsdata, och analyserade exakt vad varje verktyg gör med det aktiva DOM-objektet på e-handelswebbplatser i produktion.

Den tekniska installationen

Vi satte in mitmproxy – en öppen källkodsbaserad HTTPS-proxy – som konfigurerades för att fånga upp hela innehållet i förfrågningar och svar för all trafik till verktygens CDN- och API-domäner. Vi installerade proxyns rot-CA-certifikat i webbläsaren för att möjliggöra transparent HTTPS-avlyssning, och startade sedan en dedikerad Chrome-instans som dirigerades uteslutande via proxyn. Vi konfigurerade domänfilter för att endast fånga upp trafik till servrarna för tillgänglighetsverktygen – vilket säkerställde att vi endast analyserade det som dessa verktyg skickade in, inte webbplatsernas egen trafik.

Vi besökte sedan 14 aktiva e-handelssajter på samma sätt som en vanlig användare skulle göra: vi laddade startsidan, navigerade till produktlistasidor, tittade på produktdetaljsidor, lade till varor i varukorgen, gick vidare till kassan, besökte konto- och registreringssidor samt interagerade med modalfönster, karuseller och sökfunktioner. Varje webbläsarsession sparades som en HTTP Archive (HAR)-fil med fullständiga svarstexter – samma format som webbläsare använder internt, men utökat med det faktiska innehållet i varje JavaScript-fil, varje CSS-stilmall, varje JSON-konfiguration och varje API-svar som verktygen levererade.

Efter insamlingen skrev vi analysskript i Python som analyserade varje svarstext, klassificerade varje fil efter verktyg och funktion, extraherade varje CSS-selektor från korrigeringarna, räknade varje mönster för DOM-manipulation i JavaScript-koden, identifierade varje fall där innehåll doldes för hjälpmedel och kopplade varje korrigering till det sidområde den påverkar (kassa, varukorg, produktlista, navigering osv.).

Proxyservern registrerade 924 HTTP-förfrågningar med 579 fullständiga svarstexter under tre registreringssessioner – inklusive varje webbplatsspecifikt korrigeringsskript, varje JSON-fil för korrigering, varje konfigurationsfil och varje analysdata. Vi sparade också kompletta DOM-snapshots av sidor med tillämpade överlagringsändringar, vilket gjorde det möjligt för oss att inspektera de exakta aria-label-värdena och leverantörsdataattributen som injicerades vid körning. Vi skrev sedan automatiserade analysskript för att analysera JavaScript, räkna varje DOM-ändringsmönster, extrahera varje CSS-selektor, klassificera varje korrigering efter sidområde och identifiera varje instans av innehåll som doldes från hjälpmedelsteknik.

Vad vi analyserade

Webbplatserna omfattade stora modekedjor, lyxchokladmärken, bagagetillverkare, butiker för designade handväskor, leksaksföretag, en telekomleverantör, en nationell bank samt varumärken inom drycker, kontorsmaterial, klockor och konfektyr – med verksamhet på både EU- och USA-marknaderna.

En viktig anmärkning: Inget omfattningsområde på sidnivå i något tillgänglighetsöverlägg

En av de mest överraskande upptäckterna kom fram redan innan vi hade analyserat korrigeringsreglerna: varje tillgänglighetsöverlägg laddar hela sin uppsättning korrigeringar på varje enskild sida, oavsett sidtyp. Korrigeringar som är specifika för kassan aktiveras på startsidan. Regler för varukorgens antal tillämpas på sidan ”Om oss”. Korrigeringar för produktrutor körs på inloggningsformuläret.

Detta innebär att på telekomleverantörens webbplats laddar varje besökare på varje sida ner en JSON-fil på 1,25 MB som innehåller 4 974 bildbeskrivningar och 2 000 PDF-korrigeringar – även på sidor utan bilder. Hos återförsäljaren av designerhandväskor körs 383 DOM-korrigeringsregler vid varje sidladdning, i ett försök att matcha selektorer som endast finns på specifika sidtyper. När en kassaspecifik selektor som #cardNumber inte matchar på startsidan, lägger överläggets korrigeringsmotor ändå CPU-cykler på att utvärdera den – multiplicerat med hundratals regler skapar detta ett mätbart prestandasvinn vid varje sidvisning.

Överlagring A skannar endast 4,5 % av sessionerna

I data från POST-analyserna för Overlay A hittade vi ett fält som avslöjade dess faktiska skanningsfrekvens:

En samplingsfrekvens på 0,045 innebär att endast 4,5 % av besökarnas sessioner utlöser en efterlevnadskontroll hos denna modekedja. På en annan webbplats – ett lyxchokladmärke – var andelen ännu lägre: endast 1,7 %. Det är möjligt att leverantören av överläggslösningen utför en mer omfattande inledande kontroll under installationen eller konfigurationen, och därefter minskar samplingsfrekvensen för den löpande övervakningen. Konsekvenserna för den dagliga driften är dock fortfarande betydande.

Koden i startpaketet för tillgänglighetsöverlägget bekräftar tre driftsnivåer: ReleaseVersionReport (fullständig genomsökning + rapport – den angivna procentandelen), ShadowVersionReport (skugggenomsökning, inga åtgärder som syns för användaren) och RunReleaseFixesNoReport (tillämpa alla korrigeringsregler men utför ingen genomsökning alls). Detta innebär att under normal drift får den stora majoriteten av dina besökare DOM-ändringar som inte valideras under deras session.

Den praktiska risken är följande: om en webbplatsuppdatering ändrar DOM-strukturen och bryter mot en eller flera korrigeringsregler, innebär den låga kontinuerliga samplingsfrekvensen att felet kan förbli oupptäckt under en längre tid. Eftersom endast 1,7–4,5 % av sessionerna skannas kan en felaktig korrigering påverka tusentals besökare innan nästa samplade session råkar aktiveras på den berörda sidan och flaggar problemet. Under den tiden får varje besökare inaktuella eller felriktade korrigeringar – och varken webbplatsoperatören eller leverantören av överlägg kan vara medveten om problemet.

Resultaten: Korrigera regler och ändringar i DOM

Överlägg A: JavaScript-korrigeringsfiler per webbplats

Denna överlagring har en separat JavaScript-korrigeringsfil för varje kundwebbplats, som innehåller regler riktade mot specifika CSS-selektorer. Vid en analys av de fem webbplatserna fann vi följande:

Vi fann också 7 fall där den bokstavliga strängen "true" injicerades som en aria-label – ett kodfel där ett booleskt värde skickades istället för beskrivande text. Skärmläsare läser upp ”knapp, true” – vilket är helt meningslöst. På en annan webbplats stavades ”Sök” felaktigt som ”Seacrh” i en infogad etikett.

Överlagring B: AI-genererad alt-text i stor skala

Detta tillägg hämtar stora JSON-filer med korrigeringar som innehåller AI-genererade bildbeskrivningar. Från tre webbplatser:

Konkreta exempel från saneringsdata:

323 bildbeskrivningar var längre än 125 tecken – vilket ledde till att skärmläsaren läste upp dem i detalj, med en uppläsningstid på 10–15 sekunder per bild. 156 av dem inleddes onödigt med ”bild av” – vilket strider mot WCAG-riktlinjerna eftersom skärmläsaren redan anger elementtypen.

Övervakningsverktyg: Inga ändringar – verifierat i källkoden

Vad ”Dölj från AT” innebär för vanliga användare

När ett överlägg döljer ett element för hjälpmedel för funktionsnedsatta förblir elementet synligt på skärmen men blir helt osynligt för skärmläsare. Vi har klassificerat varje dolt element efter vilket område på sidan det påverkar:

Data från faktiska active.js-korrigeringsfiler per webbplats, extraherade via mitmproxy. Varje siffra motsvarar en unik CSS-selektor som påverkas av funktionen hideFromAT().

På en lyxbutiks betalningssida omfattade de element som doldes för skärmläsare följande:

Så här skapar överläggsverktyg för tillgänglighet en tudelad köpupplevelse: seende användare ser alla betalningsalternativ och kan välja mellan kreditkort, PayPal, Amazon Pay, Shop Pay och Klarna. Blinda användare kan endast se de betalningsmetoder som överlägget inte har dolt. Hos en modebutik var både fältet för antal i varukorgen och uppdateringsknappen dolda – en blind användare kunde lägga till varor men kunde inte ändra antalet.

Detta väcker en grundläggande fråga: gör ett överlägg som döljer betalningsknapparna för synskadade webbplatsen mer eller mindre tillgänglig?

Inverkan på prestanda

Vad händer efter en webbplatsdistribution

Den kanske mest förrädiska risken med överläggsverktyg blir först synlig med tiden: korrigeringarna försämras i det tysta. Till skillnad från ett JavaScript-fel som synligt får webbläsaren att krascha eller en trasig layout som någon lägger märke till, ger en föråldrad överläggskorrigering upphov till varken felmeddelanden, varningar eller synliga förändringar. Den slutar helt enkelt att fungera – och det tillgänglighetshinder som den tidigare dolde dyker upp igen utan att någon märker det.

För att förstå detta kan du fundera över hur varje typ av överlägg kopplas till webbplatsens DOM-struktur.

Lösningar baserade på selektorer: En tickande klocka

Overlay A – liksom de flesta lösningar för tillgänglighetsöverlägg – hanterar webbplatsspecifika JavaScript-korrigeringsfiler som innehåller regler av detta slag (återgivna utifrån den faktiska koden som fångats upp):

Denna regel riktar sig mot bakåtpilen i ett Slick-karusell med hjälp av tre CSS-klasser: .js-recommendation_carousel, .slick-prev, och .slick-arrow. Varje del av denna selektor är känslig. Om webbplatsteamet byter namn på karusellens behållarklass, byter från Slick till Splide eller Swiper, eller helt enkelt uppdaterar Slick-biblioteket till en version som ändrar klassnamnskonventionen – kommer selektorn inte att matcha någonting. Knappen förlorar sin etikett ”Föregående bild”. Användare av skärmläsare kan inte längre identifiera den.

Vid de fem platser som vi analyserade för överlägg A fann vi 98 % av alla selektorer innehåller ramverksspecifika klassnamn – klasser som inleds med .js-, .b-, .chakra-, .splide__, eller CSS-i-JS-hashar som .css-acuo7n. Det här är inga stabila, semantiska identifierare – det är implementeringsdetaljer som ändras vid varje uppdatering av ramverket, omstrukturering av komponenter eller ändring av byggsystemet.

Hos en återförsäljare av designerhandväskor upptäckte vi selektorer som riktade sig mot Chakra UI-komponenter. Chakra UI släpper versioner med bakåtkompatibla ändringar – klassnamn, komponentstruktur och ARIA-mönster förändras. När webbplatsen uppgraderar Chakra riskerar hundratals regler för överläggskorrigeringar att sluta fungera utan förvarning. Överlagringsleverantören måste då manuellt granska den nya DOM-strukturen, skriva om varje berörd selektor och distribuera uppdaterade korrigeringsfiler. Under tiden mellan webbplatsens distribution och överlagringsleverantörens uppdatering körs webbplatsen med föråldrade korrigeringar – vissa gör ingenting, andra kan potentiellt tillämpas på fel element.

URL-baserade lösningar: Ännu mer sårbara

Overlay B:s sanerings-JSON-nycklar kopplar varje alt-text-post till den exakta bildkällans URL. Vi hittade poster som:

Lägg märke till hur känsligt detta är: URL:en innehåller ett enhets-ID (13555), en miniatyrbildsstorlek (86x86), samt ett filnamn som innehåller produktnamnet. Var och en av dessa kan ändras separat. Om CMS-systemet genererar nya miniatyrbilder i en annan storlek, kommer thumb_86x86 en del av URL:en ändras och posten stämmer inte längre. Om produktteamet laddar upp en ny bild med ett annat filnamn blir posten övergiven. Om webbplatsen flyttar sina mediefiler till ett CDN med en annan domän blir varje enskild post i den 1,17 MB stora JSON-filen överflödig – och samtidigt förlorar alla bilder på webbplatsen sin alt-text.

Det värsta scenariot är att matchningen inte fungerar fullt ut: vissa bilder behåller sina gamla URL:er (och får alt-text), medan nya eller uppdaterade bilder inte matchar någon post (och därmed inte får någon alt-text). Resultatet blir en inkonsekvent upplevelse där vissa bilder beskrivs medan andra tyst hoppas över – vilket är betydligt mer förvirrande för en användare av skärmläsare än om alt-texten helt saknas.

Korrigeringar på global nivå: Kaskadproblemet

Overlay C:s metod – att koppla en MutationObserver till hela dokumentet och tillämpa generiska korrigeringar på alla element av vissa typer (a, button, input, img, h1) – skapar ett annat men lika farligt felmönster. Istället för att tysta ner sig när selektorer blir inaktuella, så gör detta överlägg arbetar aktivt med ny kod.

Tänk dig ett vanligt scenario: webbplatsteamet implementerar en ny tillgänglig modal dialogrutekomponent som korrekt hanterar fokusfångning, stängning genom att trycka på Esc samt ARIA-attribut. Överläggets MutationObserver upptäcker de nya DOM-elementen, utvärderar dem mot sina generiska regler och – när den hittar element som matchar dess mönster – tillämpar sin egen fokushantering, tangentbordsbehandling och ARIA-attribut ovanpå komponentens befintliga, korrekta implementering. Resultatet blir dubbel fokusering, dubbla tangentbordshanterare och motstridiga ARIA-attribut. Modalen som fungerade perfekt innan överlägget laddades beter sig nu oberäkneligt.

Detta är inte bara en teoretisk fråga. Ramverksbibliotek som Radix UI, Headless UI och Chakra UI lägger ner stora tekniska resurser på att implementera ARIA på rätt sätt. Ett överlägg som generellt tillämpar sina egna ARIA-attribut på alla button och a elementen riskerar att komma i konflikt med dessa beprövade implementationer, vilket gör det svårt att skapa korrekt tillgängliga komponenter mindre tillgänglig.

Övervakningsverktyget: Inget som kan gå sönder

Det övervakningsverktyg vi analyserade har inga selektorbaserade korrigeringar, inga URL-baserade poster, ingen MutationObserver och ingen generisk elementinriktning. När webbplatsen publicerar ny kod utvärderar övervakningsverktygets nästa genomsökning automatiskt det nya DOM-trädet mot axe-cores standardiserade regeluppsättning och rapporterar eventuella nya överträdelser – utan att ändra någonting. Skanningsresultaten visas i verktygets instrumentpanel med allvarlighetsgrader, antal berörda element och standardiserade WCAG-regel-ID:n. Utvecklare granskar resultaten och implementerar korrigeringar i sin egen kodbas, där korrigeringarna genomgår kodgranskning, automatiserad testning, validering i staging-miljö och kontrollerad distribution.

Denna process är i sig själv motståndskraftig mot förändringar: verktyget skannar det DOM som finns vid skanningstillfället, rapporterar de problem som upptäcks och börjar om från början vid nästa skanning. Det finns ingen ackumulerad teknisk skuld i form av korrigeringsdefinitioner, inga föråldrade selektorer, inga övergivna alt-textposter och ingen risk att fel korrigering tillämpas på fel element.

Vad går sönder när du gör en ny distribution?

Varje korrigering av tillgänglighetsöverlägget är kopplad till webbplatsens aktuella DOM-struktur. Vi har konstaterat att 98 % av selektorerna i ett överlägg riktar sig mot ramverksspecifika klassnamn – klasser som .chakra-, .splide__, .js-, .b-, och CSS-in-JS-hashar som .css-acuo7n som ändras vid varje kompilering.

Övervakningsverktyget visar ”Ej påverkad” i varje rad eftersom det inte finns några selektorbaserade korrigeringar. Det finns inget som kan bli inaktuellt, inget som kan träffa fel element och inget som kan sluta fungera.

GDPR, integritet och frågan om samtycke

Vår analys bekräftade att tre av de fyra tillgänglighetsöverläggen skickar data till externa servrar innan användaren hinner interagera med någon samtyckesbanner:

Enligt EU-domstolens dom i målet Planet49 krävs ett förhandsgodkännande för icke-nödvändig spårning. Två popup-fönster skickar permanenta identifierare redan vid den första nätverksförfrågan – innan någon samtyckesmekanism hinner aktiveras. För webbplatser riktade mot EU innebär detta automatiskt att GDPR inte efterlevs.

Den rättsliga situationen

I april 2025 ingick den amerikanska Federal Trade Commission (FTC) en förlikning på 1 miljon dollar med en av leverantörerna av tillgänglighetsöverlägg i vår studie, efter att företaget felaktigt hävdat att dess AI-drivna verktyg kunde göra vilken webbplats som helst WCAG-kompatibel. FTC konstaterade att verktyget inte lyckades göra grundläggande webbplatskomponenter – menyer, rubriker, tabeller, bilder och inspelningar – tillgängliga. I ett av de exempel som nämndes fick en bild av filet mignon den AI-genererade beskrivningen ”Brunt bröd på vit keramikplatta”.

Enligt branschstatistik angav 25 % av alla rättsprocesser om digital tillgänglighet under 2024 uttryckligen överläggswidgets som hinder – inte som lösningar. Under första halvåret 2025 fortsatte rättsprocesserna mot företag som använder överläggswidgets i en takt på över 100 per månad. Två av leverantörerna av överlägg i vår studie har varit direkt inblandade i rättstvister: en i tre separata patent- och affärshemlighetsmål, och en annan som står inför en grupptalan från en småföretagskund som stämdes trots att denne använde överlägget.

Övervakningsverktyget i vår studie har inte varit föremål för några rättstvister gällande brister i tillgängligheten – vilket är en logisk följd av dess arkitektur: eftersom det aldrig ändrar DOM kan det inte skapa hinder för tillgängligheten.

En titt in i koden: Vad överlägg egentligen ändrar

För att få en uppfattning om omfattningen av DOM-manipulationen har vi räknat alla ändringsmönster i varje verktygs JavaScript-kod. Skillnaderna är dramatiska:

Överlagring C förtjänar särskild uppmärksamhet. Dess monolitiska paket på 794 KB innehåller en MutationObserver till document.documentElement med konfigurationen {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Det innebär varje enskild DOM-ändring på hela sidan – oavsett om det kommer från React:s virtuella DOM-synkronisering, ett A/B-testskript, en chattwidget eller webbplatsens eget JavaScript – utlöser överläggets observatör, som sedan omvärderar och eventuellt tillämpar sina korrigeringar på nytt. Efter en omdistribution av webbplatsen skapar detta en kedjereaktion av nya korrigeringsförsök på element som kanske redan är korrekt tillgänglighetsanpassade, vilket kan leda till att korrekta ARIA-attribut skrivs över med felaktiga.

Vi har bekräftat att överlägg C sänder USER-BEHAVIOR-ANALYTICS POST-förfrågningar till sin egen loggmottagare, med data som innehåller webbplatsens domän, widgetversionen, användarspråket och interaktionshändelser. I kombination med localStorage uthållighet och enhetsidentifiering via navigator.userAgent och navigator.maxTouchPoints... detta innebär en databehandling som de flesta webbplatsoperatörer inte är medvetna om.

Åtgärd av JSON-problemet

Overlay B hämtar en enorm JSON-fil (upp till 1,17 MB för en telekomwebbplats) som innehåller alla bildbeskrivningar. På en webbplats observerade vi att den hämtades fyra gånger under en och samma webbläsarsession – 4,7 MB bandbredd för en fil som borde ha lagrats i cacheminnet. JSON-filen innehåller 11 kategorier, men den överväldigande majoriteten är AI-genererade bildbeskrivningar: 4 974 av 6 975 poster för en webbplats. Varje post är kopplad till en specifik bild-URL – när CMS byter namn på en fil, ändrar miniatyrbildens dimensioner eller migrerar CDN-domäner slutar posterna tyst att matcha. Ersättningsbilderna får ingen alt-text alls, vilket gör sidan mindre tillgänglig än innan överlägget installerades.

Detta överlägg distribuerar även körningsmoduler som aktivt skriver om sidan: en korrigeringsmotor på 110 kB, ett hjälpverktyg för navigeringsmenyn på 23 kB som omstrukturerar menyns tangentbordsfunktioner, en karusellkorrigering på 5,8 kB samt en klientsideskanner på 53 kB som använder egenutvecklad logik istället för branschstandardmotorn axe-core – vilket innebär att dess resultat inte kan verifieras oberoende.

Det mest transparenta överlägget – fortfarande riskabelt

Överlägget D hade den mest öppna arkitekturen: läsbara JSON-konfigurationsfiler med tydliga alternativ för att aktivera eller inaktivera funktioner. Alternativ som addAriaHidden, overwriteAlt, och adjustMetaViewport hade uttryckligen ställts in på false. Den underliggande motorn (649 KB) innehåller dock 216 setAttribute samtal, 47 aria-hidden referenser, 282 addEventListener registreringar och 9 MutationObserver fall. Motorn stöder aggressiva ändringar av DOM även om den aktuella konfigurationen är konservativ – en ändring av konfigurationen från leverantörens sida kan aktivera riskfyllda funktioner utan webbplatsansvariges vetskap.

Vi hittade selektorer per webbplats som innehöll JavaScript-genererade hash-suffix som button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 som ändras vid varje ny version, och URL-selektorer för sociala medier som blir inaktuella när webbplatsen uppdaterar sina länkar till Facebook eller Instagram.

Den europeiska tillgänglighetslagen: Varför överlägg inte uppfyller kraven i EAA

Från och med den 28 juni 2025 kräver den europeiska tillgänglighetslagen (EAA) att digitala produkter och tjänster som säljs inom EU uppfyller tillgänglighetsstandarder som överensstämmer med EN 301 549, vilken hänvisar till WCAG 2.1 AA. Till skillnad från ADA – som främst tillämpas genom privata stämningar – tillämpas EAA av nationella marknadsövervakningsmyndigheter som har befogenhet att utdöma böter, föreskriva korrigerande åtgärder och dra tillbaka produkter som inte uppfyller kraven från marknaden.

Tysklands officiella avslag på överlagringsverktyg

Tyskland har intagit den tydligaste ståndpunkten av alla länder när det gäller tillgänglighetsöverlägg. BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – Tysklands federala tillsynsmyndighet för tillgänglighet inom informationsteknik – har tillsammans med alla delstatliga tillsynsmyndigheter utfärdat en gemensam bedömning där man uttryckligen avvisar användningen av överläggsverktyg för att uppfylla tillgänglighetskraven:

Den 12 mars 2025 bekräftade kommittén för tillgänglig informationsteknik (Ausschuss für barrierefreie Informationstechnik, inrättad enligt § 5 BITV 2.0) denna ståndpunkt vid sitt sammanträde och uttryckte sin oro över att offentliga organ fortsätter att försöka uppfylla sina skyldigheter avseende tillgänglighet genom att integrera överlagringsverktyg. Kommittén drog slutsatsen att ”en tillfällig tillgänglig återgivning av en webbplats med hjälp av programvara – eventuellt först efter att användaren har konfigurerat inställningarna – under besökets varaktighet inte uppfyller kraven i tillämpliga lagbestämmelser.”

Kommittén varnade uttryckligen för att offentliga organ som använder överläggsverktyg riskerar att göra sina webbplatser mindre tillgängliga, inte mer – vilket leder till en försämring av tillgängligheten (”Verschlechterung der Barrierefreiheit”). Detta stämmer väl överens med vår tekniska slutsats att 26 % av reglerna för korrigering med överläggsverktyg leder till nya överträdelser av WCAG.

BIK-testmärkning: Avvisad för webbplatser som använder överlägg

Tysklands BIK-testnätverk – de ackrediterade organ som utvärderar webbplatser enligt BITV 2.0, EN 301 549 och WCAG 2.1 AA – har vidtagit en operativ åtgärd: webbplatser som använder överläggsverktyg kan inte erhålla BIK-testmärket. Testorganen har förklarat att de inte kan göra en tillförlitlig bedömning av överensstämmelse när ett överlägg finns, eftersom överlägget modifierar DOM under körning på ett sätt som gör testresultaten opålitliga. BIK-märket används i stor utsträckning i Tyskland som bevis på överensstämmelse med BITV 2.0 – och det är nu otillgängligt för alla webbplatser som använder ett överlägg.

Detta är inte en rent teoretisk fråga. Det innebär att en tysk e-handelswebbplats som använder någon av de fyra överlägg som vi testat inte kan erhålla det standardcertifikat som krävs på den tyska marknaden.

Bekräftelse på EU-nivå

Denna rättsliga ståndpunkt gäller inte bara Tyskland. Europeiska handikappforumet och den internationella sammanslutningen för tillgänglighetsexperter (International Association of Accessibility Professionals) utfärdade 2023 ett gemensamt uttalande där de varnade för att tillgänglighetsöverlägg inte gör webbplatser tillgängliga eller förenliga med europeisk lagstiftning om tillgänglighet, däribland den europeiska tillgänglighetslagen. Europeiska kommissionen har också yttrat sig om påståenden om att överlägg uppfyller kraven och dragit slutsatsen att överlägg inte kan garantera att gällande standarder följs.

Enligt den tyska lagen BFSG (Barrierefreiheitsstärkungsgesetz – den tyska införlivningen av EAA, som trädde i kraft den 28 juni 2025) kan marknadsövervakningsmyndigheter utdöma böter på mellan 10 000 och 100 000 euro per överträdelse. BFIT-Bunds bedömning och BIK-testnätverkets vägran att certifiera webbplatser som använder överlägg innebär i praktiken att överläggsverktyg inte ger något rättsligt skydd i Tyskland – och kan aktivt öka risken för tillsynsåtgärder.

Säkerhet och risker i leveranskedjan

Alla överlagringsverktyg fungerar genom att infoga JavaScript från tredje part i det globala området på dina produktionssidor. Detta JavaScript körs med samma behörigheter som din egen kod – det kan läsa och ändra vilket DOM-element som helst, avlyssna formulärinlämningar, komma åt cookies, omdirigera användare och stjäla data. Säkerhetsriskerna med denna lösning är betydande och förbises ofta.

Angreppsytan

Tänk på hela kedjan: när du lägger till ett tillgänglighetslager på din webbplats ger du en extern leverantör kontinuerlig och obegränsad skrivbehörighet till ditt aktiva produktions-DOM. Leverantörens CDN levererar JavaScript-koden, leverantörens team underhåller koden och leverantörens distributionspipeline skickar uppdateringar direkt till din webbplats – utan din kodgranskning, utan din kvalitetssäkringsprocess och utan ditt godkännande.

Om leverantörens CDN utsätts för intrång får angriparen möjlighet att infoga skadlig kod i alla webbplatser som använder det nätverket. Om en anställd hos leverantören publicerar en felaktig uppdatering drabbas alla kunders webbplatser samtidigt. Om leverantörens API-ändpunkt kapas kan den JSON-fil eller de konfigurationsdata som skickas till din webbplats manipuleras för att ändra formulärfält, omdirigera länkar eller infoga phishing-innehåll.

Riskens omfattning står i direkt proportion till överläggets DOM-avtryck:

Overlay B utgör den största riskytan i leveranskedjan: 228 API-anrop per session fördelade på 3 externa domäner, med en JSON-payload på 1,17 MB som definierar hur DOM-modellen ska modifieras. Ett komprometterat API-svar kan instruera korrigeringsmotorn att injicera godtyckligt innehåll i vilket element som helst på sidan. Overlay C:s monolitiska paket på 1 285 KB är den största enskilda JavaScript-nyttolasten – och eftersom den är minifierad och förvrängd kan varken webbplatsoperatören eller en säkerhetsrevisor på ett meningsfullt sätt granska vad den utför vid körning.

Efterlevnad av PCI DSS: En direkt konflikt

För alla e-handelswebbplatser som hanterar kreditkortsbetalningar är efterlevnad av PCI DSS inte valfritt. Våra undersökningsresultat visar dessutom att det finns en direkt konflikt mellan arkitekturen hos tillgänglighetsverktyg och kraven i PCI DSS.

Krav 6.4.3 i PCI DSS (infört i PCI DSS v4.0, obligatoriskt från och med den 31 mars 2025) kräver att alla skript på betalningssidor som laddas och körs i kundens webbläsare hanteras enligt följande: en metod måste införas för att bekräfta att varje skript är godkänt, varje skripts integritet måste säkerställas och en förteckning över alla skript måste upprätthållas med en skriftlig motivering till varför varje skript är nödvändigt.

Vår analys bekräftade att regler för överlagringskorrigering aktivt riktar in sig på DOM-element på betalningssidor på flera webbplatser:

Detta är inte en teoretisk risk – det handlar om faktiska koder som vi har hämtat från produktionswebbplatser och som aktivt ändrar fält för kreditkortsnummer, val av faktureringsadress, knappar för betalningsleverantörer och formulärrutor för utcheckning. Enligt PCI DSS 6.4.3 kräver vart och ett av dessa skript från tredje part dokumenterad auktorisering, integritetskontroll och skriftlig motivering.

Tänk på vad en leverantör av överläggsskript kan göra på din kassasida:

Övervakningsverktyget har däremot ingen möjlighet att skriva till DOM. Dess 4,2 KB stora skript kan inte ändra formulärfält, kan inte avlyssna inmatningshändelser och kan inte komma åt eller ändra element i kassan. Även om övervakningsleverantörens CDN skulle utsättas för intrång skulle angriparen endast få tillgång till ett skript som kan läsa sidans URL och enhetstyp – inte ett som kan skriva om kassaformuläret. När det gäller fastställandet av tillämpningsområdet för PCI DSS skapar övervakningsverktyget ingen ytterligare riskyta på betalningssidorna.

Frågan om diskriminering

Detta är det diskrimineringsproblem som ligger till grund för alla tillgänglighetsöverlägg: Det mest oroande är inte någon teknisk brist – utan ett mönster där användare med funktionsnedsättning systematiskt nekas tillgång till funktioner som seende användare tar för givet.

När ett överlägg döljer en Amazon Pay-knapp i tillgänglighetsträdet ser en synskadad användare färre betalningsalternativ än en seende användare. När inmatningsfältet för antal i varukorgen är dolt kan en synskadad användare inte ändra sin beställning. När länkar till sökresultat är dolda försvåras det att hitta produkter. När stjärnbetyg är dolda kan en synskadad användare inte bedöma produktkvaliteten på samma sätt som en seende användare kan.

Det här är inga undantagsfall – det handlar om centrala arbetsflöden inom e-handeln som störs av just de verktyg som lovar att göra dem tillgängliga.

Funktionshindrade har påpekat detta i åratal. Faktabladet om överlägg – undertecknat av hundratals tillgänglighetsexperter – varnar för att tillgänglighetsöverlägg ”inte åtgärdar den underliggande HTML-koden” och ”ofta aktivt hindrar personer med funktionsnedsättning”. Vår tekniska analys ger bevisen: 141 funktionella element dolda för skärmläsare, 7 meningslösa etiketter infogade och 5 066 ogranskade AI-beskrivningar implementerade i produktion – på endast 14 webbplatser.

För webbplatsoperatörer handlar det inte om huruvida överlägg är ”tillräckligt bra” – utan om det går att motivera att införa ett verktyg som skapar en uppdelad upplevelse: en version för seende användare som får full funktionalitet, och en filtrerad, ofullständig och ibland meningslös version för användare med funktionsnedsättning.

Inverkan på efterlevnaden av ADA: Hjälper dessa åtgärder verkligen?

Det centrala löftet med alla överlägg är att de förbättrar ADA-efterlevnaden genom att åtgärda WCAG-överträdelser under körning. Men vår analys avslöjar en oroande paradox: en betydande andel av överläggens korrigeringar skapar aktivt nya WCAG-överträdelser samtidigt som de försöker åtgärda befintliga.

Vi har kopplat varje registrerad korrigeringsregel från Overlay A till det specifika WCAG 2.1-kriterium som den avser. Av de 776 regler som kunde kopplas in delades resultaten upp i två kategorier: korrigeringar som verkligen åtgärdar ett WCAG-problem, och korrigeringar som samtidigt skapar en ny WCAG-överträdelse.

För att vara rättvis är tre fjärdedelar av de kartlagda korrigeringarna verkliga förbättringar – man lägger till saknade knapptexter, rättar till rubrikhierarkier, korrigerar attribut för automatisk komplettering och implementerar modala fokusfällor. Men den återstående fjärdedelen är direkt skadlig, och skadan drabbar oproportionerligt just de användare som verktyget påstår sig hjälpa.

Hur varje riskfyllt mönster bryter mot WCAG

Problemet är inte bara att dessa korrigeringar misslyckas – utan att de medför överträdelser av specifika WCAG-kriterier som inte fanns innan överlägget tillämpades. I en ADA-rättegång kan en kärandes sakkunnig peka på dessa överträdelser, som skapats av överlägget, som bevis för att webbplatsen diskriminerar personer med funktionsnedsättning.

Överlagring B: AI-alternativtext och WCAG 1.1.1

WCAG 1.1.1 kräver att icke-textinnehåll har ett ”textalternativ som fyller samma syfte”. En AI-genererad alt-text som beskriver ett företagslogotyp som ”en blå och gul skylt” fyller inte samma syfte – syftet med en logotyp är varumärkesidentifiering, inte färgbeskrivning. En alt-text som ”text” för en reklambanner, eller ”stad” för en hero-bild, uppfyller inte samma kriterium på ett annat sätt – den är så vag att den är värdelös.

Av de 5 068 AI-genererade alt-texterna som vi samlade in från Overlay B var 241 kortare än 15 tecken (för vaga för att vara användbara), 323 var längre än 125 tecken (vilket strider mot rekommendationerna för skärmläsares användbarhet) och 156 inleddes med ”bild av” eller ”foto av” (överflödigt eftersom skärmläsare redan anger elementtypen). Endast 2 hade godkänts av en mänsklig granskare.

Enligt rättspraxis inom ADA skulle en kärandes tillgänglighetsexpert peka på detta som ett brott mot WCAG 1.1.1 – det kriterium som oftast åberopas i rättsprocesser om webbtillgänglighet enligt ADA. Överlägget åtgärdar inte överträdelsen; det ersätter en form av bristande efterlevnad (saknad alt-text) med en annan (felaktig eller vag alt-text), samtidigt som det skapar en falsk känsla av efterlevnad hos webbplatsoperatören.

Överlagring B: Insprängning av formuläretiketter under körning – när ”korrigeringar” förvärrar situationen

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.

När saneringsmotorn i Overlay B var aktiverad meddelade en skärmläsare:

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 blir sämre än det ursprungliga formuläret utan etiketter. Innan överlägget lades till stötte en användare av skärmläsare på sju fält utan etiketter – förvirrande, men åtminstone konsekvent. Användaren kunde använda tabbningsordningen och sammanhanget för att gissa vilket fält som var vilket. Efter överläggets införande möter användaren två fält med samma etikett (”Namn” för både förnamn och efternamn), två fält med påhittade etiketter i valideringsstil som inte stämmer överens med den synliga texten, och tre fält med meningslösa typbaserade namn. Den partiella, felaktiga märkningen är mer förvirrande än ingen märkning alls, eftersom den skapar ett falskt intryck av att formuläret har gjorts tillgängligt när viktiga fält förblir omärkta eller felmärkta.

Denna upptäckt avslöjar även en blindfläck i Overlay B:s JSON-korrigering. JSON-filen innehöll 87 AI-genererade alt-textposter och inga formkorrigeringsposter för denna webbplats. Injektionen av formuläretiketter sker helt och hållet vid körning via EmptyControls-regelhanteraren – den syns inte i den konsoliderade korrigerings-JSON-filen, spåras inte i någon instrumentpanel som webbplatsoperatören kan granska och är inte föremål för mänskligt godkännande. Webbplatsoperatören har inget sätt att veta att deras kontaktformulär är felmärkt om de inte testar det själva med en skärmläsare.

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 totala effekten av ADA-efterlevnaden

Det grundläggande problemet är att överlagringsverktyg blandar ihop täckning med efterlevnad. En överlagring kan peka på 1 058 korrigeringsregler och hävda att den uppfyller över 40 WCAG-framgångskriterier. Men när 26 % av dessa korrigeringar leder till nya överträdelser – däribland brister på nivå A som uppstår genom att funktionella element döljs – kan den totala efterlevnaden bli sämre än på den oförändrade webbplatsen.

En webbplats utan överlägg som har 50 WCAG-överträdelser befinner sig i en tydligare rättslig situation än en webbplats med överlägg som har 30 ursprungliga överträdelser plus 203 överträdelser som orsakats av överlägget – eftersom de överträdelser som orsakats av överlägget visar att webbplatsoperatören har använt ett verktyg som aktivt diskriminerar användare med funktionsnedsättning, vilket undergräver varje försvar som bygger på god tro.

Sammanfattningsvis