Wie prüft man Barrierefreiheit?

Kurz gesagt

Eine Barrierefreiheitsprüfung heißt, Ihr Produkt so zu benutzen wie jemand mit einer Seh-, Hör-, Bewegungs- oder kognitiven Beeinträchtigung. Der Maßstab ist WCAG. In meinen Prüfungen ziele ich auf Stufe AA der WCAG 2.2.

Barrierefreiheitstest, Accessibility Audit und a11y-Audit sind verschiedene Namen für dieselbe Arbeit. „a11y“ ist eine Abkürzung des englischen Worts accessibility: Zwischen dem a am Anfang und dem y am Ende stehen 11 Buchstaben.

Barrierefreiheit verkaufe ich nicht als eigenes Produkt. Im UX Audit sind die Kernprüfungen der WCAG 2.2 schon enthalten. Was die Kriterien sagen, beschreibe ich im WCAG-Ratgeber. Diese Seite beschreibt den Test selbst, also wo und wie ich hinschaue.

• Ein automatischer Scan ist nur der Anfang. Den eigentlichen Test macht ein Mensch mit Tastatur, Screenreader und bei 320 Pixeln Breite.
• Jeder Befund ist an einen Screen, ein WCAG-Kriterium und eine Korrektur gebunden.

Wann Sie prüfen lassen sollten

Am günstigsten ist eine Prüfung, solange das Design noch in Figma liegt. Ein blasser Hilfetext oder ein Fehler, der nur über Farbe gezeigt wird, ist dort in Minuten behoben. Nach dem Release braucht dieselbe Korrektur eine Codeänderung und eine neue Version.

In diesen Fällen empfehle ich eine Prüfung:

• Bevor ein neues Produkt oder ein großes Redesign live geht.
• Wenn ein Nutzer schreibt, dass er eine Aufgabe mit Screenreader oder Tastatur nicht abschließen konnte.
• Wenn eine neue Komponente ins Designsystem kommt. Ein Fehler am Button wandert auf jeden Screen, auf dem der Button vorkommt.
• Wenn eine Behörde oder ein Kunde WCAG-Konformität von Ihnen verlangt. Was das BFSG dazu sagt, steht im WCAG-Ratgeber.

Wichtig ist auch, wer prüft. Das Team, das das Produkt jeden Tag nutzt, übersieht Barrieren leicht, weil es weiß, wie der Screen funktionieren soll. Jemand von außen merkt beim ersten Versuch, dass sich das Menü nicht mit der Tastatur öffnen lässt.

Die WAI spricht auch von Fachleuten, die aus erster Hand wissen, wie Menschen mit unterschiedlichen Behinderungen das Web nutzen. Diese Fachleute können auch Probleme beurteilen, die einzelne Nutzer nicht finden würden.

In der Prüfung mache ich meine eigenen Kontrollen. Wo es geht, empfehle ich dem Team zusätzlich eine kurze Testrunde mit echten Nutzern.

Sehen Sie die Prüfung nicht als Zeremonie einmal im Jahr. Den Hauptablauf bei jedem großen Release einmal mit der Tastatur durchzugehen, verhindert, dass sich Fehler stapeln.

Automatisch und von Hand testen: der Unterschied

Automatische Tools sind schnell, haben aber nicht das letzte Wort. Die Web Accessibility Initiative (WAI) des W3C schreibt es deutlich: Evaluierungstools können Barrierefreiheit nicht feststellen, sie können nur dabei helfen.

Laut dem WAI-Leitfaden zur Auswahl von Tools lassen sich manche Prüfungen nicht automatisieren und brauchen menschliches Urteil. Derselbe Leitfaden sagt, dass Tools manchmal falsche oder irreführende Ergebnisse liefern. Null Fehler im Toolbericht heißt deshalb nicht, dass die Website barrierefrei ist.

Der Alternativtext zeigt das gut. Laut der WAI-Seite Easy Checks kann ein automatischer Test sagen, ob das Attribut alt fehlt. Ob der Text passt, entscheidet jemand, der das Bild im Zusammenhang sieht.

Die Tabelle unten habe ich aus meiner Praxis geschrieben:

Prüfung	Was das Tool tut	Was der Mensch tut
Alternativtext	Schaut, ob das Attribut alt fehlt.	Entscheidet, ob der Text die Aufgabe des Bilds beschreibt.
Formularlabel	Findet Felder ohne Label.	Liest, ob das Label sagt, was das Feld will.
Kontrast	Misst das Verhältnis bei Text auf einfarbigem Grund.	Misst Text auf Fotos oder Verläufen von Hand.
Fokus	Bleibt meist stumm.	Sieht beim Durchgehen mit Tab, ob der Ring sichtbar und die Reihenfolge logisch ist.

