Varför automatiserade tillgänglighetsskannrar bara upptäcker 30 % av problemen (och vad du kan göra åt det)

Du kör en automatiserad tillgänglighetsskanning, instrumentpanelen kommer tillbaka grön och du drar en lättnadens suck. Men här är en obekväm sanning: den där rena rapporten kan dölja majoriteten av din webbplats verkliga tillgänglighetshinder. Forskning och oberoende studier visar konsekvent att automatiska skannrar upptäcker någonstans mellan 30% och 57% av faktiska WCAG-överträdelser — vilket betyder att allt från hälften till två tredjedelar av problemen som dina användare med funktionsnedsättning möter varje dag är helt osynliga för de verktyg som de flesta team förlitar sig på.

Läget för automatiserad tillgänglighetstestning

Automatiserad tillgänglighetstestning har exploderat i popularitet, och av goda skäl. Allt fler team vänder sig till automatisering för att screena efter tillgänglighetsproblem: 50% av respondenterna i en undersökning från 2024 sa att de använder automatiserade tillgänglighetsverktyg för att identifiera potentiella problem, upp från 40% år 2023. Dragningskraften är uppenbar — skannrar är snabba, relativt billiga och kan integreras direkt i CI/CD-pipelines. De fångar de uppenbara, upprepningsbara, regelbaserade överträdelserna i stor skala: den saknade alt-attributet, formulärfältet utan etikett, knappen med ett tomt tillgängligt namn.

Men täckningstaket är ett envist problem som ingen skanningleverantör har lyckats bryta igenom. Enligt Deque "kan du i genomsnitt hitta 57% av WCAG-problemen automatiskt", och även då kommer verktyg att returnera komponenter som ofullständiga där manuell granskning behövs. Siffran 57% representerar den optimistiska änden av spektrumet, uppnådd av en av de mest mogna och allmänt betrodda tillgänglighetsmotorerna på marknaden med en pragmatisk, verklighetsnära mätmetod. Andra uppskattningar är avsevärt lägre. Automatiserade verktyg fångar ungefär 30–40% av WCAG-överträdelserna, medan de återstående 60–70% kräver manuell testning.

Skillnaden mellan 30% och 57% handlar om hur du definierar nämnaren. Deque kom fram till siffran 57% genom att ta ett pragmatiskt, verklighetsnära angreppssätt snarare än ett teoretiskt — genom att ta stickprov på ett stort antal webbplatser och mäta hur många av de faktiskt dokumenterade tillgänglighetsfelen som skulle ha upptäckts med axe-core. När forskare istället mäter täckning mot alla WCAG:s framgångskriterier som en teoretisk uppsättning, faller siffrorna kraftigt. Vid tidpunkten för detta skrivande visar filtrering för WCAG 2.2 nivå A och AA för att endast visa godkända automatiserade testr regler partiell eller full täckning för endast 17 av 55 framgångskriterier. Oavsett hur du räknar lämnar automatiserad testning en betydande — och juridiskt farlig — lucka.

Problemet förvärras av hur svårt det är att se den luckan utifrån. En godkänd skanning signalerar aktivt säkerhet, vilket är precis när team är som mest benägna att sluta leta. Instrumentpanelen är grön. Utrullning sker. Riktiga användare med funktionsnedsättning stöter på verkliga hinder.

Vad skannrar faktiskt är bra på

Innan vi dyker ner i täckningsluckan är det värt att vara tydlig med vad automatiserade verktyg faktiskt gör bra. De är snabba, konsekventa och outtröttliga när det gäller att kontrollera sådant som kan avgöras enbart genom att läsa DOM:en. Tillgänglighetsautomatisering kan pålitligt fånga vanliga WCAG-överträdelser som saknad alt-text, tomma länkar, felaktiga formuläretiketter och låga färgkontrastförhållanden. Detta är strukturella, binära kontroller — antingen finns attributet eller så gör det inte det, antingen klarar kontrastförhållandet 4,5:1 eller så gör det inte det.

WebAIM Million-rapporten, som analyserar de en miljon mest besökta startsidorna årligen, ger en tydlig bild av hur utbredda dessa upptäckbara fel fortfarande är. 95,9% av startsidorna hade upptäckta WCAG 2-fel. De sex vanligaste kategorierna — text med låg kontrast, saknad alt-text, saknade formuläretiketter, tomma länkar, tomma knappar och saknat dokumentspråk — står för 96% av alla upptäckta fel, och dessa vanligaste fel har varit desamma de senaste sju åren. Automatiserade verktyg är verkligen hjälpsamma för att lyfta fram dessa högfrekventa, lågkomplexa överträdelser i stor skala. Problemet är att om man bara åtgärdar dessa problem lämnar man ändå kvar de flesta av webbplatsens verkliga hinder.

