Pa11y und axe für Barrierefreiheitstests

Pa11y und axe-core sind Open-Source-Werkzeuge, die Barrierefreiheitstests nach WCAG automatisieren. Beide analysieren eine Seite, wenden Regeln auf das DOM an und melden Verstöße. Erkennen Sie den Großteil der Barrierefreiheitsprobleme automatisch und reservieren Sie manuelle Tests für die übrigen Fälle.

axe-core ist eine JavaScript-Bibliothek, die die Barrierefreiheitsprüfungen in Chrome DevTools, Lighthouse, Jest, Cypress, Playwright und vielen weiteren Tools ermöglicht. Sie ist der De-facto-Standard für automatisierte Barrierefreiheitstests – mit breiter Regelabdeckung und einer niedrigen Rate an Fehlalarmen.

Die axe DevTools-Browsererweiterung (Chrome, Firefox, Edge) fügt den DevTools einen Tab „Accessibility“ hinzu. Klicken Sie auf „Scan all pages“. Daraufhin werden alle Verstöße mit betroffenen Elementen, Schweregrad und Anleitung zur Behebung aufgelistet. Sie eignet sich am besten für einmalige Prüfungen während der Entwicklung.

Pa11y ist ein Node.js-CLI: npx pa11y https://example.com prüft eine URL. Die gefundenen Probleme werden im Terminal aufgelistet. Verwenden Sie es für schnelle Prüfungen, in Shell-Skripten oder für eine CI-Integration mit geringem Aufwand.

Kombinieren Sie axe-core mit Playwright für End-to-End-Tests der Barrierefreiheit: const results = await new AxeBuilder({ page }).analyze(). Stellen Sie sicher, dass results.violations.length === 0 gilt. So werden Regressionen erkannt, bevor sie die Produktion erreichen.

jest-axe führt axe in Jest-Tests für gerenderte Komponenten aus. Rendern Sie die Komponente mit React Testing Library und übergeben Sie den Container an axe: expect(await axe(container)).toHaveNoViolations(). Jeder Komponententest enthält nun auch eine Barrierefreiheitsprüfung.

Mit beiden Tools können Sie Regeln projektspezifisch deaktivieren oder anpassen: Schalten Sie Regeln aus, die mit bewusst getroffenen Designentscheidungen kollidieren, und erhöhen Sie die Strenge für bekannte kritische Regeln. Dokumentieren Sie jede deaktivierte Regel mit einem Kommentar, der den Grund erklärt – diesen Kontext benötigen zukünftige Entwickler.

Automatisierte Tools erkennen etwa 30–40 % der WCAG-Probleme. Für den Rest (eine sinnvolle Fokusreihenfolge, verständlicher alt-Text, eine semantisch korrekte Hierarchie von Überschriften und eine ARIA-Nutzung, die dem tatsächlichen UI-Verhalten entspricht) ist eine manuelle Überprüfung erforderlich. Automatisierung ist für Barrierefreiheit notwendig, aber nicht ausreichend.

Testen Sie mit NVDA unter Windows, VoiceOver auf dem Mac und JAWS für Unternehmenskunden. Tests mit echten Screenreadern zeigen Probleme auf, die Automatisierung nicht erkennen kann – verwirrende Ansagen, fehlerhafte Orientierungspunkte und eine unlogische Fokusreihenfolge. Einmal pro Release mit jedem wichtigen Screenreader ist eine sinnvolle Ausgangsbasis.

Die wertvollste Validierung der Barrierefreiheit erfolgt durch Menschen mit Behinderungen, die das tatsächliche Produkt verwenden. Rekrutieren Sie sie über Beratungen für Barrierefreiheit, universitäre Beratungsstellen für Studierende mit Behinderungen oder Testplattformen wie UserTesting.com. Ihr Feedback aus der Praxis deckt Probleme auf, die kein automatisiertes Tool sichtbar macht.

Blockieren Sie PRs bei Regressionen der Barrierefreiheit (neuen Verstößen), aber nicht bei bereits bestehenden Verstößen (der bestehenden Ausgangsbasis). So erhöhen Sie den Qualitätsmaßstab kontinuierlich, ohne die Auslieferung zu blockieren. Verfolgen Sie die Gesamtzahl der Verstöße über die Zeit als Frühindikator für den allgemeinen Zustand der Barrierefreiheit.

Verwenden Sie mehrere Tools: axe für die umfassende automatisierte Prüfung, Pa11y als zweite Meinung und manuelle Screenreader-Tests für die qualitative Lücke. Die Überschneidung ist gering; zusammen decken sie mehr Probleme ab als jedes einzelne Tool.

Welcher Anteil der WCAG-Probleme bei der Barrierefreiheit kann durch automatisierte Tools wie axe und Pa11y zuverlässig erkannt werden?

axe-core ermöglicht die meisten Barrierefreiheitsprüfungen. Die Browsererweiterung eignet sich hervorragend für einmalige Prüfungen, jest-axe- und Playwright-Integrationen für kontinuierliche Tests. Pa11y ist ein ergänzendes CLI. Die Automatisierung erkennt etwa 30–40 % der Probleme. Kombinieren Sie sie für eine vollständige Abdeckung mit manuellen Screenreader-Tests (NVDA, VoiceOver) und Tests durch Menschen mit Behinderungen. Blockieren Sie neue Regressionen in der CI, ohne die bestehende Ausgangsbasis zur Blockierbedingung zu machen.