Website auf Barrierefreiheit testen
Welche Ebenen ein belastbarer Barrierefreiheits-Test kombinieren muss - von automatischen Tools über die Tastatur- und Screenreader-Prüfung bis zur manuellen Inhaltsbewertung - und warum ein perfekter Lighthouse-Score kein Nachweis für Barrierefreiheit ist.
Ein Lighthouse- oder Accessibility-Score von 100 fühlt sich wie ein Nachweis vollständiger Barrierefreiheit an - ist es aber nicht. Automatische Tools erkennen zuverlässig einen Teil der Probleme, aber laut Schätzungen aus der Praxis der WCAG-Prüfung typischerweise nur etwa ein Fünftel bis ein Drittel aller relevanten Kriterien überhaupt automatisiert prüfbar ist - der Rest erfordert eine Kombination aus Tastatur-, Screenreader- und manueller Prüfung. Ein belastbarer Test einer Website kombiniert deshalb mehrere Ebenen, nicht nur eine.
1. Automatische Prüfung
Werkzeuge wie Googles Lighthouse (in den Chrome-DevTools integriert), axe DevTools oder WAVE scannen den gerenderten HTML-Code und erkennen zuverlässig strukturelle Probleme: fehlende alt-Attribute, fehlerhafte oder doppelte IDs, unzureichende Farbkontraste, fehlende Formularbeschriftungen, ungültige ARIA-Attribute. Diese Prüfung ist schnell, kostenlos und ein sinnvoller erster Schritt - sie sagt aber nichts darüber aus, ob ein vorhandener Alternativtext inhaltlich sinnvoll ist oder ob eine Seite sich tatsächlich per Tastatur bedienen lässt.
2. Tastaturtest
Die Maus beiseitelegen und die komplette Seite ausschließlich mit Tab, Umschalt+Tab, Enter, Leertaste, Escape und den Pfeiltasten bedienen. Dabei prüfen:
- Sind alle interaktiven Elemente per Tab erreichbar?
- Ist der Fokus an jeder Stelle sichtbar erkennbar?
- Folgt die Fokusreihenfolge der visuellen und inhaltlichen Anordnung?
- Lässt sich jedes Element mit der erwarteten Taste bedienen (Buttons mit Enter/Leertaste, Links mit Enter)?
- Gibt es Stellen, an denen der Fokus hängen bleibt - eine Tastaturfalle?
- Lässt sich ein zentraler Nutzerpfad (Formular, Warenkorb, Checkout) vollständig per Tastatur durchführen?
Dieser Test ist ohne zusätzliche Software durchführbar und deckt in der Praxis überproportional viele echte Probleme auf, weil er genau die Interaktionsebene prüft, die automatische Tools kaum bewerten können.
3. Screenreader-Test
Bei zentralen Nutzerpfaden zusätzlich mit einem echten Screenreader prüfen - unter Windows etwa NVDA (kostenlos) oder den in Windows integrierten Narrator, unter macOS/iOS VoiceOver, unter Android TalkBack. Wichtige Fragen dabei:
- Wird jedes interaktive Element mit einem sinnvollen Namen angekündigt?
- Ist die Überschriftenstruktur nachvollziehbar, wenn man ausschließlich per Überschriften-Navigation durch die Seite springt?
- Werden Formularfehler beim Auftreten tatsächlich vorgelesen, nicht nur visuell angezeigt?
- Ist erkennbar, in welchem Zustand sich ein dynamisches Element (aufgeklapptes Menü, geöffneter Dialog) gerade befindet?
Kein einzelner Screenreader repräsentiert alle Nutzer - Kombinationen aus Screenreader und Browser verhalten sich teils unterschiedlich -, aber schon ein einziger gründlicher Durchlauf deckt typischerweise Probleme auf, die weder automatische Tools noch der reine Tastaturtest zeigen.
4. Zoom- und Viewport-Test
Die Seite auf 200 % Browser-Zoom vergrößern und prüfen, ob Inhalte weiterhin lesbar bleiben, ohne horizontal scrollen zu müssen, und ob nichts abgeschnitten oder überlappend dargestellt wird. Ergänzend die Seite in einem schmalen Viewport (etwa 320 Pixel Breite) testen - beides deckt Probleme auf, die bei Standard-Desktopansicht unsichtbar bleiben.
5. Manuelle Inhaltsprüfung
Manche Kriterien lassen sich grundsätzlich nicht automatisiert bewerten:
- Ist ein Alternativtext inhaltlich zutreffend und nicht nur formal vorhanden (“Bild123.jpg” vs. eine sinnvolle Beschreibung)?
- Ist eine Überschrift tatsächlich als Gliederungspunkt gemeint, oder nur optisch groß formatiert?
- Ist eine Fehlermeldung verständlich formuliert, oder nur technisch korrekt zugeordnet?
- Ist ein Formular auch ohne visuelle Hinweise (Icons, Farbe) nachvollziehbar aufgebaut?
6. Priorisierung der Befunde
Nicht jeder gefundene Verstoß hat dieselbe Dringlichkeit. In der Praxis bewährt sich eine grobe Priorisierung danach, ob ein Problem einen zentralen Nutzerpfad vollständig blockiert (etwa eine Tastaturfalle im Checkout - höchste Priorität), einen Pfad erschwert, aber nicht verhindert (etwa unklare Fehlermeldungen), oder eine reine Qualitätsverbesserung ohne Blockade darstellt (etwa ein optimierbarer, aber vorhandener Alternativtext).
Fazit
Ein Testverfahren, das sich allein auf ein automatisches Tool verlässt, prüft nur einen Bruchteil dessen, was tatsächlich über Zugänglichkeit entscheidet - und ist damit weder ein verlässlicher Gradmesser für Nutzerfreundlichkeit noch ein tragfähiger Nachweis für BFSG-Konformität. Wer regelmäßig neue Funktionen ausliefert, kommt um eine wiederkehrende Kombination aus automatischer, Tastatur-, Screenreader- und manueller Prüfung nicht herum.