Varför luckan finns: Vad skannrar inte kan utvärdera

Täckningstaket är inte ett ingenjörsmisslyckande — det är en grundläggande begränsning i vad en maskin kan bedöma utan mänskligt omdöme. Luckan finns eftersom maskiner inte kan förstå kontext, användarens avsikt eller subjektiva frågor som huruvida rubrikhierarkin är vettig eller om alt-texten är korrekt. En skanner kan bekräfta att en bild har ett alt-attribut. Den kan inte tala om för dig om det attributet lyder "photo-123-final-v2.jpg" eller en genuint användbar beskrivning. Verktyg kan flagga att en bild har alt-text, men bara en människa kan bedöma om den texten faktiskt beskriver bilden väl.

Här är de viktigaste kategorierna av problem som konsekvent undgår automatiserad upptäckt:

• Skärmläsarupplevelse: Automatiserade verktyg kan inte lyssna på hur en skärmläsare läser upp innehåll. De kan kontrollera ARIA-attributens giltighet men kan inte avgöra om de resulterande uppläsningarna är begripliga för användare. Ett formulärfält kan ha ett tekniskt giltigt aria-label som läses upp som en förvirrande teckensträng för en verklig NVDA- eller JAWS-användare.
• Logisk läs- och fokusordning: I praktiken är läsordningen ofta inte vettig när skärmläsaranvändare tar del av information som visuellt kan se helt korrekt ut. I en kolumnlayout läser en skärmläsare första raden i kolumn 1, sedan kolumn 2, vilket leder till förvirring. Skannrar analyserar DOM-ordningen isolerat, utan kontexten av hur den visuella layouten transformerar den ordningen för en seende användare.
• Meningsfull länk- och knapptext i kontext: Automatiserade verktyg kan kontrollera om en länk finns och om den innehåller text, men de kan inte alltid bedöma om syftet med länken är tydligt. Fem "Läs mer"-länkar på samma sida klarar alla automatiska kontroller och misslyckas alla för verkliga användare som behöver förstå vart varje länk leder.
• Dynamiskt innehåll och live regions: Automatiserade verktyg kommer inte att kunna fånga problem med dynamiskt inläst innehåll. Man måste köra testet igen efter att den dynamiska uppdateringen har lagts till — men även då kan verktyget inte säga om en skärmläsare kommer att läsa upp det eller inte.
• Kognitiv tillgänglighet och klarspråk: Automatisering kan upptäcka strukturella problem som rubrikordning eller förekomst av etiketter, men kan inte utvärdera läsbarhet, tydlighet eller om instruktioner är lätta att följa. En komplex flerstegsutcheckning med förvirrande felmeddelanden kan vara strukturellt "ren" samtidigt som den är djupt otillgänglig för användare med kognitiva funktionsnedsättningar.
• Tangentbordsnavigering i komplexa interaktioner: Automatisering kan testa grundläggande tangentbordsfokus och -användbarhet, men kan inte fullt ut validera komplexa flerstegsinteraktioner, anpassade gester eller alternativa inmatningsenheter. En anpassad datumväljare kan i teorin vara fullt tangentbordsanvändbar och i praktiken en total fälla.
• Överlappande visuella element och gradientkontrast: Automatiserade verktyg kan utvärdera kontrastförhållanden, men de tar inte alltid hänsyn till överlappande element, bilder bakom text eller dynamiskt förändrat innehåll som stör läsbarheten.

En ren automatiserad skanning betyder att du har åtgärdat de 30–40% av problemen som automatisering kan fånga. De återstående 60–70% är otestade. Påstå aldrig WCAG-efterlevnad enbart baserat på automatiserad testning.

Ett särskilt slående bevis: i en studie skapade statliga tillgänglighetsförespråkare i Storbritannien medvetet en webbsida med 142 tillgänglighetshinder och analyserade sedan sidan med 13 automatiserade tillgänglighetsverktyg. Det bäst presterande verktyget kunde bara identifiera 40% av hindren. Det sämst presterande verktyget hittade bara 13%. Även när förutsättningarna var riggade till verktygens fördel — genom att använda en kontrollerad sida med kända, dokumenterade problem — var resultaten nedslående. Och att kombinera verktyg löser inte problemet fullt ut: även med sex verktyg i parallell täcks inte hälften av alla WCAG 2-framgångskriterier och 6 av 10 överträdelser missas.

Den juridiska risken med att förlita sig för mycket på automatisering

