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

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.

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.

Zugänglichkeit von QT-Anwendungen – Möglichkeiten und Fallstricke

Auch wenn die Programmiersprache C++ schon Jahre totgesagt ist, es gibt sie noch immer. Mit dem QT-Framework kann man in dieser Sprache modern anzuschauende und leistungsstarke Anwendungen programmieren. Damit nicht genug, das Framework ist unter bestimmten Bedingungen frei verfügbar.
Nährere Infos über QT finden sich hier www.qt.nokia.com

Wie zugänglich können QT-Anwendungen grundsätzlich sein

Von seiner Grundstruktur her, erscheint QT erstmal recht problematisch für Screenreader. Alle Steuerelemente werden selbst gezeichnet und die nativen des Betriebssystems bleiben außen vor. Da erscheint u.U. nicht mehr als ein leeres Fenster.

Aber QT hat sich in vielen Punkten längst um Zugänglichkeit gekümmert. Dabei wird konsequent die Alternative mit speziellen Zugänglichkeitsschnittstellen wie MSAA und IAccessible2 beschritten. Falls ein Screenreader also auf diesem für ihn speziell entwickelten Kanal hört, hat er wiederum gute Chancen reichlich Infos von der Anwendung mitzubekommen. Die Situation ist ein wenig vergleichbar mit der unter Java Swing. auch hier sind nur Informationen über die definierten Schnittstellen verfügbar.

QT braucht allerdings im Gegensatz zu Java keine spezielle Access Bridge und beschickt stattdessen den Screenreader so, wie es vorgesehen ist. Spezielle Installationsorgien und Probleme beim Update sind hier also kein Problem.

Wie mache ich eine QT-Anwendung für Screenreader zugänglich?

Damit eine QT-Anwendung einem Screenreadernutzer sinnvolle Informationen geben kann, muss man als Entwickler konsequent die Attribute

  • accessible name – Wie soll dieses GUI-Element für den Anwender benannt werden?
  • Accessible Description: Längere Beschreibung des GUI-Elements. Hier können erweiterete Informationen zum Kontext in dem sich die Anwendung befindet angegeben werden.
  • Accessible Role: Welcher Typ verwendet das GUI-Element bzw. welche Rolle spielt es in der Anwendung? Hier sind i.d.R nur bestimmte Rollen zulässig und in den meisten Fällen sind sie durch die Steuerelemente bereits korrekt gesetzt.

Der Entwickler sollte zudem diese Beschriftung auch konsequent in Rahmen, Tabseiten – eben in allen Elementen der Oberfläche fortsetzen. Sie werden nicht alle automatisch vorgelesen, aber wenn ein Screenreadernutzer in de Anwendung navigiert, benötigt er zu den lokalen Informationen z.B. Datei zum Hochladen auch den Kontext – welche Datei zum Hochladen soll hier ausgewählt werden? Durch die Navigation mit dem Screenreader im Objektbaum der Anwendung kann diese Information leichter beschafft werden, wenn alle Ebenen sinnvolle Semantik liefern.
Nehmen Sie sich also bitte die Zeit, sich zu überlegen, was in einem Rahmen, einem Register etc. gekapselt wird und was nicht.

Versuchen Sie zu dem Ihre Anwendung mit abgezogener Maus und abgeschaltetem Schirm mit Hilfe eines Screenreaders wie NVDA zu bedienen. Sie finden ihn hier www.nvda-project.org NVDA ist ein nützlicher Begleiter während der Entwicklung. Er braucht keine Installation und über den Sprachbetrachter könnenn Sie sich die Sprachausgabe in einem Fenster anzeigen lassen.

Für den finalen Test braucht es aber wirklich die Situation, dass Sie den Schirm nicht sehen. Erst dann, wenn sie alle Anwendungsfälle Ihrer Anwendung leicht bedienen können und zu jedem Zeitpunkt wissen wo sie sich befinden, ist Ihre Anwendung gut Zugänglich bzw. barrierefrei.

Eine QT-Anwendung ist mit Zugänglichkeitsinformationen ausgerüstet, es wird aber nichts vorgelesen.

