Pa11y: Automatisierte Barrierefreiheitstests für die Kommandozeile

Pa11y richtet sich an Entwicklerteams, die Barrierefreiheitsprüfungen in ihren automatisierten Workflow einbauen wollen, ohne auf kommerzielle Lösungen angewiesen zu sein. Das Tool ist minimalistisch, schnell und lässt sich mit wenigen Befehlen in jede CI/CD-Pipeline einbinden. Der Name ist ein Numeronym: "p-a-11-y" steht für "p-accessibility" – die 11 Buchstaben zwischen p und y.

Installation und erster Test

Pa11y wird über npm installiert: npm install -g pa11y. Danach genügt ein einzelner Befehl für den ersten Test: pa11y https://example.com. Pa11y startet einen Headless-Browser (Puppeteer/Chromium), lädt die Seite und gibt alle gefundenen WCAG-Verstöße in der Konsole aus.

Jeder Verstoß wird mit Regelcode, Schweregrad, betroffenem Element und Beschreibung angezeigt. Die Ausgabe lässt sich in verschiedenen Formaten generieren: JSON, CSV, HTML oder als CLI-Tabelle. Für Teams, die Ergebnisse weiterverarbeiten wollen, ist das JSON-Format ideal. Ein einzelner Test dauert typischerweise 5–15 Sekunden, abhängig von Seitengröße und Komplexität.

Konfiguration und Standards

Pa11y unterstützt verschiedene WCAG-Level: A, AA und AAA. Der Standard ist WCAG2AA, was der BFSG-Anforderung entspricht. Die Konfiguration erfolgt über eine .pa11yrc-Datei im JSON-Format oder über Kommandozeilen-Flags:

{
"standard": "WCAG2AA",
"timeout": 30000,
"wait": 2000,
"ignore": ["WCAG2AA.Principle3.Guideline3_1.3_1_1.H57.2"]
}

Mit "ignore" lassen sich bekannte Falsch-Positiv-Meldungen unterdrücken. Die "wait"-Option ist wichtig für Seiten mit JavaScript-Rendering: Pa11y wartet die angegebene Zeit in Millisekunden, bevor es die Analyse startet. Mit "actions" können vor dem Test Interaktionen simuliert werden – etwa Login-Formulare ausfüllen oder Cookies akzeptieren.

Pa11y-CI: Integration in Build-Pipelines

Für CI/CD-Umgebungen gibt es pa11y-ci, ein speziell für Pipelines optimiertes Paket. Es liest eine Liste von URLs aus einer Konfigurationsdatei und testet sie parallel. Die Konfiguration erfolgt in .pa11yci.json:

{
"defaults": { "standard": "WCAG2AA" },
"urls": [
"https://example.com/",
"https://example.com/kontakt",
{ "url": "https://example.com/login", "actions": ["set field #email to test@test.de", "click element #submit"] }
]
}

In GitHub Actions, GitLab CI oder Jenkins lässt sich pa11y-ci als Build-Step einbinden. Bei Verstößen gibt der Prozess einen Exit-Code ungleich 0 zurück, was den Build fehlschlagen lässt. So wird Barrierefreiheit zum Merge-Gate – kein PR kommt durch, der neue Barrieren einführt.

Pa11y Dashboard und Web-Interface

Pa11y Dashboard ist eine selbst gehostete Web-Oberfläche, die Pa11y-Ergebnisse über Zeit visualisiert. Es zeigt Trends, ermöglicht URL-Verwaltung und bietet eine übersichtliche Darstellung für Nicht-Entwickler. Die Installation erfordert Node.js und MongoDB.

Das Dashboard eignet sich gut für Teams, die regelmäßige Barrierefreiheits-Überwachung betreiben wollen, ohne dafür ein kommerzielles Tool zu nutzen. Allerdings wird das Dashboard-Projekt weniger aktiv gepflegt als pa11y-ci. Für professionelles Monitoring empfiehlt sich daher oft eine Kombination aus pa11y-ci in der Pipeline und einem spezialisierten Monitoring-Service für die Produktion.

Pa11y im Vergleich zu axe-core und Lighthouse

Pa11y nutzt intern die HTML_CodeSniffer-Engine (nicht axe-core), was zu leicht unterschiedlichen Ergebnissen führt. HTML_CodeSniffer deckt teilweise andere Regeln ab und meldet an manchen Stellen mehr Verstöße – was nicht immer besser ist, da auch die Falsch-Positiv-Rate höher sein kann.

Im Vergleich zu axe-core bietet Pa11y den Vorteil einer fertigen CLI-Integration ohne eigenen Testcode. axe-core ist flexibler und besser in Testing-Frameworks eingebunden, erfordert aber Programmieraufwand. Lighthouse enthält axe-core, prüft aber weniger Regeln. Pa11y ist die beste Wahl für Teams, die schnell und ohne viel Setup automatisierte Tests in der Pipeline haben wollen.