Screenreader leicht und verständlich erklärt

Blinde und sehbehinderte Menschen arbeiten mit einer Software, die unter dem Oberbegriff Screenreader zusammengefasst wird. Was diese Software macht und wie Sie funktioniert, erfahren Sie hier.

Computernutzung bei Blindheit und Sehbehinderung
Blinde Personen können Computer mithilfe einer Braillezeile nutzen. Das Computer-Ausgabegerät stellt Zeichen in Brailleschrift dar und wird üblicherweise durch Screenreader angesteuert. Bildquelle: zlikovec – 428299819 / Shutterstock.com

Ein Screenreader ist ein Bildschirmleseprogramm. Wenn ein Mensch blind oder sehbehindert ist, heißt das nicht, dass er nicht am PC/Laptop arbeiten kann. Der Screenreader „spielt“ für den blinden oder sehbehinderten Menschen die Augen und liest den Bildschirminhalt. Die Vermittlung der Informationen auf dem Bildschirm können dabei auf zwei verschiedene Arten geschehen:

  • Akustisch: über eine Soundkarte
  • Taktil: über eine Braillezeile

Wenn der gelesene Text über die Soundkarte ausgegeben wird, heißt das, dass der Text dem blinden oder sehbehinderten Menschen vorgelesen wird. Im Fall der Braillezeile kann der Nutzer den Inhalt selbst in Blindenschrift lesen.

Hier noch ein Youtube-Video in dem ich erkläre was ein Screenreader ist:

Zwei Wege der Sprachausgabe

Die akustische Wiedergabe des Bildschirminhalts ist besonders für sehbehinderte Menschen geeignet, deren Sehvermögen noch gut genug ist, dass sie auf Blindenschrift verzichten können. Es gibt zwei Wege, um synthetische Sprache zu erzeugen:

  • Externe Geräte: Diese werden an den Computer angeschlossen und erzeugen die Sprachausgabe unabhängig vom benutzten Endgerät. Dabei werden die Bildschirminformationen vom Endgerät (PC, Tablet, Laptop) auf das externe Ausgabemedium übertragen.
  • Internes Softwareprogramm: Dieses Programm ist in der Regel in den Screenreader integriert und übersetzt die Bildschirminhalte in Sprache. Die Ausgabe erfolgt über die PC-Lautsprecher wahlweise mit oder ohne Kopfhörer.

Synthetische Sprache hat den Nachteil, dass sie sehr maschinell klingt. Das Hauptproblem dieser assistiven Technologie ist zweifellos, mit so produzierter Sprache Gefühle zu transportieren. Das Ergebnis wirkt deshalb nicht immer angenehm und harmonisch. Die Sprachausgabe erfolgt recht monoton ohne Pause oder Betonung. Bei Wörtern, die anders ausgesprochen als sie geschrieben werden, können teilweise Verständnisprobleme auftreten.

Die in die Software integrierte Wörterbuchfunktion kann unverständliche Wörter aber noch einmal nach ihrem Sinn erklären. Diese Funktion ist auch bei Zeichenfolgen wie Smileys oder Abkürzungen sehr hilfreich. Ähnlich wie bei Navigationsgeräten können Benutzer in der Regel zwischen einer Männer- oder Frauenstimme wählen. Über die Einstellungen kann zudem die Lesegeschwindigkeit angepasst werden.

Braillezeilen übersetzen Bildschirminhalte in Blindenschrift

Die Braillezeile ist ein Ausgabegerät, welches den gelesenen Text in Brailleschrift (=Blindenschrift) ausgibt. Die Brailleschrift wird mit Stößel dargestellt, die aus einer Fläche herausragen. Diese herausragenden Stößel bilden die Zeichen der Blindenschrift ab. Der blinde oder sehbehinderte Mensch kann mit seinen Fingerkuppen die Stößel abtasten und somit eine Bildschirmzeile lesen.

Alternativtexte für Bilder und Videos sind wichtig

Da Screenreader nur lesen und nicht sehen können, ist es z. B. wichtig, dass Bilder auf einer Webseite einen Alternativtext haben. Fehlt dieser Alternativtext, wird diese Fläche vom blinden oder sehbehinderten Menschen als „leere“ Fläche wahrgenommen.
Bei Videos verhält es sich genau gleich. Der Screenreader kann ein Video nicht „lesen“. Wenn man auf einer Webseite Videos einbindet, sollte man unter dem Video kurz beschreiben, was auf dem Video zu sehen ist.
Mit oben beschriebener Vorgehensweise können blinde und sehbehinderte Menschen am PC/Laptop arbeiten. Der Screenreader liest den Bildschirminhalt und liest ihn vor oder schickt ihn an die Braillezeile.

Programmoberflächen müssen Text beinhalten