1. Zunächst brauchen Sie einen Screenreader der wirklich die Zugänglichkeitsschnittstellen verwendet. JAWS ist leider nicht von dieser Sorte. NVDA liefert hier deutlich bessere Ergebnisse.
2. Unter Windows XP müssen zusätzlich zur Anwendung die sog. Accessibility Plugins in einem Verzeichnis Namens accessible im Anwendungsverzeichnis also parallel zur ausfürhbaren Anwendung installiert werden. Unter Windows 7 scheint das Problem nicht aufzutreten.
Der Anwendungsentwickler sollte diese Plugins erstellen können – sie können beim Übersetzen des QT-Frameworks erstellt werden. Sie befinden sich anschließend im Ordner plugin und dort im Ordner accessible. Es müssen die Plugins der gleichen QT-Version verwendet werden, wie die anwendung verwendet. Ein Kopieren an den richtigen Ort ist ausreichend.

Wie zugänglich können QT-Anwendungen werden?

Wir haben bei www.david-software.de eine Anwendung mit Zugänglichkeitsinformationen ausgerüstet, die neben den üblichen Eingabefeldern, Listen, Registerkarten und Baumstrukturen auch Tabellen enthielt. Diese ist gut und flüssig in der Bedienung. Allerdings wird der Cursor in Eingabefeldern beim Editieren nicht gesprochen, sodass ich manchmal den Text in einem anderen Editor bearbeite und zurückkopiere. Nicht schön und sicher nicht barrierfrei, aber praktikabel.
Ein anderes Problem sind Auswahlfelder, bei denen die gewählte Option nicht unmittelbar vom Screenreader vorgelesen wird, wie sonst üblich. Hier hilft aber das erneute Anspringen des Steuerelements oder ein Screenreadergefehl, der das aktuelle Objekt erneut vorliest.

Weitere Informationen

Wer mehr über die Zugänglichkeit in QT erfahren möchte, der findet Details unter dem folgenden Link:
Accessibility in QT

Vom Hai zum Känguru – von der Zwangsabgabe zur freiwilligen Spende

Es ist vollbracht. An meinem privaten PC hüpft quasi nur noch das Känguru NVDA. Der Hai beißt nicht mehr recht.
Und auch an meinem Arbeitsplatz in der Firma wird der Hai allmählich zum Ersatzspieler.

Hintergrund

Ich bin eigentlich ein echter JAWS-Poweruser. Während meiner Arbeit als Softwareentwickler verwende ich diesen kommerziellen Screenreader den ganzen Tag. Ich kenne alle Befehle, die ich im Alltag brauche, habe ein paar winzige Skripte hingefummelt und habe einige Anwendungen, die einem Screenreader alles abverlangen. Also gibt es doch keinen Grund fremdzugehen? Trotzdem werde ich dem Hai Stück für Stück untreu. Mittlerweile bin ich mir sicher, dass es mehr als nur ein kleiner Ausflug wird.

Mit diesem Artikel möchte ich andere JAWS-Bemnutzer dazu ermutigen sich intensiver mit NVDA zu beschäftigen und die eigenen Möglichkeiten auszuloten. Doch beginnen wir erstmal am Anfang.

Die Chronik

Alles begann damit, dass ich Software mit dem QT-Framework entwickeln musste bzw. durfte. QT ist plattformübergreifend und verwendet deshalb keine sog. nativen win32-Steuerelemente. Anders gesagt, um Anwendungen mit dem QT-Framework nutzen zu können, braucht es einen Screenreader, der auf die offiziellen Schnittstellen MSAA bzw. IAccessible2 hört. Die Verwendung der nativen Win32-API ist bei solchen Frameworks sinnlos, weil sie alle Oberflächenelemente selbst zeichnen. Ooops machte da der Hai – er konnte nicht mal eine simple Meldungsbox vorlesen. Bis zu diesem Zeitpunkt hatte das NVDA-Känguru als zweiter Screenreader geduldig auf dem PC sein darsein gefristet und schwups – der las denn auch anstandslos die Meldungsbox. Also den Hai für alles normale und das Känguru für QT? Außerdem war NVDA immer zur Stelle, wenn sich JAWS mal wieder aufgehängt hatte und beendet werden musste. Eine Weile war es so und damit konnte ich die Arbeit fortführen. Damit nicht genug war es ein leichtes für meine Kollegen mit NVDA die Stellen unserer Anwendung anzupassen, wo dieser Reader noch hakte. Ein Screenreader, der sich für Entwickler wie ein kleines Hilfswerkzeug anfühlt, die Sprachausgabe auf Wunsch auf dem Schirm anzeigt, ist für viele Entwickler Motivation und Hilfe genug. Am Ende war unsere Anwendung zur Eingabe von Testfällen und Bewertung so weit angepasst, dass ein produktives Arbeiten mit NVDA damit möglich war. Das beinhaltete auch das Navigieren in Tabellen und zwischen verschiedenen Fenstern.

