Schlagwort-Archiv: Screenreader

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.

Fernwartung mit NVDA jetzt kostenlos möglich

Eine der herausragenden Funktionen von JAWS war und ist die Möglichkeit, auf entfernte Rechner der sog. Remote Desktop zugreifen zu können. Dafür wird die Professional-Lizenz benötigt und JAWS muss auf beiden Systemen installiert sein.

Etwas ähnliches gibt es nun auch für NVDA. Auch hier muss auf beiden Maschinen NVDA laufen, aber die Unterschiede sind dennoch beachtlich:
* Sowohl NVDA als auch die Erweiterung NVDARemote sind kostenlos verfügbar. Jeder ist eingeladen einen Betrag seiner Wahl zu spenden, um eines oder beide dieser Projekte zu unterstützen.
* NVDA braucht bekanntlich keine Administrationsrechte bei der Installation – sieht man mal von der Verwendung im Anmeldebildschirm ab. Damit dürfte eine Installation von NVDA auf einem Terminalserver o.ä. eine Administrator deutlich weniger Kopfzerbrechen machen als bei JAWS,
* Mit JAWS und seinem Grafiktreiber hat es bei virtuellen Hosts so seine Tücken. Die akzeptieren nämlich häufig nicht, dass ein Grafiktreiber installiert werden soll, oder sind so weit von der Hardware entfernt, dass die Installation seltsame Fehlermeldungen ergibt. Deshalb war die Nutzung von JAWS-Remote in der Praxis für mich oft nicht möglich. Für “normale” Rechner sieht dies freilich anders aus.
* Prinzipiell kann man natürlich darauf bauen, dass JAWS oder NVDA auf dem entfernten Rechner laufen und den Audiokanal zu einem umgeleitet wird. Die Verzögerung und die Audioqualität sind hier aber ein echtes Hindernis. Außerdem fällt damit jegliche Brailleunterstützung weg – nichts um von zu Hause arbeiten zu können.

NVDA Remote wird einfach als Erweiterung in ein laufendes NVDA installiert – zur Erinnerung: Es ist problemlos möglich mehrere NVDA-Versionen auf einem Rechner zu betreiben. Die Erweiterung landet allerdings in Ihrem Benutzerverzeichnis und ist somit überall verfügbar.

Die Erweiterung kann hier heruntergeladen werden:
http://nvdaremote.com/download/
Hier gibt es eine sehr knappe Beschreibung der Erweiterung:
http://nvdaremote.com/blog/

Das Release ist noch ganz frisch und man sollte daher nicht verwundert sein, dass die Beschreibung sehr knapp und die Texte noch auf Englisch sind. Es sollte noch erwähnt werden, dass die Entwickler der Erweiterung zwar bekannte Entwickler im Umfeld von NVDA sind, aber die Entwicklung nichts mit dem Team zu tun hat, das NVDA selbst entwickelt – genau wie bei diversen Erweiterungen für Firefox.

Mit NVDARemote ist NVDA wieder ein Stück näher zu JAWS & Co aufgerückt. Arbeitsplätze, die eine Verwaltung entfernter Maschinen benötigen, können nun oft auch mit NVDA betrieben werden – eine Installation des Screenreaders ist in beiden Fällen nach wie vor notwendig. Außerdem dürfte es nun einfacher sein, andere Anwender zu unterstützen, die NVDA verwenden. Hierfür gibt es bei JAWS das Tandem, aber auch da sind ordentliche Lizenzgebühren fällig.

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 http://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.

NVDA bläst zum Sturm auf Ofice

Es ist noch nicht lange her, als ich in einem Artikel für die “Gegenwart” über NVDA berichtet hatte. Damals war klar, dass NVDA den anderen Screenreadern im Bereich Microsoft Office unterlegen war. Für viele Anwender war das sicher ein Grund bei ihrem bisherigen Screenreader zu bleiben.

Nun ist der erste Release Candidate von NVDA 2014.3 veröffentlicht worden. Die Liste der Neuerungen enthält fast ausschließelich Verbesserunen für Microsoft Office. Damit dürfte der Vorsprung der Konkurrenten wie JAWS und Kobra weiter dahin schmelzen.

Hier ist der Link zur Testseite von NVDA. Von dort kann man sowohl die Neuerungen einsehen als auch den Release Candidate herunterladen.