Detta är inte bara en teoretisk fråga om användarupplevelse. De juridiska insatserna för bristande tillgänglighet ökar kraftigt, och en godkänd automatiserad skanning erbjuder nästan inget skydd i en rättsprocess. År 2024 väcktes mer än 4 000 stämningar i amerikanska domstolar med påståenden om hinder för webb- eller mobiltillgänglighet. Under första halvan av 2025 ensamt väcktes 2 014 ADA-stämningar om webbplatser — en ökning med 37% från 2024.

Förlikningar utanför domstol ligger i genomsnitt på 30 000 dollar, medan domstolsutslag i genomsnitt ligger på 85 000 dollar. Försvarskostnader på 30 000–175 000 dollar tillkommer i alla fall. Än värre, en förlikning en gång är ingen garanti för säkerhet: 45–46% av de federala stämningarna om digital tillgänglighet 2025 riktades mot företag som redan hade blivit stämda tidigare. Att bli stämd och bara lappa det som automatiserade verktyg flaggar, utan att ta itu med de bredare strukturella luckorna, målar helt enkelt upp en måltavla för nästa kärande.

Det är också värt att bemöta en vanlig missuppfattning om tillgänglighetswidgets och overlays som en genväg till efterlevnad. Data från 2025 visar att 456 ADA-stämningar väcktes mot webbplatser som hade tillgänglighetswidgets installerade, vilket utgjorde 22,64% av alla stämningar — vilket understryker att det inte är en heltäckande lösning att bara lägga till en tillgänglighetswidget. Automatiserade verktyg kan bara upptäcka 30% av WCAG-problemen, vilket betyder att alla verktyg eller widgets som enbart förlitar sig på automatiserad upptäckt per definition lämnar majoriteten av problemen oadresserade. Det som skiljer ett genuint värdefullt tillgänglighets-SDK — som Accsible — från de overlay-produkter som har mött juridisk och regulatorisk motreaktion är kombinationen av automatiserad åtgärd med ett åtagande om en ärlig, lagerbaserad efterlevnadsstrategi snarare än falska garantier.

En lagerbaserad teststrategi som faktiskt fungerar

Svaret på täckningsluckan är inte att överge automatiserade skannrar — det är att använda dem på rätt sätt, som det första lagret i en heltäckande strategi, inte det sista. Av de 86 framgångskriterierna i WCAG 2.2 kräver sjuttio procent mänsklig granskning för att korrekt tolka kriterierna och tillämpa dem på de gråzoner som ligger utanför automatiserad tillgänglighetstekniks räckvidd. Det betyder att mänskligt omdöme inte är valfritt — det är strukturellt krävt av standarden själv.

Ett robust program för tillgänglighetstestning fungerar typiskt i tre lager:

1. Automatiserad skanning (kontinuerlig): Integrera skannrar som axe-core i din CI/CD-pipeline och kör dem på varje build. Fånga de strukturella, binära överträdelserna innan de når produktion. Sätt tröskelvärden och låt builds fallera vid nya kritiska överträdelser. Detta är ditt säkerhetsnät för det uppenbara — snabbt, skalbart och billigt. Kör automatiserade verktyg tidigt och ofta under utvecklingen. Integrera axe eller WAVE i din CI/CD-pipeline så att problem fångas innan koden når QA. Detta flyttar tillgänglighetstestning åt vänster, så att problem fångas när de är billigast att åtgärda.
2. Expertgranskad manuell revision (periodisk): Genomför strukturerade manuella revisioner mot hela WCAG-checklistan, utförda av personer med djup tillgänglighetskunskap. Manuella tillgänglighetstester utförs av utbildade experter som aktivt använder webbplatser med hjälpmedel som skärmläsare, tangentbordsnavigering eller förstoringsprogram. De bedömer kontext och användarupplevelse — den logiska fokusordningen och den intuitiva känslan i navigeringen, tydligheten i formulär och felmeddelanden, läsbarhet i komplext innehåll. Manuella revisioner sker vanligtvis kvartalsvis eller när större funktioner lanseras, och de bör täcka dina mest trafikerade användarresor från början till slut. Vägledda manuella tillgänglighetsrevisioner ligger mellan helt manuella och helt automatiserade tester, minskar täckningsluckan, och vissa uppskattningar anger täckning på upp till 80% med detta angreppssätt.
3. Testning med hjälpmedel och användare (löpande): Du kan inte förlita dig enbart på automatiserade verktyg för att avgöra tillgänglighetsproblem på din webbplats. Varje webbplatsprojekt behöver en användarteststrategi, och det rekommenderas starkt att du inkluderar tillgänglighetsanvändargrupper — skärmläsaranvändare, tangentbordsanvändare, icke-hörande användare, användare med rörelsenedsättningar. Riktiga användare med funktionsnedsättningar hittar problem som inga checklistor förutser. Testa med NVDA och JAWS på Windows, VoiceOver på macOS och iOS, och TalkBack på Android. Navigera hela din utchecknings- eller registreringsflöde enbart med tangentbordet. Lyssna faktiskt på hur ditt innehåll låter när det läses upp.