Ich verwende bei mir zuhause noch eine veraltete JAWS-Version, obwohl ich die entspr. Lizenz zur Verfügung hätte. Das letzte Update des gefräßigen meeresbewohners steckt mir noch in den Knochen. Jedesmal muss ich um den Treiber für mein Papenmeier Trio bangen, brauche eine Weile bis die Einstellungen umgezogen sind – und jedesmal muss ich die Brailezeile erneut auswählen. Ein Blick in die Neuigkeiten für eine neue JAWS-Version zeigen, dass es viele neue Funktionen gibt, deren Nützlichkeit ich teilweise nicht nachvollziehen kann und vor allem, dass Fehler in der Software verbleiben. Um es kurz zu machen, ich vermeide ein JAWS-Update wo immer ich kann und ich glaube nicht, dass Probleme mit einer neuen Version wirklich besser werden. Ich will nicht behaupten, dass ein JAWS-Update nicht problemlos möglich wäre, aber es bereitet mir großes Kopfzerbrechen und es gibt kaum Funktionen, auf die ich mich freuen könnte.

Ich verwende Outlook 2010 für meine E-Mails und JAWS 11 verreckt regelmäßig, wenn ich nur eine Mail mit Escape schließe. Resigniert über ein sicher erfolgloses Update bekommt wieder einmal das Känguru die Chance – und nutzt sie.

Mittlerweile lese ich mit NVDA meine Mails, lese und kommentiere Statusmeldungen auf Facebook, verkaufe Gegenstände bei Ebay, erstelle Blog-Artikel, und versuche immer mehr auf den Hai zu verzichten. Damit nicht genug kann ich mittlerweile fast alle notwendigen Anwendungen an meinem Arbeitsplatz mitNVDA nutzen, sodass ein ernsthaftes produktives Arbeiten als Softwareentwickler mit Visualstudio 2008 möglich ist. Einziger Nachteil ist, dass ich meine private Papenmeier Braillezeile nicht nutzen kann. Wieso? Während NVDA selbst Zeilen der Firma Hedo unterstützt, gibt es immer noch keinen Treiber für die Papenmeier-Zeilen. Die Lösung mit BRLTTY, die gerne dafür genannt wird, beißt sich mit dem Treiber von JAWS und lastet das System vollständig aus. Es spricht für sich, dass einer der größten deutschen Hardwarehersteller keinen NVDA-Treiber anbietet. Wie auch immer, dieser Nachteil geht nicht auf Kosten von NVDA. Außerdem konnte ich mit NVDA weitgehend einen Elterngeldantrag von http://www.elterngeld.de/pages/elterngeld.html ausfüllen. Hier sind lediglich die Kontrollkästchnen nicht immer klar mit ihrem Status erkennbar. Das ist sicher ein gravierendes Problem, aber für mich zählt, dass ich die Eingabefelder lesen und editieren konnte und alle Elemente gut lesbar waren.

Nachdem ich so ganz gut zurecht kam, stellte ich gleichzeitig fest, dass ich immer versucht habe, mit dem JAWS-Cursor unter NVDA die Oberfläche zu erkunden. Nachdem ich mittlerweile großes vertrauen in den freien Screenreader gewonnen hatte, war es also an der Zeit mich mit der Bedienphilosopieh näher auseinanderzusetzen. Eine gründliche Studie des deutschsprachigen Handbuchs brachte mich dem Ziel um einiges näher. Für alle Mitumsteiger hier die Unterschiede, bzw. wie man unter NVDA zurecht kommt.

  1. NVDA hält sich ähnlich wie Voice Over (das ist der Screenreader von Aple) strikt an die Hierarchie, die eine Anwendung vorgibt. Anstatt mit dem Jaws-Cursor das gesamte

