Warum Sie als Sehender nicht mit Screenreadern testen sollten

Stilisierte Radiowellen stralen nach links und rechtsIn diversen Anleitungen sehe ich wie nebenbei, dass der Screenreader NVDA für Tester:Innen empfohlen wird. Es ist aber eher zweifelhaft, dass ein Sehender einen Screenreader flüssig zu bedienen lernt, vor allem nicht nebenbei. Die einziegen Leute, denen ich das zutraue sind Trainer:Innen für Screenreader-Nutzende. Und selbst die würden häufig den ultimativen Test nicht bestehen: Schalten Sie den Bildschirm ab und bedienen Sie Ihren Computer komplett blind.
Es spricht leider für die Arroganz vieler Sehender, dass sie ihre diesbezüglichen Fähigkeiten überschätzen. Trotz Sehrest käme ich nie auf die Idee, ich könnte die Usability oder Ästhetik einer grafischen Benutzeroberfläche beurteilen. Aber viele Sehende glauben, weil sie NVDA installieren oder VoiceOver starten können, sie könnten die Benutzbarkeit einer Anwendung für Blinde beurteilen.

Den Screenreader-Output verstehen

Der Output eines Screenreaders lässt sich in zwei Bereiche einteilen. Da ist zum Einen die Ausgabe von sichtbarem Text. Zum Anderen gibt es aber auch etwas, was man als Meta-Daten bezeichnen kann. Das Wort „Neu“ zum Beispiel bringt ohne Meta-Kontext nichts. Ist das ein Text, ein Button, ein Element mit einem Untermenü, ein Radiobutton? Ist es fokussiert oder nicht, ist es aktiviert, aktivierbar oder nicht aktivierbar? Diese Informationen werden dem Blinden im besten Fall alle zusätzlich zum Wort „Neu“ vorgelesen.
Geübte Blinde nehmen diese Information mehr oder weniger nebenbei wahr. Es ist vergleichbar mit der Art, in der Sehende visuelle Komponenten einer Benutzeroberfläche wahrnehmen. Sie erkennen die Art eines Elements an deren visueller Gestaltung, ihren Status und ob sie aktivierbar ist oder nicht. Ist die Oberfläche gut gestaltet, müssen Sie darüber nicht nachdenken.
Da einem Blinden die visuelle Gestaltung unzugänglich bleibt, ist er darauf angewiesen, dass ihm diese Information zusätzlich kommuniziert wird.
Nun macht es selten Sinn, das ausführlich zu beschreiben. Wir müssen mit einem gewissem Maß an Grundrauschen klar kommen, aber ab einem bestimmten Level ist es schwierig, dies auszublenden. Man braucht also eine möglichst kurze und kompakte Zusammenfassung.
Die Sprachausgabe bzw. der Braille-Output ist abstrakt und zwar sowohl für Sehende als auch für frisch Erblindete bzw. Blinde ohne große Screenreader-Erfahrung.

Sehende sehen, was Blinde nicht wahrnehmen

Sehende sind selten konsequent oder geduldig genug, eine Anwendung per Tastatur zu erkunden. Zudem können sie ihren Instinkt, doch hinzusehen nicht ablegen.
Nehmen wir ein simples Beispiel: Bei der Webversion von GMail werden die Aktionen erst eingeblendet, wenn man eine Mail angehakt hat. Diese Buttons tauchen aber vor der eigentlichen Anwendung auf. Ein Sehender sieht das natürlich, ein Blinder bekommt das aber nicht mit bzw. würde er nach der Mailliste danach suchen.

Betriebsblindheit von Sehenden

Hinzu kommt auch das Problem der doppelten Betriebs-Blindheit, wie man es nennen könnte.
Zum Einen sind es häufig die Entwickler:Innen selbst, die testen. Wenn es aber nicht gerade Testprofis sind, sind sie selten neutral. Sie wissen, was passieren bzw. was ausgegeben werden soll. Die Nutzer:In hingegen wird das nicht wissen.
Zum Anderen ist man den Projekten anderer Personen gegenüber oft kritischer als gegenüber den eigenen Projekten. Ein Test sollte immer von jemandem durchgeführt werden, welcher der Sache selbst gegenüber neutral bis kritisch ist.

Optimierung für den Test-Screenreader

Leider neigen die Tester:innen dazu, für einen bestimmten Screenreader zu optimieren, weil sie eben diesen zur Verfügung haben, meistens Jaws.
Das bringt aber den Nutzer:innen von NVDA und VoiceOver reichlich wenig. Der grösste Bullshit der letzten Zeit ist Jaws Connect, eine Möglichkeit für Jaws-Nutzende, Probleme mit Jaws und der jeweiligen Applikation zu melden. M.E. ist das schlimmer als Overlays.

Testen Sie mit mehreren Screenreadern – ernsthaft?

Immer öfter hört man die Forderung, dass sogar mit mehreren Screenreadern getestet werden soll. Na klar, die Sehenden kommen schon mit einem Programm nicht zurecht, dann sollen sie es gleich mit mehreren versuchen und die Unterschiede kennen und verstehen. Welche dürfen es sein: Jaws, NVDA, Narrator unter Windows, VoiceOver unter Mac und iOS, Talkback unter Android – das wäre das Minimum. Im Grunde müsste man sich zumindest bei Jaws auch mehrere Versionen anschauen, da ja nicht alle die aktuelle Version nutzen. Bei iOS kann es auch Unterschiede in der Entwicklung zwischen iPad und iPhone geben.
Last not least müsste zumindest jeder Screenreader einmal mit einem Chromium-basierten Browser und Firefox getestet werden. Auf dem Mac müssten es sogar Firefox, Safari und ein weiterer Chromium-basierter Browser sein.
Welcher Sehende beherrscht all diese Plattformen und Screenreader ausreichend, um valide Ergebnisse zu bekommen? Und wer hat überhaupt die Geduld dazu?
Das scheint mir mehr Beschäftigungs-Therapie als ernsthaftes Testen zu sein. Eine Frage dazu hätte ich: Warum überlässt man das nicht den Profis, also geschulten Blinden, die in der Nutzung von Screenreadern erfahren sind, und das wesentlich besser könnten?

