Barrierefreie Website testen: Tools und Vorgehen

Automatisch vs. manuell: Was leisten die Tests?

Automatische Accessibility-Tests durchsuchen den DOM nach bekannten Mustern (fehlende Alt-Attribute, falsche ARIA-Rollen, ungenügender Farbkontrast). Sie sind schnell und reproduzierbar – finden aber nur 30–40 % aller WCAG-Fehler.[2]

Manuelle Tests hingegen prüfen, ob die Website tatsächlich bedienbar ist: Kann ich sie vollständig mit der Tastatur nutzen? Versteht ein Screenreader-Nutzer den Inhalt? Sind Fehlermeldungen in Formularen sinnvoll? Diese Fragen lässt sich kein Algorithmus allein beantworten.

Kostenlose Tools im Überblick

• axe DevTools (Browser-Extension für Chrome/Firefox) – der Industriestandard für automatische Scans mit sehr geringer Falsch-Positiv-Rate
• WAVE (wave.webaim.org oder Extension) – visuelles Feedback direkt auf der Seite, gut für Einsteiger
• Google Lighthouse (in Chrome DevTools integriert) – Accessibility-Score als Teil des allgemeinen Performance-Reports
• Colour Contrast Analyser (Desktop-App von TPGi) – prüft Farbkontraste nach WCAG 1.4.3
• HeadingsMap (Extension) – zeigt die Überschriftenstruktur der Seite als Übersicht
• NVDA (Windows, kostenlos) oder VoiceOver (macOS/iOS, eingebaut) – Screenreader für manuelle Tests

Schritt-für-Schritt: Erste Prüfung

Mit diesem Ablauf erhalten Sie in 1–2 Stunden einen soliden ersten Überblick:

1. Automatischen Scan durchführen ToolInstallieren Sie die axe DevTools-Extension, öffnen Sie die zu prüfende Seite und klicken Sie auf „Scan All of My Page“. Exportieren Sie den Bericht als CSV oder PDF.
2. Tastaturnavigation prüfen ManuellNavigieren Sie die gesamte Seite ausschließlich mit Tab, Shift+Tab, Enter und den Pfeiltasten. Erreichen Sie jeden Link und jede Schaltfläche? Ist der Fokus immer sichtbar?
3. Farbkontraste prüfen ToolNutzen Sie den Colour Contrast Analyser für Text auf Hintergrund. WCAG AA verlangt mindestens 4,5:1 für normalen Text und 3:1 für großen Text.
4. Überschriftenstruktur prüfen ToolPrüfen Sie mit HeadingsMap oder axe, ob die H1–H6-Hierarchie logisch und vollständig ist. Jede Seite sollte genau eine H1 haben.
5. Bildalt-Texte prüfen ManuellDeaktivieren Sie Bilder im Browser (Firefox: about:config → permissions.default.image=2) und prüfen Sie, ob der Kontext erhalten bleibt.
6. Ergebnis dokumentieren. Notieren Sie alle Befunde mit Seite, Kriterium (z. B. WCAG 1.4.3) und Priorität. Diese Liste ist die Grundlage für die Behebung und die Barrierefreiheitserklärung.

Was automatische Tools nicht finden

Folgende WCAG-Kriterien können automatische Tools nicht zuverlässig prüfen:

• Bedeutungsvolle Alt-Texte: Tools erkennen, ob ein Alt-Attribut vorhanden ist – aber nicht, ob der Text sinnvoll ist (z. B. „img_123.jpg“ vs. eine echte Beschreibung).
• Logische Lesereihenfolge: Die DOM-Reihenfolge kann von der visuellen abweichen und für Screenreader-Nutzer verwirrend sein.
• Formulare und Fehlermeldungen: Sind Fehlermeldungen verständlich und programmatisch mit dem Eingabefeld verknüpft?
• Gesten und Interaktionen: Touch-Gesten ohne Alternativbedienung, zeitbasierte Inhalte (Slider), Drag-and-Drop.
• Kognitive Barrierefreiheit: Verständlichkeit von Texten, konsistente Navigation, Hilfetexte.

Screenreader-Tests

Ein Screenreader-Test gibt den realistischsten Einblick in die Nutzungserfahrung blinder oder sehbehinderter Menschen. Empfohlene Kombinationen:[3]

• NVDA + Firefox (Windows, kostenlos) – deckt den größten Teil realer Nutzer ab
• JAWS + Chrome (Windows, kommerziell) – verbreiteter in Unternehmensumgebungen
• VoiceOver + Safari (macOS und iOS, eingebaut) – besonders wichtig für mobile Prüfung
• TalkBack + Chrome (Android, eingebaut) – für Android-Mobile-Prüfung

Beim Screenreader-Test navigieren Sie die Seite nur mit der Tastatur und der Screenreader-Ausgabe. Können Sie alle Inhalte verstehen, alle Funktionen nutzen und Formulare ausfüllen?

WCAG-Konformitätserklärung

Für eine rechtssichere WCAG-2.1-AA-Konformitätserklärung gehören zum Prüfungsnachweis:

• Vollständige Evaluation aller 50 WCAG-2.1-AA-Kriterien (kein automatischer Scan allein)
• Dokumentierter Testbericht mit Konformitätsstatus je Kriterium (Erfüllt / Nicht erfüllt / Nicht zutreffend)
• Angabe von Ausnahmen (z. B. nicht barrierefreie Drittanbieter-Inhalte)
• Datum der Prüfung und Angaben zu den verwendeten Test-Tools und Screenreadern
• Feedbackmechanismus für Nutzer (Kontaktmöglichkeit bei Problemen)

A Barrierefreiheit bei Velury WCAG-Audit und Zertifizierung Wir führen manuelle WCAG-2.1-AA-Audits durch und erstellen rechtssichere Konformitätserklärungen für Unternehmen.

Fazit

Der schnellste Einstieg gelingt mit axe DevTools oder WAVE – die Browser-Extensions sind kostenlos und liefern in Minuten erste Ergebnisse. Für eine vollständige Prüfung müssen jedoch manuelle Tests und Screenreader-Tests ergänzt werden. Automatische Tools sind ein gutes Monitoring-Werkzeug, kein Ersatz für echte Barrierefreiheitsprüfungen.

Häufige Fragen

Quellen

Alle Quellen abgerufen am 19.10.2026.

1. Understanding WCAG 2.1. W3C, 2018. w3.org
2. The WebAIM Million – Annual Accessibility Analysis of the Top 1,000,000 Home Pages. WebAIM, 2024. webaim.org
3. Screen Reader User Survey. WebAIM, 2024. webaim.org
4. Evaluating Web Accessibility Overview. W3C WAI. w3.org