Wenn es um digitale Barrierefreiheit geht, denken viele Menschen zunächst an die Zielgruppe der blinden und sehbehinderten Menschen. Sprachausgabe über sogenannte Screenreader, also spezielle Vorleseprogramme, sind mittlerweile relativ bekannt. Nicht zuletzt, weil die Smartphones und Tablets mit den Betriebssystemen von Apple (iOS) und Google (Android) bereits vorinstallierte Screenreader besitzen, die man selbst leicht ausprobieren kann. Und auch Siri und Co. haben das Verständnis für Vorleseprogramme sicherlich verbessert. Sprachausgabe kennt man. Aber wie sieht es mit dem Thema Spracheingabe beziehungsweise Sprachsteuerung aus?
Sprachsteuerung für Menschen mit Behinderung
Für ein besseres Verständnis von Systemen zur Sprachsteuerung für Menschen mit Behinderung helfen Beispiele, wie Siri, Cortana oder Alexa – vor allem, wenn es um die Leistungsfähigkeit solcher Sprachsteuerungssysteme geht. Die meisten Menschen nutzen diese Technik als Komfortlösung, zum Beispiel beim Autofahren oder zur Fernsteuerung der heimischen Entertainment-Landschaft. Die wenigsten Menschen sind aber wirklich auf Sprachsteuerungssysteme angewiesen. Für manche Menschen mit motorischer Einschränkung sind sie aber von elementarer Bedeutung. Durch meine Arbeit und durch den Austausch mit Menschen mit einer Behinderung habe ich viele unterschiedliche Behinderungsarten und deren üblicherweise eingesetzten Kompensationstechniken kennen gelernt. Ende 2019 musste ich mir aber eingestehen, dass ich keine gute Vorstellung davon hatte, wie Menschen mit einer motorischen Behinderung ausschließlich Sprachsteuerungssysteme nutzen. Ich selbst nutze seit fast 15 Jahren Dragon Naturally Speaking als Spracheingabesystem, allerdings hauptsächlich, um schneller Texte schreiben zu können. Also eher als Diktierprogramm, obwohl Dragon Naturally Speaking viel mächtiger ist und eine vollständige Sprachsteuerung des Computers und vieler Programme erlaubt. Da ich aber selbst nicht darauf angewiesen bin, habe ich es über ein paar Grundbefehle nicht hinaus geschafft.
BITV-Prüfschritt und Sprachsteuerung
Dass ich Ende 2019 mal unter Kollegen rumgehört habe, wer sich denn mit Sprachsteuerung für Menschen mit Behinderung wirklich auskennt, hatte mit dem seinerzeit relative neuen Prüfschritt „2.5.3a Sichtbare Beschriftung Teil des zugänglichen Namens“ zu tun, der erst mit der WCAG 2.1 Bedeutung in der Prüfpraxis erlangt hat. Dabei geht es darum, dass die sichtbare Beschriftung von interaktiven Elementen (Links, Buttons, Formularelemente) auch Teil der tatsächlichen Beschriftung, also des sogenannten Accessibility Names (zu Deutsch zugänglicher Name), sein muss. Klingt kompliziert, heißt aber nur, dass die sichtbare Beschriftung – zum Beispiel von einem Button – Teil der ganzen Beschriftung des Buttons sein muss. Zum Beispiel bei einem „Menü“-Button. Stellen Sie dich vor die sichtbare Beschriftung lautet „Menü“ – die vollständige Beschriftung lautet aber „Menü öffnen“. Das Wort öffnen wird nur für Screenreader-Nutzer zusätzlich vorgelesen und ist unsichtbar. Laut Prüfschritt 2.5.3a des BITV-Tests ist das nicht zu bemängeln. Natürlich kann der zugängliche Name auch weitaus komplizierter sein, als in meinem Beispiel. Die Frage ist nun, was muss man für einen Befehl aussprechen, damit das Menü mit dem Namen „Menü öffnen“ angesteuert und ausgeführt werden kann. Also ohne Maus oder Tastatur.
Sprachsteuerung mit Dragon Naturally Speaking?
Um besser zu verstehen, wie das das mit der Sprachsteuerung genau funktioniert, habe ich aus nachvollziehbaren Gründen Dragon Naturally Speaking für meine ersten Tests verwendet. Wie gesagt, ich bin kein Profi, was Spracheingabe angeht. Aber es gibt eine Dokumentation von Dragon Naturally Speaking, wie man mit einer großen Anzahl an Sprachbefehlen die Steuerung von Computer und Programmen erreichen kann. Beispielsweise soll man mit dem Befehl „Klick Linkname“ Dragon dazu bringen können, einen bestimmen Link zu klicken. Das ist genau das, was mich interessiert. Nach der Testpraxis müsste es reichen, wenn ich den sichtbaren Link-Namen für diesen Befehl verwende. Also bei meinem obigen Beispiel müsste es reichen, wenn ich sage „Klick Menü“. Das hat in meinen ersten Versuchen mit Dragon Naturally Speaking in Kombination mit Google Chrome leider überhaupt nicht funktioniert. Nur wenn ich den Befehl „Klick Menü öffnen“ gegeben habe, hat es funktioniert. Dragon Naturally Speaking in Kombination mit Google Chrome verlangt also den Accessibility Namen und nicht die sichtbare Beschriftung. Dafür muss ich aber den zugänglichen Namen erstmal kennen, was eigentlich nur durch einen Blick in den Quellcode möglich ist. Zudem kann der Accessibility Name natürlich weitaus komplizierter sein, als in meinem Beispiel (zum Beispiel durch Aria-Label o. ä.).
Das hat mit sehr irritiert, denn wenn Spracheingabesysteme wie Dragon zur Ausführung eines Befehls den kompletten, zugänglichen Namen brauchen, macht der Prüfschritt „2.5.3a Sichtbare Beschriftung Teil des zugänglichen Namens“ wenig Sinn. Denn versteckte Hilfetexte oder zusätzliche ARIA-Beschriftungen für blinde Nutzer würden dann letztendlich dazu führen, dass eine Sprachsteuerung zumindest mit Dragon Naturally Speaking unmöglich wird. Mehr noch, die Sprachsteuerung mit Dragon Naturally Speaking funktionierte auf Seiten, auf denen die sichtbare Beschriftung von interaktiven Elemente mit der tatsächlichen Beschriftung identisch war, zuverlässiger. Da das irgendwie nicht korrekt sein konnte habe ich mich mit dieser Zwischenerkenntnis an die BITV-Test-Mailingliste gewendet.
Erfahrungen mit Sprachsteuerung aus der Praxis
Glücklicherweise haben wir in der BITV-Test-Mailingliste auch Experten in eigener Sache, die oftmals viel bessere Einblicke geben können. Thomas Ernst von der Pfennigparade in München war so nett seine persönlichen Erfahrungen zu teilen. Er nutzt die Spracheingabe Dragon Naturally Speaking als überwiegende Eingabemöglichkeit am Computer und ist auf diese auch angewiesen und kann viel besser einschätzen, was meine Probleme verursacht hat. „Nach meiner Erfahrung ist die Unterstützung des Befehls „Klick Bedienelement“ beispielsweise im Firefox nicht so gut wie im Internet Explorer. Bei Links verhalten sich die Browser identisch, bei Feldbeschriftungen funktioniert es, meiner Erfahrung nach, im Firefox nicht.“ Schrieb mit Thomas Ernst zurück. Offensichtlich werden Sprachbefehle nicht in jedem Browser gleich unterstützt, was meine Probleme mit Dragon Naturally Speaking in Kombination mit Google Chrome erklären könnte.
Sprachsteuerung, Spracherkennung und Aussprache
Später hat sich Thomas Ernst von der Pfennigparade noch etwas mehr Zeit genommen und mir seine Arbeitsweise mit der Spracheingabe Dragon Naturally Speaking erläutert. Dabei hat mehr in einem Nebensatz auf ein weiteres Problem mit Sprachsteuerung und Spracherkennung hingewiesen: Undeutliche oder unkorrekte Aussprache. Das betrifft natürlich nicht nur Menschen mit einer Behinderung, sondern auch Menschen mit einem starken Dialekt oder Akzent. Oder Menschen mit einer manchmal nachlässigen Aussprache. Aber auch dafür gibt es eine Lösung. Thomas Ernst, der früher noch mit Tastatur gearbeitet hat, verwendet Tastaturkürzel, um den Computer zu bedienen. Da ist die Erkennung besser, auch wenn die Aussprache nicht so gut ist.
Sprachbefehle mit Mausraster
„Im Internet benutze ich überwiegend ein sogenanntes Mausraster“ erzählte mir Thomas Ernst in seinem Erfahrungsbericht weiter. Das macht mich neugierig und er berichtete, dass ein solches Mausraster für ihn ausgesprochen hilfreich und effizient sei, um den Cursor nur via Sprachbefehl schnell und präzise von A nach B zu steuern. Die Funktionsweise ist vergleichsweise trivial. Beim Mausraster wird über den gesamten Bildschirm ein Raster mit neun Feldern gelegt. Dieses ist dann von 1 bis 9 durchnummeriert. Um mit dem Cursor zum gewünschten Ziel zu gelangen, spricht man die Zahl des entsprechenden Feldes, in dem das Ziel liegt. Der Cursor springt in das entsprechende Feld, worauf dieses Feld wieder in 9 Felder unterteilt wird. Der Mauscursor steht immer in der Mitte auf dem Feld Nummer 5. So kann man normalerweise in 3 bis 4 Schritten die Maus an jede beliebige Stelle des Bildschirms bewegen. Dann sagt man beispielsweise „Linksklick“ und das interaktive Element unter dem Cursor wird ausgeführt. Das Mausraster ist fester Bestandteil der Spracheingabe von Dragon Naturally Speaking. Man aktiviert es mit dem Befehl „Mausraster“ oder kann den Befehl auch verkürzen und die Quadranten in einem Rutsch ansteuern, zum Beispiel mit dem Befehl „Maus 3“ oder einer anderen Zahl natürlich. Allein Drag and Drop ist bei dieser Funktion zwar theoretisch möglich, aber laut Ernst nicht überall gut implementiert und für grafische Anwendungen unpraktisch. Auf Youtube gibt es diverse Videos zu Dragon Naturally Speaking und dem beschriebenen Mausraster, leider nur auf Englisch.
Fazit:
Je mehr man sich mit dem Thema digitale Barrierefreiheit auseinandersetzt, umso mehr muss man sich mit verschiedenen Behinderungsarten und kompensierenden Techniken befassen (Siehe auch Artikel über Barrierefreiheit für Menschen mit Autismus-Syndrom). Es gibt eben nicht nur blinde Screenreader-Nutzer oder motorisch eingeschränkte Tastaturnutzer, sondern eben auch Menschen, die auf Sprachsteuerung und Spracheingabe angewiesen sind. Für viele Prüfschritte der WCAG 2.1 reicht es nicht nur deren Wortlaut zu kennen. Das Beispiel Sprachbefehle mit Mausraster zeigt, dass es für manche Aspekte auch einfach keine Prüfschritte gibt. Wenn Menschen mit motorischen Einschränkungen Sprachbefehle in Kombination mit dem Mausraster verwenden, helfen beispielsweise vor allem eine ausreichend große Basisschriftgröße, große Schalt- und Linkflächen oder auch ein erhöhter Zeilenabstand, beispielsweise bei Linklisten. Anforderungen, für die es keine Richtlinien-Vorgaben gibt. Aber beim Thema digitale Barrierefreiheit geht es nicht immer nur streng um Richtlinienerfüllung, sondern auch um Best-Practice Lösungen. Und dabei helfen Erklärungen und Demonstrationen von Menschen mit Behinderung oft am ehesten weiter. Zumindest, wenn es um ein tiefer gehendes Verständnis geht.
Jörg Morsbach, Diplomdesigner und Kommunikationswirt (WAK), betreibt bereits seit 2003 die Düsseldorfer Agentur anatom5 und macht sich aus Überzeugung für universelles Design und einen weit reichenden Inklusionsgedanken stark. anatom5 wurde vielfach für Barrierefreiheit ausgezeichnet. Seit Anfang 2017 ist Jörg Morsbach zugelassener Erstprüfer des BITV-Test (BIK-Test). Sein heimliches Steckenpferd ist die Suchmaschinenoptimierung.
Zum Portfolio von anatom5 gehören Internetauftritte und Webapps ebenso, wie barrierefreie PDF-Dokumente und Übersetzungen in leichte Sprache. Zudem hat anatom5 mit dem Barriere-Check Pro ein Testverfahren entwickelt, das auch WCAG-Empfehlungen, Best-Practice Lösungen, Aspekte der Usability und Performance sowie BITV-Anforderungen der Priorität 2 berücksichtigt.
Sein Credo lautet:
Ohne Screenreader-Tests und Analysen im Detail ist Testen mit automatisierte Testtools nur das sprichwörtliche „Fischen im Trüben“.