Mit dem Screenreader testen.

Der Screenreader-Test heißt, eine Seite durch Zuhören mit Hilfstechnologie zu prüfen — die eine Methode, die kein automatisches Werkzeug ersetzen kann.

In der Barrierefreiheitsprüfung gibt es eine Schwelle: den Punkt, an dem die automatischen Werkzeuge enden. Ein Werkzeug kann sagen, ob ein Alternativtext existiert; ob dieser Text das Bild richtig beschreibt, kann es nicht sagen. Es kann sagen, dass eine Überschrift ein h2 ist; ob diese Überschrift den Abschnitt darunter wirklich beschreibt, nicht. Die Antworten auf diese Fragen findet nur das Zuhören.

Der Screenreader-Test wird von den meisten Teams übersprungen, und der Grund ist psychologisch, nicht technisch: Beim ersten Versuch ist das Erlebnis fremd und erdrückend. Die Stimme ist schnell, die Kürzel sind unbekannt, die Seite wird unkenntlich. Dieses Gefühl ist normal und vergeht in wenigen Stunden. Danach bleibt Ihnen eine Prüffähigkeit, die kein anderes Werkzeug liefern kann.

Welcher Screenreader

Die Wahl des Screenreaders hängt von der geprüften Plattform und der Zielgruppe ab. Alle zu installieren ist unnötig; einen gut zu lernen ist mehr wert, als alle oberflächlich zu kennen.

1. NVDA — Windows, kostenlos und quelloffen. Einer der meistgenutzten am Desktop und der leichteste Einstieg zum Testen.
2. JAWS — Windows, kommerziell. In Unternehmensumgebungen verbreitet; kleine Teams meiden ihn wegen der Lizenzkosten.
3. VoiceOver — in macOS und iOS eingebaut. Keine Installation nötig; wer ein Apple-Gerät hat, kann sofort probieren.
4. TalkBack — in Android eingebaut. Das Gegenstück für den mobilen Webtest.
5. Narrator — in Windows eingebaut. Am leichtesten erreichbar, aber nicht so verbreitet wie die anderen.

Der praktische Rat: Beginnen Sie mit dem, was Sie haben. Auf dem Mac ist VoiceOver schon installiert und öffnet mit einem Kürzel; unter Windows ist NVDA kostenlos. Fürs Testen zählt nicht, welche Software Sie verwenden, sondern dass Sie die Seite hörend durchlaufen haben.

Eine Warnung: Screenreader verhalten sich unterschiedlich, und dieselbe Seite kann in verschiedenen Readern verschieden klingen. Dass es in einem funktioniert, heißt also nicht „funktioniert überall“. Aber dass es in einem BRICHT, ist fast immer ein echter Fehler — daher kommt der Wert des Tests.

Worauf hören: vier Touren

Einer strukturierten Tour zu folgen statt zufällig zu hören ist schneller und fängt mehr Fehler. Vier Touren legen den Großteil des Barrierefreiheitszustands einer Seite offen.

1. Die Überschriften-Tour — öffnen Sie die Überschriftenliste und hören Sie. Erzählt die Liste die Seite? Klingt sie wie ein Inhaltsverzeichnis oder durcheinander? Fehlen Überschriften, gibt es leere?
2. Die Landmarken-Tour — bewegen Sie sich zwischen den Landmarken. Werden Menü, Hauptinhalt und Footer getrennt erkannt? Gibt es unbenannte oder doppelte Bereiche?
3. Die Link-Tour — öffnen Sie die Linkliste. Sind die Linktexte ohne Kontext verständlich? Bei fünfmal „Mehr lesen“ ist unklar, was wohin führt.
4. Die Formular-Tour — füllen Sie das Formular vollständig aus und senden Sie es ab. Ist das Etikett jedes Feldes zu hören? Wird die Fehlermeldung angekündigt? Die Erfolgsmeldung?

Die Link-Tour ist besonders lehrreich, weil sie ein Problem zeigt, das ein sehender Nutzer nie bemerkt. „Mehr lesen“-Links ergeben im visuellen Kontext Sinn — man sieht, unter welchem Text sie stehen. In der Linkliste gibt es keinen Kontext, und fünf identische Zeilen bleiben. Die Lösung: den Linktext für sich allein aussagekräftig machen.

Die Formular-Tour bringt die meisten Fehler hervor. Unbeschriftete Felder, unangekündigte Fehler, stumme Erfolgsmeldungen und verlorener Fokus — alles taucht hier auf. Und das sind die teuersten Fehler der Website, denn das Formular ist meist der einzige Konversionspfad.

Das automatische Werkzeug sagt, dass der Alternativtext EXISTIERT; der Screenreader sagt, ob er NÜTZT.

Beim ersten Mal

Einige praktische Punkte erleichtern den ersten Versuch, und sie zu kennen verhindert das Aufgeben, das die meisten in den ersten fünf Minuten erreicht.

