Hvad automatiseret test af tilgængelighed kan og ikke kan bevise

Automatiseret test af webtilgængelighed kan vise, at dele af en side ikke opfylder bestemte krav: Et billede har intet tekstalternativ, et formularfelt har ingen etiket, siden angiver intet sprog, eller en tekst har mindre farvekontrast, end WCAG kræver. Den kan ikke bevise, at en side eller en hel webshop er i overensstemmelse med WCAG 2.2 niveau AA.

Om det, værktøjer ikke kan, siger W3C’s vejledning om valg af værktøjer til evaluering af webtilgængelighed følgende (citater fra engelsksprogede kilder er oversat på denne side): »Værktøjer kan ikke automatisk kontrollere alle aspekter af tilgængelighed. Menneskelig vurdering er nødvendig. Nogle gange kan evalueringsværktøjer give falske eller vildledende resultater. Værktøjer til evaluering af webtilgængelighed kan ikke afgøre tilgængelighed, de kan kun hjælpe med at gøre det.«

W3C forventer begge former for test. Understanding Conformance, en del af W3C’s forklarende dokumenter (Understanding WCAG 2.2), siger, at alle succeskriterier i WCAG 2 er skrevet som testbare kriterier, og tilføjer: »Test af succeskriterierne ville indebære en kombination af automatiseret test og menneskelig evaluering.«

Grænsen mellem de to går gennem selve succeskriterierne. Mange af dem stiller krav om både noget, et program kan finde, og noget, et menneske skal vurdere. Succeskriterium 1.1.1 kræver et tekstalternativ, »der tjener det tilsvarende formål«. Succeskriterium 2.4.6 lyder i sin helhed: »Overskrifter og etiketter beskriver emne eller formål.« Et program kan finde tekstalternativet, overskriften og etiketten. Om de tjener deres formål, er en vurdering af, hvad de betyder.

En scanner bygget på en regelmotor som axe-core indlæser en side i en browser og kører et sæt regler på siden, sådan som browseren gengiver den. Hver regel leder efter én slags fejl, for eksempel en knap uden tilgængeligt navn, og rapporterer det element, hvor den fandt fejlen.

axe-core, open source-regelmotoren fra Deque Systems, som Validiscans scanner kører, har regler for WCAG 2.0, 2.1 og 2.2 på niveau A, AA og AAA og desuden regler for god praksis (README for axe-core). Ved en optælling til denne guide placerer regellisten for axe-core 4.13.0 63 regler under WCAG-niveau A og AA, når man ser bort fra de regler, som listen markerer som eksperimentelle eller udfasede. Disse 63 regler er tilsammen knyttet til 20 af de 55 succeskriterier, som WCAG 2.2 har på de to niveauer.

En scanning ser det, der er på siden, når reglerne kører. API-dokumentationen for axe-core oplister trinene i en test, og det sidste er: »Gentag for alt inaktivt eller ikke-gengivet indhold, efter at det er gjort synligt«. En menu, en dialogboks eller en fejlmeddelelse, der først vises efter et klik eller en indsendt formular, bliver kun testet, hvis noget åbner den først. Nogle kontroller interagerer derfor med siden: De bevæger sig gennem den med Tab-tasten eller gengiver den i en smal bredde og måler, hvad der sker. Validiscans kontroller af den slags beskrives nedenfor.

Nej. En fejl, som en regel rapporterer, er et belæg for, at et krav ikke er opfyldt. Et bestået resultat viser kun, at reglen ikke fandt nogen fejl af den slags, den leder efter.

W3C trækker denne grænse for sine egne testregler. ACT-regler beskriver, hvordan man tester overensstemmelse med WCAG og WAI-ARIA, og en ACT-regel kan teste ét enkelt aspekt af et krav: »en ACT-regel kan teste, at en tabelcelle har en overskriftscelle, i stedet for at teste succeskriterium 1.3.1 ›Info and Relationships‹ i sin helhed.« Når indhold ikke består en ACT-regel, opfylder det ikke det tilsvarende krav. Når det består, blev der »ikke opdaget nogen tilsvarende fejl«, hvilket »ikke nødvendigvis betyder, at indholdet opfylder alle aspekter af det tilsvarende tilgængelighedskrav.« ACT-regler er informative: De kræves ikke for at afgøre overensstemmelse med WCAG.

Blandt principperne i README for axe-core står der: »Den returnerer nul falske positiver (programfejl undtaget).« Der står også, at axe-core returnerer elementer som »incomplete«, hvor den ikke kunne være sikker, og at der så kræves en manuel gennemgang. Det er projektets egen udtalelse om dets design, ikke en uafhængig måling, og W3C’s vejledning, som er citeret ovenfor, advarer om, at evalueringsværktøjer i almindelighed kan give falske eller vildledende resultater. Designet gør dog én ting tydelig: Antallet af rapporterede fejl er ikke et samlet antal. Det tæller det, reglerne kunne fastslå, ikke alt, der er galt.

Tre regler i axe-core 4.13.0 viser, hvor grænsen går:

