Schlagwort-Archiv: Musterlösung

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.