Anwendungsfenster zu lesen und ggf. irgendwo zu klicken, navigiert man bei NVDA mit NVDA-Taste und den Ziffern des Nummernblocks durch die Objekthierarchie. Der Hai kann das auch – Homerow hieß das mal und war eigentlich nur als Werkzeug zur Skriptentwicklung bzw. Anwendungserkundung gedacht. NVDA hingegen hat dieses Werkzeug immer an der aktuellen Position. NVDA sagt also: suche zuerst das Objekt, mit dem du etwas anfangen – vielleicht auch nur es lesen möchtest und interagiere mit ihm.
Diese Form der Navigation kann dadurch unterstützt werden, indem Entwickler konsequent alle Steuerelemente (auch Groupboxen) mit Zugänglichkeitsattributen ausrüsten. Hier erhält der Anwender schnell die Information in welchem Bereich er sich gerade befindet.
NVDA beherrscht etwas ähnliches wie dem JAWS-Cursor. Das nennt sich Screen-Review-Modus und wird mit Nvda+Num7 ein- und ausgeschaltet. Diese Navigationsform ist dann sinnvoll, wenn die Objekthierarchie nicht zum gewünschten erfolg führt oder die optische Anordnung innerhalb der Anwendung wichtig ist.

  1. Unter NVDA kann man jeder zeit mit den Tasten des Nummernblocks Zeilenweise, wortweise oder Zeichenweise im aktuellen Objekt navigieren. NVDA kennt dabei nicht die seltsamen Beschränkungsmodi, die man unter JAWS für den JAWS-Cursor auswählen kann. Der Lesebereich ist strikt auf das aktuelle Navigator-Objekt beschränkt – für alles andere braucht man den Screen-Review-Modus.
  2. Häufig ist es unter NVDA ausreichend, auf einem gewünschten Objekt die Eingabetaste des Nummernblocks zu drücken, um es zu aktivieren. Wenn Sie z.B. einen Link in einer Mail haben, brauchen sie weder Cursorrouting noch Klicks ausführen – navigieren sie mit dem Nummernblock oder mit den cursortasten auf den Link, und aktivieren ihn mit der Eingabetaste des Nummernblocks. Apropos cursorrouting: Dies wird unter NVDA auch unterstützt, reagiert aber manchmal etwas anders als von JAWS gewohnt. Unter dem Hai ist das Cursorrouting ein Klick an die passende Stelle in der Anwendung. Unter NVDA wird für das Objekt, in dem das Routing ausgeführt wird, die Standardaktion ausgeführt. Das muss nicht immer ein Klick sein. Beim Bearbeiten von Texten ist dies kein Unterschied, aber wenn man z.B. in Visualstudio ein Fenster durch einen Klick aktivieren möchte, funktioniert Cursorrouting nicht. Es handelt sich eben um eine andere herangehensweise.
  3. Mit Nvda+Num/ zieht man die Maus zum Navigator-Objekt und kann dann mit Num/ einen Linksklick ausführen. Dies hat bei mir allerdings manchmal nicht zuverlässig funktioniert.
  4. NVDA kennt keinen Grafikbezeichner. Stattdessen liest er schlicht den Tooltip vor, wenn man sich durch die Objekthierarchie auf ein Werkzeug einer Symbolleiste bewegt. anstatt also auf dem Schirm nach dem Symbol zu suchen, verwenden sie die Objektnavigation zur Navigation zur Symbolleiste bzw. zum Werkzeug, dass sie anklicken möchten und aktivieren es mit Num-Eingabe. Das ist am Anfang vielleicht etwas umständlich, aber schon bald kennt man die Struktur der Anwendung und kann schnell navigieren.
  5. Die Navigation mit dem Navigator ist einfach zu merken: Die Tasten links, rechts, oben und unten zur Fünf also 4, 6, 8 und 2 Navigieren eben links, rechts, nach oben und zum ersten Kind im Objektbaum. Dazu muss jeweils die NVDA-Taste gedrückt werden. Das klingt Theoretisch, aber wenn Sie es z.B. im Explorer ausprobieren, wird schnell klar, wie es funktioniert. Bleibt noch anzumerken, dass die Objektstruktur der Anwendung oft nichts mit der Anordnung der Objekte auf dem Schirm zu tun hat. Eine Auflistung der Navigations-Tastenkombinationen erspare ich mir hier – das ist bereits im Handbuch und der Kurztastenreferenz so wie in der Tastaturhilfe geschehen. Die Tasten des Nummernblocks ohne NVDA-Taste lesen übrigens den Text Zeilen- Wort- oder Zeichenweise je nach Reihe des Blocks.
  6. NVDA verfolgt auf Wunsch die Maus, gibt ihre Koordinaten akustisch aus und man kann steuern, welche Informationen über ein Objekt vorgelesen werden, wenn man mit der Maus darüber fährt.
  7. Viele Fortschrittsbalken wird NVDA auf Wunsch akustisch verfolgen – unter Jaws kennt man so etwas nicht.
  8. Auf Webseiten muss man eingebettete Objekte wie Flash-Filme zunächst z.B. mit der Leertaste aktivieren. Fortan ist man in diesem Objekt “gefangen” und kann zwischen den Schaltern etc. navigieren. Zum Verlassen des objekts drückt man Strg+NVDA+Leertaste. Das klingt konsequent und führt aus meiner Sicht zu einer besseren Zugänglichkeit der eingebetteten Objekte.
  9. NVDA kennt nicht das große (und für mich unübersichtliche) Arsenal an Hilfsprogrammen unter JAWS. Vielleicht ein Nachteil, aber dem steht die Programmierung über Python (siehe unten) gegenüber.
  10. Es gibt noch eine Reihe anderer Tastenbefehle, die ich mir noch nicht merken kann. Hier hilft das Handbuch und die Liste der Tastenkombinationen.

