Kategorie-Archiv: Zugänglichkeit

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.

Kopfhörer raus! Geld her!

Als unsere lokale Filiale Der NordLB umgezogen war, wurden Geldautomaten aufgestellt, mit denen man blind per Sprachausgabe Geld abheben können sollte. Die gesichter der Mitarbeiter wurden ziemlich lang, als mein spontaner Praxistest keinerlei Sprache ergab. Nach einigem hin und her stellte sich heraus, dass für die Sprachausgabe eine spezielle software in einem Rechenzentrum hätte eingespielt werden müssen. Die Automaten blieben stumm und das Problem des Geldholens bestehen.

Nun hat sich endlich etwas getan. Der lokale Blindenverein veröffentlichte eine Mitteilung, dass die automaten ihre Sprache nun gefunden hätten und das kam mir gerade recht. Also ein zweiter Praxistest und zwar ohne sehende Hilfe.

Das ergebnis hat mich positiv überrascht. Sobald der Kopfhörer direkt neben dem Kartenschlitz eingesteckt wird, beginnt die Menüführung zu sprechen. Ein paar Anmerkungen grundsätzlicher art hätte ich allerdings:
- Es ist etwas zynisch, dass die automaten ohne Sprachausgabe mit Blindenschrift beschriftet sind (also Kartenschlitz, Geldausgabe etc.), aber die mit sprachausgabe hier keine Beschriftung haben.
- Ich hoffe, dass die Entwickler so klug waren, den Bildschirm bei Verwendung der Sprachausgabe abzudunkeln bzw. zu verschleiern um neugierigen Passanten den Einblick zu nehmen. Mindestens sollte dies eine mögliche Option zu Beginn der Menüführung sein.

Die Menüführung beginnt damit, dass erläutert wird, wie die Karte einzulegen ist und Fehler hierbei werden kommentiert. Anschließend erhält man die Optionen Kontostand oder Auszahlung. Der Hinweis, das die Geheimzahl verdeckt einzugeben ist und bestätigt werden muss ist gut. Leider wird nicht gesagt, wo die Bestätigungstaste ist (nämlich unten rechts). Anschließend kommt der Teil, der mich in seiner Lösung interessiert hat. Normalerweise wählt man den Betrag durch Tasten Links und Rechts am Bildschirm aus. Hier hat man mitgedacht und steuert dies über den Nummernblock. sodass man nur mit dem Nummernblock interagieren muss.

Fazit: das selbstbestimmte und unabhängige Abheben von Bargeld ist nun in zwei Filialen der NordLB endlich möglich. Die Menüführung ist gut umgesetzt und es gäbe nur ein paar Details nachzubessern. Vielleicht könnten die automaten, die eine Sprachausgabe anbieten sich mit einem akustischen Hinweis alle X Sekunden bemerkbar machen, damit man sie leichter findet. Es bleibt zu hoffen, dass diese Geldautomaten sich endlich in der Fläche durchsetzen und das eigenständige Abheben von geld überall möglich ist.

Zugängliche und kostenlose Ausgabe von E-Mail-ertifikaten

Vor einiger Zeit habe ich darüber berichtet, dass PGP inzwischen gut zugänglich ist. Genauer hatte es immer an Kleopatra gehakt. Neben PGP gibt es schon lange den Standard S/MIME mit dem E-Mails signiert und verschlüsselt werden können. Das ist letztlich das gleiche Verfahren wie bei PGP, ist aber bereits in Outlook und Outlook Express (und anderen Mailprogrammen) integriert.

Diese Art von E-Mails, sind derzeit hauptsächlich beruflich interessant, weil viele der Anbieter solcher Zertifikate (man kann sich nicht einfach eines erstellen wie bei PGP) von kommerziellen Anbietern ausgegeben werden.

Allerdings gibt es diese Zertifikate auch kostenlos (genauso seriös). Dafür wurde schon vor langer Zeit die Organisation CACert.org www.cacert.org gegründet.