• Billeder. Reglen for billeder lader et billede bestå, hvis det har en alt-attribut eller, blandt nogle få andre muligheder, en ARIA-label, og dens kontrol melder bestået med teksten »Element has an alt attribute« (kontrollen has-alt). Kontrollen tester, at attributten findes, ikke hvad der står i den. En tom alt, som markerer et billede som dekorativt, består også. Om teksten beskriver billedet, og om billedet virkelig er dekorativt, er op til et menneske at vurdere.
• Undertekster til video. Reglen for undertekster lader en video bestå, hvis den har et undertekstspor. Mangler sporet, kan reglen ikke underkende videoen, fordi »medier kan bruge en anden metode til undertekster«, som en kommentar i dens kode siger. Den returnerer resultatet »kræver gennemgang« med meddelelsen »Check that captions are available for the element« (kontrollen caption). Om underteksterne er rigtige, kan den ikke afgøre.
• Farvekontrast. Kontrastkontrollen beregner kontrastforholdet mellem tekst og baggrund, og den nævner 15 grunde til i stedet at returnere »kræver gennemgang«, blandt andet et baggrundsbillede, en baggrundsgradient og et element, der er overlappet af et andet (kontrollen color-contrast). Tekst på et baggrundsbillede, for eksempel et banner, får resultatet »kræver gennemgang«.

Efter Validiscans egen vurdering kan en automatisk kontrol afgøre de fleste tilfælde for nogle få succeskriterier i WCAG 2.2. For de fleste kriterier kan en kontrol fastslå nogle fejl, men et menneske afgør, om kriteriet er opfyldt. For omkring en tredjedel kan kun et menneske afgøre det.

Denne gruppering er ikke en klassifikation fra W3C. Den bygger på teksten i hvert succeskriterium i WCAG 2.2, W3C’s ACT-regler, regellisten for axe-core 4.13.0 og et arbejdsudkast fra W3C, Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them, som her citeres som igangværende arbejde, sådan som udkastet selv beder om. Udkastet opsummerer det generelle problem: »Vi ved, hvordan man automatisk tester for og tæller forekomsterne af relevant opmærkning. Vi ved dog endnu ikke, hvordan man automatisk kontrollerer kvaliteten af det, som opmærkningen formidler til brugeren.«

Grupperet på denne måde falder de 55 succeskriterier i WCAG 2.2 på niveau A og AA i tre grupper:

Grupperingen beskriver, hvad en kontrol i princippet kan fastslå. Hvad et bestemt værktøj tester, er snævrere og varierer fra værktøj til værktøj.

I en fuld evaluering hjælper værktøjer, og mennesker evaluerer. W3C’s evalueringsmetode giver værktøjer to roller: at hjælpe med at udpege en repræsentativ stikprøve og at hjælpe de mennesker, der derefter evaluerer den.

WCAG-EM 2.0, evalueringsmetoden for WCAG (WCAG Evaluation Methodology), som arbejdsgruppen Accessibility Guidelines Working Group i W3C udgav som en Group Note den 23. juli 2026, har fem trin:

1. Fastlæg evalueringens omfang.
2. Udforsk det digitale produkt, der evalueres.
3. Vælg en repræsentativ stikprøve.
4. Evaluer den valgte stikprøve.
5. Rapportér resultaterne af evalueringen.

Om værktøjer siger WCAG-EM 2.0: »Selv om de fleste tilgængelighedskontroller ikke kan automatiseres fuldt ud, kan evalueringsværktøjer hjælpe dem, der evaluerer, betydeligt under evalueringen og bidrage til en mere effektiv evaluering.« Metodens eksempel: »nogle værktøjer til evaluering af tilgængelighed kan scanne et helt digitalt produkt for at hjælpe med at udpege relevante stikprøver til manuel evaluering.«

WCAG-EM 2.0 adskiller også store undersøgelser fra evalueringen af ét produkt. Undersøgelser af mange produkter udføres »typisk primært med automatiserede evalueringsværktøjer«, og sådanne evalueringer »dækker normalt ikke den nødvendige kvalitative dybde i gennemgangen af overensstemmelse for hvert enkelt produkt, som denne metode er udformet til.«

I en offentliggjort test mod et kendt sæt barrierer fandt ingen af de testede automatiserede værktøjer mere end halvdelen af dem. Det britiske Government Digital Service (GDS) placerede bevidst 142 tilgængelighedsbarrierer på en indholdsside og kørte 13 automatiserede værktøjer på den. I sin undersøgelse Accessibility tool audit, senest opdateret den 13. april 2018, fandt det bedste værktøj 40 % af barriererne og det dårligste 13 %. Medregner man de barrierer, som et værktøj markerede, så et menneske kunne kontrollere dem, for eksempel om beskrivelserne i alt-teksterne var rigtige, nåede det bedste værktøj op på 50 %. Projektets README opsummerer det således: Automatiserede kontrolværktøjer er »gode til at finde enkle og åbenlyse problemer, men kan ikke opdage mange tilgængelighedsproblemer.« Tallene stammer fra værktøjsversioner fra 2017 og 2018 og fra en testside, der blev bygget til formålet, ikke fra en rigtig webshop, så de viser et spænd og ikke en andel, der gælder for nogen webshop i dag.