Damit Screenreader Programmoberflächen „lesen“ können, müssen diese so programmiert werden, dass die Oberflächenkomponenten Texte beinhalten, die Sinn und Zweck der Komponente erklären.
Da Screenreader in unterschiedlichen Betriebssystemen anders heißen, hier eine kurze Auflistung:

Betriebssysteme Name des Screenreaders Wo finden Sie den Screenreader
Windows Sprachausgabe Einstellungen -> Erleichterte Bedienung
IOS Voice Over Einstellungen -> Bedienungshilfen
Android Talkback Einstellungen -> Bedienungshilfen oder Eingabehilfe
Ubuntu Bildschirmleser Einstellungen -> Zugangshilfen

Die in der Praxis am meisten verwendeten Screenreader

Die Softwareprogramme für Screenreader gibt es sowohl als kostenlose oder Open-Source-Versionen als auch von kommerziellen Anbietern gegen Bezahlung. Der bekannteste Gratis-Screenreader ist NonVisual Desktop Access (NVDA) für Microsoft Windows. In diesem Blogartikel erkläre ich den Screenreader NVDA. Hier ein Video in dem ich den Screenreader NVDA im Betriebssystem Windows 10 vorstelle:

In folgenden Video zeige ich den Screenreader Orca im Linux-Betriebssystem Ubuntu:

In folgenden Video zeige ich den Screenreader VoiceOver im Betriebssystem MacOS:

In folgenden Video zeige ich den Screenreader Talkback im Betriebssystem Android:

Youtube-Video, das den Gebrauch des NVDA Screenreaders in englischer Sprache erklärt.
Zu den bekanntesten kommerziellen Screenreadern gehört die (JAWS). Die Kosten für die Version Professional liegen bei etwa 900 Euro. Die Home Edition gibt es schon ab etwa 735 Euro.
In diesem Video wird der Screenreader JAWS vorgestellt. Leider habe ich kein deutschsprachiges Video gefunden:

Video-Tutorial in englischer Sprache über die verschiedenen Elemente einer Webseite, einschließlich Links, Überschriften und Dialogboxen und wie JAWS auf diese Elemente zugreift.
Auf meiner Webseite finden Sie weitere nützliche Informationen zum Thema barrierefreies Webdesign.

Warum ist die Java Access Bridge zur barrierefreien Software-Entwicklung mit Java wichtig?

Ich habe gerade einen Auftrag bei dem es darum geht eine Software, entwickelt mit der Programmiersprache Java, barrierefrei zu machen. Hierbei musste ich mich intensiv mit der Java Access Bridge beschäftigen. Was die Java Access Bridge ist und wofür Sie gebraucht wird, erfahren Sie in diesem Artikel.

Was eine Barrierefreie Software ist, wird in diesem Blogartikel erklärt
Was ist eine “barrierefreie Software”? (  ). Barrierefreie Software-Entwicklung bedeutet, dass eine Software so entwickelt ist dass sie von Menschen mit unterschiedlichen Behinderungen bedient werden kann. Die Programmiersprachen Java und C# eignen sich zur barrierefreien Software-Entwicklung.

Blinde und auch viele Sehbehinderte Menschen können den Computer nur mit einem Screenreader bedienen. Die schwierigste Aufgabe der barrierefreien Software-Entwicklung ist, die komplette Software für Blinde und Sehbehinderte komplett zugänglich zu machen. Hierzu gehört dass die Programmoberfläche Informationen für Screenreader bereitstellt. Sie müssen Swing-Komponenten zur Oberflächenprogrammierung verwenden. Jede Swing-Komponenten hat die Eigenschaft „AccessibleName“ und „AccessibleDescription“. Hier müssen Texte hinterlegt werden, welche den Screenreadern mitgeteilt werden.
Jetzt ist die Frage wie kommen die Informationen der Programmoberfläche zum Screenreader?

Es gibt bei Java eine Java Accessibility API (JAAPI). Die Java Accessibility API (JAAPI) Ermöglicht die Kommunikation zwischen Java-Anwendungen und Unterstützungstechnologien (zum Beispiel Screenreader oder Braille-Zeile). Die Java Access Bridge ist die Brücke zur Kommunikation zwischen den Unterstützungstechnologien wie Screenreader oder Braillezeile und der JAAPI.

Kurz gesagt, damit Ihre Software mit Screenreadern kommunizieren kann, muss die Java Access Bridge installiert sein. Da die Installation der Java Access Bridge nicht ganz einfach ist, werde ich diese in einem eigenen Artikel erklären.

Wie Sie die Java Access Bridge installieren, erfahren Sie in folgenden Blogartikel:
Wie installiere ich die Java Access Bridge? 

Barrierefreie Software-Entwicklung: Wie kann eine Software für Blinde barrierefrei gemacht werden?