1. Senken Sie das Sprechtempo — die Standardgeschwindigkeit ist für erfahrene Nutzer eingestellt und für Anfänger unverständlich schnell.
2. Verwenden Sie Kopfhörer — über offene Lautsprecher mischen sich Seitenton und Reader-Stimme.
3. Versuchen Sie, den Bildschirm abzuschalten — die Augen zu schließen oder den Bildschirm zu verdunkeln verhindert, dass Sie vom Gesehenen ausgehen. Der Test wird so viel ehrlicher.
4. Notieren Sie die Kürzel — schreiben Sie die grundlegenden Navigationskürzel Ihres Readers auf Papier. Sie ändern sich zwischen Versionen; führen Sie Ihre eigene Liste statt auswendig zu lernen.
5. Lernen Sie vorher das Abschalten — das ist es, was beim ersten Versuch am meisten Panik auslöst.
6. Probieren Sie zuerst eine bekannt gute Website — hören Sie erst eine gut gebaute Website, lernen Sie, wie das Erlebnis klingen soll, und testen Sie dann die eigene.

Der letzte Punkt hilft am meisten. Ohne Referenzpunkt können Sie nicht unterscheiden, ob das Chaos, das Sie hören, ein Fehler Ihrer Website ist oder das normale Verhalten des Screenreaders. Eine gut gebaute Seite einmal zu hören lehrt diese Unterscheidung sofort.

Häufigkeit und Umfang

Der Screenreader-Test kann nicht bei jedem Deployment laufen — er braucht Zeit und lässt sich nicht automatisieren. Die richtige Frage ist deshalb nicht „wie oft“, sondern „was“: Welche Bildschirme müssen unbedingt gehört werden.

Die praktische Antwort: die Konversionspfade. Kontaktformular, Suche, Anmeldung, Bezahlung — die Bildschirme, auf denen der Nutzer etwas TUT. Sie sind die kritischsten und brechen am häufigsten. Eine fehlerhafte Informationsseite ärgert; ein fehlerhaftes Formular beendet das Geschäft.

Steht der Umfang, ergibt sich die Häufigkeit von selbst: immer wenn sich diese Bildschirme ändern. Wenn eine neue Komponente kommt, der Formularfluss umgebaut, das Ebenensystem geändert wird. In den Deployments dazwischen genügen automatische Tests und die manuelle Tastaturtour.

Und zu jedem gefundenen Fehler gehört eine Frage: Kann ich diesen Fehler an einen Test binden? Meist lautet die Antwort ja — eine nicht angekündigte Meldung lässt sich mit einem Test fangen, der die Existenz der Live-Region prüft. Der Screenreader-Test FINDET den Fehler; der Wächter verhindert seine Rückkehr.

Typische Fehler, die beim Hören gefangen werden

Es gibt eine Liste von Fehlern, die in Screenreader-Touren immer wieder auftauchen, und keiner davon erscheint in automatischen Prüfungen. Die Liste vorab zu kennen heißt zu wissen, wonach auf der ersten Tour zu jagen ist — und macht den Test deutlich effizienter.

1. Der stumme Button — ein Button mit Icon, aber ohne zugänglichen Namen. Der Screenreader sagt „Schalter“ und verstummt; was er tut, bleibt unbekannt.
2. Die sprechende Dekoration — ein dekoratives Bild, vorgelesen mit seinem Dateinamen. Passiert, wenn das Alternativ-Attribut vergessen wurde.
3. Der verlorene Fokus — der Fokus fällt beim Schließen einer Ebene an den Seitenanfang. Der Nutzer verliert seinen Ort und beginnt von vorn.
4. Die unangekündigte Änderung — das Formular wurde gesendet, die Meldung erschien auf dem Bildschirm, der Screenreader sagte nichts.
5. Der wiederholte Inhalt — dieselbe Information im Alternativtext und in der Überschrift daneben; der Nutzer hört denselben Satz zweimal.
6. Die sinnlose Reihenfolge — zwei visuell nebeneinanderstehende Informationen werden beim Hören voneinander losgelöst gelesen.
7. Der nicht verborgene verborgene Inhalt — visuell versteckte, aber nicht aus dem Barrierefreiheitsbaum entfernte Menüs; der Nutzer wandert zwischen unsichtbaren Links.

Der letzte Punkt ist besonders heimtückisch, weil der Fehler nur in einem Zustand auftritt: bei geschlossenem Menü. Wer mit der Maus testet, sieht ihn nie, automatische Werkzeuge fangen ihn meist nicht, und der Nutzer navigiert zwischen Elementen, die auf der Seite nicht existieren. Ein gutes Beispiel dafür, warum das Zuhören durch keine andere Methode zu ersetzen ist.

Was diese Fehler teilen: Alle bestehen die Frage „existiert es“ und scheitern an „stimmt es“. Der Button hat einen Text, aber einen sinnlosen; die Meldung steht auf der Seite, wird aber nicht angekündigt; das Menü ist versteckt, aber im Barrierefreiheitsbaum. Die automatische Prüfung misst die erste Hälfte, das Zuhören die zweite.