axe-core
Se även: axe
En öppen källkodsmotor för automatiserad tillgänglighetstestning från Deque, använd av webbläsartillägg (axe DevTools, Accessibility Insights), CI-skript och Lighthouse. Fångar uppskattningsvis 30–40 % av WCAG-problem.
axe-core är den öppna källkodsmotorn för automatiserad tillgänglighetstestning, utvecklad av Deque Systems. Den driver ett brett ekosystem av testverktyg — webbläsartillägg (axe DevTools, Accessibility Insights), CI-skript (axe-cli, jest-axe, cypress-axe, playwright-axe) och framför allt Lighthouse tillgänglighetsgranskning.
Under det senaste decenniet har axe-core varit den mest använda automatiserade tillgänglighetskontrollen i världen. De flesta tillgänglighetsrelaterade CI-pipelines i produktion i dag kör axe-core under huven, ofta utan att teamet är medvetet om det.
Vad axe-core gör bra
axe-core:s regeluppsättning är konservativ av design: en regel inkluderas bara när dess andel falsklarm i princip är noll. Det gör axe-core pålitligt som en CI-grindvakt — när det flaggar en överträdelse är överträdelsen verklig och teamet kan agera utan att oroa sig för jakt på opålitliga kontroller.
Regler som axe-core fångar tillförlitligt inkluderar:
- Saknade eller tomma etiketter på formulärkontroller.
- Saknade alt-attribut (och uppenbart värdelös alt som filnamn).
- Otillräcklig färgkontrast (text och UI-komponenter).
- Ogiltig ARIA — icke-existerande roller, saknade obligatoriska egenskaper, förbjudna barnstrukturer.
- Duplicerade ID:n som bryter ARIA-referenser.
- Saknat språkattribut på
<html>. - Knappar utan tillgängligt namn.
- Formulärfält utan programmatisk etikett.
- Tomma länkar (
<a href>...</a>utan text eller alt). - Hopp i rubriknivå och saknad
<h1>i vissa konfigurationer.
Den listan täcker en meningsfull andel av lätthängande tillgänglighetsbrister. Att köra axe-core i CI fångar dem vid kodgranskning snarare än vid granskningstillfället.
Taket
axe-core:s upphovspersoner är tydliga med taket: automatiserade verktyg kan som mest upptäcka 30–40 % av WCAG-problem. Resten kräver mänsklig bedömning och testning med hjälpmedelsteknik.
Specifikt kan axe-core inte fånga:
- Felaktig alternativtext — det kan tala om att alt saknas, men
inte att
alt="hamburger icon"är fel för en knapp som öppnar en meny. - Vilseledande länktext — “Klicka här”-länkar är specifikationsenliga, men oanvändbara för skärmläsaranvändare.
- Trasig fokusordning — tabordning som inte stämmer med den visuella ordningen är ett 2.4.3-fel som ingen statisk kontroll kan upptäcka.
- Felaktig rubrikstruktur — axe-core fångar saknad h1 och nivåhopp, men kan inte avgöra att en sida har använt h2 för det som borde ha varit h1.
- Innehåll som enbart fungerar för vissa användargrupper — tillgängligt enligt WCAG men oanvändbart för svagsynta, personer med kognitiva funktionsnedsättningar, etc.
En webbplats som får noll överträdelser i axe-core är nödvändig för tillgänglighet men inte tillräcklig. Det återstående arbetet — fokusordning, innehållskvalitet, skärmläsarbeteende, testning med verkliga användare — är det som tar merparten av den faktiska tiden.
Hur man använder axe-core operativt
Tre driftsättningsmönster fungerar bra tillsammans:
- I editorn. axe DevTools och Accessibility Insights körs på begäran mot det renderade DOM:et i en webbläsarflik. Används under utveckling.
- I CI. axe-cli, jest-axe, cypress-axe eller playwright-axe fallerar bygget vid nya överträdelser. Används för att förhindra regressioner.
- Vid granskningstillfället. Externa granskare kör axe-core som startpunkt och lägger sedan manuell testning ovanpå. Används för att validera den automatiserade baslinjen.
Kombinationen håller automatiskt detekterbara problem på noll medan ett verkligt tillgänglighetsprogram hanterar resten.