Barrierefreiheit einer Website testen: praktische Prüfschritte

Warum ein grünes Prüftool nicht genügt

Automatisierte Werkzeuge sind ein guter Anfang: Sie finden beispielsweise fehlende Feldbezeichnungen oder bestimmte Kontrastprobleme. Sie können aber nicht zuverlässig beurteilen, ob ein Alternativtext die Funktion eines Bildes verständlich erklärt, ob ein Fehlerhinweis hilfreich ist oder ob eine Aufgabe mit einer Tastatur vollständig gelingt. Das W3C betont deshalb: Eine automatisierte Prüfung allein kann keine Barrierefreiheit bestätigen.

Für einen ersten Test brauchst du keine aufwendige Infrastruktur. Eine Tastatur, ein moderner Browser, die Zoomfunktion und ein klarer Arbeitsauftrag reichen, um reale Hindernisse zu entdecken. Für eine formale Konformitätsbewertung sind zusätzliche Fachkenntnis, geeignete Stichproben und die maßgebliche Standardfassung erforderlich. Dieser Artikel ist eine praktische Einstiegscheckliste, kein WCAG-Zertifikat.

Schritt 1: Die wichtigste Aufgabe ohne Maus durchlaufen

Lade die Seite neu und lege die Maus beiseite. Nutze Tab und Shift + Tab, um interaktive Elemente zu erreichen; betätige Buttons mit Enter oder Leertaste, je nach Element. Beginne mit einer realistischen Aufgabe, etwa einer Suche oder einem mehrstufigen Formular. Achte auf drei Fragen:

1. Ist jeder notwendige Schritt erreichbar – einschließlich Menüs, Dialogen und Fehlermeldungen?
2. Siehst du jederzeit, wo der Tastaturfokus gerade liegt?
3. Kommst du aus einem Dialog wieder heraus, ohne festzustecken?

Eine Fokusmarkierung ist nicht bloß ein optisches Detail. Ohne sie ist unklar, welche Aktion die nächste Taste auslöst. Wenn ein Menü geöffnet wird, prüfe, ob es mit der Tastatur nutzbar ist und ob Escape es wie erwartet schließen kann. Dokumentiere den genauen Schritt, an dem der Ablauf scheitert.

Schritt 2: Zoom, Text und kleine Bildschirme prüfen

Vergrößere den Browser schrittweise und wiederhole die Aufgabe. Werden Inhalte abgeschnitten, überlagern sich Labels oder bleibt der Absenden-Button außerhalb des sichtbaren Bereichs? Prüfe zusätzlich eine schmale Ansicht und größere Systemeinstellungen für Schrift. Eine Seite kann auf einem Screenshot „responsive“ aussehen und trotzdem unbenutzbar sein, wenn horizontales Scrollen und kleine Touch-Ziele zusammenkommen.

Kontrolliere nicht nur die Darstellung, sondern auch die Reihenfolge: Stehen Überschrift, Erklärung und Feld logisch hintereinander? Wird ein Hinweis auf dem Smartphone erst nach der Aktion angezeigt, auf die er sich bezieht? Notiere das beobachtete Verhalten, nicht nur „mobil kaputt“.

Schritt 3: Bilder und Formulare im Kontext verstehen

Ein dekoratives Bild braucht keinen langen Alternativtext. Ein Bild, das eine wichtige Information oder Aktion vermittelt, braucht einen passenden Text. Prüfe, ob ein Link mit einem Icon auch ohne Bild erkennbar ist und ob eine Fehlermeldung nicht nur durch Farbe vermittelt wird. Beim Formular sollten Labels dauerhaft dem richtigen Feld zugeordnet und Fehlermeldungen so formuliert sein, dass sie eine Korrektur erlauben.

Ein sinnvoller Praxistest: Sende das Formular mit einer absichtlich ungültigen fiktiven Eingabe ab. Bleiben die übrigen Felder erhalten? Erfährst du, welcher Eintrag falsch ist und was du ändern musst? Bei sensiblen Angaben verwendest du ausschließlich freigegebene Testdaten.

Schritt 4: Screenreader und Fachprüfung sinnvoll ergänzen

Ein Screenreader-Test kann zeigen, wie Überschriften, Listen, Buttons und Statusmeldungen vorgelesen werden. Wer mit dem Werkzeug noch nicht vertraut ist, sollte einzelne Beobachtungen nicht als vollständiges Urteil über die Nutzung durch blinde Menschen ausgeben. Für wichtige Prozesse sind Menschen mit unterschiedlichen Nutzungsweisen und erfahrene Accessibility-Prüfer besonders wertvoll.

