axe-core
Se også: axe
En open source-motor til automatiseret tilgængelighedstest fra Deque, brugt af browserudvidelser (axe DevTools, Accessibility Insights), CI-scripts og Lighthouse. Opdager anslået 30–40 % af WCAG-problemer.
axe-core er den open source-motor til automatiseret tilgængelighedstest, som er udviklet af Deque Systems. Den driver et bredt økosystem af testværktøjer — browserudvidelser (axe DevTools, Accessibility Insights), CI-scripts (axe-cli, jest-axe, cypress-axe, playwright-axe) og frem for alt Lighthousens tilgængelighedsaudit.
I det seneste årti har axe-core været den mest udbredte automatiserede tilgængelighedschecker i verden. De fleste tilgængeligheds-CI-pipelines i produktion i dag kører axe-core under hætten, ofte uden at teamet er klar over det.
Hvad axe-core gør godt
axe-cores regelsæt er bevidst konservativt: en regel inkluderes kun, når dens falsk-positiv-rate er reelt nul. Det gør axe-core pålidelig som CI-gate — når den markerer en overtrædelse, er overtrædelsen reel, og teamet kan handle på den uden at bekymre sig om uforudsigelige kontroller.
Regler, som axe-core opdager pålideligt, inkluderer:
- Manglende eller tomme labels på formularkontrols.
- Manglende alt-attributter (og åbenlyst ubrugelige alt-tekster som filnavne).
- Utilstrækkelig farvekontrast (tekst og UI-komponenter).
- Ugyldig ARIA — ikke-eksisterende roller, manglende påkrævede egenskaber, forbudte understrukturelle strukturer.
- Dublerede id’er, der ødelægger ARIA-referencer.
- Manglende sprogattribut på
<html>. - Knapper uden tilgængeligt navn.
- Formularfelter uden programmatisk label.
- Tomme links (
<a href>...</a>uden tekst eller alt). - Spring i overskriftsniveauer og manglende
<h1>i visse konfigurationer.
Den liste dækker en betydelig andel af lavthængende tilgængelighedsfejl. At køre axe-core i CI opdager dem på tidspunktet for kodegennemgang snarere end på revisonstidspunktet.
Loftet
axe-cores forfattere er eksplicitte om loftet: automatiserede værktøjer kan højst opdage 30–40 % af WCAG-problemer. Resten kræver menneskelig vurdering og test med hjælpeteknologi.
Specifikt kan axe-core ikke opdage:
- Forkert alternativ tekst — den kan fortælle, at alt mangler, men ikke
at
alt="hamburger icon"er forkert for en knap, der åbner en menu. - Vildledende linktekst — “Klik her”-links er specifikationskorekte, blot ubrugelige for skærmlæserbrugere.
- Brudt fokusrækkefølge — tabulatorrækkefølge, der ikke matcher den visuelle rækkefølge, er en 2.4.3-fejl, som ingen statisk checker kan opdage.
- Forkert overskriftsstruktur — axe-core opdager manglende h1 og niveauspring, men kan ikke afgøre, at en side har brugt h2 til det, der burde have været h1.
- Indhold, der kun virker for visse brugergrupper — tilgængeligt iht. WCAG, men ubrugeligt for svagtseende brugere, brugere med kognitive handicap osv.
Et websted med nul overtrædelser i axe-core er nødvendigt for tilgængelighed, men ikke tilstrækkeligt. Det resterende arbejde — fokusrækkefølge, indholdskvalitet, skærmlæseradfærd, test med rigtige brugere — er det, der udgør størstedelen af den faktiske tid.
Sådan bruger man axe-core operationelt
Tre implementeringsmønstre fungerer godt i kombination:
- I editoren. axe DevTools og Accessibility Insights kører on-demand mod den renderede DOM i en browserfane. Brug under udvikling.
- I CI. axe-cli, jest-axe, cypress-axe eller playwright-axe fejler bygningen ved nye overtrædelser. Brug til at forhindre regressioner.
- Ved revisioner. Eksterne revisorer kører axe-core som udgangspunkt og lægger derefter manuel test oven på. Brug til at validere det automatiserede grundlag.
Kombinationen holder automatisk-detekterbare problemer på nul, mens et reelt tilgængelighedsprogram håndterer resten.