Auch ein Nutzertest reicht allein nicht. Laut der WAI-Seite zur Einbeziehung von Nutzern deckt ein Test mit Nutzern mit Behinderungen Usability-Probleme auf, die eine Konformitätsprüfung allein nicht findet. Dieselbe Seite fügt hinzu, dass auch ein Nutzertest allein nicht feststellen kann, ob eine Website barrierefrei ist.

Eine gute Prüfung verbindet deshalb beide Methoden.

Meine Reihenfolge

Den automatischen Scan lasse ich nach der ersten Runde von Hand laufen. Zuerst gehe ich den Screen wie ein Nutzer durch und notiere, wo ich hängen bleibe. So lenkt mich die Liste des Tools nicht von Anfang an ab.

Nach dem Scan lege ich beide Listen nebeneinander. Hat das Tool etwas gefunden, das ich übersehen habe, gehe ich zu diesem Screen zurück. Wertet das Tool etwas als Fehler, ich sehe auf dem Screen aber keine Barriere, öffne ich den Code und schaue selbst. In den Bericht kommen nur Befunde, die ich mit eigenen Augen bestätigt habe.

Die WAI-Seite zu Nutzern erinnert an noch etwas. Ein Nutzer mit Behinderung weiß nicht unbedingt, wie andere Menschen mit derselben Behinderung das Web nutzen. Deshalb lese ich auch den Kommentar eines einzelnen Nutzers nicht als allgemeine Regel.

Die Prüfung Schritt für Schritt

Ich beginne eine Prüfung mit einem Umfang: welche Abläufe und welche WCAG-Stufe ich anschaue. Auch in WCAG-EM, der Evaluierungsmethode des W3C, ist der erste Schritt, den Umfang festzulegen. Dann gehe ich auf jedem gewählten Screen in dieser Reihenfolge vor.

Zu jedem Schritt habe ich das passende Kriterium der WCAG 2.2 geschrieben. Die vollständige Liste steht im WCAG-Ratgeber.

1. Tastatur (2.1.1, A)

Legen Sie die Maus weg und versuchen Sie, den Hauptablauf nur mit Tab, Umschalt+Tab, Enter, Leertaste und Pfeiltasten abzuschließen. Laut WCAG 2.2 müssen alle Funktionen des Inhalts über eine Tastaturschnittstelle bedienbar sein. Ich achte besonders auf aufklappende Menüs, das X zum Schließen eines Fensters und Datumsauswahlen.

Die einzige Ausnahme sind Funktionen, die vom Weg der Nutzerbewegung abhängen, etwa freies Zeichnen. Wenn eine Karte in eine Liste gezogen wird, ist der Weg egal. Ziehen fällt deshalb nicht unter die Ausnahme und muss auch mit der Tastatur gehen.

2. Fokus (2.4.3, A; 2.4.7 und 2.4.11, AA)

Beim Navigieren mit der Tastatur stelle ich drei Fragen. Ist der Fokusring auf jedem Element sichtbar? Folgt der Fokus der Lesereihenfolge auf dem Screen? Verschwindet das fokussierte Element unter einem fixierten Header oder einem Cookie-Banner?

2.4.11 verlangt, dass das fokussierte Element nicht vollständig von Inhalten verdeckt wird, die die Autoren der Seite hinzugefügt haben. Als typisches Beispiel nennt das W3C fixierte Header und Footer. In der Demo unten können Sie die ersten zwei Fragen selbst ausprobieren.

3. Kontrast (1.4.3, AA)

Bei normalem Text muss das Kontrastverhältnis zwischen Text und Hintergrund mindestens 4,5:1 betragen, bei großem Text mindestens 3:1. Laut WCAG ist großer Text mindestens 18 Punkt oder 14 Punkt fett. Nach der Rechnung des W3C entspricht das etwa 24 und 18,5 Pixeln.

Ich messe Fließtext, Hilfetext, Platzhalter, Buttontext und Fehlermeldung einzeln. Das Verhältnis zweier Farben finden Sie im Kontrastrechner.

4. Alternativtext (1.1.1, A)

Jedes Bild, das eine Information trägt, braucht eine Textalternative mit demselben Zweck. Der Alternativtext eines Produktfotos beschreibt das Produkt, zum Beispiel „Dunkelblaues Leinenhemd, langärmlig“. Das Wort „Bild“ oder der Dateiname leisten das nicht.