Erwägen Sie bitte auch eine Spende für dieses großartige und freie Projekt, denn es wäre sehr ärgerlich, wenn die Weiterentwicklung an der Finanzierung scheitern würde.

Hier nun der Link:
http://community.nvda-project.org/wiki/Test

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 http://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 http://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.

Mein Hai geht in Teilzeit

Ich habe schon lange auf den Tag gewartet, da NVDA an meinem Arbeitsplatz das Kommando übernimmt. Nich aus Gehässigkeit gegen die kommerzielle Lösung, sondern es sich schon lange abgezeichnet hat. Folgende Ereignisse haben diesen Tag nun wahr werden lassen:
* Immer mehr unserer verwendeten Webanwendungen lassen sich besser mit Firefox und damit auch mit NVDA verwenden.
* Der Zugriff auf das Internet ist nur noch via Firefox möglich – und weil viele Dokus dort liegen, bin ich quasi drauf angewiesen.
* Ich habe endlich das Problem gelöst, dass NVDA bei der Verwendung von Outlook immer eingefroren ist. “schuld” war eine Software namens advanced security for Outlook, die für Catlok verwendet wird. Das ist eine sehr zugängliche Anwendung um die eigenen und die Termine von Kollegen zu überblicken. Nach deinstallation des “Schuldigen” lief NVDA ohne Probleme und dem ständigen Einsatz stand nichts mehr im Weg.

Allerdings brauche ich JAWS noch zum Debugging in Visualstudio und vermutlich auch noch für andere Anwendungen.

Wie auch immer: Ich bin froh, dass es wirklich gelungen ist, als Softwareentwickler produktiv den ganzen Tag mit NVDA zu arbeiten. Das beste daran: Wenn irgendwas zu klemmen scheint, Drücke ich die NVDA-Kombination und die Software wird durchgestartet.

Ich wünsche mir, dass die kommerzielle Konkurrenz wie JAWS endlich aus den Fehlern lernt und Screenreader baut, die stabil laufen und das Abdecken, was die Anwender brauchen. Ich habe den Eindruck, dass oft Funktionen am Bedarf vorbei eingebaut werden.

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.

Link