Aktueller Stand und Ausblick

Die Installation oder Aktualisierung von NVDA dauert nicht mehr als ein paar minuten. Dabei begleiten einen die gesamte Zeit während der Installation die zuletzt eingestellten Stimmeneinstellungen. Seit Version 2012.1 beherrscht NVDA ein automatisches Aktualisieren und zwar je nach dem, ob eine Release- Beta- oder sog. Snapshotversion verwendet wird.
Während unter JAWS die Scansoft Stephi Schlaftabletten verabreicht bekommt, quasselt sie munter für NVDA. Das erlaubt endlich das Verwenden einer etwas angenehmeren Stimme. Kleinigkeit, aber selbst die getunten JAWS-Stimmen, die eingeführt wurden, weil SAPI zu lahm war, haben’s unter JAWS nicht gebracht.
Allerdings ist mir auch aufgefallen, das die Verwendung einer Handytech-Braillezeile die Performance irgendwie reduziert. Das ist nur mein ganz persönlicher Eindruck. Kleinigkeit, aber irgendwie bekommt JAWS auf der Arbeit deshalb ab und an wieder seine Chance, weil ich irgendwie nicht schnell genug arbeiten kann.

Apropos Braillezeile: Auch hier verhält es sich etwas anders als unter JAWS. NVDA verwendet eine Art strukturierten Modus (so heißt das unter JAWS) und zeigt neben der aktuellen Zeile auch Informationen der übergeordneten Fenster auf der Zeile an. Ob das so wirklich hilfreich ist, kann ich nicht beurteilen. Mir persönlich ist der Flächenmodus lieber, aber das kann man unter NVDA nicht einstellen.

Die zwei getrennten Installationspakete von NVDA wurden in einem vereinigt, was gleichzeitig für alle Sprachen lokalisiert ist. Das bedeutet: Man packt das einmal auf seinen USB-Stick und kann sich spontan entscheiden, ob man die portable Version z.B. bei einem Kumpel verwenden möchte, oder ob eine dauerhafte Installation sinnvoll ist.

Wenn mir unter JAWS etwas nicht gefällt, mache ich nicht mehr den Versuch dies irgendwo zu melden – es kommt vermutlich sowieso nicht an. Unter NVDA erstelle ich ein Ticket und wenn es wirklich wichtig ist, spende ich etwas für die Umsetzung Immerhin kann ich den Status jeder zeit einsehen, die Entwickler bekommen direkt bescheid und wenn der Fehler behoben ist, kann ich am nächsten Tag mit einem aktuellen Installer überprüfen, ob das Problem wirklich korrigiert ist. Ich behaupte nicht, dass NVDA ohne Fehler ist, aber es ist transparent und ich bin gerne bereit Fehler zu melden.