Ich habe mich dort registriert und bin zufällig angesprochen worden, ob ich die Webseite einmal auf Zugänglichkeit testen könnte. Das Ergebnis ist schlicht, dass sie bis auf Kleinigkeiten gut mit Screenreadern nutzbar ist. Ich bin kein WCAG oder BITV Experte, aber sie sollte gut von jedem Anwender bedient werden können.

Nachdem man sich angemeldet hat, muss man sich von mind. zwei anderen Nutzern (die eine spezielle Prüfung abgelegt haben) bestätigen lassen. Dazu trifft man sich (real) und weist sich mit seinem Ausweis aus. Anschließend kann man sich ein Zertifikat mit seinem eigenen Namen erstellen lassen, dass zum Signieren und Verschlüsseln von E-Mails benutzt werden kann.

Microsoft Office Online offenbar gut mit Screenreadern zugänglich

Microsoft hat ja schon länger eine Office-version, die über das Web funktioniert. Also eine sog. Cloud-Anwendung. Frühere Versuche einen solchen dienst mit NVDA & Co. zu nutzen waren immer recht kläglich gescheitert – zumindest als ich das mal probiert habe. Auch www.projectplace.de war überhaupt nicht zugänglich – letztlich ist das auch eine Webanwendung zur Bearbeitung von projektdokumenten.

Auf http://www.blind-geek-zone.net/ wurde nun in einem audiobeitrag Microsofts Onedrive www.onedrive.live.com vorgestellt. Die Bedienung erfolgt eigentlich wie bei einer normalen Webseite bzw. Webanwendung – man wählt menüs, Schalter etc. Im Fall von Onedrive macht der autor sich die Umschaltmöglichkeit von NVDA zwischen Brows mode (dort kann man mit h zu einer Überschrift springen etc.) und dem focus mode (dann werden alle Tasten an die Anwendung durchgereicht) zunutze. Durch das Umschalten, kann man dabei Auswahlen etc. bewusst an Onedrive weitergeben.

Bislang habe ich nur einen kurzen Test gemacht. Die Ergebnisse finde ich erstaunlich:

  • Das Eingeben von Text in Word Online ist wie in einem normalen Mehrzeiligen Textfeld. Allerdings reagiert Word im Web etwas träger und es wird Absatz bearbeitbar vorgelesen, wenn man mit den Pfeiltasten rauf und runter geht.
  • Das nachträgliche Kursivsetzen eines Textbereichs war intuitiv möglich – Text markieren, Focus mode verlassen und den Schalter für kursiv suchen. Das Ergebnis kann anschließend mit NVDA überprüft werden, in dem man die Schriftinformationen auf dem Text abruft (NVDA+f).
  • Eine Rechtschreibprüfung konnte ich durchführen. Allerdings habe ich nicht klar überblicken können, welches Wort genau gemeint war und welche Vorschläge gemacht wurden. Aber das mag an meiner mangelnden Erfharung mit Word Online zusammenhängen – es war eben der allererste Versuch.
  • In Excel werden die Texte zusammen mit den Zellen ähnlich vorgelesen, wie im klassischen Excel – allerdings auch hier verzögert. Ein detaillierter Test steht allerdings noch aus.

Auch wenn ich nur an der oberfläche gekrazt habe, kann man wohl sagen, dass Onedrive eine wirklich nutzbare Onlineversion von Office für Screenreadernutzer ist. ich habe NVDA verwendet, aber andere Screenreader, die die entspr. Zugänglichkeitsstandards einhalten – eine Umschaltung zwischen Browsen und Fokus bieten sie hoffentlich an.

Es ist schön, das Microsoft hier ohne langes Ringen mit Selbsthilfeverbänden etc. eine zugängliche Version für Screenreader erstellt hat. Das ist weit mehr, als man oft anderen Anbietern bei Anwendungen abringen kann. Auch wenn nicht alles leicht bedienbar und reibungslos ist, so ist die technische Machbarkeit doch gezeigt. Rausreden kann sich also nun keiner mehr.

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.

