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 Artikel „Barrierefreie 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.

Was ist ein Screenreader?

Blinde und sehbehinderte Menschen arbeiten mit einer Software die sich Screenreader nennt. Was diese Software macht und wie Sie funktioniert, erfahren Sie hier.

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. Der Screenreader kann den gelesenen Text über die Soundkarte ausgeben oder an eine Braillezeile schicken. Wenn der gelesene Text über die Soundkarte ausgegeben wird, heißt das, dass der Text dem blinden oder sehbehinderten Menschen vorgelesen wird.

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

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.

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.

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ärt.

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 zwei bekanntesten Screenreader sind Jaws und NVDA . Der Screenreader NVDA ist sogar kostenlos! In folgendem Blogartikel erkläre ich den Screenreader NVDA:

Hier ein Video, welches den NVDA vorstellt:

In diesem Video wird der Screenreader Jaws vorgestellt. Leider habe ich kein deutschsprachiges Video gefunden:

Auf meiner Webseite finden Sie auch Infos zum Thema barrierefreies Webdesign