Accessibility Testing – Tools & Methoden (axe, WAVE, Lighthouse)

Accessibility Testing ist der Prozess der systematischen Überprüfung digitaler Produkte auf Barrierefreiheit, kombiniert aus automatisierten Werkzeugen (axe, WAVE, Lighthouse), manuellem Testing mit Tastatur und Screen Reader sowie Nutzertests mit betroffenen Personen.

Rubrik: Mediendesign & Digitale Medien · Unterrubrik: Accessibility · Niveau: Fortgeschritten

Was ist Accessibility Testing?

Accessibility Testing ist die Prüfung eines digitalen Produkts auf Übereinstimmung mit WCAG – Web Content Accessibility Guidelines im Überblick und anderen Barrierefreiheitsstandards. Es ist eine spezialisierte Form des Quality Assurance (QA)-Prozesses und sollte kontinuierlich in den Entwicklungszyklus integriert sein, nicht als einmalige abschließende Prüfung.

Ein fundamentales Prinzip: Automatisierte Tests allein sind nicht ausreichend. Aktuelle Studien zeigen, dass automatisierte Tools nur 30–40 % aller WCAG-Konformitätsprobleme identifizieren können (Deque, 2023). Der Rest erfordert manuelles Testen und Nutzertests.

Erklärung

Die drei Säulen des Accessibility Testings

1. Automatisierte Tests: Tools scannen den Quellcode und die gerenderte Seite auf bekannte Fehler. Schnell, skalierbar, aber limitiert.

2. Manuelles Testing: Testerinnen und Tester navigieren die Seite mit Tastatur und Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer, prüfen Logik, Reihenfolge und Kontextverständlichkeit.

3. Nutzertests mit betroffenen Personen: Die einzige Methode, um zu prüfen, ob barrierefreie Implementierungen im echten Nutzungskontext funktionieren und verständlich sind.

Automatisierte Testing-Tools

axe (Deque Systems): axe ist das am weitesten verbreitete Open-Source-Accessibility-Testing-Framework. Es wird als Browser-Extension (axe DevTools), NPM-Paket (axe-core) und als Teil von Selenium/Cypress-Testsuiten eingesetzt.

• axe DevTools (Browser-Extension): Kostenlose Basisversion für Chrome und Firefox. Identifiziert WCAG 2.1/2.2 A/AA-Verstöße in der gerenderten Seite.
• axe-core (npm): Integration in automatisierte CI/CD-Pipelines. Führt Tests bei jedem Build-Prozess durch.
• Stärke: Geringe False-Positive-Rate; gut dokumentierte Ergebnisse mit Code-Referenzen.
• Limitation: Prüft nur automatisch prüfbare Regeln (ca. 30 % der WCAG-Kriterien).

WAVE (WebAIM): WAVE (Web Accessibility Evaluation Tool) von WebAIM ist ein browserbasiertes Tool, das Accessibility-Fehler direkt in der visuellen Darstellung der Seite markiert.

• Kostenlose Web-Version und Browser-Extension für Chrome/Firefox.
• Zeigt Fehler, Warnungen und strukturelle Informationen direkt im Seitenkontext.
• Besonders nützlich für visuelle Tester, die den Kontext eines Fehlers direkt sehen wollen.
• Stärke: Intuitive visuelle Darstellung; zeigt auch strukturelle Informationen (Landmark-Regionen, Überschriftenhierarchie).
• Limitation: Sendet Seiten-URL an WebAIM-Server (kein Test für passwortgeschützte Seiten in der Web-Version möglich).

Google Lighthouse: Lighthouse ist in Chrome DevTools integriert und als CLI-Tool verfügbar. Es enthält einen Accessibility-Audit-Score (basierend auf axe-core) als einen von mehreren Bewertungsbereichen (Performance, SEO, PWA).

• Accessibility-Score 0–100, basierend auf axe-Regeln.
• Direkt in Chrome DevTools, kein separates Tool erforderlich.
• Nützlich für schnelle Ersteinschätzung.
• Limitation: Der Score-Wert kann trügerisch sein: Eine Seite mit Score 90 kann immer noch zahlreiche manuelle Accessibility-Probleme haben.

IBM Equal Access Toolkit: Kostenloses Open-Source-Tool von IBM, als Browser-Extension und als npm-Paket verfügbar. Bietet detaillierte WCAG-Mapping und deckt mehr Kriterien als axe allein ab. Gut geeignet für Compliance-Dokumentation.

Pa11y: Open-Source CLI-Tool und Node.js-Bibliothek für automatisiertes Accessibility-Testing. Gut für CI/CD-Integration und das Testen großer Website-Verbünde.

Deque WorldSpace Attest / Deque axe Pro: Kommerzielle Erweiterung von axe mit geführtem manuellen Testing, Team-Workflows und Compliance-Reporting.

Manuelles Testing

Tastaturtest: Alle Seiten werden ausschließlich mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten durchnavigiert. Prüfung:

• Ist der Fokus immer sichtbar? (vgl. Tastaturnavigation & Fokus-Management)
• Ist die Tab-Reihenfolge logisch?
• Können alle Funktionen aktiviert werden?
• Gibt es Tastaturfallen?

Screen-Reader-Test: Test mit NVDA + Chrome/Firefox (Windows) und VoiceOver + Safari (macOS/iOS):

• Werden alle Inhalte korrekt und vollständig vorgelesen?
• Werden Bilder mit sinnvollem Alt-Text für Bilder – Regeln & Best Practices angekündigt?
• Sind Formulare vollständig nutzbar?
• Werden Fehlermeldungen und Statusänderungen angekündigt?