Woher kommen eigentlich die Ellen langen Seiten?

Wenn man in seinem Browser mit einem Screenreader gefühlt unendlich oft nach unten wandern kann, wenn die Liste an Links, Schaltern, Registerkarten und Tabellen im mittleren zweistelligen Bereich ist, dann befindet man sich in einer Webanwendung. Machen sich die Entwickler die Mühe so lange Seiten zu erstellen? Können sie nicht einfach kurze und übersichtliche Dialoge entwerfen?

Nein, denn die Seiten werden i.d.R. aus einer Reihe von Bausteinen generiert. Natürlich entscheiden die Entwickler darüber, welche Komponenten an welcher Stelle ihrer Anwendung angezeigt werden, aber sie sind dabei immer mehr vom HTML-Text entfernt, der beim Anwender im Browser angezeigt wird. Aus wenigen Skriptaufrufen oder deklarierten Komponenten werden dadurch im nu lange und komplexe HTML-Dokumente, die vom Browser einerseits und vom Screenreader andererseits interpretiert werden müssen.

Während bei der Verwendung von PHP der Entwickler den generierten HTML-Code noch relativ gut beeinflussen kann und ungefähr weiß, wie der Code an Ende aussieht, ist dies bei Frameworks wie JSF anders. Der Entwickler deklariert in XML- und XHTML-Dokumenten den Seitenaufbau, deren Verknüpfung und bettet Aktionen etc. ein. Die Objekte mit denen er hantiert sind direkt an die Anwendungslogik gekoppelt, die in Java erstellt wird. Was am Ende tatsächlich im HTML-Code steht, entscheidet die JSF-Implementierung (JSF ist nämlich nur eine Spezifikation). Die Seiten werden also eher komponiert und durch abstrakte Regeln wird ihre Verknüpfung festgelegt.

Beratung bei der Gestaltung von Barrierefreien Seiten

Bislang haben sich die Spezialisten den HTML-code der Seiten angesehen und darauf basierend gezielt Hinweise gegeben, wie die Barrieren entfernt werden können. Das können sie zwar auch bei Webanwendungen tun, aber die verantwortlichen Entwickler haben kaum Kenntnis über den HTML-code, den sie generieren. Sie können ihn auch nur im Rahmen der Möglichkeiten von JSF und den Implementierungen beeinflussen. Damit sind sie in der gleichen Situation, wie die Entwickler von Desktop-Anwendungen. Damit solche Webanwendungen möglichst zugänglich bzw. barrierefrei sind, müssen zunächst die JSF-Implementierungen wie
Prime Faces korrekten Code im Sinne der WCAG erstellen.

JSF-Anwendungen kommen vor allem bei beruflichen Anwendungen zum tragen, weil sie eine komplexe Infrastruktur benötigen und auf verteilte und komplexe Logik ausgerichtet sind. Weil sich in diesem Kontext meistens keine Alternativen Anwendungen verwenden lassen (Ein Unternehmen installiert solche Anwendungen aus handfesten Gründen), wiegen Barrieren hier schwerer als bei Anwendungen im privaten Umfeld.

Wie bei Desktopanwendungen auch, ist die Zugänglichkeit durch das zugrundeliegende Framework eine Grundvoraussetzung, aber alleine nicht ausreichend. Nur der Entwickler weiß, welche Bereiche der Anwendungen mit welchen ARIA-Rollen ausgestattet werden müssen – welche Semantik die Informationen in einem bestimmten Bereich haben. Erst mit der neuesten JSF-Spezifikation ist es möglich geworden, solche Informationen über die Komponenten in den generierten HTML-Code einzuwerfen. Dies muss nun von den Implementierungen unterstützt und umgesetzt werden.
Der folgende Link beschreibt die Situation der Webanwendungen und die technischen Abhängigkeiten recht gut und nachvollzieh bar.
http://blog.akquinet.de/2013/07/26/the-state-of-web-accessibility-in-the-javaee-world/

