Die Gewährleistung der Barrierefreiheit deiner Website ist entscheidend, um allen Nutzern den Zugang zu digitalen Inhalten zu ermöglichen. In diesem Artikel erfährst du, wie du die Barrierefreiheit deiner Website und Webanwendungen testen kannst – von manuellen Tests mit Screenreadern bis hin zu automatisierten Tools wie pa11y, Lighthouse und WAVE. Entdecke bewährte Methoden und praktische Tipps, um sicherzustellen, dass deine digitalen Angebote für alle zugänglich sind. Ich zeige dir außerdem, wie du auch ohne kommerzielle Tools effektive Tests durchführen kannst.
Accessibility Testing: Wie du die Barrierefreiheit deiner Website und Webanwendungen testest
Barrierefreiheit ist kein Nice-to-have, sondern eine gesetzliche und ethische Verpflichtung. Doch wie testest du, ob deine Website oder Webanwendung wirklich für alle Nutzer:innen zugänglich ist? In diesem Artikel zeige ich dir verschiedene Methoden – von manuellen Tests bis hin zu automatisierten Tools – und erkläre, warum manuelle Tests unverzichtbar sind.
1. Manuelles Testen: Die Basis für echte Barrierefreiheit
Automatisierte Tools können viele technische Probleme aufdecken, aber sie ersetzen nicht die Perspektive echter Nutzer:innen. Hier sind einige bewährte und kreative Methoden für manuelle Tests:
Screenreader nutzen
Screenreader wie NVDA (Windows) oder VoiceOver (macOS/iOS) simulieren, wie blinde oder sehbehinderte Menschen deine Website erleben. Teste dabei:
- Lesereihenfolge: Wird der Inhalt logisch und verständlich vorgelesen?
- Alternativtexte: Sind Bilder und Grafiken mit aussagekräftigen
alt-Texten versehen? - Semantische Struktur: Werden Überschriften, Listen und Buttons korrekt erkannt?
Tipp: Nutze die Tastenkombinationen für NVDA, um dich effizient durch die Seite zu bewegen.
Simulationsbrillen und physische Einschränkungen
- Simulationsbrillen (z. B. für Grauer Star oder Farbfehlsichtigkeit) helfen, visuelle Barrieren nachzuvollziehen. Einfache Modelle sind sehr günstig online erhältlich. Ich habe selbst ein Set bei perspektrum.de gekauft.
Simulationsbrillen von perspektrum.de
- Tastaturbedienung: Teste, ob alle Funktionen nur mit der Tastatur (Tab, Enter, Pfeiltasten) nutzbar sind.
- Kreative Methoden: Probiere aus, wie gut deine Website bedienbar ist, wenn du Fäustlinge trägst oder nur eine Hand verwendest. So deckst du motorische Barrieren auf.
Kontrast und Lesbarkeit
- Nutze Tools wie den WebAIM Contrast Checker, um sicherzustellen, dass Texte auch bei schlechter Sicht lesbar sind.
2. Automatisiertes Testen mit pa11y
pa11y ist ein Open-Source-Tool, das Webseiten auf Barrierefreiheitsprobleme prüft – direkt in der Kommandozeile oder als Teil deiner CI-Pipeline. Was mir an pa11y besonders gefällt, ist dass es gleichzeitig sehr einfach zu bedienen und dennoch mächtig ist. Man darf sich nur nicht davor scheuen, ein bisschen mit der Kommandozeile zu arbeiten. Aber keine Sorge: Bereits mit wenigen einfachen Befehlen kannst du wertvolle Erkenntnisse gewinnen.
Installation
Voraussetzung für die Installation ist Node.js und npm (Node Package Manager).
Installiere pa11y global mit npm:
npm install -g pa11y
Einfaches Beispiel
Teste eine einzelne URL:
pa11y https://deine-website.com
pa11y gibt dir eine Liste von Problemen aus, sortiert nach Schweregrad (Error, Warning, Notice). Du kannst auch spezifische Standards (z. B. WCAG 2.1 AA) oder Reporter (z. B. JSON) angeben:
pa11y --standard WCAG2AA --reporter json https://deine-website.com > ergebnis.json
Mit > ergebnis.json speicherst du die Ergebnisse direkt in einer Datei.
Das tolle an den Ergebnissen von pa11y ist, dass sie sehr detailliert sind. Du bekommst nicht nur eine Liste der Probleme, sondern auch Hinweise zur Behebung. So kannst du gezielt an den Schwachstellen arbeiten. Es werden auch die genauen HTML-Selektoren angegeben, was die Fehlersuche erleichtert. So kannst du bspw. direkt im Code oder in den Entwicklungstools deines Browsers nach dem fehlerhaften Element suchen.
Hier ist ein einfaches Beispiel für die Ausgabe von pa11y. In diesem Fall wurde ein Kontrastproblem auf der Website der Wirtschaftskammer Tirol gefunden:
pa11y https://www.wko.at/tirol
Welcome to Pa11y
> Running Pa11y on URL https://www.wko.at/tirol
Results for URL: https://www.wko.at/tirol
• Error: This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 3:1, but text in this element has a contrast ratio of 1:1. Recommendation: change text colour to #949494.
├── WCAG2AA.Principle1.Guideline1_4.1_4_3.G145.Fail
├── #wkolatestnewscontainer > div > div > h2
└── <h2>Top Themen</h2>
1 Errors
Wie man anhand des Beispiels sieht, gibt pa11y nicht nur den Fehler an, sondern auch den genauen Ort im HTML-Code, wo das Problem auftritt. In diesem Fall schlägt pa11y vor, die Textfarbe des Elements Chrome DevTools: Element finden#wkolatestnewscontainer > div > div > h2 zu #949494 zu ändern, um den Kontrast zu verbessern. In den Entwicklungstools des Browsers kann man nun mit dem Befehl document.querySelector('#wkolatestnewscontainer > div > div > h2') direkt zu dem fehlerhaften Element navigieren und die Änderung testen.
3. Erweiterung: Skript für mehrere URLs
Mit einem einfachen Node.js-Skript kannst du mehrere URLs testen und die Ergebnisse in einer CSV- oder JSON-Datei speichern. Hier ein Beispiel:
const pa11y = require('pa11y');
const fs = require('fs');
async function testUrls(urls, outputFile) {
const results = [];
for (const url of urls) {
try {
const result = await pa11y(url);
results.push({ url, issues: result.issues });
} catch (error) {
console.error(`Fehler bei ${url}:`, error);
}
}
fs.writeFileSync(outputFile, JSON.stringify(results, null, 2));
console.log(`Ergebnisse gespeichert in ${outputFile}`);
}
// Beispielaufruf
const urls = [
'https://deine-website.com/seite1',
'https://deine-website.com/seite2'
];
testUrls(urls, 'accessibility-results.json');
Hinweis: Installiere vorher das pa11y-Paket lokal in deinem Projekt:
npm install pa11y
4. Weitere Tools: Lighthouse und WAVE
Lighthouse
Lighthouse ist in die Chrome DevTools integriert und prüft neben Barrierefreiheit auch Performance, SEO und Best Practices. So nutzt du es:
- Öffne die DevTools (F12), gehe zum Tab „Lighthouse“.
- Wähle „Accessibility“ und starte den Audit.
- Lighthouse zeigt dir eine bewertete Liste von Problemen und Optimierungsmöglichkeiten.
Vorteil: Schnell, kostenlos und direkt im Browser nutzbar. Nachteil: Erfasst nicht alle WCAG-Kriterien – manuelle Tests bleiben nötig. Hinweis: Auch für Lighthouse gibt es eine CLI-Version, die du in deine CI/CD-Pipeline integrieren kannst.
WAVE (WebAIM)
WAVE ist ein webbasiertes Tool, das Barrierefreiheitsprobleme direkt auf der Seite visualisiert. Du kannst es als:
- Online-Tool (einfach URL eingeben)
- Browser-Erweiterung (für Chrome, Firefox, Edge)
WAVE markiert Fehler wie fehlende Alt-Texte, Kontrastprobleme oder falsche ARIA-Attribute direkt im Seitenlayout. Besonders hilfreich für schnelle, visuelle Analysen.
Fazit: Manuelle Tests sind unverzichtbar
Automatisierte Tools wie pa11y, Lighthouse oder WAVE sind großartig, um technische Probleme zu finden. Aber: Sie decken nicht alle WCAG-Kriterien ab. Außerdem können automatisierte Tests nicht zwischen dekorativen Elementen und echten Inhalten bei Grafiken und Bildern unterscheiden. Dadurch läuft man Gefahr, Alt-Attribute zu setzen, wo sie gar nicht notwendig wären. Echte Barrierefreiheit erreichst du nur durch:
- Regelmäßige manuelle Tests mit Screenreadern und Simulationsbrillen. Lasse diese Tests idealerweise von Menschen mit Behinderungen oder von Expertinnen und Experten begleiten.
- Nutzer:innen-Feedback von Menschen mit Behinderungen. Wenn du die Möglichkeit hast, bitte Betroffene, deine Website zu testen und Feedback zu geben.
- Kombination aus automatisierten und manuellen Methoden. Regelmäßige automatisierte Tests helfen, technische Probleme frühzeitig zu erkennen, während manuelle Tests die Nutzererfahrung sicherstellen.
Kommerzielle Tools sind selten nötig – mit den hier vorgestellten Open-Source-Lösungen und etwas Kreativität kannst du bereits viel erreichen.