Im Blogartikel „Accessibility – Barrierefreie Software-Entwicklung: Blinde“ habe ich erklärt, welche Probleme blinde Menschen bei der Bedienung von Software haben. In diesem Blogartikel erfahren Sie wie Software entwickelt werden kann, damit blinde Menschen keine Probleme bei der Bedienung von Software haben.

Da blinde Menschen mit einem Programm namens Screenreader arbeiten, sind sie darauf angewiesen, das die Programmoberfläche der Software dem „Bildschirmleser“ Textinformationen bereitstellen.

Wenn Sie Programmoberflächen mit Java entwickeln sollten Sie die Swing-Komponenten benutzen. Diese haben die Eigenschaften „AccessibleName“ und „AccessibleDescription“. Diesen Eigenschaften können Sie Textinformationen für den Screenreader zuweisen. Näheres über die barrierefreie Softwareentwicklung mit Java können Sie im Blogartikel „Accessibility: Barrierefreie Software-Entwicklung mit Java“ nachlesen.

Wenn Sie mit dem Microsoft .net-Framework Programmoberflächen entwickeln so gibt es dort ebenso die Eigenschaften „AccessibleName“ und „AccessibleDescription“.
Ausführliche Informationen finden Sie im Blogartikel „Accessibility: Barrierefreie Software-Entwicklung mit .net bzw. C#“.

Ebenso ist es wichtig, dass Sie Grafiken einen Alternativtext geben. Falls In Ihrer Software Videos vorhanden sind, die für die Benutzung der Software wichtig sind, sollten Sie eine Zusammenfasung des Videoinhalts als Text bereitstellen.

Blinde Menschen können keine Computermaus bedienen, deswegen muss eine Software komplett per Tastatur bedienbar sein, damit Sie für blinde Menschen bedienbar ist. Ihre Software sollte ein Menü besitzen in dem die wichtigsten Programmfunktionen vorhanden sind. Außerdem hilft es blinde Menschen, wenn wichtige Programmfunktionen mit Tastenkürzel(Shortcuts) ausgeführt werden können. Wenn Ihre Software nur Schalter ohne Beschriftung besitzt, müssen blinde Menschen so lange die Tabulatortaste drücken, bis der gewünschte Schalter den Fokus hat. Das ist sehr mühsam.
Wenn Sie in Ihre Software Eingabefelder mit Beschriftungen haben, dann sorgen Sie dafür, dass die Beschriftung mit dem Eingabefeld verbunden ist und per Tastenkürzel direkt erreichbar ist. Wenn der Blinde das Tastenkürzel der Beschriftung drückt wird der Textcursor in das dazugehörige Eingabefeld gesetzt.

Mit diesen Maßnahmen wird Ihre Software für Blinde bedienbar.

Wie kann barrierefreie Software entwickelt mit .net bzw. C# auf Accessibility getestet werden

Im ArtikelBarrierefreie Software-Entwicklung (=Accessibility) mit .net bzw. C#“ ging es darum wie man mit .net barrierefreie Software entwickelt. In diesem Artikel möchte ich besprechen wie man Barrierefreiheit bei Software die mit .net bzw. C# entwickelt wurde testen kann.

 

Trotz redlicher Bemühungen die Software barrierefrei zu entwickeln, kann es sein, dass man etwas vergisst oder übersehen hat. Deswegen sollte man, bevor man einer Software das Prädikat „barrierefrei“ verleiht, testen ob dies auch zutrifft. Da es höchst unwahrscheinlich ist, dass jeder Software-Entwickler einen Menschen mit Behinderung greifbar hat, welcher die Software testet, ist es sinnvoll, dass hierfür Tools entwickelt worden sind. Microsoft hat zwei Open Source-Tools entwickelt um Barrierefreiheit bei Software zu testen. Das eine Tool heißt „UI Automation Verify“ und das andere „UI Accessibility Checker“.
„UI Automation Verify“ ist ein Framework um Microsoft UI-Automation-Implementierungen automatisiert Prüfen zu können. Ich möchte mich in diesem Abschnitt mit dem AccChecker genauer beschäftigen.
Den AccChecker gibt es als Konsolen- und Windows-Anwendung. Ich werde hier das Verfahren mit der Windows-Anwendung beschreiben die sich hinter der AccCheckUI.exe verbirgt. Ob man zuerst den AccChecker und dann die zu testende Anwendung startet oder umgekehrt ist egal. Links oben im Acc-Checker-Fenster gibt es nun 3 Möglichkeiten, das zu prüfende Fenster bzw. Anwendung auszuwählen.
Ich entscheide mich für das auswählen eines Fensters aus der auf klappbaren Liste, weil es wohl am einfachsten ist. Unten kann ich ein „suppression file“ auswählen in dem ich festlegen, kann welche Fehler ignoriert werden. Auf der rechten Seite gibt es die Überschrift „Verification Routines“. Hier kann angeklickt werden, welche Dinge überprüft werden soll. Da die Dokumentation nicht gerade ein Highlight ist und zum Teil gewisse Fakten verschweigt, möchte ich nachfolgend diese Optionen etwas erläutern und berichten, wie es mit der Praxistauglichkeit aussieht.
Wir fangen an mit den Eigenschaften.