När team implementerar alla tre lager kan den kombinerade täckningen närma sig 80–90% av verkliga problem — en dramatisk förbättring jämfört med taket på 30–57% för enbart automatisering. Målet är inte perfektion dag ett; det är en systematisk, dokumenterad process som visar genuina ansträngningar i god tro och kontinuerligt minskar luckan.

Att integrera tillgänglighet i din utvecklingsprocess

Den viktigaste kulturella förändringen är att flytta tillgänglighet från en checklista före lansering till en kontinuerlig praktik. Många organisationer gör misstaget att behandla den som en engångsrevision de beställer när de fruktar en stämning, snarare än en kvalitetsstandard inbakad i varje sprint. När en revision väl avslöjar problem i ett produktionssystem är kostnaden för att åtgärda dem fem till tio gånger högre än den skulle ha varit i designfasen.

Börja med att göra tillgänglighetskriterier till en del av din definition av klart. När en utvecklare levererar en ny komponent bör en snabb automatisk kontroll köras automatiskt. När en designer skapar ett nytt mönster bör färgkontrast och fokusmarkeringar granskas innan designen ens lämnas över. När en redaktör lägger till en ny bild bör hen ha en tydlig förståelse av hur meningsfull alt-text ser ut — inte bara att alt-text krävs.

För compliance-ansvariga är den praktiska implikationen dokumentation. Vissa team kör automatiska tester men åtgärdar aldrig resultaten. Detta ger inget värde och skapar dokumentation som visar att ni kände till problemen men inte fixade dem — problematiskt i juridiska situationer. Ett tillgänglighetsprogram är bara försvarbart om du kan visa en rimlig, godtroget genomförd process för kontinuerlig förbättring: regelbundna skanningar, dokumenterade fynd, en åtgärdsplan och bevis på att du agerar på det du lär dig. WCAG-efterlevnad är inte ett binärt tillstånd du uppnår en gång — det är en hållning du upprätthåller.

Verktyg som Accsible finns för att stödja detta lagerbaserade angreppssätt — genom att tillhandahålla ett SDK som bäddar in tillgänglighetsförbättringar direkt i användarupplevelsen, lyfter fram problem i realtid och kompletterar den manuella revisionsprocessen snarare än att försöka ersätta den. Rätt overlay eller SDK är inte en magisk sköld mot stämningar; det är en komponent i ett genomtänkt program som erkänner vad automatisering kan och inte kan göra.

Viktiga slutsatser

• Automatiserade skannrar är en startpunkt, inte en mållinje. Även de bästa verktygen upptäcker mellan 30% och 57% av verkliga WCAG-överträdelser. En ren skanningsrapport betyder inte att din webbplats är tillgänglig — det betyder att den upptäckbara delmängden av problem har åtgärdats.
• Majoriteten av WCAG:s framgångskriterier kräver mänskligt omdöme. Skärmläsarupplevelse, logisk läsordning, meningsfull länktext i kontext, kognitiv tydlighet och komplexa tangentbordsinteraktioner är alla områden där automatisering strukturellt sett inte kan ge dig ett tillförlitligt svar.
• Den juridiska miljön är fientlig mot självgodhet. Över 5 100 federala ADA-stämningar om webbplatser väcktes 2025, förlikningar kostar rutinmässigt 30 000–85 000 dollar plus försvarskostnader, och nästan hälften av de svarande hade redan blivit stämda tidigare — vilket tyder på att ytliga åtgärder inte räcker.
• En trelagersstrategi — automatiserad skanning, expertgranskade manuella revisioner och verklig testning med hjälpmedel — kan pressa täckningen mot 80–90% och ger dig den dokumenterade, godtroget genomförda efterlevnadshållning som domstolar och tillsynsmyndigheter förväntar sig att se.
• Flytta tillgänglighet åt vänster. Att fånga problem i design- och utvecklingsfasen kostar en bråkdel av vad åtgärder kostar efter lansering. Integrera automatiska kontroller i CI/CD, gör tillgänglighet till en del av din definition av klart och genomför regelbundna manuella revisioner av dina mest trafikerade användarresor.