Der folgende Link verweist auf ein Buch zu JSF und macht die Mächtigkeit und Tragweite von JSF für Webanwendungen deutlich.
http://jsfatwork.irian.at/book_de/jsf.html

Barrieren liegen auf der Lauer

Nun könnte man meinen, dass sich erst bei komplexen Tabellen und überfrachteten Seiten ernsthafte Probleme einstellen. Die Hindernisse finden sich aber schon in viel banaleren Situationen. Z.B. dann, wenn man einen Baum (z.B. ein Inhaltsverzeichnis oder eine Ordnerstruktur) darstellen möchte. Wenn man Glück hat, dann wird die Struktur aus wild in einander geschachtelten Listen zusammengesetzt. Das ist zwar nicht übersichtlich, aber wenigstens kann man den Inhalt lesen. Weil parallele Knoten in einzelnen Listen dargestellt werden, können hier Teile der Navigationstasten des Screenreaders nicht mehr helfen. Wenn man pech hat, und das erwähnte Prime Faces zum einsatz kommt, dann erkennt der Screenreader, dass eine Baumstruktur vorhanden ist, kann sie aber überhaupt nicht auslesen. Das wäre dann i.d.R. ein Knockout-Kriterium für die Zugänglichkeit einer Anwendung, weil sich in solchen Bäumen oft zentrale Informationen wiederfinden.

QT 5.3 und 5.4 bringen große und positive Veränderungen für die Zugänglichkeit

Offenbar wird in QT weiterhin fleißig an der Verbesserung der Zugänglichkeit gearbeitet. Das bedeutet auch, dass es neben Java ein weiteres plattformunabhängiges GUI-Framework gibt, für das eine gewisse Zugänglichkeit vorhanden ist.

Der folgende Blog-Artikel beschreibt die Änderungen in QT 5.3 und 5.4, die für diesen Bereich zu erwarten sind:
http://blog.qt.digia.com/blog/2014/05/14/accessibility-in-qt-5-3/
Dies betrifft vorallem zwei Dinge:

  1. QT-Anwendungen werden unter Mac OS deutlich zugänglicher
  2. Die Infrastruktur wird ab QT 5.4 nicht mehr als Plugins sondern direkt im Kern bereitgestellt. Das heißt, dass Software nicht mehr ohne die Schnittstellen ausgeliefert werden kann. Java hat diesen Schritt bereits vollzogen und es uns damit erheblich leichter gemacht.

Wir können also wohl positiv auf die weitere Entwicklung bei QT hoffen.

Einige Autoren von Anwendungen meinen, dass die Zugänglichkeitsschnitstellen in QT instabil seine und liefern sie teilweise deshalb bewusst nicht aus. Der Autor von Caliber sei hier beispielhaft genannt. Aber in Wahrheit sind die Schnittstellen nur eine Art Softwaretest. Durch die Verwendung eines Screenreaders werden viele Anfragen an das Datenmodell der Anwendung gestellt und wenn es kleine Fehler hat, dann stürzt die Anwendung gnadenlos ab. Verhindern können das die Anwendungen nur, wenn sie ein sauberes und stabiles Datenmodell erstellen. Diese Aussage ist keine graue Theorie, sondern erlebte Praxis. Eine Anwendung von uns stürzte mit Screenreaderverwendung solange ab, bis wir das Modell robuster und korrekter im Sinne der QT API gemacht haben. Und schwups, läuft die Anwendung problemlos mit NVDA.

Also: Ich freue mich sehr über diese Entwicklung.

Screenreader im Wandel der Zeit


Screenreader im Wandel der Zeit

Screenreader lesen für blinde Menschen den Inhalt des Bildschirms vor. Da es im netz bereits viele gute Erkläungen hierzu gibt, führe ich das hier nicht weiter aus.

