Website auf Barrierefreiheit testen: So geht’s

Wie teste ich eine Website auf Barrierefreiheit?

Ein Test hat drei Ebenen: einen automatischen Scan, eine manuelle Prüfung durch dich oder Fachleute und, für wichtige Abläufe, Rückmeldungen von Menschen mit Behinderungen. Keine Ebene ersetzt die anderen.

Lege vorher fest, woran du misst. Für die meisten Projekte ist WCAG 2.2 auf Stufe AA ein sinnvolles Ziel. Das W3C beschreibt mit WCAG-EM eine Methode in fünf Schritten: Umfang festlegen, die Website erkunden, eine repräsentative Stichprobe wählen, diese prüfen und die Ergebnisse berichten. Auch für kleine Teams ist diese Reihenfolge eine gute Orientierung. Der erste Durchgang muss nicht perfekt sein. Wichtiger ist, dass du ihn wiederholen kannst: gleiche Seiten, gleiche Abläufe, gleiche Notizen.

Welche Seiten solltest du prüfen?

Prüfe nicht hundert ähnliche Produktseiten, sondern jede Vorlage einmal. Zu einer guten Stichprobe gehören Startseite, Navigation, Suche, eine Inhaltsseite, eine Produkt- oder Leistungsseite, das Kontaktformular, Anmeldung, Warenkorb und Checkout sowie eine Fehlerseite.

Denke auch an Zustände: geöffnetes Menü, Formular mit Fehlermeldungen, Dialog, Cookie-Banner und Erfolgsmeldung. Wichtige PDF-Downloads gehören ebenfalls dazu, ebenso Bereiche hinter dem Login, die ein öffentlicher Scan nicht erreicht. Notiere für jede Seite, welche Aufgabe dort erledigt wird. So bewertest du später nicht nur einzelne Fehler, sondern ob der Ablauf als Ganzes funktioniert.

Was findet ein automatischer Test und was nicht?

Ein Scanner findet schnell technische Fehler: fehlende Alternativtexte, zu schwache Kontraste, Formularfelder ohne Namen oder fehlerhafte Überschriftenstrukturen. Er erkennt nicht, ob ein Alt-Text das Richtige beschreibt, ob die Fokusreihenfolge logisch ist oder ob eine Anleitung verständlich bleibt.

Der Accessonaut-Check nutzt axe-core, ordnet jeden Hinweis nach Wichtigkeit ein und erklärt, wie du das Problem behebst. Laut W3C kann kein automatisches Werkzeug allein feststellen, ob eine Website die Barrierefreiheitsstandards erfüllt. Deshalb ist ein Scan ein Ausgangspunkt für deine Arbeit, keine Zertifizierung. Nutze die Ergebnisse als Aufgabenliste mit konkreten Fundstellen.

Wie gehst du bei einem manuellen Test vor?

• Seitentitel: Prüfe im Browser-Tab, ob jede Seite einen eindeutigen, passenden Titel hat.
• Tastatur: Lege die Maus zur Seite und bediene Navigation, Dialoge und Formulare mit Tab, Umschalt+Tab, Enter und Escape. Der Fokus muss jederzeit sichtbar sein.
• Zoom: Vergrößere die Seite auf 200 Prozent und prüfe, ob Inhalte und Funktionen erreichbar bleiben.
• Kontrast: Miss Text- und Hintergrundfarben mit einem Kontrast-Werkzeug. Normaler Text braucht mindestens 4,5:1.
• Farbe: Prüfe, ob Informationen auch ohne Farbe erkennbar sind, etwa Pflichtfelder, Fehler oder Links im Fließtext.
• Überschriften: Prüfe, ob die Überschriften die Seite gliedern und in sinnvoller Hierarchie stehen.
• Formulare: Sende absichtlich fehlerhafte Angaben und prüfe, ob Fehler verständlich benannt werden.
• Bewegung und Medien: Prüfe, ob sich Karussells und Animationen anhalten lassen und Videos Untertitel haben.
• Mobil: Wiederhole die wichtigsten Schritte auf einem Smartphone, auch im Querformat.
• Sprache: Lies Anleitungen und Buttontexte laut. Verstehst du ohne Vorwissen, was als Nächstes passiert?

Wie testest du mit einem Screenreader?

Für einen ersten Test reichen kostenlose oder eingebaute Screenreader: NVDA unter Windows, VoiceOver auf Mac und iPhone, TalkBack auf Android. Plane etwas Einarbeitung ein, denn die Bedienung unterscheidet sich stark von der Maus. Teste mit einem Browser, für den der Screenreader gedacht ist, etwa VoiceOver mit Safari.

Höre dir an, ob Links, Buttons und Felder verständlich angekündigt werden. Springe über die Überschriftenliste durch die Seite und fülle ein Formular aus. Achte darauf, ob Fehlermeldungen und Statusänderungen wie „Artikel in den Warenkorb gelegt“ vorgelesen werden. Typische Befunde sind Buttons, die nur „Button“ heißen, Bilder, deren Dateiname vorgelesen wird, und Dialoge, die nicht als solche angekündigt werden. Eine ausführliche Anleitung findest du im Beitrag zum Screenreader-Test.

Warum solltest du Menschen mit Behinderungen einbeziehen?

Wer täglich mit Screenreader, Vergrößerung oder Sprachsteuerung arbeitet, bemerkt Hürden, die bei einem Kurztest untergehen. Dazu gehören umständliche Abläufe, unklare Begriffe oder eine Bedienung, die zwar funktioniert, aber viel zu lange dauert.

Beziehe solche Rückmeldungen vor allem bei zentralen Abläufen ein, etwa bei Bestellung, Buchung oder Anmeldung. Halte Beobachtungen fest, ohne sie vorschnell zu verallgemeinern: Eine Person spricht nicht für alle Menschen mit derselben Behinderung. Plane Zeit und eine faire Vergütung ein und bereite konkrete Aufgaben vor, etwa „Bestelle dieses Produkt in Größe M“.

In welcher Reihenfolge behebst du die Findings?

Ein unbedienbarer Button kann einen kompletten Ablauf blockieren. Ein fehlender Formularname erschwert die Eingabe mit einem Screenreader. Beginne mit solchen Hindernissen, danach mit Problemen auf vielen Seiten und zuletzt mit Einzelfällen.

Lies bei jedem Finding die Erklärung, die Fundstelle und den zugeordneten WCAG-Bezug. Liegt die Ursache in einer gemeinsamen Komponente wie Header oder Produktkarte, behebst du sie dort einmal für alle Seiten. Eine einfache Einteilung hilft: blockiert, erschwert oder störend. Halte zu jedem Punkt fest, wer ihn behebt und bis wann.

Wie dokumentierst du Ergebnisse und prüfst erneut?

Notiere den Befund, die betroffene URL, die Änderung und das Ergebnis der erneuten Prüfung. Prüfe nach größeren Veröffentlichungen dieselben Abläufe. Eine regelmäßige Prüfung macht Fortschritte und neue Probleme nachvollziehbar.

Lege feste Anlässe für eine neue Prüfung fest: eine neue Vorlage, ein neues Plugin, ein Theme-Update oder ein geänderter Checkout. Automatische Scans kannst du häufig wiederholen, um neue technische Fehler früh zu sehen. Die manuellen Tests der wichtigsten Abläufe wiederholst du nach größeren Änderungen.