Definition: axe-core ist eine Open-Source-Bibliothek von Deque Systems, die Webseiten im Browser automatisch auf Barrierefreiheit prüft. Sie enthält Regeln zu den WCAG-Stufen A, AA und AAA sowie zu Best Practices und steht unter der Mozilla Public License 2.0 [1]. Viele Prüfwerkzeuge bauen darauf auf, auch Reviseberg.
Englisch: axe-core · Auch: axe · Zuletzt geprüft: 27. September 2026
Wie axe-core arbeitet
axe-core ist JavaScript und läuft in der geladenen Seite. Es prüft also das fertige DOM, nachdem die Skripte der Seite gelaufen sind – das, was auch der Browser und ein Screenreader sehen. Jede Regel prüft eine Sache und hat eine eigene ID, etwa image-alt (Bild ohne Alternativtext), color-contrast (Textkontrast), label (Formularfeld ohne Beschriftung) oder button-name (Schaltfläche ohne Namen) [3].
Eingesetzt wird axe-core in Browser-Erweiterungen, in automatisierten Tests mit Playwright oder Puppeteer und in Build-Pipelines. Deque bietet darauf aufbauend auch kommerzielle Produkte an.
Tags: welche Regel zu welchem Standard gehört
Jede Regel trägt Tags [2]. wcag2a und wcag2aa stehen für WCAG 2.0 Stufe A und AA, wcag21a und wcag21aa für WCAG 2.1, wcag22aa für WCAG 2.2 Stufe AA. Dazu kommt das konkrete Kriterium, etwa wcag143 für 1.4.3. Regeln mit dem Tag best-practice verweisen auf kein Erfolgskriterium; sie beschreiben gute Praxis. Regeln mit experimental sind standardmäßig abgeschaltet.
Vier Arten von Ergebnissen
- violations: Die Regel hat einen Verstoß gefunden.
- passes: Die Regel wurde erfüllt.
- incomplete: Die Regel konnte nicht entscheiden, etwa beim Kontrast von Text über einem Bild. Ein Mensch muss prüfen.
- inapplicable: Auf der Seite gab es nichts, worauf die Regel passt.
Wichtig ist „incomplete“. Ein Werkzeug, das diese Ergebnisse weglässt, zeigt eine Seite als sauber, die es gar nicht beurteilen konnte.
Im Code
import AxeBuilder from '@axe-core/playwright'
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa', 'wcag21a',
'wcag21aa', 'wcag22aa'])
.analyze()
console.log(results.violations.length)
console.log(results.incomplete.length)Was axe-core nicht kann
axe-core drückt keine Tasten. Eine Tastaturfalle oder eine unlogische Fokusreihenfolge findet es deshalb nicht. Es sieht, ob ein Alternativtext fehlt, aber nicht, ob er passt. Es prüft den Zustand der Seite in dem Moment, in dem es läuft – ein Menü, das erst nach einem Klick aufgeht, bleibt ungeprüft, wenn niemand es öffnet. Nur ein kleinerer Teil der WCAG-Kriterien lässt sich so vollständig entscheiden [4]. Null Verstöße heißt deshalb nicht barrierefrei.
Wie Reviseberg damit umgeht
Reviseberg führt auf jeder gecrawlten Seite bei 1280 px Breite die axe-core-Regeln für WCAG 2.0, 2.1 und 2.2 auf Stufe A und AA aus, dazu die Best-Practice-Regeln. Die Regeln color-contrast, target-size, meta-viewport und scrollable-region-focusable laufen bei 360 px noch einmal. Die Ergebnisse ordnet Reviseberg den WCAG-2.2-Kriterien und Kapitel 9 der EN 301 549 zu. Ergebnisse mit „incomplete“ landen als „mögliches Problem“ in einer eigenen Liste und zählen nie als bestanden. Seit dem 27. September 2026 zeigt Reviseberg Best-Practice-Regeln wie region, heading-order, landmark-one-main und page-has-heading-one als „Best Practice, kein WCAG-Kriterium“. Sie fließen mit kleinem Gewicht in den Score ein, können aber nie ein Kriterium verfehlen lassen. Was axe nicht kann, übernimmt zum Teil der Tastatur-Agent: Er geht eine Nutzerreise mit echten Tastendrücken durch.
Verwandte Begriffe
Automatisierte Prüfung · Manuelle Prüfung · Tastaturfalle · Kontrastverhältnis · Overlay · WCAG