axe-core: Die Open-Source-Engine für automatisierte Barrierefreiheitstests

axe-core hat sich als De-facto-Standard für automatisierte Accessibility-Tests etabliert. Die Engine wird in Tools wie axe DevTools, Google Lighthouse und vielen Testing-Frameworks eingesetzt. Ihr Regelwerk ist öffentlich dokumentiert, peer-reviewed und wird kontinuierlich aktualisiert. Für Teams, die Barrierefreiheit systematisch in ihren Entwicklungsprozess einbauen wollen, ist axe-core das Fundament.

Was ist axe-core und wer steckt dahinter?

axe-core wurde von Deque Systems entwickelt, einem US-Unternehmen, das seit über 20 Jahren im Bereich digitale Barrierefreiheit arbeitet. Die Engine ist unter der Mozilla Public License 2.0 veröffentlicht und auf GitHub frei verfügbar. Sie analysiert den DOM einer Webseite zur Laufzeit – also den tatsächlich gerenderten Zustand, nicht nur den Quellcode. Das ist ein entscheidender Vorteil gegenüber statischen Analysewerkzeugen, weil viele Barrieren erst durch JavaScript, CSS-Rendering oder dynamisch nachgeladene Inhalte entstehen.

axe-core prüft über 90 Regeln, die auf WCAG 2.1 Level A und AA, Section 508 und EN 301 549 abgestimmt sind. Jede Regel liefert eine eindeutige ID, eine menschenlesbare Beschreibung, den betroffenen WCAG-Erfolgsklassifikator und einen Impact-Level (minor, moderate, serious, critical). Das macht die Ergebnisse maschinenlesbar und leicht in Dashboards oder Issue-Tracker integrierbar.

Das Regelwerk im Detail

Jede axe-core-Regel besteht aus einem oder mehreren Checks, die auf bestimmte DOM-Elemente angewendet werden. Ein Beispiel: Die Regel "image-alt" prüft alle -Elemente auf ein vorhandenes, nicht-leeres alt-Attribut. Dabei unterscheidet axe-core zwischen Checks, die alle bestehen müssen (all), von denen mindestens einer bestehen muss (any), und solchen, die keiner bestehen darf (none).

Die Regeln decken unter anderem ab: Farbkontraste (color-contrast), fehlende Formular-Labels (label), Dokumentsprache (html-has-lang), Überschriftenhierarchie (heading-order), ARIA-Attribute (aria-valid-attr), Tastatur-Traps (no-focus-trap) und Link-Texte (link-name). Besonders stark ist axe-core bei Farbkontrast-Prüfungen, wo es Vorder- und Hintergrundfarben auch bei CSS-Gradients und Transparenzen berechnet. Jede Regel ist einzeln aktivier- oder deaktivierbar, sodass Teams ihr eigenes Profil zusammenstellen können.

Integration in Browser und DevTools

Die bekannteste Oberfläche für axe-core ist die axe DevTools Browser-Extension, verfügbar für Chrome, Firefox und Edge. Nach der Installation erscheint ein neuer Tab in den Entwicklertools. Ein Klick auf "Scan" analysiert die aktuelle Seite und listet alle gefundenen Verstöße mit Schweregrad, betroffenem Element und Lösungsvorschlag auf. Für jedes Issue kann man direkt zum DOM-Element navigieren.

Neben der Extension nutzt auch Google Lighthouse axe-core als Backend für seinen Accessibility-Audit. Wer Lighthouse nutzt, verwendet also indirekt bereits axe-core – allerdings nur einen Teil der Regeln. Die vollständige axe DevTools-Extension bietet mehr Checks und eine detailliertere Auswertung. Auch Microsofts Accessibility Insights for Web basiert auf axe-core.

CI/CD-Integration und Testautomatisierung

axe-core lässt sich als npm-Paket (@axe-core/core) in jede JavaScript-Testumgebung einbinden. Für die gängigen Testing-Frameworks gibt es fertige Adapter: @axe-core/react für React-Komponenten, axe-playwright für Playwright, cypress-axe für Cypress und jest-axe für Unit-Tests. Die Einbindung ist in der Regel wenige Zeilen Code:

const { AxeBuilder } = require("@axe-core/playwright");
const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toHaveLength(0);

In einer CI/CD-Pipeline kann so jeder Pull Request automatisch auf Barrierefreiheit geprüft werden. Bei Verstößen schlägt der Build fehl und die Entwickler sehen sofort, welche Regel verletzt wurde. Das ist der effektivste Weg, um Regressionen zu verhindern – Barrieren werden erkannt, bevor sie in die Produktion gelangen.

Grenzen automatisierter Tests mit axe-core

axe-core erkennt nach eigenen Angaben etwa 57 % aller WCAG-Verstöße automatisch. Die restlichen 43 % erfordern menschliches Urteil: Ist der Alt-Text sinnvoll formuliert? Ist die Tab-Reihenfolge logisch? Ergibt der Seiteninhalt ohne Bilder noch Sinn? Automatisierte Tests sind daher immer nur eine Säule einer umfassenden Barrierefreiheits-Strategie.

Weitere Einschränkungen: axe-core testet nur die aktuell sichtbare Seite. Interaktive Zustände (geöffnete Modals, ausgeklappte Menüs, Fehlermeldungen nach Formularversand) müssen separat angesteuert werden. Auch Inhalte in Shadow DOMs oder iframes erfordern gesonderte Konfiguration. Trotz dieser Grenzen bleibt axe-core das produktivste Werkzeug für den Einstieg in systematische A11y-Tests.