In den vergangenen Wochen habe ich mich intensiv in die Entwicklung komplexer Anwendungen mit Java eingearbeitet. Das man mit einem Editor und den Kommandowerkzeugen javac und java gut mit einem Screenreader arbeiten kann, ist nichts Neues.
Die Entwicklungsumgebung Eclipse ist auch schon lange für seine gute Zugänglichkeit bekannt. Wo ist hier also die Überraschung?

Bei der Entwicklung von Mehrschicht-anwendungen sind eine ganze Reihe von Editoren und Werkzeugen notwendig, die nicht automatisch bei der Entwicklung kleinerer Desktop-anwendungen benutzt werden müssen. Da es nur wenige blinde Java-Entwickler gibt, war nicht klar, ob alle diese Werkzeuge genauso gut zugänglich sind, wie man es von den Standardansichten in Eclipse gewohnt ist. Die gute Zugänglichkeit von Eclipse basiert zum Großteil darauf, dass keine Swing-Steuerelemente verwendet werden, sondern native Steuerelemente des Betriebssystems. Dadurch verhält sich das ganze wie jede andere Windows-Anwendung auch. Allerdings ist die Zugänglichkeit genau dann vorbei, wenn es notwendig ist, ein Steuerelement mit anderen Mitteln zu realisieren – z.B. weil es kein entspr. natives Steuerelement auf allen Plattformen gibt. Wie uns auf einer Tagung der BFG IT vor Jahren kompetent erläutert wurde, ist es in solchen Fällen sehr schwer und aufwendig, die Zugänglichkeit einzubauen. Tatsächlich zeigte sich relativ früh ein solches Objekt. Beim Generieren von Entitätsklassen aus den Tabellen einer Datenbank kann man die Spalten und deren Eigenschaften nicht ändern. Glücklicherweise kann man wenigstens alles übernehmen und im Nachhinein im Code bearbeiten.

Ein weiteres Problem tritt auf, wenn man Unittests ausführen will. Hier werden die Ergebnisse (erfolgreich oder fehlgeschlagen) über Icons im Baum angezeigt. JAWS-Anwender können hier die Grafiken beschriften, aber NVDA-Benutzer sehen diese Icons nicht. Das gilt übrigens für alle Icons, die an Bäumen in Swing-Anwendungen hängen. Im Gegensatz zu Eclipse sind sie in Swing-Anwendungen auch für JAWS nicht mehr auslesbar. Hier wäre es wohl notwendig, die Zugänglichkeitsschnittstellen so zu erweitern, dass Objekte zusätzlich zu den Status wie angehakt, ausgewählt etc. auch anwendungsspezifische Status haben können. In Java kann man hierfür jedem Bild einen Alternativtext geben, der als Statustext verwendet werden könnte.

In einigen Projekten ist es notwendig eine ältere Version von Eclipse z.B. Eclipse Juno zu verwenden. Hier fällt auf, dass beim Navigieren im Baum zunächst immer der zuvor ausgewählte Eintrag vorgelesen wird und anschließend der nun selektierte. daran kann man sich zwar gewöhnen, es kostet auf die Dauer aber viel Zeit. Die Lösung für das Problem war verblüffend einfach. Bei neuen Versionen von Eclipse tritt das Problem nicht auf, aber dafür in allen Java-Anwendungen, die einen Baum verwenden. Es fiel auf, dass NVDA für die ältere Eclipse-Version wie für die Java-Anwendungen javaw.exe als Anwendungsnamen identifiziert, während es in der aktuellen Eclipse-Version eclipse.exe ist. für Eclipse gibt es im NVDA-Quellcode eine eclipse.py die mit wenigen Zeilen Code die erste Meldung ausschaltet und damit den Fehler, der eigentlich in der Java-Zugänglichkeitsschnittstelle steckt ausbügelt. Das Kopieren dieser Datei in javaw.py in eigenen Erweiterungsverzeichnis von NVDA behebt das Problem für das alte Eclipse und alle Java-Anwendungen. Herausgefunden habe ich das nicht alleine, sondern durch den Austausch mit James Teh dem zweiten NVDA-Hauptentwickler.

Der Vorfall zeigt auf, dass für Java die bisherigen Konzepte zur Erweiterung von Anwendungen nicht mehr greifen, denn die haben sich immer am Anwendungsnamen orientiert – und dieser ist für alle Java-Anwendungen java.exe oder javaw.exe.

Das Debuggen in Client und Server inkl. dem Verfolgen des Callstacks oder das Inspizieren von Objekten war leicht möglich. Durch die Tastenkürzel für die üblichen Schritt- und Haltepunktaktionen kann man schnell und effizient arbeiten.