Ein Highlight von NVDA ist sicher der Plugin-Mechanismus mit denen man ähnlich wie unter JAWS spezielle Anwendungsunterstützung oder Erweiterungen für allgemeine Funktionen installieren kann. So gibt es z.B. ein Plugin um auf einem Objekt eine optische Zeichenerkennung (OCR) auszuführen. Damit zieht NVDA mit JAWS 13 gleich. Eine Seite für solche Plugins findet man unter http://www.stormdragon.us/nvda/

Ein Hindernis für die noch zögerlichen Umsteiger dürfte die etwas andere Bedienphilosophie sein. Auch die Darstellung auf der Braillezeile ist gewöhnungsbedürftig.

Während das große Rätselraten darum, ob und wann JAWS und die anderen kommerziellen Screenreader Windows 8 unterstützen werden anhält, heißt es in den News zur aktuellen Betaversion von NVDA lapidar: Support für Windows 8 Metrooberflächen. Ich weiß nicht, ob es wirklich schon funktioniert, aber dafür würde eine Mail in der Entwicklerliste reichen – es ist immerhin transparent.

Währen JAWS eine eigene Skriptsprache ohne vernünftigen Debugger verwendet, verwendet NVDA Python – jene kryptische aber mächtige Programmiersprache, die NVDA selbst gebar. Python ist verbreitet, eine interpretierte und reflexive Sprache und erlaubt eine andere Art der Programmierung. Will sagen, der Screenreader dürfte für kompetente Entwickler deutlich leichter erweiterbar sein. Apropos Entwickler: Es gibt eine Bibliothek, die man in Anwendungen einbinden kann, um direkt mit NVDA zu kommunizieren. Wer will kann also, an allen üblichen Wegen vorbei eine Anwendung programmatisch zugänglich machen. Das ist sicher nicht ganz einfach, aber wenn die verwendeten Frameworks etc. nicht die notwendige Unterstützung für Screenreader bereitstellen, kann dies ein vergleichsweise einfacher Weg sein.

Während die Lokalisierung (zumindest in früheren Versionen) von JAWS ungefähr bis zur nächsten englischen Version brauchte, wird sie unter NVDA parallel zur Entwicklung spätestens zum Release gepflegt. Und wem wirklich noch eine ausgefallene Sprache fehlt, der kann sich seine eigene Übersetzung erstellen und damit das projekt unterstützen.

Mittlerweile gehen die Anwendungen, die nur mit Screenreadern mit einem Grafiktreiber bedienbar sind stark zurück. Das ist auch gut so, denn bei der Virtualisierung von Rechnern, können diese Treiber nicht mehr korrekt installiert werden – oder es gibt Probleme dabei. Konkret muss ich lediglich mit einem Zeiterfassungsprogramm arbeiten, dass von JAWS besser vorgelesen wird als von NVDA.

Der Vorsprung des Marktführers JAWS ist arg zusammengeschmolzen und die Unterschiede sind nur noch für einige bestimmte Anwendungen am Arbeitsplatz relevant. Damit will ich nichtsagen, dass JAWS & co. überflüssig währen – Vielfalt ist immer wichtig, aber objektiv können die kommerziellen Reader den enormen Kostenaufwand immer schwerer rechtfertigen. Statt ein entspr. Update zu kaufen, sollte man überlegen, eine ähnlich hohe Spende bei NVDA zu tätigen. Legen Leute zusamen, wäre es sicher möglich, ein bestimmtes dringend benötigtes Feature umsetzen zu lassen. Und wem das nicht reicht, der kann jeder Zeit selbst Hand anlegen – allerdings braucht es einiges an Einarbeitung die komplexe Software und das Design zu versteh. Ich bedaure es sehr, dass ich nicht die Kraft habe, mich abends an der Weiterentwicklung zu beteiligen.

Nun müssen die Anwender entscheiden, welchen Weg sie gehen möchten. Vielleicht gibt es in Zukunft professionelle Schulungen für NVDA und ein Anpassungsgeschäft – was spricht dagegen, dass jemand für eine Anpassung für einen Arbeitsplatz Geld bekommt und diese im Gegenzug in das NVDA-Projekt einspeist?