Farbkontrast-Test: Prüfung aller Text-Hintergrund-Kombinationen mit dem Colour Contrast Analyser (kostenlos, Windows/macOS) oder dem WebAIM Contrast Checker (web-basiert), vgl. Farbkontrast & Accessibility – AA vs. AAA-Standards.

Zoom-Test: Browser auf 200 % zoomen und prüfen, ob Text und Layout korrekt skalieren, ohne horizontales Scrolling oder Überlappungen, vgl. Schriftgröße & Lesbarkeit – Mindeststandards für barrierefreien Text.

Farbenblindheit-Simulation: Design für Farbenblinde – Typen, Auswirkungen & Tools-Simulation mit Stark (Figma) oder Chrome DevTools > Rendering > Emulate vision deficiency.

Das WCAG-EM: Evaluation Methodology

Das Website Accessibility Conformance Evaluation Methodology (WCAG-EM) des W3C ist ein strukturiertes Verfahren für formelle Accessibility-Audits. Es definiert:

1. Scope: Welche Seiten und Funktionen werden geprüft?
2. Stichprobe: Repräsentative Auswahl (Startseite, Kontaktseite, Formulare, kritische User Journeys).
3. Audit: Prüfung jedes Erfolgskriteriums per Kombination aus automatisierten und manuellen Tests.
4. Bericht: Dokumentation der Ergebnisse nach Erfolgskriterium, Seite und Konformitätsstufe.

WCAG-EM ist Grundlage für offizielle Prüfberichte, die für BITV 2.0 & EU-Accessibility-Richtlinie und Barrierefreiheitsstärkungsgesetz (BFSG) 2025 erforderlich sind.

Nutzertests mit betroffenen Personen

Trotz aller technischen Tools gilt: Ein Test mit einer Person, die täglich einen Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer verwendet, ist durch kein automatisiertes Werkzeug ersetzbar. Nutzertests decken auf:

• Ob die Sprach-Ausgabe einer Komponente verständlich und ausreichend ist.
• Ob die Navigation mit einem echten Screen Reader (mit Speed-Einstellungen, die normalen Nutzenden entsprechen) praktikabel ist.
• Ob kognitive Accessibility-Probleme existieren, die kein Tool erkennt.

Organisationen wie die Deutsche Hörfilm gGmbH, Deutsche Blindenstudienanstalt (blista) oder das Kompetenzzentrum Digitale Barrierefreiheit (KBB) bieten User-Testing mit Menschen mit Behinderungen an.

Beispiele

Automated CI/CD Testing mit axe-core + Cypress:

```javascript // cypress/integration/accessibility.spec.js import 'cypress-axe';

describe('Accessibility Tests', () => { it('Startseite hat keine kritischen WCAG-Fehler', () => { cy.visit('/'); cy.injectAxe(); cy.checkA11y(null, { runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa', 'wcag21aa'] } }); }); }); ```

In der Praxis

Empfohlener Testing-Workflow:

1. Entwicklungsphase (laufend): axe DevTools Browser-Extension beim Entwickeln.
2. Build-Prozess (automatisch): axe-core in CI/CD-Pipeline.
3. Sprint-Review: Manuelle Tastatur- und Screen-Reader-Tests für neue Features.
4. Release: WAVE-Scan der wichtigsten Seiten; Farbkontrast-Prüfung.
5. Quartalsprüfung: Vollständiger WCAG-EM-Audit der kritischen Seiten-Journeys.
6. Jährlich: Nutzertests mit betroffenen Personen.

Vergleich & Abgrenzung

Automatisierte Tests vs. manuelle Tests: Automatisierte Tests sind schnell und skalierbar, aber limitiert. Manuelle Tests sind zeitaufwendig, aber decken deutlich mehr Probleme auf. Beide sind notwendig.

axe vs. WAVE: Axe ist besser für Entwickler und CI/CD-Integration; WAVE ist besser für visuelle, kontextbezogene Überprüfung durch Designer. Beide in Kombination erhöhen die Abdeckung.

Häufige Fragen (FAQ)

Welcher Accessibility-Score in Lighthouse ist gut genug? Es gibt keine offizielle Mindestgrenze. Ein Score von 100 schließt manuelle Probleme nicht aus. Wichtiger als der Score ist das Beheben aller automatisch erkannten Fehler + manuelle Tests.

Wie oft sollte Accessibility Testing durchgeführt werden? Kontinuierlich im Entwicklungsprozess (CI/CD), nicht als einmaliges Audit. Jede inhaltliche oder Code-Änderung kann neue Barrieren einführen.

Verwandte Einträge

• WCAG – Web Content Accessibility Guidelines im Überblick
• Accessibility – Grundlagen digitaler Barrierefreiheit
• Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer
• Tastaturnavigation & Fokus-Management
• Farbkontrast & Accessibility – AA vs. AAA-Standards
• ARIA-Labels – Zugängliche Rich Internet Applications
• BITV 2.0 & EU-Accessibility-Richtlinie
• Barrierefreiheitsstärkungsgesetz (BFSG) 2025

Weiterführend

• Deque Systems: axe-core: Accessibility Testing Engine. 2024.
• WebAIM: WAVE Web Accessibility Evaluation Tool. 2024.
• Google Chrome: Lighthouse Accessibility Audits. 2024.
• W3C WAI: Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0. 2014.
• Deque Systems: Automated Accessibility Testing: Rule-Based Testing vs. AI-Powered Testing. Deque Blog, 2023.
• WebAIM: The WebAIM Million – Annual Accessibility Analysis of the Top 1,000,000 Home Pages. 2024.