Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM

In diesem Blogartikel werden die Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM wiedergeben. Und erklärt. Es handelt sich hierbei um die Version 3.6 .
 

1. Tastaturbedienbarkeit

1.1 Alle Softwarefunktionen müssen auch ohne Maus, also nur per Tastatur ausführbar sein

Erklärung:
Blinde und einige Sehbehinderte können keine Maus bedienen, weil zum positionieren des Mauszeigers die Fähigkeit zu sehen unbedingt notwendig ist. Deswegen bedienen diese Menschen den kompletten Computer mit der Tastatur. Dies kann nur geschehen, wenn auch die Software komplett per Tastatur bedienbar ist.
Ein zweiter Grund ist, dass es Menschen mit einer starken Einschränkung an der Hand gibt, für die es nicht möglich ist eine Computermaus zu bedienen, sehr wohl aber eine Tastatur.

1.2 Es darf keine Konflikte geben zwischen Ihrer Software und der Tastatureingabehilfen des Betriebssystems

Erklärung:
Im Betriebssystem Windows gibt es Eingabehilfen für behinderte Menschen. Diese helfen zum Beispiel mehrere Tasten gleichzeitig mit einer Hand zu drücken oder die Drucksensibilität von Tasten zu verändern. Zwischen diesen Eingabehilfen und Ihrer Software darf es keine Konflikte geben. Sie dürfen in Ihrer Software keine Tastenkürzel verwenden die vom Betriebssystem für Eingabehilfen (https://www.marlem-software.de/marlemblog/2010/12/28/was-sind-eingabehilfen/ ) reserviert sind.

 

2. Informationen über Objekte

2.1 Bieten Sie eine optische Fokusanzeige an, die den Änderungen des Eingabefokus zwischen den interaktiven Objekten folgt. Diese Fokusanzeige muß programmtechnisch für die assistive Technik zugänglich sein.

Erklärung:
Sehbehinderte haben oft Probleme zu erkennen welches Bedienelement gerade den Fokus hat. Deswegen sollten Sie dafür sorgen, dass der Fokus gut sichtbar ist. Desweiteren muss gewährleistet sein, dass der Screenreader ( https://www.marlem-software.de/marlemblog/2010/02/09/was-ist-ein-screenreader/ ) die Position des Fokus kennt.

2.2 Liefern Sie semantische Informationen über Objekte der Benutzerschnittstelle. Wenn ein Programmelement aus einem Bild besteht, dann muss die Information, die durch das Bild transportiert wird, auch als Text verfügbar sein.

Erklärung:
Der Screenreader von Blinden benötigt Informationen welches Objekt den Fokus hat und welche „Rolle“ das Objekt hat. Der Screenreader muss zum Beispiel wissen, dass ein Optionsfeld aktiv ist und welche „Option“ ausgewählt ist.

2.3 Beschriften Sie Bedienelemente, Objekte, Icons und Bilder. Wenn ein Bild zur Kennzeichnung von Programmelementen benutzt wird, muss die Bedeutung des Bildes in der gesamten Applikation einheitlich sein.

Erklärung:
Für Screenreader ist es wichtig, dass Objekte wie z. B. Icon-Name, Fenstertitel oder Eingabefelder Beschriftungen haben. Damit diese Beschriftungen für Screenreader und andere Eingabehilfen verfügbar sind, müssen Sie programmtechnisch mit einem Objekt verbunden sein. Ansonsten bekommt der Screenreader Probleme bei der Zuordnung von Objekten und Beschriftungen.

2.4 Wenn elektronische Formulare in der Software benutzt werden, sollten die Formulare den Menschen, die assistive Technik benutzen, erlauben, auf die Informationen, Feldelemente und Funktionen zuzugreifen, die zum Ausfüllen und zur Abgabe des Formulars, einschließlich aller Anweisungen und Hinweise, notwendig sind.

Erklärung:
Elektronische Formulare müssen für Screenreader zugänglich sein. Hierfür ist es wichtig, dass die Formulare und Bedienelemente sachgerecht Kodiert werden.

 

3. Sound und Multimedia

3.1 Bieten Sie eine Option, um Audio-Warnmeldungen visuell anzuzeigen.

Erklärung:
Gehörlose Menschen können Töne gar nicht wahrnehmen und schwerhörige Menschen nur sehr begrenzt. Damit diese Personen Töne(Informations- oder Warnsignale) wahrnehmen können müssen diese visuell durch ein Meldungsfenster oder einer Statusinformation angezeigt werden.

3.2 Bieten Sie zugängliche Alternativen für wichtige Audio- und Videosequenzen.

Erklärung:
Für Gehörlose und Schwerhörige sind Hörbeiträge (=Audio) oder Videos mit Ton nicht wahrnehmbar. Deswegen sollte in einer Software immer eine Alternative zur Audio oder Videowiedergabe geben. Am besten eignet sich hierfür Text der bei Videos auch in Form eines Untertitels bereitgestellt werden.

3.3 Bieten Sie eine Option zum Einstellen der Lautstärke

Erklärung:
Schwerhörige müssen den Ton lauter stellen wie nicht Schwerhörige. Blinde und Sehbehinderte sind auf Audiowiedergabe angewiesen und müssen deswegen die Lautstärke regulieren können um andere Geräusche im Umfeld übertönen zu können.

 

4 Anzeige

4.1 Erzeugen Sie Text durch normale Systemfunktionsaufrufe oder einer API (Schnittstelle für Anwendungsprogrammierung), die die Interaktion mit assistiver Technik unterstützen.

Erklärung:
Screenreader können nur systemgestützte Zeichenoperationen wahrnehmen. Wenn Text nicht standardmäßig dargestellt wird, kann der Screenreader diese Informationen nicht an den Benutzer weitergeben.

4.2 Benutzen Sie Farbe als eine Ergänzung und nicht ausschließlich, um Informationen zu übermitteln oder Aktionen anzuzeigen.

Erklärung:
Grundsätzlich kann Farbe ein wichtiges Hilfsmittel sein um Informationen besser darzustellen. Sie sollten es vermeiden Farbe als wesentliches Merkmal einzusetzen. Menschen mit einer Farbfehlsichtigkeit ( http://de.wikipedia.org/wiki/Farbfehlsichtigkeit )haben große Probleme Farben zu erkennen und zu unterscheiden. Es ist zum Beispiel nicht sinnvoll einen Benutzer dazu aufzufordern einen „grünen“ Schalter anzuklicken wenn dieser grün und braun nicht unterscheiden kann. Deswegen sollten Sie den Schalter beschriften mit „Übernehmen“.

4.3 Unterstützen Sie Einstellungen für starken Kontrast für alle Bedienelemente des Benutzerinterfaces und Client-Bereiches.

Erklärung:
Die Verwendung von bestimmten Farben ist oft kritisch. Farbfehlsichtige und Sehbehinderte können damit ein Problem haben. Sie benötigen einen hohen Kontrast zwischen Hintergrundfarbe und Schriftfarbe. Im Betriebssystem Windows in der Systemsteurung kann der Farbkontrast eingestellt werden. Deswegen muss eine Software in der Lage sein, diese Farbeinstellungen zu übernehmen, sonst hilft es der oben genannten Personengruppe nicht, dass der Kontrast im Betriebssystem anpasspar ist.

4.4 Wenn kundenspezifische Farbanpassung durch das Programm unterstützt wird, bieten Sie vielfältige Farbeinstellungsmöglichkeiten, damit mehrere Kontrastniveaus erzeugt werden können.

Erklärung:
Farbfehlsichtigkeit und Sehbinderungen können sich sehr unterschiedlich auswirken. Deswegen sollten die Möglichkeiten der Farbeinstellungen sehr individuell gehalten werden.

4.5 Übernehmen Sie die Systemeinstellungen für Schriftart, Größe und Farbe für alle Steuerelemente der Benutzerschnittstelle.

Erklärung:
Menschen mit einer Sehbehinderung benötigen eine größere Schrift. Im Betriebssystem Windows kann die Systemschriftgröße eingestellt werden. Deswegen sollten Beschriftungen von Eingabefelder und Schalter und die Eingabefelder selbst diese Schriftgröße übernehmen.

4.6 Bieten Sie eine Option an, die Animationen in einer nicht animierten Form darstellt.

Erklärung:
Animierte Informationen sind für Blinde nicht wahrnehmbar. Stellen Sie sicher, dass Animationen angehalten werden können. Desweiteren sollten Sie die in der Animation übermitteten Informationen alternativ, zum Beispiel als Text, bereitstellen.

 

5 Timing

5.1 Bieten Sie die Möglichkeit, die Reaktionszeit auf zeitlich begrenzte Hinweise einzustellen oder ermöglichen Sie den Verbleib des Hinweises.

Erklärung:
Menschen die eine Einschränkung in der Bewegung der Arme oder Hände haben, können oft nur sehr langsam auf Ereignisse oder Hinweise reagieren. Deswegen sollte die Zeitspanne, wie lange ein Hinweis angezeigt wird, einstellbar sein.

5.2 Verwenden Sie keine leuchtende oder blinkende Texte, Objekte oder andere Elemente mit einem Blitz oder blink Frequenz größer als 2 Hz und kleiner als 55 Hz.

Erklärung:
Anzeigen, die flackern oder blinken, können bei empfänglichen Menschen epileptische Anfälle auslösen, besonders wenn das Blinken eine hohe Intensität in einem Frequenzbereich zwischen 2 Hz und 55 Hz hat. Das schließt blinkenden Text, das Ein- und Ausschalten von Grafik oder das Wechseln zwischen unterschiedlichen Bildern ein.

Das sind die Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM.

Entwicklungsumgebungen für die Software-Entwicklung sollten Modus für Barrierefreiheit haben

Mit dem heutigen Artikel möchte ich versuchen etwas anzuregen. Damit es die Software-Entwickler bei der Entwicklung von barrierefreier Software leichter haben, sollten Entwicklungsumgebungen einen Modus haben, der während der Arbeit Überprüft ob die Software barrierefrei ist.

Um das Thema barrierefreie Software-Entwicklung einer breiteren Öffentlichkeit zugänglich zu machen, gab es letztes Jahr eine ganze Blogartikelreihe zur barrierefreien Software-Entwicklung. Durch ein Gespräch in der letzten Woche bin ich auf die Idee gebracht worden, dass es für die Software-Entwickler eine große Erleichterung ist, wenn die Entwicklungsumgebung eine Möglichkeit hätte die Barrierefreiheit während der Entwicklung zu überprüfen. Eine Entwicklungsumgebung ist eine Software mit dessen Hilfe Programmierbefehle eingegeben werden um eine neue Software zu erstellen. Jede Programmiersprache hat Ihre eigene Entwicklungsumgebung.
Ich könnte mir das folgender Maßen vorstellen:
Zunächst mal wäre es sinnvoll, dass die Hersteller von Entwicklungsumgebungen die Richtlinien für barrierefreie Software-Entwicklung veröffentlichen. Es gibt Richtlinien von Sun / Oracle und Microsoft. IBM hat auch Richtlinien für barrierefreie Software-Entwicklung, stellt aber keine Entwicklungsumgebung her.
Als zweites möchte ich die Idee von meinem Besuch aufgreifen. Es lassen sich mit Sicherheit nicht alle Kriterien der Barrierefreiheit per Software überprüfen, aber einige schon. Hierfür könnte es einen bestimmten „Modus“ geben oder dass ein bestimmter Haken gesetzt werden muss innerhalb der Entwicklungsumgebung. Die Entwicklungsumgebung überprüft nur dann auf Barrierefreiheit, wenn dieser Modus aktiviert ist.
Für Java könnte zum Beispiel überprüft werden ob für die Programmoberfläche Swing-Komponenten verwendet wurden, weil nur diese eine Möglichkeit besitzen Screenreader mit Informationen für blinde und sehbehinderte Menschen zu versorgen.

Hier sind wir bei dem zweiten Kriterium. Wenn eine Software für blinde und sehbehinderte Menschen bedienbar sein soll, dass müssen die Komponenten für die Programmoberfläche Informationen für Screenreader bereitstellen. Dies geschieht über bestimmte Eigenschaften der Komponenten. Die Entwicklungsumgebung könnte hier überprüfen ob diese Eigenschaften Texte enthalten oder ob diese Eigenschaften leer sind.

Ein weiteres wichtiges Kriterium ist die Bedienbarkeit per Tastatur. Blinde und Sehbehinderte arbeiten nicht mit der Maus, sondern mit der Tastatur. Deswegen gehört es zu einer barrierefreien Software dazu, dass eine Software komplett per Tastatur bedienbar ist. Hier könnte die Entwicklungsumgebung überprüfen ob Menüs auch über Tastenkürzel erreichbar sind, ob Java-Entwickler mittels Labelfor Beschriftungen von Eingabefeldern per Tastenkürzel erreichbar sind und vieles mehr!
Wenn der Modus zur Überprüfung auf Barrierefreiheit aktiv ist und es ist ein Kriterium nicht erfüllt, sollte der Compiler eine Fehlermeldung anzeigen, und die Compilierung, so heißt der Vorgang wenn aus Befehle Maschinencode generiert wird, bricht ab! Somit wären die Software-Entwickler gezwungen sich um die fehlende Barrierefreiheit zu kümmern!

Ich möchte mit diesem Artikel nur Anregungen geben und würde mich freuen, wenn Hersteller von Entwicklungsumgebungen mit mir Kontakt aufnehmen würden um diese Idee in die Tat umzusetzen.