Tschüß Offscreen-Modell

Screenreader müssen sich ständig den Gegebenheiten in aktueller Software anpassen. Es geht letztendlich darum, irgendwie die für den Anwender notwendigen Informationen zusammenzustellen. Da ist prinzipiell jedes Mittel recht, wenn es zum Erfolg führt.

In den Anfängen von Windows bestand eine zentrale Informationsquelle darim, die Grafikausgabe der Anwendungen zu verfolgen und daraus ein sog. Offscreen-Modell zu erstellen. Aus diesem Grund installieren die kommerziellen Reader einen Videotreiber im System. Durch das Abgreifen der Grafikausgabe kann dem Anwender ein genaues Bildschirmabbild aus Texten und Grafiken in Form von Codes bereitgestellt werden. Die Reader wissen außerdem, wenn ein Fenster ein anderes überlagert und zeigen nur das an, was wirklich optisch zu sehen war.

Neben der Grafikausgabe verfolgen die Reader auch die Win32-Ausgabekommandos über den sog. Device Context. Alle Anwendungen, die solche nativen Ausgabemethoden verwenden sind damit gut zugänglich.

Aber das Bild hat sich längst gewandelt. Moderne Frameworks wie QT, Java Swing oder .net verwenden eigene Methoden um Texte und Bilder auf dem Schirm zu bringen. Die beschriebenen Methoden für das Offscreen-Modell bleiben dabei vollkommen außen vor – es kommen auf diesen Kanälen keine brrauchbaren Informationen mehr an.

Stattdessen wurden Schnittstellen wie MSAA weiterentwickelt. Der aktuelle Standard heißt IAccessible2. Dabei wird aus der Holschuld der Screenreader eine Bringschuld der Anwendungen. Es ist, als wenn ein Geheimdienst sagen würde: “OK, wir hören euch nicht mehr ab – ihr müsst uns alles sagen, was wir brauchen.” Aber der Geheimdienst in Form des Screenreaders wartet nicht darauf, dass die Anwendung brav alles anschleppen, denn wir als Anwender stellen ständig Anfragen, navigieren etc. Bei Verwendung des Offscreenmodells hat der Screenreader sein internes Modell befragt und ggf. den installierten Videotreiber um Informationen ersucht. Die anderen Schnittstellen (abgesehen von MSAA) waren darauf ausgelegt, dass der Screenreader mitliest. Mit MSAA und dessen Nachfolger IAccessible2 und seinen Freunden sieht es anders aus. Der Screenreader fragt ständig die Anwendung nach Informationen und läßt sich über Ereignisse benachrichtigen. Dabei greift er gewissermaßen bis in den Speicher der Anwendung.

Eigentlich sollten diese technischen Details dem Endanwender herzlich egal sein. Er möchte nach wie vor den Bildschirm erkunden. Aber genau das ist nicht mehr möglich, denn IAccessible2 sieht vor, dass eine Anwendung ein Baum aus Informationen bereitstellt. Dabei ist es sogar möglich anzugeben, auf welchen Bildschirm bzw. Fensterkoordinaten ein Objekt liegt, aber das ist nur eine Option. Die Position der Objekte auf dem Schirm kann mit dem Baum übereinstimmen, muss es aber nicht. Kurz: Der Screenreader kann daraus kein Offscreen-Modell mehr entwickeln.

Mit dem Offscreenmodell fallen eine Reihe Von Werkzeugen, die JAWS & Co. mitbringen. Z.B. kann man nicht mehr ohne Weiteres eine Grafik beschriften oder einen bestimmten Bereich des Bildschirms als Rahmen definieren. Wenigstens das Klicken auf bestimmte Positionen kann mit anderen Werkzeugen wie Autohotkey nachgebildet werden.