Ulrich Hanke betreibt seit vielen Jahren eine Seite mit vielen Beschreibungen von Anwendungen, Links zu Sprachausgaben etc. Sie ist zu finden unter
[[http://www.ulrichhanke.de]].

GWConnect – Ein leichtgewichtiges Skype-Programm im Test

== Vorgeschichte ==
Im Rahmen des Fachausschusses für Informations- und Telekommunikationssysteme (FIT) wollten wir spontan eine Konferenz über Skype abhalten. Bislang hatte ich den dienst nicht genutzt und bat einen Kollegen um einen Crashkurs. Erfreut wurde mir berichtet, dass GWConnect ein vollständig zugängliches und einfaches Programm sei, um zu Skypen. Na genau das Richtige.
== Installation und Einrichtung ==
Die Anwendung
[[https://www.gwmicro.com/catalog/gw_connect/|GWConnect]] wird von GWMicro dem Hersteller von Window-Eyes herausgegeben. Die Anwendung ist frei verfügbar und blendet zu Beginn und alle halbe Stunde eine Werbung ein, falls man keine Lizenz erwirbt. Es handelt sich also um eine spezielle Skype-Lösung für Screenreader-Nutzer von einem kompetenten Hersteller.

Die Installation verläuft unproblematisch und es gibt keine besonderen Schwierigkeiten für ungeübte Nutzer. Da dies die Zielgruppe der Anwendung ist, versuche ich die Testergebnisse entsprechend zu bewerten. Es ist nicht entscheidend, ob ich als Profi-Anwender mit der Anwendung zurechtkomme, sondern ob sie wirklich hilft, mit wenigen Kenntnissen am PC skypen zu können.

Nach dem Start der Anwendung gelangt man über den Knopf Registrierung auf die Webseite von Skype um sich dort ein Konto einzurichten. Die Webseite ist im Großen und Ganzen sicher recht zugänglich, aber wie üblich mit viel Inhalt gefüllt, den ein Anwender nicht bei der Kontoeinrichtung braucht. Nun, das ist aber keine Schuld von GWConnect.

Als Anwender mit einem Facebook-Konto gefiel mir die Möglichkeit, dieses für Skype zu verwenden. Ich würde zu den Freunden aus Facebook ggf. skypen wollen und brauche nicht unbedingt noch ein weiteres Passwort. GWConnect gibt auf seiner Homepage nicht explizit an, dass Konten mit Facebook nicht unterstützt werden.

Die Verknüpfung mit Facebook ist recht einfach, birgt aber seine Tücken. Es ist nämlich so, dass die Facebook-Seite geöffnet wird und der relevante Dialog ganz am Ende der Seite (also nach dem üblichen Kram am Seitenende) eingeblendet wird. Das liegt offenbar daran, dass der Inhalt zuletzt eingefügt wird und zumindest NVDA ihn am Ende präsentiert. Dies geschieht mit einem eingebetteten Objekt mit dem schnöden Namen “dlg”. Auch kann hier kann GWConnect nichts dafür, aber ein normaler PC-Anwender wird hier schon recht ordentlich geprüft. Im Prinzip klickt man sich durch die Dialoge – ich habe es tunlichst unterlassen dort Änderungen vorzunehmen. Zu fragil erscheinen mir diese neuartigen Webdialoge.

Am Ende ist aber mein Skype-Konto eingerichtet. Also gwconnect gestartet und sich anmelden … Hier findet sich nur ein Feld für den Nutzernamen und ein Kennwort. Auf der Homepage von Skype und im richtigen Skype-Client gibt man zwar den Skypenamen an, aber kein Kennwort, sondern klickt dafür einen Link an, der sich bei Facebook anmeldet. Ein solcher Link fehlt in GWCwconnect und die Eingabe des Facebook-Kennworts führt (wie auch auf der Seite von Skype) nicht zum Erfolg.

Es ist mir auch nicht mit einem weiteren Konto gelungen, dass überhaupt nicht mit Facebook verknüpft war. Der Anmeldedialog enthält außerdem einen echten kleinen Vauxpas: Die Option zur automatischen Anmeldung beim Programmstart ist noch in englisch. OK, das bekommt vielleicht noch jeder raus, aber es zeigt, dass offenbar niemand die lokalisierte Version getestet hat.

Wenn man die falschen Login-Daten gespeichert hat und die Anwendung neu startet, bekommt man eine Fehlermeldung, das das Passwort falsch ist (mit den gleichen Daten konnte ich das unverknüpfte Konto aber auf der Skype-Seite anmelden). Meldet man sich aber im Programm manuell an – also ohne die automatische Anmeldung, dann kommt keine entspr. Fehlermeldung. Ich habe erst nach vielen Minuten begriffen, dass ich gar nicht angemeldet war.

Natürlich habe ich die Anfrage der Windows-Firewall positiv beantwortet, aber es funktioniert trotzdem nicht. Es mag gut sein, dass ich einen Fehler gemacht habe, oder das ein Problem anderer Art vorliegt, aber ich habe keine Lust, mich extra dafür in einem Mailingliste einzutragen. Die Anwendung werde ich deinstallieren und stattdessen den offiziellen Client verwenden.

== Fazit ==
Die gefundenen Fehler wiegen doppelt schwer, weil sich hier ein namenhafter Hersteller eines kommerziellen Screenreaders eine schlechte Werbebotschaft leistet. Eigentlich wäre ich neugierig ein Window-Eyes mal richtig intensiv zu testen. Die Zielgruppe, nämlich relativ ungeübte Anwender dürften hier auf echte Hindernisse stoßen. Die Tatsache, dass im ersten Dialog, der nach Installation der Anwendung erscheint einen englischen Text enthält, könnte auf eine nur schlecht getestete Anwendung hindeuten. Ich habe auch im Handbuch der Anwendung nachgesehen (das vollständig auf Englisch ist), aber auch da konnte ich keine Lösung für meine Probleme finden.

Eigentlich ist es sehr schade, dass GWConnect diese Fehler hat, denn ein einfacher Skype-Client wäre eine echte Alternative zum überfrachteten Skype-Client.

Link

Unter dem folgenden Link findet sich ein sehr interessanter Blog mit vielen (aber anderen) Artikeln rund um das Thema Zugänglichkeit und blind leben. Der Autor ist zudem ein sehr erfahrener Blogger, was man an der kompakten und gut lesbaren Form der Artikel merkt. Und es erscheinen deutlich öfter Artikel als hier:
http://blindleben.blogspot.de
Viel Spaß beim schmökern