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