Damit nicht genug; Die ständigen Anfragen der Screenreader über die neuen Zugänglichkeitsschnittstellen setzen die Anwendung ordentlich unter Stress. Zu Beginn der zugänglichen Java-Anwendungen mit Swing waren diese mit Verwendung der Accessbridge so langsam, dass ein flüssiges Arbeiten kaum möglich war. Die Bridge hat außerdem das Verhalten der Anwendung beeinflusst.
QT-Anwendungen, die mit Screenreadern betrieben werden, stürzen deutlich häufiger ab, als ohne Reader. Dies liegt oft daran, dass das Datenmodell in der Anwendung nicht ganz sauber ist. Normalerweise kommt hier kaum jemand vorbei und es gibt keine Probleme. Durch die Vielzahl der Anfragen des Screenreaders zu allen Objekten, die erreichbar sind, sieht das anders aus und die Anwendung tritt auf die Falltür und stürzt ab. Viele Entwickler sind daher der Ansicht, dass die Zugänglichkeitsschnittstelle von QT daran schuld sein. Vielleicht ist sie das auch teilweise, aber man kann zeigen, dass Fehler im Datenmodell sehr schnell mit einem Screenreader aufgedeckt werden. Falls ein Entwickler sich die Mühe gemacht hat, die Anwendung mit Zugänglichkeitsimformationen auszurüsten, wird er es bereuen und diese ausbauen, weil das die Anwendung fordergründig instabil macht.

Auf ins Web

Nun, der Umstieg auf IAccessible2 wäre alleine kein Grund für den hochtrabenden Titel. Die Zukunft hat längst begonnen. Viele große Anwendungen bringen eine eigene spezialisierte Schnittstelle mit, die dann von den Screenreadern verwendet wird. Die Vorleser müssen also nach wie vor auf vielen Hochzeiten tanzen.

Damit nicht genug; Das zeitalter der Webanwendungen hat längst begonnen. OK, mögen viele denken: Die Arbeit im Browser wie Firefox geht doch ganz gut. Für Webseiten, die ein paar Formaulare enthalten stimmt dies auch, aber ganze Anwendungen spielen ssich im Browser ab. Dabei können Menüs an beliebigen Stellen untergebracht werden oder Teilanwendungen als eingebettete Objekte integriert sein. Es gibt sogar hierfür bereits Spezifikationen, damit die Zugänglichkeit gewahrt bleibt. Es handelt sich um Aria das vom W3C schon vor einigen jahren erstellt wurde. Aber viele praktische Probleme sind noch ungelöst:

  • Wie kann ein Anwender mit seinem Screenreader Drag-And-Drop in einer Webanwendungen ausführen?
  • Wie können die großen Informationsmengen bei einer ökonomisch sinnnvollen Arbeitsgeschwindigkeit bewältigt werden? Webanwendungen präsentieren id.d.R viel mehr Inhalte als klassische Desktop-Anwendunge. Ich nenne das immer den Facebook-effekt. Das HTML von Facebook ist quasi barrierefrei, aber kaum jemand vermag die notwendigen Informationen schnell zu extrahieren.
  • Das Aktualisieren der Seiten braucht bei der Verarbeitung durch die Screenreader oft sehr lange.
  • Wie kann eine sinnvolle Navigation aussehen, wenn es diverse Menüs etc. auf einer Seite geben kann?
  • Wie können Aktualisierte Informationen vorgelesen und per Braille erkundet werden, ohne die zuvor gelesene Stelle zu verlieren?
  • Wie erkennt ein Anwender den Kontext eines Links, wenn es davon viele gleichlautende gibt?

Tablets

