axe-core — Disability-World-Glossar

axe-core ist die quelloffene automatisierte Engine für Barrierefreiheitstests, die von Deque Systems entwickelt wird. Sie bildet das Herzstück eines breiten Ökosystems von Testwerkzeugen — Browser- Erweiterungen (axe DevTools, Accessibility Insights), CI-Skripte (axe-cli, jest-axe, cypress-axe, playwright-axe) und insbesondere das Barrierefreiheits-Audit von Lighthouse.

Im vergangenen Jahrzehnt war axe-core der am weitesten verbreitete automatisierte Barrierefreiheits-Checker weltweit. Die meisten barrierefreiheitsbezogenen CI-Pipelines in der Produktion laufen heute unter der Haube mit axe-core — häufig ohne dass das jeweilige Team es weiß.

Was axe-core gut kann

Das Regelwerk von axe-core ist bewusst konservativ ausgelegt: Eine Regel wird nur aufgenommen, wenn ihre Falsch-Positiv-Rate nahezu null beträgt. Das macht axe-core zuverlässig als CI-Gate — wenn ein Verstoß gemeldet wird, ist er real, und das Team kann handeln, ohne sich mit instabilen Prüfungen auseinandersetzen zu müssen.

Verlässlich erkannte Regeln umfassen unter anderem:

Fehlende oder leere Beschriftungen von Formularsteuerelementen.
Fehlende Alt-Attribute (und offensichtlich unbrauchbare Alt-Texte wie Dateinamen).
Unzureichender Farbkontrast (Text und UI-Komponenten).
Ungültiges ARIA — nicht existierende Rollen, fehlende erforderliche Eigenschaften, unzulässige Kindstrukturen.
Doppelte IDs, die ARIA-Referenzen zerstören.
Fehlendes Sprachattribut auf <html>.
Schaltflächen ohne zugänglichen Namen.
Formularfelder ohne programmatische Beschriftung.
Leere Links (<a href>...</a> ohne Text oder Alt-Attribut).
Überspringen von Überschriftenebenen und fehlendes <h1> in bestimmten Konfigurationen.

Diese Liste deckt einen bedeutenden Anteil leicht behebbarer Barrierefreiheitsmängel ab. Der Einsatz von axe-core in der CI erkennt sie zum Zeitpunkt des Code-Reviews — nicht erst beim Audit.

Die Obergrenze

Die Entwicklerinnen und Entwickler von axe-core benennen die Obergrenze explizit: Automatisierte Werkzeuge können höchstens 30–40 % der WCAG- Probleme erkennen. Der Rest erfordert menschliches Urteil und Tests mit assistiver Technologie.

Im Einzelnen kann axe-core folgende Probleme nicht erkennen:

Falschen Alternativtext — es kann feststellen, dass Alt fehlt, aber nicht, dass alt="hamburger icon" für eine Schaltfläche zum Öffnen eines Menüs falsch ist.
Irreführenden Linktext — „Hier klicken“-Links sind spezifikationskonform, für Screenreader-Nutzende aber nutzlos.
Gestörte Fokusreihenfolge — eine Tab-Reihenfolge, die nicht der visuellen Reihenfolge entspricht, ist ein Verstoß gegen 2.4.3, den kein statischer Checker erkennen kann.
Fehlerhafte Überschriftenstruktur — axe-core erkennt ein fehlendes h1 und übersprungene Ebenen, kann aber nicht feststellen, dass eine Seite h2 verwendet, wo h1 korrekt wäre.
Inhalte, die nur für bestimmte Nutzergruppen funktionieren — WCAG-konform, aber für Menschen mit Seheinschränkungen oder kognitiven Beeinträchtigungen nicht nutzbar.

Eine Website, die in axe-core null Verstöße aufweist, ist eine notwendige Voraussetzung für Barrierefreiheit — aber keine hinreichende. Die verbleibende Arbeit — Fokusreihenfolge, Inhaltsqualität, Screenreader- Verhalten, Tests mit echten Nutzenden — beansprucht den größten Teil des tatsächlichen Aufwands.

Axe-core operativ einsetzen

Drei Einsatzmuster ergänzen sich sinnvoll:

Im Editor. axe DevTools und Accessibility Insights laufen auf Anfrage gegen das gerenderte DOM in einem Browser-Tab. Empfohlen während der Entwicklung.
In der CI. axe-cli, jest-axe, cypress-axe oder playwright-axe brechen den Build bei neuen Verstößen ab. Empfohlen zur Vermeidung von Regressionen.
Beim Audit. Externe Prüfende nutzen axe-core als Ausgangspunkt und schichten manuelle Tests darüber. Empfohlen zur Validierung der automatisierten Basis.

Die Kombination hält automatisiert erkennbare Probleme dauerhaft bei null, während ein echtes Barrierefreiheitsprogramm den Rest übernimmt.