Für dekorative Bilder gilt die umgekehrte Regel. Das W3C verlangt, dass sie so ausgezeichnet werden, dass assistive Technologien sie ignorieren können. Die HTML-Technik des W3C nutzt dafür einen leeren Alternativtext, also alt="".

5. Überschriften (1.3.1, A)

Alles, was auf dem Screen wie eine Überschrift aussieht, muss auch im Code eine Überschrift sein, also ein Element von h1 bis h6. Easy Checks schaut auch, ob die Hierarchie der Überschriften sinnvoll ist.

Im Screenreader gehe ich die Seite einmal von Überschrift zu Überschrift durch. Ein fett gesetzter Absatz ist in dieser Runde gar nicht zu hören. Dann ziehe ich die Liste der Überschriften heraus und schaue, ob sie für sich allein lesbar ist.

6. Formularlabels (3.3.2, A)

Überall, wo Angaben verlangt werden, braucht es ein Label oder eine Anweisung. Laut W3C wird ein Label allen angezeigt, ein zugänglicher Name kann dagegen nur für assistive Technologien sichtbar sein. Ein Feld, das nur über aria-label einen Namen hat, erfüllt das Kriterium also nicht, wenn das Label nicht allen gezeigt wird.

Meine Einschätzung: Felder, die nur mit Platzhaltertext beschriftet sind, sind riskant. Sobald der Nutzer tippt, verschwindet der Text, und was das Feld will, ist weg vom Screen. Setzen Sie das Label dauerhaft über das Feld.

7. Screenreader

Ich schalte auf Mac und iPhone VoiceOver ein, auf Android TalkBack, und versuche, den Hauptablauf abzuschließen, ohne auf den Screen zu schauen. Vor jedem Kriterium stelle ich hier eine Frage: Beschreibt das, was ich höre, dieselbe Aufgabe wie das, was ich sehe?

Am häufigsten finde ich Icon-Buttons ohne Namen und Statusmeldungen, die stumm bleiben. Ein X, das nur als „Schalter“ vorgelesen wird, sagt nicht, was es schließt. Erscheint „In den Warenkorb gelegt“ auf dem Screen, ist aber nicht zu hören, weiß der Nutzer nicht, ob es geklappt hat.

8. Umbruch und Zoom (1.4.10, AA)

Inhalte müssen bei 320 CSS-Pixeln Breite nutzbar sein, ohne in zwei Richtungen scrollen zu müssen. Laut Hinweis des W3C entspricht das einem Fenster mit 1280 Pixeln Breite bei 400 % Zoom.

Ich teste das auf zwei Wegen. Im Desktopbrowser zoome ich die Seite auf 400 %, dann setze ich in den Entwicklertools die Breite auf 320 Pixel. Erscheint eine horizontale Scrollleiste oder läuft ein Button aus dem Screen, notiere ich das.

9. Bewegung und Blitzen (2.2.2 und 2.3.1, A)

Bewegung, die von selbst startet, neben anderem Inhalt erscheint und länger als fünf Sekunden dauert, muss sich anhalten lassen. Ein Laufband mit Aktionen oder ein automatischer Slider sind Beispiele.

Außerdem darf nichts öfter als dreimal pro Sekunde blitzen. Die einzige Ausnahme im Kriterium: Das Blitzen bleibt unter den Schwellen, die das W3C definiert. Aus meiner Praxis kommt eine Prüfung dazu: Ich schalte im Betriebssystem die Einstellung für reduzierte Bewegung ein und schaue, ob die Seite sie beachtet.

Was diese neun Schritte nicht abdecken

Diese Liste ist eine erste Runde. Ein vollständiger Konformitätstest verlangt mehr. Die WAI warnt bei Easy Checks genauso: Eine Seite kann diese Prüfungen scheinbar bestehen und trotzdem ernste Barrieren haben.

Hat Ihr Produkt Videos, brauchen Untertitel, Transkript und Audiodeskription eine eigene Runde. Auch ein eindeutiger, beschreibender Seitentitel auf jeder Seite gehört zu den Prüfungen in Easy Checks. Auf welchen Screens ich darauf schaue, schreibe ich vorher in das Dokument zum Umfang.

Ausprobieren: mit der Tab-Taste navigieren

Im kleinen Formular unten stecken zwei Fehler. Drücken Sie Test starten und gehen Sie mit der Tab-Taste bis zum Ende des Formulars. Der gelbe Kasten sagt Ihnen bei jedem Element, welches Kriterium erfüllt oder verletzt ist.

Wechseln Sie dann zu Korrigiert und machen Sie dieselbe Runde. Auf dem Screen scheint sich nichts zu ändern, aber mit der Tastatur ist der Unterschied sofort klar.

