Neue Ansätze für Screenreader

Heute gibts wieder mal einen etwas technischeren Beitrag. Ich möchte mit euch ein paar Gedanken dazu austauschen, was Screenreader heute noch leisten und welche Ansätze es braucht, um sie zu verbessern.
Die ersten Screenreader griffen Informationen über die Grafikkarte ab. Deshalb brachte Jaws lange Zeit einen Treiber für Grafikkarten mit, der so manche Windows-Installlation zerschossen hat. Möglicherweise gibt es den immer noch.
Heutige Screenreader greifen auf Informationen der Accessibility API zurück. Das ist eine Schnittstelle. Der Programmierer hinterlegt Informationen nach einem bestimmten Schema, die vom Screenreader ausgelesen werden.
Nun haben wir zwei gegenläufige Tendenzen: Screenreader stehen immer mehr Leuten teils kostenlos zur Verfügung. Der Narrator ist fürs einfache Surfen geeignet. NVDA und VoiceOver auf dem Mac sind leistungsfähige Alternativen zum überteuerten Jaws.
Auf der anderen Seite werden immer mehr Anwendungen ins Web ausgelagert. Oder sie sind nicht barrierefrei programmiert. Für Blinde zum Beispiel stehen ganze Berufsfelder nicht zur Verfügung, weil sie mit den nötigen Tools nicht arbeiten können.
Nun ist es einfach, Barrierefreiheit einzufordern und für einem Multi-Milliarden-Konzern wie Microsoft ist die Umsetzung kein Problem. Für den Software-Mittelständler mit einer Handvoll Entwicklern ist das schwierig. Ein nicht barrierefreies Programm barrierefrei zu machen kostet sie im Verhältnis mehr Geld, mehr Zeit und mehr Woman-Power als Apple oder Microsoft. Dass sie es von Anfang an hätten barrierefrei programmieren können, steht auf einem anderen Blatt.
Das zweite Problem ist, dass Screenreader – so mein Eindruck – generell Probleme mit
dynamischen Anwendungen haben. Auch wenn es funktioniert ist es mehr als hakelig. In Word kann ich zum Beispiel einfach die Alt-Taste nutzen, um das Menü aufrzurufen. In Google Docs bekomme ich das kaum hin.
Außerdem wäre es manchmal sinnvoll, das Gleiche zu sehen wie Sehende. Blinde wissen nicht, welche Position ein Element auf dem Bildschirm hat und ein Sehender kann ihnen ohne Screenreader-Kenntnisse nicht sagen, wie sie an eine bestimmte Stelle kommen. Manchmal höre ich Dinge, die der sehende Kollege nicht sehen kann. Sie sind zwar da, aber nicht visuell sichtbar.
Wie dem auch sei, hier meine Wunschliste ohne Anspruch auf Vollständigkeit. Vielleicht fasst sich ja jemand ein Herz und entwickelt bis morgen die passende Anwendung dazu.

Mustererkennung

Der Screenreader muss den Bildschirm-Inhalt analysieren. Anhand bestimmter Muster wie der Anordnung von Links oder ihrem Aussehen kann er erkennen, dass es sich um ein Textfeld, ein Menü, einen Scrollbalken oder etwas anderes handelt. Diese Muster muss er erkennen und die passende Information an den Nutzer weitergeben. Außerdem muss er die passende Interaktion wie anklicken, scrollen Auswählen und so weiter ausführen können.

Erkennen und Rückmelden von Veränderungen

Nun habe ich eine Checkbox ausgewählt, einen Text geschrieben, oder einen Befehl in einem Menü aufgerufen. Der Screenreader müsste mir diese Veränderung zurück melden, so wie er es bei einer barrierefreien Anwendung auch tun würde. Soweit ich erkennen kann, ist das ein Kernproblem heutiger dynamischer Anwendungen wie Google Docs.

Verschieben und fallen lassen

Drag and Drop gehört zu den wichtigen Aufgaben etwa in Redaktionssystemen mit dynamisch angelegten Oberflächen. Hier muss es eine adequate Lösung geben, die nichts mit Mausschubserei zu tun hat.

Beschreibung komplexer Oberflächen

Die komplexeste Aufgabe ist die Beschreibung von Web-Oberflächen. Hintergrund ist folgender: Wenn ich eine Anwendung das erste Mal aufrufe, weiß ich ja nicht, welche Optionen zur Verfügung stehen. Ich sehe nur das, was ich gerade fokussiert habe. Ich brauche also eine kurze Zusammenfassung des visuellen Interfaces. Das machen übrigens auch barrierefreie Anwendungen derzeit nicht. Nur im Internet gibt es beim Aurruf einer Webseite Schlüsselinfos wie „Seite hat 20 Überschriften und 120 Links“. Das ist nicht immer informativ, aber ein erster Ansatz. Wünschenswert wäre eine Zusammenfassung von Bedien-Segmenten wie Menüs, Symbolleisten und so weiter. Im nächsten Schritt müsste man in das jeweilige Segment absteigen und sich einzelne Elemente ansagen lassen können.
Mit der Mustererkennung ist das Erkennen solcher Segmente kein großes Problem. Schwierig ist vor allem eine Beschreibung, die vom Nutzer verstanden werden kann.