Apple hat in kürzester zeit aus der Furcht vor Touchscreens unter blinden Menschen eine Begeisterung gemacht. Voiceover hat tatsächlich eine schöne Möglichkeit gefunden, einen Touchscreen für Screenreadernutzer zugänglich zu machen. Dabei wird vorgelesen, was man berührt und erst dann angeklickt, wenn man mit einem anderen finger irgendwo tippt. Natürlich gibt es noch viele weitere Gesten und details. Aber trotz dieser Ansätze bleibt das ganze eine große herausforderung. Es ist nach wie vor nicht leicht sich auf einer glatten Fläche ohne die abgebildeten Steuerelemente sehen zu können zu orientieren. Klar, man kann Elementweise navigieren, aber das ist genauso mühsam, als würde man eine Facebook-Seite Link für Link erkundigen. Wieviele Tage man wohl für eine Seite braucht? Es müssen also weitere Konzepte und Methoden her, befor ein Tablet mit Screenreadern wirklich effizient nutzbar ist – irgendiwe vergleichbar mit der sehenden Konkurrenz.

Virtuelle Rechner und Fernwartung

Weiterhin hält der Trend zur Virtualisierung von computern an. Es ist zu verlockend: Ein Rechner als Gastwirt (Host genannt) und einen PC, den man darauf starten, ihn sichern und im Notfall zurücksetzen kann. Ein virusbefall? Kein Problem – die letzte Sicherung einspiele (ein paar Dateien kopieren) und alles ist wieder gut.

Für Screenreader ergeben sich daraus einige Probleme:

  • Das Installieren von Grafiktreibern in Virtualisierte Rechner führt oft zu ärger.
  • Die Hardware wie Braillezeilen oder (etwas exotisch) externe Sprachausgaben muss zuverlässig beim Umschalten zwischen virutellen Rechnern und Host umgebogen werden. Klappt das nicht zuverlässig, steht man schnell im Wald.
  • Einige Meldungen der virtuellen Systeme bekommt man mit dem Screenreader auf dem Host nicht mit.

Früher waren Werkzeuge zur Vernwartung von PCs sehr teuer und damit nur im Bereich der Administrtion verbreitet. Mittlerweile gibt es einige Freeware-Tools, mit denen jeder Sohn den PC seiner Eltern reparieren kann, ohne das eigene Heim verlassen zu müssen. Screenreader bleiben bei diesen Anwendungen i.d.R außen vor, weil die Grafik pixelweise transportiert wird. Es wäre zwar möglich, auf dem vfernzusteuernden Rechner einen Screenreader zu starten, aber bei Problemen läuft dieser evtl. nicht oder die Übertragung der Sprachausgabe benötigt zu viel Bandbreite auf dem Netz. Eine Lösung, bei der ein Screnreader automatisch eine Art Kopie von sich auf dem anderen Rechner startet, ohne Adminrechte zu benötigen und bei der die Daten so übertragen werden, das die lokale Stimme und Braillezeile den Inhalt wiedergeben wäre hier notwendig.

Fazit

Trotz der Umstellung auf IAccessible2 & co. wird den Screenreaderherstellern sicher nicht langweilig. Es gäbe außerdem genug potenzial für kommerzielle Screenreader, um sich von der freien Konkurrenz abzusetzen.

Der Umstieg von Offscreenmodell auf IAccessible2 & Co. ist mehr als ein Wechsel der Schnittstelle. Sie verschiebt die Verantwortlichkeiten zu den Anwendungen, setzt diese unter Dauerfeuer und kann sie leicht zum Absturz bringen. Ein geschicktes Cachen der Informationen im Screenreader wird hier auf Dauer unerläßlich sein.

Foren von Yahoogroups für blinde Moderatoren nicht zugänglich

Bis vor kurzem konnte man als Gruppenmoderator seine Gruppen bei Yahoogroups recht gut mit einem Screenreader verwalten. Die Webseite wurde nun grudlegend überarbeitet und man findet nicht einmal mehr seine Gruppen wieder. Es wurde bereits eine entspr. Beschwerde bei Yahoo eingereicht. Alle Screenreadernutzer sollten diese unterstützen, um die Situation wieder zu verbessern.
Hier der Link zur Beschwerde:
https://yahoo.uservoice.com/users/45025064