Eine echte Barriere war der Installer des Glassfish-Servers, der vollkommen unzugänglich ist. Zum Glück kann man den Server auch als Zip-Datei herunterladen. Das Oracle es nicht schafft, einen zugänglichen Installer bereitzustellen spricht allerdings für sich.

Alles in Allem ist die Erprobung mit verblüffend wenig Hindernissen verbunden gewesen. Dinge wie die oben beschriebenen Steuerelemente und Statusbilder sind zwar ärgerlich, aber keine wirkliche Barriere. Da die Applicationserver wie Glassfish oder Websphere alle über eine Weboberfläche zur Administration verfügen und die verwendeten Plugins in Eclipse sich in den meisten Fällen aus den bereits verwendeten Steuerelementen bedienen, treten auch hier relativ wenig Probleme auf. Ein Hindernis war z.B. das Bedienen des Subversion-Plugins mit dem man den Code gegen die Versionsverwaltung synchronisiert. Vermutlich wird man sich Änderungen und Konflikte über den klassischen Subversion-Client ansehen müssen.

Die Erprobung wurde vollständig mit NVDA durchgeführt. JAWS dürfte wohl ähnliche Ergebnisse liefern, weil spätestens bei Swing-Anwendungen die Zugänglichkeitsschnittstelle in Java das Nadelöhr ist. Was sie nicht liefert sieht keiner der Screenreader und das auslesen der angelieferten Attribute ist keine Herausforderung für einen Screenreader. Ein Offscreenmodell, wie es in Windows-Anwendungen sonst üblich ist, müssten sich die Reader hier mühsam anhand der gemeldeten Positionsangaben der Zugänglichkeitsobjekte zusammenbauen. Bis dahin ist man auf die Tastaturnavigation der Anwendung festgenagelt, oder man muss sich durch den Objektbaum hangeln. Wehe, wenn ein wichtiges Steuerelement für die Arbeit keinen Hotkey oder Menübefehl hat. Apropos: Eclipse ist u.a. deshalb so gut zugänglich, weil es tonnenweise Tastenkürzel gibt.

OK, und was ist, wenn ein Projekt nicht mit Eclipse entwickelt wird? Das kann sehr unterschiedlich sein. Da gibt es z.B. IntelliJ von http://www.jetbrains.com. Die Anwendung ist vollkommen unzugänglich – man kann NICHTS lesen. Auf eine Supportanfrage wurde ich mit “It is a known issue” auf einen Bugeintrag verwiesen. Der Inhalt ist rasch erklärt: Der Autor ist mir über die NVDA-Entwicklerliste bekannt und er hat alles versucht um nach Kräften zu unterstützen, aber seit dem der Fehler vor einem Jahr angelegt wurde, sind keine Kommentare des Herstellers eingefügt worden. Selbst wenn es einen Fix gäbe, würde s wohl noch lange dauern, bis eine solche Umgebung hinreichend zugänglich ist.

Als dritte IDE gibt es noch NetBeans von http://www.netbeans.org. Hier fällt positiv auf, dass Zugänglichkeit dort ein Thema ist, dass auf den Seiten diskutiert wird. Das Stichwort heißt hier A11Y. Ein Schnelltest zeigte zwar, dass die Menüs und Editoren zwar grundsätzlich zugänglich sind, aber dass es doch noch an vielen Stellen hakt. Z.B. wird beim Navigieren in einem Java-Editor der Screenreader in einen Baum gerufen, während der Fokus im Editor verbleibt. Beim Versuch die Anwendung im Detail zu justieren, konnte ich den Optionen-Dialog nicht öffnen. Ich vermute aber, dass es sich hier um Details handelt, die man mit dem Hersteller klären könnte.

== Fazit ==
Die Entwicklung komplexer Mehrschicht-Anwendungen ist für blinde Menschen im professionellen Umfeld gut möglich. Es gibt zwar einige Hindernisse und Stolperfallen, aber die sind bei der Komplexität der Anwendungen wohl normal. Es kommt wie immer auf die Details an, ob der Einsatz in allen Projektbereichen möglich ist. Da das Eis wie beschrieben sehr dünn sein kann, habe ich den Rettungsanker schon bereitgelegt: Ich arbeite mich in Python und das Objektmodell von NVDA ein, um im Notfall die benötigten Änderungen umsetzen oder zumindest initiieren zu können. Es ist wohl nur eine Frage der Zeit, bis ich aktiv den Weg freiprogrammieren muss.

Ich hoffe, dass ich mit diesem Artikel anderen blinden Entwicklern ein paar hilfreiche Erfahrungen mitgeben konnte.