Die WCAG 2.2 ordnen Anforderungen unter vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Eine saubere Prüfung vergleicht konkrete Beobachtungen mit passenden Erfolgskriterien. Behaupte keine vollständige Erfüllung anhand einer einzelnen automatischen Messung.

Befunde verständlich weitergeben

Ein Bericht sollte Aufgabe, Umgebung, Schritte, tatsächliches Verhalten und Auswirkung enthalten. Beispiel: „Bei 200 % Zoom und schmalem Fenster verdeckt das geöffnete Menü das Suchfeld. Mit Tab ist die Suche erreichbar, aber die Fokusmarkierung liegt außerhalb des sichtbaren Bereichs.“ Damit lässt sich eine Korrektur gezielt prüfen. Die Vorlage für reproduzierbare Fehlerberichte hilft dabei.

Bei Pruviso gehören solche Prüfungen zu Website- und SaaS-Tests. Für Unternehmen erklärt die Usability-Test-Anleitung, wie aus Beobachtungen ein geordneter Verbesserungsprozess wird.

Verlässliche Grundlagen

• W3C WAI: Easy Checks – eine erste manuelle Sichtung von Titel, Struktur, Fokus und Kontrast.
• W3C WAI: Evaluation von Barrierefreiheit – Möglichkeiten und Grenzen von Werkzeugen.
• W3C: WCAG 2.2 – die technischen Erfolgskriterien im Original.

Zwei weitere kurze Checks: Kontrast und Bewegung

Informationen dürfen nicht ausschließlich durch Farbe vermittelt werden. Ein Pflichtfeld sollte beispielsweise zusätzlich beschriftet oder mit einem verständlichen Hinweis markiert sein. Bei Diagrammen, Statusanzeigen und Links lohnt die Frage: Würde die Aussage auch dann verständlich bleiben, wenn die Farben nicht unterschieden werden können? Ein Kontrastwerkzeug kann Verdachtsfälle finden, die Entscheidung über die Bedeutung trifft aber weiterhin der Kontext.

Prüfe außerdem Bewegungen und automatische Aktualisierungen. Ein Karussell, das selbstständig weiterspringt, kann Inhalte schwer lesbar machen. Eine Statusmeldung, die nur kurz erscheint, kann bei langsamer Nutzung übersehen werden. Für jede animierte oder dynamisch nachgeladene Information sollte es einen Weg geben, sie in Ruhe zu erfassen oder die Bewegung zu pausieren. Nutzer mit Konzentrations- oder motorischen Einschränkungen profitieren davon; viele andere ebenfalls.

Eine manuelle Prüfung sinnvoll organisieren

Arbeite nicht nur von oben nach unten durch die Startseite. Nimm drei bis fünf wichtige Aufgaben und prüfe jeweils mehrere Zugangswege: Maus, Tastatur, Zoom und – soweit möglich – eine unterstützende Technologie. Dokumentiere pro Aufgabe den Startzustand und die Stelle, an der der Weg anders als erwartet verläuft. So entsteht ein prüfbarer Umfang.

Eine gute interne Übersicht enthält mindestens:

Prüffeld	Was dokumentiert wird
Tastatur	erreichbare Elemente, Fokusreihenfolge und Ausstieg aus Dialogen
Struktur	Überschriften, Labels und verständliche Reihenfolge
Anpassung	Zoom, größere Schrift, schmale Ansicht und Überlagerungen
Fehlermeldung	betroffene Eingabe, Erklärung und Korrekturmöglichkeit
Dynamik	Statusänderungen, Fokusbewegung und pausierbare Animation

Diese Liste ersetzt keine vollständige WCAG-Evaluation. Sie liefert aber konkrete Ansatzpunkte, die ein Team nach einer Änderung erneut prüfen kann. Ein Befund sollte wie bei jedem anderen digitalen Test mit Schritten und erwartetem Ergebnis dokumentiert werden.

Menschen mit unterschiedlichen Bedürfnissen einbeziehen

Technische Checks beantworten technische Fragen. Sie sagen nicht zuverlässig voraus, ob ein Prozess für alle Menschen verständlich oder im Alltag praktikabel ist. Wenn ein Angebot viele Personen erreichen soll, sollten Nutzer mit unterschiedlichen Geräten, Einstellungen und Assistenztechnologien früh beteiligt werden. Dabei ist es fair, die Erfahrung der Teilnehmenden zu vergüten und ihre Daten nur für den vereinbarten Zweck zu verwenden.

Bei Pruviso kann Barrierefreiheit Teil eines klar begrenzten Website- oder SaaS-Tests sein. Unternehmen sollten vorab festlegen, ob sie einen ersten manuellen Check, einen moderierten Nutzertest oder eine formale Konformitätsprüfung benötigen. Diese drei Ziele sind verwandt, aber nicht austauschbar.