CheckAccessKeys
Wenn diese Option angeklickt ist, wird überprüft ob ein Accesskey doppelt vergeben ist.Leider bekommt man nur mitgeteilt wo der Accesskey zum zweiten mal vorkommt, wo er aber das erste mal vorkommt muss man selbst herausfinden.enn an einen Menü oder Schalter kein Accesskey vergeben wurde, wird einem das nicht mitgeteilt.

CheckRole
Hier kann überprüft werden ob den einzelnen Komponenten eine AccessibleRole vergeben wurde oder nicht. Standardmäßig ist im Eigenschaftenfenster von Visual Studio 2008 default eingestellt bei der Eigenschaft „AccessibleRole“. Wenn hier als Wert „None“ angegeben wird, bringt der AccChecker eine Fehlermeldung.

CheckBoundingRect
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche eine rechteckige Begrenzung hat, die für Anklick-Tests genutzt werden kann.

CheckState
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche einen gültigen, logischen Aktiven Zugänglichkeitsstatus zurück meldet.

CheckName
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche einen gültigen, logischen Aktiven Zugänglichkeitsnamen zurück meldet.

Unter der der Überschrift Tree (Baum) finden Sie nachstehende Optionen

CheckNavigate
Diese Überprüfungsroutine benutzt die IAccessible::accNavigate Methode um zu bestätigen, dass die Navigation zwischen den „Eltern“, dem „Kind“ bzw. den „Geschwister Elementen übereinstimmend und vorhersehbar ist.

CheckParentChild
Diese Überprüfungsroutine bestätigt, dass Eltern->Kind-Beziehungen im Elementebaum übereinstimmend und vorhersehbar sind.

HitTesting
Diese Option ist im Programm nicht vorhanden, aber in der Dokumentation. Diese Überprüfungsroutine bestätigt, dass alle Elemente an den Koordinaten die durch „AccessibleObjectFromPoint angegeben werden gültig sind und sich innerhalb des überprüften Ziels befinden.

Consistency (=Konsistenz)

Screen Reader
Diese Überprüfungsroutine übersetzt alle sichtbaren Elemente des zu überprüfenden Ziels und zeigt sie in einer Listenansicht in der Reihenfolge, in welcher der Standard Screen Reader sie dem Benutzer meldet. Wenn diese Option ausgewählt wurde, erscheint im linken Teil des Fenster ein Register „Screen reader“.

Navigation
Tree Depth Check (CheckTreeDepth)

Zunächst ist zu erwähnen, dass es hier unterschiedliche Begriffe gibt. In der Programmoberfläche steht CheckTreeDepth und in der Dokumentation steht Tree Depth Check.
Diese Überprüfungsroutine sendet Tab oder Umschalt- Tab Zeichen als Eingangssignal an das zu überprüfende Ziel um zu bestätigen das die Benutzeroberfläche des Zielsystems für standard Tastatur Navigation weder allzu sehr komplex oder unerreichbar ist.

Check Tabbing
Diese Überprüfungsroutine sendet Tab oder Umschalt Tab Zeichen als Eingangssignal an das zu überprüfende Ziel um zu bestätigen das alle fokusierbaren Elemente das Benutzeroberfläche in einer geordneten Art und Weise über eine Standard Tastatur Navigation zu erreichen sind.

Soweit zu den Einstellungsmöglichkeiten des AccCheckers.
Hat man nun das zu prüfende Fenster ausgewählt und auf der rechten Seite die entsprechenden Optionen angeklickt, startet man die Überprüfung mit anklicken des Schalters „Run Verifications“.
Nach erfolgter Überprüfung erscheint oben ein Register „Results“, „Tree“ und bei entsprechend ausgewählter Option „Screen reader“. Wenn Sie im Register „Results“ keine Einträge sehen, heißt bedeutet dies, dass keine Fehler gefunden wurden und Ihre Anwendung somit barrierefrei ist.
Wurden Fehler gefunden werden diese im Register „Results“ angezeigt. Wenn man in der Liste „Results“ auf einen Fehler klickt, sieht man unten nähere Infos zu diesem Fehler. Sollte man mit der Fehlermeldung nichts anfangen können, kann man durch einen rechten Mausklick und das anklicken des Kontextmenüpunktes „Help“ eine genaue Beschreibung zum Fehler bekommen.