Warum Screenreader und nicht eine andere assistive Technologie?

Aus irgendeinem Grund gelten Blinde als besonders wichtig, oft sind sie die einzige Gruppe, die im Kontext Barrerefreiheit erwähnt wird. Aber warum? Warum nicht die zahlenmäßige größere Zahl der Sehb- oder motorisch Behinderten? Warum nicht kognitiv Behinderte? Und warum sollte man mit Screenreadern testen und nicht zum Beispiel mit der Bildschirmlupe, dem Hoch-Kontrast-Modus oder der Sprachsteuerung?

Fazit

Wie oben erwähnt sind die meisten Sehenden nicht in der Lage, einen PC so zu bedienen, wie es ein Blinder tun würde. Sich einmal durch eine Website durchzutaben ist keine Kunst. Aber welche Sehende kann schon blind ein Formular ausfüllen. Also gucken sie hin oder noch schlimmer, testen mit der Maus. Was dabei rauskommt ist bestenfalls suboptimal.
Aus dem gleichen Grund würde ich auch nicht auf Tests vertrauen, die von frisch Erblindeten oder wenig Screenreader-erfahrenen Personen durchgeführt werden. Sie kämpfen noch mit den Macken des Screenreaders und haben deshalb keine Einschätzung darüber, wie gut die Test-Objekte sind.
Die Verwendung eines Screenreaders kann sinnvoll sein, um ein Gefühl für die Arbeitsweise von Blinden zu gewinnen. Zum Testen durch ungeübte Personen sind sie jedoch ungeeignet.

Zum Weiterlesen

2 Gedanken zu „Warum Sie als Sehender nicht mit Screenreadern testen sollten“

  1. Du liebst eS, streitbar zu sein. Machst Du dabei nicht auch mal einfach so Fronten auf, wo keine sind? Was ist eigentlich die Botschaft Deines Beitrags? Dass nur Du die Tests machen kannst? Wer ist überhaupt in der Lage, allgemein gültige Tests zu machen? Oder auch anders gefragt: Was ist das Ziel, der Gegenstand oder Inhalt der Tests?
    Du sagst, „Sehende“ können sich nicht in die Situation blinder Nutzer hinein versetzen, die komplett per Tastatur arbeiten und die Botschaften des Screenreaders interpretieren. Stimmt. Und Du sagst, neu Erblindete können das auch nicht, wenn sie nicht fit sind mit dem Screenreader. Auch das stimmt. Irgendwie stimmt das alles.
    In diesem Raster ist es dann doch so, dass sehende Entwickler der Täuschung unterliegen können, es sei screenreadertauglich, obwohl sie mit Augen und Maus nachgeholfen haben.
    Der Screenreader-Frischling dürfte mit hoher Wahrscheinlichkeit zu dem irrigen Ergebnis kommen, die Oberfläche sei nicht bedienbar. Das habe ich leider auch oft erlebt, dass Leute, die die Browser-Navigation von Jaws oder NVDA gar nicht richtig kannten, Kraft der Autorität ihrer Betroffenheit getestet haben und dann zu dem falschen Ergebnis kamen, die Webseite sei nicht barrierefrei.
    Ich rate Entwicklern allerdings auch nach Deiner Argumentation weiterhin, sich NVDA zu installieren und den „Sprachbetrachter“ zu aktivieren. Sie können damit etwas sehr wichtiges erfahren, nämlich ob die Bedienelemente überhaupt so belabelt sind, dass der Screenreader sie verwerten kann. Wichtig ist, dass sie nicht meinen, dass dies schon die ganze Usability für Tastatur- und Screenreadernutzung sei. Da gehört natürlich viel mehr dazu.
    Ich hätte es also hilfreicher gefunden, wenn Du etwas mehr differenziert hättest, statt Gräben zu schaufeln. Wenn Entwickler
    im Bewusstsein ihrer begrenzten Fähigkeit, Screenreader-Navigation nachvollziehen zu können, dennoch mal schauen, ob es überhaupt eine Rückmeldung gibt, wenn sie dieses oder jenes Element annavigieren, wäre sehr viel gewonnen.
    Und übrigens, wenn qualifizierte Tester mit einer gut strukturierten Seite gut klar kommen, heißt das ja auch noch nicht, dass ungeübte Nutzer dies können. Nutzer müssen also genauso qualifiziert werden wie Entwickler. Wir müssen also alle an uns arbeiten und dabei irgendwie zusammenfinden statt uns nur gegenseitig zu erzählen, wie inkompetent wir sind.

    1. Ich hab den Eindruck, du hast den Artikel nicht zuende gelesen. Es geht nicht um Entwickler*innen, sondern um Tester*innen. Selbstverständlich ist es hilfreich beim Entwickeln, alles regelmäßig mit Screenreadern durchzuspielen. Das steht auch genauso im letzten Absatz. Nur TESTS sollten nunmal von Testpersonen der richtigen Peergroup durchgeführt werden, das gilt aber grundsätzlich, nicht nur bei Bedienhilfen für Sehbehinderte. Als Entwicklerin mit Restsehkraft fand ich den Artikel sehr aufschlussreich und differenziert.

Kommentare sind geschlossen.