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 (http://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 ( http://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.

Dieser Beitrag wurde unter barrierefreie Softwareentwicklung, Barrierefreiheit, Accessibility abgelegt und mit , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.