Mit der Tab-Taste navigieren

Beispiel: Terminanfrage bei einer Zahnarztpraxis

Vor- und Nachname

E-Mail

Telefon

Ich möchte einen Tag vor dem Termin erinnert werden

Termin anfragen

Weil JavaScript aus ist, steht das Formular im korrigierten Zustand. Die zwei Fehler sind unter der Demo beschrieben.

Das Beispielformular sendet nichts. Im fehlerhaften Zustand sind zwei Fehler absichtlich drin: Die Felder Telefon und E-Mail stehen im Code in umgekehrter Reihenfolge, und der Fokusring des Buttons wurde entfernt. Ohne Tastatur drücken Sie Tab-Reihenfolge zeigen, dann sehen Sie die Reihenfolge als Zahlen.

Fehler 1: Fokus-Reihenfolge falsch (2.4.3, A)

Auf dem Screen steht E-Mail über Telefon. Im Code kommt aber Telefon zuerst, und das CSS vertauscht die beiden. Weil die Tab-Taste dem Code folgt, springt der Fokus nach unten und wieder zurück. Korrektur: Bringen Sie die Reihenfolge im Code in die sichtbare Reihenfolge, statt sie mit CSS zu bauen.

Fehler 2: kein Fokusring (2.4.7, AA)

Die Fokuslinie des Browsers am Button wurde entfernt und durch nichts ersetzt. Wer mit der Tastatur arbeitet, sieht nicht, dass er beim Button angekommen ist. Korrektur: Definieren Sie für :focus-visible einen kräftigen, kontrastreichen Rahmen.

Dass ich diese beiden Fehler so oft sehe, hat einen Grund: Wer mit der Maus schaut, sieht keinen von beiden. In der Designabnahme sieht der Screen richtig aus, der Fehler zeigt sich erst, wenn jemand mit der Tastatur navigiert.

Der Bericht

Der letzte Schritt in WCAG-EM ist, die Befunde zu sammeln und zu berichten. Mein Bericht ist weniger eine Konformitätsnote als eine Aufgabenliste. Öffnet das Team ihn, soll es sehen, mit welchem Punkt es heute anfängt.

Bei jedem Befund steht:

• Auf welchem Screen oder in welchem Schritt des Ablaufs er auftritt.
• Was passiert, in einem Satz aus Sicht des Nutzers.
• Nummer und Stufe des Kriteriums der WCAG 2.2.
• Wen er betrifft und wie ich getestet habe.
• Eine Empfehlung zur Korrektur und der Schweregrad.

Der Beispielbefund stammt nicht aus einem echten Kundenauftrag, er ist aus der Demo oben geschrieben.

Die Skala von 0 bis 4, die ich für den Schweregrad nutze, beschreibe ich im Ratgeber zum UX-Audit. Bei Befunden zur Barrierefreiheit habe ich eine Regel: Alles, was den Nutzer daran hindert, seine Aufgabe abzuschließen, kommt ganz nach oben.

Für wen der Bericht ist

Design, Entwicklung und Produktmanagement lesen den Bericht mit unterschiedlichen Zielen. Deshalb kennzeichne ich jeden Befund nach dem Ort, an dem er behoben wird. Kontrast und Labeltext werden in der Designdatei behoben, Fokus-Reihenfolge und Namen für den Screenreader im Code.

An den Anfang des Berichts schreibe ich eine kurze Einleitung für das Produktmanagement. Dort steht, wie viele Befunde es gibt und welche eine Aufgabe ganz blockieren. Die Nummern der Kriterien stehen dort, wo die Entwicklung sie sucht: im Befund selbst.

Mit der Übergabe ist die Arbeit nicht vorbei. Wenn die Korrekturen live sind, wiederhole ich dieselben Schritte auf denselben Screens. Erst dann nehme ich einen erledigten Punkt von der Liste.

Meine Notiz

Ich sehe Barrierefreiheit als Teil der Usability. Deshalb habe ich daraus kein eigenes Paket gemacht. Wenn ich einen Ablauf prüfe, schaue ich in derselben Runde auf Tastatur und Kontrast.

Am häufigsten irren sich Teams beim grünen Haken im Bericht des automatischen Scans. Der Bericht ist sauber, und alle sind beruhigt. Dann drückt jemand die Tab-Taste und kommt nie beim Zahlungsbutton an.

Wenn Sie es selbst versuchen wollen, fangen Sie mit den ersten zwei der neun Schritte an: Tastatur und Fokus. Eine Runde von einer Stunde bringt die sichtbarsten Barrieren ans Licht. Den Rest mache ich auf Wunsch im UX Audit auf Ihren Screens.