Gibt es Barrierefreie Informationstechnik auch in Deutsch?

Das wichtigste was ich in der Schule gelernt habe ist englisch! Ohne Englisch wäre meine Arbeit in Sachen Barrierefreie Informationstechnik nicht möglich!

Die eigentliche Idee von barrierefreie Informationstechnik

Die barrierefreie Informationstechnik hatte die Idee, dass Webseiten von allen Menschen gelesen und bedient werden können und dass Software von allen Menschen bedient werden können. Wenn Internetseiten barrierefrei gemacht werden, sollte darauf geachtet werden, dass beim Schreiben von Texten „Einfache“ Sprache verwendet werden soll!

Ist die Sprache „Englisch“ einfach?

Immer wieder erlebe ich es, dass es zu deutschprachigen Produkten ( z. B. WordPress  ) es keine deutschsprachige Unterstützung in Sachen Barrierefreiheit gibt!
Das einzge was ich gefunden habe zu WordPress ist diese englisch-sprachige Webseite:
Make WordPress Accessible
Ein tolles Beispiel liefert auch diese Webseite von Google:
Kontakt – Google Barrierefreiheit im Web
Eigentlich eine deutschprachige Webseite, aber mit englisch-sprachigen Auswahlmöglichkeiten!
Wer barrierefreie Software mit der Programmiersprache Java entwickeln möchte hat ebenso Pech! Das Weltunternehmen Oracle bietet für Software-Entwickler für die Programmiersprache Java nur englisch-sprachige Dokumentation an:
Java Accessibility Guide
Also für mich ist englisch einfach, weil ich es kann! Wer aber kein Englisch kann und sich trotzdem über barrierefreie Informationstechnik informieren möchte hat ein großes Problem!

Positive Beispiele: barrierefreie Informationstechnik in deutsch

Zum Schluss möchte ich noch zwei positive Beispiele zeigen:
Android Accessibility-Hilfe
Naja, das Wort „Accessibility“ ist nicht wirklich deutsch, aber der Inhalt der Webseite ist deutsch!
Exemplarische Vorgehensweise: Erstellen von behindertengerechten Windows-basierten Anwendungen

Schlussbemerkungen zu barrierefreie Informationstechnik in deutsch:

barrierefreie Informationstechnik fängt nicht erst beim „programmieren“ an, sondern beim Texte schreiben. Für deutschprachige Menschen ist deutsch wesentlich „einfacher“ zu lesen wie englisch. Meiner Meinung nach sollte Oracle und WordPress in Sachen deutschprachige Unterstützung zur Barrierefreiheit dringend was tun!

Richtlinien barrierefreie Software-Entwicklung für Java von Oracle

Da ich gerade einen großen Auftrag habe bei dem ich eine Java-Software barrierefrei machen darf, werde ich heute die Richtlinien von Oracle, die ich ins deutsche übersetzt habe wiedergeben.

Um barrierefreie Software-Entwicklung mit Java zu machen bedarf es Richtlinien. Diese Richtlinien orientieren sich an den Bedürfnissen von Menschen mit Behinderungen. Das Unternehmen Oracle hat die Programmiersprache Java entwickelt. Da Java die Voraussetzungen hat für barrierefreie Software-Entwicklung hat Oracle hierfür Richtlinien herausgegeben. Diese Richtlinien werde ich hier wiedergeben mit Erklärung:

1. Kriterium:
Wenn eine Komponente keinen ‘short string’ anzeigt, dann legen Sie einen Namen mit der setAccessibleName Methode fest. Sie können das auf ‚image-only buttons’, ‚panels’ mit logischer Gruppierung, Text Felder usw. Anwenden.

Erklärung:
Es kann grundsätzlich nichts schaden jeder Komponente einen AccessibleName zu geben. Der AccessibleName soll den Zweck der Komponente kurz beschreiben.
Zum Beispiel „Beenden-Schalter“. Auf jeden Fall sollte man, wann immer es geht und Sinn macht, Tooltips bei Komponenten angeben. Wie oben beschrieben werden die Tooltips auch in die Eigenschaft AccessibleDescription eingetragen.

2. Kriterium:
Wenn Sie eine Komponente nicht mit einem ‘tooltip’ versehen wollen, dann benutzen Sie die setAccessibleDescription Methode um eine Beschreibung über die Unterstützungstechnologie an den Benutzer weiter zu geben. Zum Beispiel: aJComponent.getAccessibleContext(). setAccessibleDescription(„Clicking this component causes XYZ to happen.“);

Erklärung:
In der Eigenschaft AccessibleDescription kann man einen längeren Text angeben, der den Sinn und Zweck der Komponente beschreibt. Dieser Text wird z.B. von Screenreadern gelesen und dem blinden oder sehbehinderten Menschen mitgeteilt.

3. Kriterium:
Sehen Sie, wo immer möglich, alternative Tastatureingaben vor. Sie sollten sicher stellen, das Ihr Programm nur mit der Tastatur bedient werden kann. Denken Sie daran das Sie aus einem editierbaren Feld mit ‚Shift-Tab’ den Fokus auf die nächste Text Komponente setzen können.

Erklärung:
Blinde und sehbehinderte Menschen arbeiten oft mit der Tastatur, weil das arbeiten mit der Maus nur dann funktioniert, wenn man genau sehen kann wo der
Mauszeiger ist. Deswegen ist es für beide Personengruppen wichtig, dass die Software auch per Tastatur bedienbar ist.