Værktøjer kan rapportere forskellige tal for den samme side. De tester ikke alle det samme, som spændet i GDS’ undersøgelse viser, og de læser ikke alle WCAG på samme måde. Vejledningen til at foreslå regler i axe-core siger, at »ikke alle testere har den samme fortolkning af tilgængelighedsretningslinjerne«, og at alle reglerne i axe-core skal stemme overens med fortolkningen hos Deque Systems, udvikleren bag axe-core.

Store automatiserede undersøgelser viser den samme grænse fra den anden side. WebAIM’s analyse af forsiderne på de 1.000.000 højest rangerede websteder opdagede, med data fra februar 2026, WCAG 2-fejl på 95,9 % af dem. WebAIM tilføjer selv et forbehold: »Fordi kun WCAG-fejl, der kan opdages automatisk, blev medregnet, tyder det på, at andelen med fuld overensstemmelse med WCAG 2 A/AA helt sikkert var lavere end 4,1 %.« De seks fejltyper, den fandt oftest, er alle af en art, som en automatiseret regel kan opdage: tekst med lav kontrast, manglende tekstalternativer til billeder, manglende etiketter til formularfelter, tomme links, tomme knapper og manglende angivelse af dokumentets sprog. En sådan liste viser, hvad værktøjer kan se. Den er ikke en rangliste over alle barrierer.

Validiscans scanner kører automatiserede regler, og et menneske gennemgår en manuel tjekliste. Hvilke succeskriterier reglerne tester, og hvilke der har et punkt på tjeklisten, er offentliggjort kriterium for kriterium.

Scanneren kører 102 regler: 79 regler fra axe-core og 23 kontroller, som Validiscan selv har skrevet, mange af dem til det, axe-core ikke tester, for eksempel tastaturfælder, fokusrækkefølge og ombrydning (reflow). Yderligere 11 regler fra axe-core er slået fra, fordi en af Validiscans egne kontroller tester det samme, så ét element aldrig giver to fund, og 15 køres ikke, fordi axe-core markerer dem som eksperimentelle eller udfasede, eller fordi de kun tester niveau AAA. Regelkataloget oplister hver regel med dens status.

Nogle af Validiscans egne kontroller interagerer med siden. Én af dem »Følger Tab-rækkefølgen og finder løkker og blindgyder«; en anden »Viser sider i en bredde på 320 CSS-pixels (svarende til 400 % zoom)«. De måler adfærd. De vurderer ikke betydning.

Af de 55 succeskriterier i WCAG 2.2 på niveau A og AA testes 33 af mindst én regel, som scanneren kører. De øvrige 22 testes ikke af nogen regel, som scanneren kører, og hver af dem har et punkt på den manuelle tjekliste med 35 punkter. Tjeklisten har også punkter til nogle kriterier, som en regel kun tester delvis, for eksempel tastaturbetjening, fokusrækkefølge og undertekster. Til de øvrige kriterier, som en regel tester, har tjeklisten intet punkt. Kriteriematrixen viser for hvert succeskriterium, hvilke regler der tester det, og om den manuelle tjekliste har et punkt til det.

For hvert punkt på tjeklisten registrerer Validiscan bestået, ikke bestået eller ikke relevant, med noter og, hvor der findes en, en dokumentationsfil. Resultaterne er en del af Remediation Evidence Package i afsnittet »Manuel gennemgang og udeladte fund«. Pakkens afsnit »Omfang og metode« oplister evalueringens begrænsninger, blandt andet:

• »Automatiske kontroller finder kun en del af alle tilgængelighedsbarrierer. Et kriterium tæller kun som understøttet, når automatiske kontroller dækker det fuldt ud, eller en manuel gennemgang er bestået.«
• »Indhold i frames fra andre domæner og i lukket shadow DOM, som betalingsfelter og visse samtykkeværktøjer og widgets, vurderes ikke automatisk.«

I Validiscans applikation regnes automatiske kontroller for at dække et kriterium fuldt ud, når en regel, som scanneren kører, tester det, og den manuelle tjekliste ikke har noget punkt til det. For et sådant kriterium hviler resultatet »Understøtter« i pakken alene på automatiske kontroller. Pr. 6. oktober 2026 er der blandt disse kriterier nogle, som grupperingen ovenfor overlader til et menneske at afgøre, for eksempel 1.1.1 Non-text Content og 2.4.4 Link Purpose (In Context).

Resultater, som en regel markerer til gennemgang, gemmer scanneren ikke i dag, så de optræder ikke som fund. Siden om metode og standarder oplister det blandt begrænsningerne.

Pakken angiver, kriterium for kriterium, overensstemmelse med succeskriterierne i WCAG 2.1 AA og WCAG 2.2 AA, som de er vurderet på de anførte sider og datoer. Denne pakke er dokumentation for en vurdering og for udbedringsarbejde. Den er ikke et certifikat og udtaler sig ikke om, hvorvidt lovkrav er overholdt. Det gratis tjek er kun automatiseret, uden manuel gennemgang, og de fejl, det rapporterer, er derfor ikke et samlet antal.