Nachtrag

  • Mitlerweile funktioniert die Papenmeier Trio gut mit NVDA.
  • Der Treiber der Zeile wird auch nicht mehr bei einem JAWS-Update beschädigt.
  • Outlook 2010 kann ich zwar zu hause mit NVDA nutzen, am Arbeitsplatz friert NVDA aber bei einer geöffneten Mail ein. Woran das liegt konnte ich noch nicht ergründen. Das hält JAWS immer noch im Spiel.
  • Ich musste nur deswegen von JAWS 12.0 auf JAWS 14.0 kostenpflichtig aktualisieren, weil JAWS 12.0 in einer Eingabeaufforderung unter Windows 7 keinen Pfeilrauf (die Taste) verträgt. Ich finde es eine unverschämtheit, dass solche Blocker nicht kostenfrei korrigiert werden.

Anmelden bei Google Analytics mit NVDA und Mozilla Firefox

Um diesen Blog weiter zu optimieren wollte ich mich bei Google analytics anmelden. Allerdings scheiterte das ganze mit dem Internet Explorer 8 bereits am Captcha bei der Kontowiederherstellung. Mit der Kombination aus NVDA, Firefox und Webvisum hingegen, wurden die Captchas gelöst (Danke an das Webvisum-team) und alles andere verlief reibungslos. Nicht einmal eine Braillezeile hatte ich zur Kontrolle. Offenbr ist das Duo aus Firefox und NVDA mittlerweile wirklich gut ausgereift.
Danke an zwei so tolle Opensource-Anwendungen. Ich sollte wohl mal wieder spenden.

Erste Schritte auf Google Analytics

Nachdem der Tracking code auf diesem Blog installiert war, musste ich etwas wrten, bis analytics zugegriffen hat und die ersten Daten präsentieren konnte. Die “Neue Version” ist anscheinend mit Firefox nicht wirklich gut bedienbar. Zumindest habe ich keine meiner Daten über die Webseite gesehen. Auf der “alten Version” war es dagegen ganz einfach. OK zwei Besuche und fünf Zugriffe bzw. abgerufene Seiten sind nun wirklich kein Brüller.

Jetzt geht’s vorbei mit dem Hai

Das Erlebnis mit NVDA und Firefox hat mich ermutigt. Ist der Browser gegenüber IE8 doch aktueller – den IE kann ich nicht aktualisieren, weil Zoomtext sonst Probleme bekommt. Immerhin habe ich die Erkundung der Daten auf Analytics nun mit Firefox und NVDA vorgenommen.

Erstellen von PDF-Dokumenten aus Microsoft Word

Bei der Erstellung von PDF-Dokumenten wird das Dokument häufig zunächst in Word erstellt und anschließend in ein PDF-Dokument umgewandelt. Dabei kann man in Bezug auf die Zugänglichkeit des PDFs einiges richtig oder auch falsch machen.

Verwenden eines PDF-Druckers

Es funktioniert wie beim Ausdrucken des Dokuments. Man gibt lediglich den Dateinamen des PDFs ein und schon hat man eine fertige Datei. Ein bekannter Drucker dieser Sorte ist freepdf. Die Software installiert sich als normaler Drucker unter Windows und kann in jeder Anwendung verwendet werden.

Solche PDF-Dokumente sind i.d.R. nicht zugänglich, weil sie die Seiten meistens als Grafik im PDF ablegen.

Spezielle Software zum Export zugänglicher PDF-Dokumente

In den letzten Tagen gab es einige Meldungen über verfügbare Plugins für Word, um das Erstellen von barrierefreien PDF-Dokumenten zu ermöglichen. Während ein Tool aus der Schweiz
http://www.zhaw.ch/medien
eher ernüchternde und teilweise deffekte Resultate liefert, soll in Kürze ein weiteres Tool die Bühne betreten. Hier der Link zum Artikel:
http://blog.axespdf.com/index.php/leserseite/items/start-public-beta-axespdf-fuer-word.html

Das ganze kollidiert mit den bereits vorhandenen Möglichkeiten PDF-Dateien aus Word heraus erstellen zu können. Deshalb müssen sich solche Anwendungen an den Ergebnissen der Bordmittel messen lassen.

Bordmittel

