Schlagwort-Archiv: Braillezeile

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.

Meine Artikel jetzt mit Rechtschreibprüfung

Ich versuche zwar immer, meine Texte möglichst grammatikalisch korrekt und ohne Fehler zu schreiben, aber irgendwas rtuscht doch immer durch. Seit ich unter NVDA ohne Braillezeile schreibe, ist das nicht wirklich besser geworden.

Deshalb lasse ich jetzt über alle Artikel “after the deadline” laufen. Dabei wird interessant, wie die Rechtschreibprüfungen mit NVDA als Screenreader bedienbar sind.

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.