Tracking von Veränderungen

Dynamische Anwendungen können sich ohne Zutun des Users ändern, siehe etwa Twitter.

Fazit

Wünschenswert wäre ein Mix beider Funktionalitäten. Das heißt, es werden Informationen aus der Accessibility Api bzw. aus dem Quelltext ausgelesen und Informationen werden direkt vom Bildschirm abgenommen. Die Frage bleibt dann, wie das dem Nutzer am besten weitergegeben wird.

Ist das technisch überhaupt möglich?

Gute Frage, nächste Frage. Ich nehme an, die Mustererkennung kann man über eine künstliche Intelligenz lösen. Die Zahl sinnvoller Gestaltungsmuster für Webanwendungen ist zwar groß, aber nicht unbegrenzt. Weicht man zu oft von der üblichen Designsprache ab, ist es ja auch für Sehende schwer zu erkennen, was man da vor sich hat.
Hat man dieses Problem gelöst, ist der Rest ein Klacks.
Das ist also – so hoffe ich – keine absolute Zukunftsmusik.
Ein Kernproblem heutiger Screenreader besteht übrigens darin, dass sie zu kompliziert sind. Spät-Erblindete mögen noch in der Lage sein, sich eine Seite vorlesen zu lassen. Doch die Nutzungsmuster von Blinden und Sehenden bei Web-Anwendungen divergieren so stark, dass Blinde und Sehende sich nicht gegenseitig helfen können. Wenn ich zum Beispiel mit eTracker arbeite, verwende ich die Tastatur, lasse mir eine Liste der Links anzeigen und springe zu dem gewünschten Link, in dem ich dessen Anfangsbuchstaben eingebe. Die Menüs, die ich dabei verwende sind für den Sehenden gar nicht sichtbar, was ich aber nicht weiß, ich nehme sie ja war. So kann ich ihm nicht helfen und er kann mir nicht helfen.
Der Sehende kann mir – außer bei Touchscreens – nicht sagen, wie ich an eine bestimmte Position des Bildschirms komme. Die Arbeitsweise des Screenreaders ist für ihn und den Neu-Erblindeten nicht intuitiv.
Mit anderen Worten: Es wäre wünschenswert, die Arbeitsweise von Blinden und Sehenden näher zusammenzurücken. Das hieße nichts anderes als die Arbeitsweise heutiger Screenreader über den Haufen zu werfen. Aber vielleicht ist das ab und zu mal nötig, ein paar Schritte zurückzutreten und einen geweiteten Blick auf möglicherweise nicht mehr geeignete Möglichkeiten zu werfen. Ich sehe voraus, dass die Zahl der Geburtsblinden in Deutschland bald sehr gering sein wird, während die Zahl der im Alter Erblindeten weiter zunimmt. Für sie sind die heutigen Konzepte der Screenreader zu kompliziert.

2 Gedanken zu „Neue Ansätze für Screenreader

  1. Wichtig wäre es vor allem, bei den Sehenden ein Bewusstsein für die Barrierefreiheit zu schaffen. Das fängt doch schon bei der Bildbeschreibung auf Twitter an. Twitter hält es nicht für notwendig die Bildbeschreibung im Web Client und seiner App voreingestellt zu aktivieren. Und es werden Bilder über Bilder getwittert. Traurig aber wahr. Wir sollten zuerst einmal unsere Energien bündeln und versuchen ein #neuesBewusstsein zu schaffen. Meine Meinung.

  2. Es gibt uns einer Sicht zwei Probleme mit Screenreadern:

    1.) Nicht alle Programme sind zugänglich.

    2.) VoiceOver orientiert sich z. B., daran, wie eine Anwendung im XIB-Editor zusammengestellt wurde. Das führt u. U. Zu einer schwierigen Benutzerführung. Ein abschleckendes Beispiel ist nach meiner Meinung Microsoft Ofice. dort werden recht tief verschachtelte GUI-Strukturen verwendet. Dies hat zur Folge, dass man recht tief in die GUI-Elemente interagieren muss um mit den Anwendungen arbeiten zu können. Siegessäule macht die Einarbeitung in diesen Anwendungen nicht gerade einfach. Es ist einfach nicht offensichtlich, warum man so tief in die GUI-Struktur interagieren muss

Kommentare sind geschlossen.