Word 2010 bietet von sich aus die Möglichkeit, das Dokument als PDF zu speichern. Das Resultat ist verblüffend gut zugänglich. Bei mehreren Dokumenten konnte ich feststellen, dass die folgenden Features gut umgesetzt waren:

  • Die Meldung, dass das Dokument nicht getagt ist, entfällt.
  • Überschriften sind korrekt ausgezeichnet.
  • Tabellen sind gut lesbar
  • Listen ung geschachtelte Listen sind gut lesbar.

Ein entscheidender Vorteil bei eder integrierten Lösung in Word ist, dass viele Autoren sie intuitiv benutzen und damit ohne es zu wissen zugängliche PDF-Dokumente erstellen.

Defizite mit speziellen Plugins ausgleichen

Autoren von speziellen Plugins argumentieren oft damit, dass die Bordmittel bestimmte Funktionen nicht umsetzen bzw. das Ergebnis unbefriedigend ist. Daher wird versucht speziell auf Zugänglichkeit zugeschnittene Plugins zu entwickeln, die diese Defizite vermeiden.

Nach meinen Erfahrungen aus der Softwareentwicklung ist ein solches Vorhaben nur dann sinnvoll, wenn dauerhaft ein Team hinter einem solchen Projekt steht – es sich also nicht nur um ein kurzes befristetes Forschungsprojekt handelt. Dann hätte man besser daran getan Schwachstellen gegenüber Microsoft zu melden oder das ganze von Beginn an als quelloffene Initiative zu starten.

Die größte Hürde in der Praxis wird aber wohl sein, Anwender davon zu überzeugen, Word so einzusetzen, wie es gedacht ist. Für technikaffine Leute klingt das logisch, aber ich selbst kenne viele Anwender, die bereits bei Formatvorlagen den Sinn nicht einsehen mögen. Von Alternativtexten für Bilder etc. ganz zu schweigen.

Unterstützung für Windows 8 schon länger in NVDA

Offenbar ist die Unterstützung von Windows 8 schon länger in NVDA (Non Visual Desktop Access geplant. Bereits in der letzten Version 2011.3 wurden erste Fixes vorgenommen. Ein Test steht freilich noch aus. Es ist gut, wenn ein Freeware-Screenreader sich an der Front auch mit solchen neuen Systemen messen lassen kann. Immerhin gibt es von Freedom Scientific noch keine äußerung zu Windows 8. Window Eyes soll auch unter Windows 8 laufen. Das berichtet ein Podcast auf www.blindcooltech.com
Hier nun der Link zum Blog-Beitrag der auf die Windows 8 Unterstützung in NVDA hinweist:

NV Access – Blog: NVDA 2011.3 Released.

Anwendung zum elektronischen Personalausweis hat kein BITV-Zertifikat


Worum geht’s

In Deutschland wurde im November letzten Jahres der neue elektronische Personalausweis eingeführt. Für den Ausweis wurde eine Anwendung entwickelt, um das Dokument über das Internet nutzen zu können. Es handelt sich dabei um die sog. Ausweis-App. Nach geltendem Recht müssen Anwendungen, die von staattlichen Stellen bereitgestellt werden die Barrierefreie IT-Verordnung BITV einhalten. Dabei soll sichergestellt werden, dass die Anwendung auch für behinderte Menschen zugänglich ist. Hierfür muss die Anwendung gegenüber der BITV als konform zertifiziert werden. Genau ein solches Zertifikat liegt allerdings derzeit nicht vor.

Details

Der Hersteller der Ausweis-App OpenLimit www.openlimit.com hat mir in einer E-Mail mitgeteilt, dass es derzeit kein Zertifikat auf BITV-Konformität der Ausweis-App gibt. Es ist erst eines für die nächste Entwicklungsstufe geplant. Letztendlich kann deshalb keine Aussage über die Zugänglichkeit der Anwendung getroffen werden. Aus der Selbsthilfe wurden bislang eher Probleme als Erfolge gemeldet. Die Einsatzgebiete der Ausweis-App sind derzeit sehr eingeschränkt, was aber nichts an der Rechtslage ändert.
Ich habe die Entwicklung der Ausweis-App über nun mehr als ein Jahr begleitet und zu jedem Zeitpunkt auf Einhaltung der BITV gedrungen. Trotzdem wurde offenbar noch keine Zertifizierung angefordert.