4. Kriterium:
Weisen Sie allen ImageIcon Objekten in Ihrem Programm eine textuelle Beschreibung zu. Sie können diese Eigenschaft festlegen, indem Sie entweder die setDescription Methode oder eines der String Formulare der ImageIcon Konstruktoren verwenden.

Erklärung:
Nicht nur auf Internetseiten, sondern auch bei Software haben blinde Menschen erhebliche Probleme mit Bildern/Grafiken. Stellen an den Bildern platziert sind, werden von Blinden als leere Fläche wahrgenommen. Deswegen ist es auch bei Software wichtig, dass man Bildern eine Textbeschreibung mit gibt, damit die Screenreader-Software dem Blinden was vorlesen kann.

5. Kriterium:
Wenn eine Gruppe von Komponenten eine logische Gruppe bilden, versuchen Sie diese in einen Container zu setzen. Verwenden Sie zum Beispiel ein JPanel das alle Radio-Buttons enthält die zu einer Radio-Button-Gruppe gehören.

Erklärung:
Das Gruppieren von Komponenten macht die Programmoberfläche übersichtlicher. Wenn die Container-Komponente noch einen sprechenden AccessibleName hat, kann das für einen Blinden eine enorme Erleichterung sein, um sich schneller auf der Programmoberfläche zu orientieren. Zum Beispiel könnte man Eingabefelder zum erfassen von einer Adresse in einen Container mit dem AccessibleName „Adressdaten“ gruppieren.

6. Kriterium:
Wann immer Sie ein Label verwenden welches eine andere Komponente beschreibt, verwenden Sie die setLabelFor Methode damit die Unterstützungstechnologie die Komponente finden kann die zu dem Label gehört. Dies ist besonders wichtig, wenn das Label eine Gedächtnisstütze für eine andere Komponente (z.B. ein Text Eingabefeld) ist.

Erklärung:
Dies hängt unmittelbar mit Punkt 3 zusammen. Hier geht es wieder u.a. darum, dass die Software auch per Tastatur bedienbar sein sollte. Außerdem können aber
auch Screenreader die Zusammenhänge zwischen Label und Eingabefeld so besser erkennen.

7. Kriterium:
Wenn Sie eine benutzerdefinierte Komponente erstellen, stellen Sie die Zugänglichkeit sicher. Insbesondere beachten Sie, dass Unterklassen von JComponent nicht automatisch zugänglich sind. Benutzerdefinierte Komponenten, die Nachkommen anderer Swing-Komponenten sind, sollten, wenn notwendig, die geerbten barrierefreie Informationen überschreiben.

Erklärung:
Wenn man Java-Komponenten selber entwickelt, sollte man darauf achten, dass diese auch barrierefrei sind.

8. Kriterium:
Verwenden Sie die Beispiele die Sie bei den Dienstprogrammen für Barrierefreiheit finden um Ihre Programm zu testen. Obwohl der primäre Zweck dieser Beispiele dafür gedacht ist den Umgang mit der Accessibility-API zu zeigen, sind sie auch sehr nützlich um Anwendungsprogramme auf Barrierefreiheit zu testen. Eine Prüfung auf Barrierefreiheit zeigt ScrollDemo die mit Monkey läuft. Monkey zeigt den Baum der zugänglichen Komponenten in einem Programm und ermöglicht es Ihnen mit diesen Komponenten interagieren.

Erklärung:
Es gibt Beispiele von Sun/Oracle zum Thema Accessibility

9. Kriterium:
Wenn Ihre GUI(=Programmoberfläche) einen Container hat der nicht zugänglich ist, zum Beispiel, Ihre eigene Container Unterklasse, eine JComponente oder einen anderen Behälter, die von dem Zugänglichkeitsdienstprogramm nicht erreicht wird, sind alle Komponenten in dem Container nicht erreichbar.

Erklärung:
Komponenten die in einem nicht barrierefreien Container sich befinden, sind für Eingabehilfen und andere unterstützende Software nicht erreichbar.

10. Kriterium:
Alle wichtigen Funktionen der Software sollten über Tastenkürzel(engl. Shortcuts) ansteuerbar sein.

Erklärung:
Sehbehinderte und Blinde, welche die Software nur per Tastatur bedienen profitieren von Tastenkürzel für wichtige Funktionen.

11. Kriterium:
Vermeiden Sie es Farb-und Schrifteigenschaften unveränderlich zu machen Die Software benötigt einen Einstellungsdialog für Farben und Schriftgrößen.
Wenn der Anwender in der Systemsteuerung die Schriftgröße verändert, muss die Software diese übernehmen!

Erklärung:
Menschen die Farbenblind sind, können eventuell mit den von Ihnen gewählten Farben Probleme haben. Deswegen sollte es in der Java-Anwendung ein Menü geben, in welchem der Anwender die Farben individuell einstellen kann.

12. Kriterium:
Vermeiden der Übermittlung wichtiger Informationen allein per Audioausgabe

Erklärung:
Stellen Sie sich vor, ein Mailprogramm würde das ankommen einer Mail nur akustisch signalisieren und die neue Mail wäre optisch nicht hervorgehoben. Gehörlose Menschen hätten keine Chance das eingehen von neuen Mails war zu nehmen. Deswegen ist es wichtig, dass man sich nicht nur auf Audioausgabe verlässt.

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.