Schlagwort-Archiv: Eclipse

Die langen Schatten der Zukunft werfen ein helles Licht

enstern Dialogen und Menüs auch nach zwei Jahren immer noch nicht ernsthafte Schwachstellen in Puncto Barrierefreiheit offenbart, dann ist das schon bemerkenswert. Wenn der Screenreader eigentlich kaum mehr zu tun hat, als dem Systemfokus zu verfolgen und keine Tricks mit Skripten, virtuellen Ansichten der Anwendung oder dem Training von Werkzeugleisten notwendig sind, dann ist das wohl mustergültig.

Es ist ein Déjà-vu für mich, dass eine Entwicklungsumgebung barrierefreier ist, als fast alle anderen Anwendungen. Damals war es Visualstudio 4.2. Recht gut mit Protalk benutzbar, während nicht einmal die Eingabeaufforderung mit dem Screenreader ausgelesen werden konnte.

Die Schatten aus der Zukunft heißen Eclipse – denn eclipse heißt eigentlich Verfinsterung. Es wäre natürlich viel passender unter einem solchen Namen eine Anwendung ordentlich zu zerpflücken und sich über die Unzulänglichkeiten auszulassen. Aber in diesem Fall habe ich weder Chance noch Grund.

ich habe schon mal über die Nutzung von Eclipse mit Screenreadern geschrieben, aber diesesmal geht es mir eher um das, was die Zugänglichkeit ausmacht und was gut auf andere Anwendungen übertragbar ist.

Von der Oberfläche aus betrachtet geht es bei Eclipse darum viele verschiedene Aspekte einer Arbeitsumgebung so darzustellen, wie es ein Anwender gerade benötigt. Wenn man, warum auch immer, gleichzeitig Fehler beheben und etwas grafisch modellieren möchte, während man gleichzeitig Einstellungen in der Steuerdatei bearbeitet, die dafür sorgt, das ein ganzes Team einheitlich arbeiten kann, dann zeigt das die Flexibilität von Eclipse auf. Nun könnte man annehmen, dass so verschiedene Aufgaben mindestens in unterschiedlich aussehenden Dialogen mit eigenen Hotkeys etc. stattfinden, aber dem ist interessanterweise eher nicht so. Die Menge an benötigten Tastenkombinationen hängt eher davon ab, ob man sich die Mühe macht die Umgebung auf die aktuell benötigten Ansichten zu reduzieren. Anders gesagt, der effizienten Benutzung ob nun mit oder ohne Screenreader steht nur die eigene Arbeitsweise im Weg.

Es gibt unzählige Beispiele für Anwendungen mit ähnlich hoher Komplexität:

  • Digital Audio Workstations (DAW)
  • Fachanwendunen wie sie in Servicecentern zum Einsatz kommen um die verschiedenen Anwendungsfälle und Aspekte zu bearbeiten, die durch Anrufer etc. ausgelöst werden.
  • CMS, CRM und andere Werkzeuge um Kontakte und deren Metadaten zu verwalten

Wendet man die guten Lösungen aus der Finsternis auf solche Anwendungen an, erhält man sowohl eine gute Ergonomie für alle Anwender und eine barrierefreie Anwendung. Welche Art von Prozessen, Organisation etc. die Anwendung konkret umsetzt, ist dabei eigentlich nebensächlich. Worin besteht also der Trick bei Eclipse?

  • Alle Elemente der Oberfläche sind per Tastatur erreichbar. Das gilt auch für Elemente die keine Interaktion erlauben, als auch für Werkzeugleisten. Man kann Teile per Hotkey aktivieren, aber sie sind ebenso über das Menü oder andere Wege erreichbar – sich Tastenfolgen zu merken ist zwar schneller, aber kein Ausschluss Kriterium.
  • Die Ansichten folgen immer einem ähnlichen Schema

    • Werkzeugleisten Menüs Navigationselement
    • Details
  • Eine Ansicht oder Gruppe von Ansichten kann schnell geschlossen und wieder geöffnet werden.
  • Werkzeugleisten sind vollständig mit den Pfeiltasten navigierbar und auch deaktivierte Elemente werden dabei angesprungen.
  • Zusatzinformationen, die am Rand notiert werden und nicht per Cursor erreicht werden können, sind über eine eigene Navigation erreichbar und die Details können in einem Dialog angezeigt werden. Ein Benutzer eines Screenreaders kann dadurch entscheiden, ob er sich für die ‘Details einer Infoblase interessiert oder nicht.
  • Deutlich mehr Tastenkombinationen als in vielen anderen Anwendungen.
  • Dialoge mit einer Textbox, über die man die Menge der angezeigten Einträge reduzieren kann. Wenn Sie z.B. nicht wissen, wo sich irgendeine Maven-Einstellung verbirgt, dann beginnen Sie gar nicht erst lange mit der Suche, sondern geben maven in die fikterbox ein. Schon wird aus dem 10-Seiten-Dialog ein übersichtlicher Dialog mit wenigen Einträgen.

Darüber hinaus werden Fachanwendungen etc. immer spezielle dialoge oder Interaktionen mit dem anwender haben, bei denen Barrieren vorprogrammiert sind. Kurven können nicht mit der Maus gemalt werden und Objekte auf einer Oberfläche Platzieren sind nahezu unmöglich. Aber s wäre gut, wenn sich die Hindernisse auf solche Dinge beschränken ließen, denn dann könnte das Wissen um mögliche Lösungen effizienter Barrieren beseitigen, als die gleichen Probleme wieder und wieder lösen bzhw. Wiederholen zu müssen.

Die Beseitigung einer Barriere (sei sie so banal wie eine fehlende Beschriftung oder ein Hotkey) ist mittlerweile ein komplexer Prozess. Anwendungen bestehen aus vielen Teilen verschiedener Autoren und es gilt zu identifizieren, welcher Teil der Anwendung für die Barriere verantwortlich ist. Wenn beispielsweise das Sbuclipse-Plugin in Eclipse nicht zugänglich ist, hat das nichts mit Eclipse selbst zu tun und man müsste die Autoren des Plugins ansprechen. Egal wie schnell hier eine Lösung wäre: Man müsste stets eine Aktualisierung abwarten.

Fazit: Die Entwickler sollten sich an ihrem Lieblingswerkzeug orientieren und ihren Anwendungen genau das beibringen, was ihr eigenes Entwicklungswerkzeug für sie tut. Dummerweise stehen hier oft die Meinung der Anwender und Anforderer im Weg. Für diese ist eine Ausstattung mit Tastenkombinationen und Menüs schnell ein nettes Feature das gerne dem Rotstift weicht. Eine vollständige Zugänglichkeit per Tastatur und die konsequente Verwendung von Standarddialogen bzw. einem einheitlichen Look-And-Fel einer anwendung sollte Bestandteil in einer Norm für gurte und professionelle Software sein.

Gute Berufsmöglichkeiten für blinde Java-Entwickler

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