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.

10 Gedanken zu „Screenreader im Wandel der Zeit

  1. Oliver Nadig

    Zwei für mich wesentliche Informationsquellen verstummen ohne Offscreen-Modell:
    1. Intuitiver Zugang zu Einrückungs- und Abstands-Informationen in Textverarbeitungsprogrammen auf der Braillezeile. Ich arbeite in MS Word viel mit Aufzählungen und Nummerierungen, die auch gerne einmal bis zu einer Tiefe von 3 verschachtelt sein können. Dank Offscreen-Modell (OSM) kann ich die Einrücktiefe und die Tatsache, dass es sich um hängende Einzüge handelt, problemlos auf der Braillezeile erkennen. Gerne verhaspelt man sich im Eifer des Gefechts mit den Einrücktiefen bei verschachtelten Aufzählungen – das fällt mir beim Korrekturlesen sofort auf. Ohne OSM bleibt mir in Zukunft nur die abstrakte Formatierungsinformation, die sich über den entsprechenden Screenreaderbefehl abfragen lässt.
    2. Ein gewisser Überblick über den Großteil einer Tabellenzeile: Was ist eine der größten Herausforderungen als blinder Mensch mit einem Screenreader zu arbeiten? … richtig: Der fehlende Gesamtüberblick über den Bildschirm oder eine komplexe Arbeitssituation. In meiner Arbeitspraxis sind solche Situationen oft komplexe Tabellen – sei es in der Textverarbeitung MS Word oder in der Tabellenkalkulation MS Excel. Im sogenannten Flächenmodus meines Leib- und Magen-Screenreaders (bei anderen Bildschirmlesern nennt er sich Zeilenmodus) wird versucht, die “Flächigkeit” des Bildschirms so layoutgetreu wie möglich auf der Braillezeile abzubilden. Das bedeutet in Tabellen: Liegt meine Fokusposition mitten in einer Tabellenreihe, werden auf der Braillezeile – solange es der Platz zulässt – auch die Inhalte der links und rechts danebenliegenden Zellen abgebildet. Für mich ein unschätzbarer Anhaltspunkt, was ich in der aktuellen Zelle zu tun habe. Ohne OSM wird der Flächenmodus eines Screenreaders nicht mit diesen Informationen versorgt. Im schlimmsten aller Fälle ist das Arbeiten im Flächenmodus der Braillezeile dann überhaupt nicht mehr möglich – weil die Brailleanzeige völlig leer bleibt. Im besten Fall wird lediglich Information zum aktuellen Element, also in Tabellen zur aktuell bearbeiteten Tabellenzelle – angezeigt. Sehende können innerhalb von ein paar Sekunden den gesamten Bildschirm betrachten. Für blinde Anwender, die über eine Braillezeile verfügen, die vom Screenreader im Flächen- bzw. Zeilenmodus angesteuert werden kann, “verengt” sich der wahrnehmbare Ausschnitt auf einen “waagerechten Schlitz”, nämlich auf die aktuelle Text- bzw. Tabellenzeile – oder eben soviel davon, wie auf der angeschlossenen Braillezeile dargestellt werden kann. Der Wegfall des Flächenmodus “verengt” den wahrnehmbaren Ausschnitt abermals: Von einem Schlitz auf ein winziges “Guckloch”, das gerade einmal so groß ist, wie das aktuell fokussierte Element (das kann ein Steuerelment in einem Dialogfenster oder eine Tabellenzelle sein). Alles in allem: Düstere Zeiten für blinde Computernutzer, für die der Umgang mit Tabellen einen Großteil der täglichen Arbeit ausmacht.

    Was ist zu tun?
    Den Entwicklern und Händlern meines Leib- und Magen-Screenreaders predige ich es bei jeder passenden und unpassenden Gelegenheit: Mit Hilfe der Informationen, die der Screenreader aus dem Dokumentobjektmodell und über Schnittstellen wie IAccessible2 bekommen kann, muss eine Braillezeilendarstellung, wie sie momentan noch bis einschließlich Windows 7 im Flächenmodus möglich ist, im strukturierten Modus nachgebildet werden.
    Nur, wenn sich Screenreaderentwickler dieser Anstrengung unterziehen, bleiben wir blinden Berufstätigen in zeitkritischen Arbeitssituationen – wenn es um das erfassen einer großen Menge strukturierter Daten geht – konkurrenzfähig!

    Antworten
  2. Clemens Rüttenauer

    Sehr aufschlussreich! Mir als Nicht-Screenreader-Nutzer ist jetzt klarer, warum Versions- und Techniksprünge den Screenreader-Entwicklern so große Schwierigkeiten bereiten. Schon bei ZoomText (Screen-Magbifier), das ja wohl deutlich weniger komplex ist, ist das festzustellen.
    Übrigens fiel mir beim zufälligen Stöbern auf, dass der Artikel „Herausforderung Webanwendungen“ dreimal hintereinander drin steht. Ist das seinem Gewicht geschuldet oder doch ein Versehen?
    Grüße
    Clemens

    Antworten
  3. Beck, Steffen

    Aha, nun weis ich also warum mein Zoomtext nicht mit Java Oberflächen umgehen kann, Ich habe noch einen Visus rechts von 0,1, kann mich also noch mit entsprechender Vergrößerung orientieren, was aber lästig wir, da der Gesamtüberblick verloren geht.
    Ich bin berufstätig in einem großen Unternehmen.Dort laufen Unterweisungen inzwischen webgesteuert via Ibtranet. Einige Sachen kann ich sehr gut lesen (vorlesen lassen). Einige funktionieren überhaupt nicht, was wohl an o,g, Problemen liegt.
    Aber es kann ja nur besser werden.Meine Hochachtung an alle Vollblinden, die trotzdem nicht aufgeben.

    Antworten
  4. Petra Ritter

    Mal eine Frage an die Programmierer unter uns.
    Habt ihr auch schon Schwierigkeiten wegen dem immer weniger gebrauchten Offscrenn-Modell.
    In der Programmierung ist man meines Wissens sehr auf Einrückungen angewiesen. Machen da die modernen Programierumgebungen auch schon Schwierigkeiten?

    Antworten
  5. Heiko Folkerts Artikelautor

    Danke für die Anmerkungen.
    * Der mehrfache Artiekl wurde entfernt – es gibt ihn jetzt nur noch einmal. Wie das geschehen konnte, weiß ich nicht.
    * Das mit den Einrückungen kommt sehr darauf an, ob alles in einem Editor stattfindet – Quellcode ist i.d.R. ein Textblock pro Datei oder ob es wie in Word sich tatsächlich um eine Reihe von Objekten handelt. Beim Programmieren haben wir bislang offenbar Glück gehabt. Allerdings werden Markierungen wie die aktuelle Zeile in einer Debugger-Sitzung und andere dinge grafisch hervorgehoben (zumindest in Visual Studio) und das kann den Readern, die auf IAcessible2-Basis arbeiten leicht entgehen.
    * Zoomtext ist ähnlich komplex wie Screenreader. Zum einen kann es die beinhalteten Texte vorlesen – muss also auf IA2 etc. hören zum Anderen muss eine geglättete Anzeige dargestellt werden – auch bei hohen Vergrößerungen. Vergrößerungen werden immer Grafiktreiber benötigen und im Gegensatz zu Screenreadern müssen sie die Grafik verändern.
    * Es wird in der Tat darauf ankommen, aus den Einzelinformationen iber IA2 & Co. sinnvolle und für den Anwender effizient nutzbare Informationscluster zu bilden.

    Antworten
  6. Pingback: Bringschuld für Software-Entwickler | Chemnitzer 14

  7. Alexander Gaßner

    Hallo Heiko und Oliver,
    schön, hier eine Fortsetzung , so sehe
    ich es im Verhältnis zum begonnenen EinstiegsVergleich von NVDA und JFW
    zum Thema über die Hersteller hinaus
    zur diskussion zu stellen.
    Obwohl ich nur ein paar kurze Anmerkungen machen wollte,
    hab ich nun mal in ca 90 Minuten alles aufgeschrieben,
    was mir dazu länger schon durch denKopf geht,

    Diskutieren möchte ich gerne:
    Olivers Vorschlag:
    1. Besser gestalteter Strukturmodus!
    und die möglichkeiten der Darstellung:
    Warum schalte ich doch immer wieder auf die Fläche zurück?
    nur aus Gewohnheit?
    oder weil man ggf. Informationen über Elemente und den Inhalt
    besser voneinander getrennt ausgeben sollte oder könnte?
    - Der Text verschiebt sich zwangsläufig!
    wenn wir wieder Schalterinfos davor stellen und es stört den lesefluß
    extrem.
    ggf. wäre eine Möglichkeit,
    a) die Statuselemente dafür zweck zu entfremden mal auszuprobieren.
    b) differenzierte Ausgabe von Braille und sprache wirklichkeit werden zu lassen.
    und nicht im wesentlichen parallel auszugeben.
    c) nicht zwischen zwei Modi umzuschalten, sondern über der navigation die Erkundung des

    Umfelds zu ermöglichen.
    das wäre mal interessant, ob man in Excel durch entsprechende Belegung der Tasten das

    hinbekommt, Aus der Struktur heraus
    in die umgebende Fläche navigieren zu können.

    Das Navigieren entlang der Fensterstruktur ist / sagen wir lieber wäre /
    auch möglich.

    bei FHp gibt es einen Kombimodus, dessen Möglichkeiten ich in dieser hinsicht nocht nicht

    erkundet habe.

    Jetzt will ich mich dem Thema Darstellung von einer anderern Seite nähern:
    2. Aufbereitungen aller Art.
    Die virtuellen Modi unserer Software , die uns die Arbeit täglich
    vor allem in einem Browser , erleichtern,
    sollen hier nicht weiter besprochen werden,
    sondern tools, die darüberhinaus weisen.

    A) Researchit: JFW:
    über eine eigene Skript Sprache wird eine Anwendung / Seite aufbereitet /
    meist von Hersteller oder wenigen Kundigen, Fußball / Intranet /
    gut zugänglich gemacht.

    B) Linert hat dieses vor allem auf WEb basierende Modell.
    im grunde mit einer art Makroaufzeichnung aller Parameter
    und anschl. sinnvollen Interpretation insofern sehr erweitert,
    weil es Screenreader und Anwendungsunabhängig ist.
    aber er kann es sicher besser in diesem Kontext erklären!

    c. Allgemeines:
    Mal ein abstecher nach Linux:
    Ein Systemnaher Freak programmiert eine Anwendung
    als Kommandozeile.
    Ob wir die parameter für den Batchbetrieb verwenden, oder eine für uns gangbare GUI bauen,
    ist unsere / jedermanns Sache.
    Übertragen auf Windows hieße das:
    a) Wir bekommen alle Parameter, wenn wir sie bekommen,
    in einer Liste..
    b) Listen und MenüStrukturen könnte man ggf. teilautomatisiert erstellen lassen.

    c) wie kommen wir zu einer für uns brauchbaren GUI?
    ohne ständig nötigen händischen Eingriff dritter?
    wie Research?

    um auf Linerts Idee zurückzukommmen,
    setzt diser für eine Anpassung sagen wir mal mit einem
    über die Anwendung unsichtbar gelegtes
    Makro / Menüsystem für seinen Schützling /
    indem er alle verfügbaren Parameter einsammelt.
    -
    Soweit ich das sehe, beschäftigt sich auch Cord mit solch schönen Spielzeugen,
    aber Zeit und Geld fehlen , um ein Sr übergreifendes Tool zu entwickeln.
    -

    d) Performance GUI:
    Es fragt sich schon mit JFw beim Aufruf einer Linkliste,
    bei mehr als 150 Links,
    wie und ob man hier noch Performance und Stabilität realisieren kann.

    Ob weitere Ideen wie 3D,
    , derzeit in der Navigation erprobt, uns weiterführen,
    weiß ich nicht.
    Ein weiteres Problem sind die auch zwar barrierefreien
    aber überfüllten Facebookseiten!
    Ich glaube Heiko hat das shon gut beschrieben.

    d) Noch zur Zeile:
    als Baum seine ersten Sensor routing Tasten auf den markt gebracht hatte,
    war die Begeisterung ein wenig verhalten.
    obwohl die Idee gut war.
    nur der Einsatz / die Position war nicht ideal.
    Meine persönliche Meinung ist:
    man hätte die Sensoren in zweiter Reihe hinter die Routingtasten setzen
    können und weitere, freibelegbare Funktionen anbieten dürfen,
    wie Font abfrage o.ä. da würde vielen sicher viel einfallen.
    Viel Bedienungsmöglichkeiten um ein Modul herum ist interessant.
    Fürs cursorrouting war.s noch zu früh.
    Handytech hat mit ATC ein deutlich anders reagierendes System.
    gebracht und es wird sich zeigen,
    ob die Schnell und vielleser es mit Gewinn einsetzen.
    Auch hier stellt sich mir diese Frage,
    ob die Routingtasten vor der Zeile,
    die Sensoren hinter der zeile angeordnet sein könnten.
    nicht nur dierekt auf dem Element, das aber nur anspricht,
    sobald ein Punkt gesetzt ist, soweit mein aktueller Stand,
    Folge: bei keinen Blank wird reagiert.

    e: touchscreen:
    Mit TouchScreen / ggf mur einer Touchzeile,
    kann ich mir gut vorstellen,
    auch regler zu bedienen.
    Baum hat wohl ein entsprechendes Audioteil.
    Gewisse Module sollte es übr die zeile hinaus also noch geben,
    wie programmierbaren 16er Block, audiomodule oder
    oder Touchflächen

    f) noch zum taktilen Grafikfeld!
    ich denke, ein eigenes Grafikdisplay
    hat sich aus praktischen und kostengründen nicht durchgesetzt.
    Ich stelle mir vor,
    ein kleines Grafikfeld neben der Zeile s. Statusfelder.
    zu haben, welches mir z.B. das Symbol auch als Grafik zeigt,
    welches ich eben unter dem Cursor habe.
    Das käme der Neugier mancher , meiner auch, schon entgegen!
    und wäre wohl kaum teuerer als eine 2D-Screeen mit 25 Modulen.

    g) Touchscreen:
    zur großräumigen Navigation: / Räumlichere Darstellung.

    Da ist Apple ggf. auf keinen schlechten Weg durch bezahlbare Sprachunterstützung.
    schon auf dem 10 Zoll IPad,
    und in diesem Sinne sehe ich auch hier eher einen Durchbruch als
    in meteks unbezahlbarem Riesenbraillefeld.
    Sogesehen hat mich das Ipad mehr begeistert als das IPhone.
    weil man schnell eine räumliche Vorstellung erhält.

    Ende.

    Antworten
    1. Heiko Folkerts Artikelautor

      Hallo Alex, vielen Dank für die Anmerkungen. Marcos Artiekl über die Rückkehr vom Apple zu Windows hat gezeigt, dass es mit einem Touchpad nicht so einfach ist – vor allem dann, wenn die Oberfläche vollgestopft ist. ATC habe ich bei der Arbeit, aber bislang konnte ich daraus leider wenig Optimierung machen. Entweder reagiert das System nicht so, wie ich es erwartet habe oder die Programmiermöglichkeiten sind zu eingeschränkt.

      Ein System, was eine Oberfläche Fernsteuert, wie du es beschreibst, halte ich für eine Not- bzw. Speziallösung. Autohotkey könnte hier sicher sehr gute Dienste leisten, aber damit würden wir wieder vom Objektmodell zum Offscreenmodell schielen. Deshalb ist die Erkundung aus dem strukturierten oder sagen wir eher objektorientierten Modus heraus in die umgebende fläche mit IAccessible2 getriebenen Anwendungen kaum zu realisieren.

      Ich arbeite bereits an einem Konzept, um diese Probleme anzugehen – im Wesentlichen eine theoretische Betrachtung, denn ich werde es nicht schaffen, das Konzept in NVDA o.ä. umzusetzen Aber vielleicht beflügelt das ganze die Diskussion.

      Wir dürfen bei all dem nicht vergessen, dass Braillezeilen aus der Sicht der meisten Anwender ein Luxusproblem sind. Viele können sich im Leben keine leisten oder können kein braille. JAWS heißt nicht ohne Grund “Job access with speech”.

      Meine bisherigen Ideen beruhen darauf, dass wir die Informationen im Objekt-Modell-Puzzle richtig – also kontextabhängig zusammensetzen müssen. Ich freue mich auf die dann folgenden Diskussionen, weil man nur in der Gesamtbetrachtung zu den besten Ergebnissen kommt.

      Antworten
  8. Alexander Gaßner

    Hallo Heiko,

    was du schreibst, ist nachvollziehbar.
    Ich erinnere mich an einen sehr interessanten Vortrag von Fa Baum
    über dieses Thema, als VISTA eingeführt wurde.
    ggf. hast du den gehört.
    Hr Friehoff (ph) führte damals aus:
    Wir bekommen die Daten aus den Schnittstellen,
    aber wir wissennicht, wo sie positioniert sind.
    so hab ich es zumindest im Gedächtnis.
    Deine Ausführungen scheinen dies zu bestätigen.
    Für den Batchbetrieb, / für Softwareentwickler scheint dies auszureichen.
    Natürlich ist eine sprechende Schnittstellle besser als
    eine irgendwie nachträglich gebaute Oberfläche,
    welche die Daten einsammelt.
    das zeigt schon ein in HTML mit Labels beschriftetes formular.
    Anstatt sich den Text drumherum suchen zu müssen,
    sollte das Objekt die Daten freiwillig herausrücken.

    Noch zu Braille:
    in DL gibt es noch genug Zeilen,
    hoffentlich noch lange!
    sodass wir Braille nicht zurückstellen sollten,
    auch wenn ich mich nicht als Braillefreak betrachten würde.
    ist mir das wichtig.
    Olivers Ausführungen fand ich dazu schon gut.
    ATC habe ich auch selten im Einsatz,
    Konzept und Design der Zeile sagen mir aber immer noch zu.

    touch und Grafik:
    Ich kenne Windows 8 noch nicht, und kann nicht sagen,
    wie gut man W8 ohne Touch noch flüssig bedienen kann.
    bzw. flüssiger als Mac,
    Ich sehe das für den PC als Vorraussetzung,
    s. Bedienung ohne Maus.
    Ich sehe den Touchscreen für uns als zus. gute Orientierungshilfe
    ggf. Von Vorteil. für den PC Arbeitsplatz.
    Das sehen glaube ich, nicht wenige in den Büros so.
    Ich habe mir, wie zu Optacons Zeiten, durchaus schon mit der Hand auf dem Monitor zeigen lassen,
    wo ich was finde.
    Inwieweit das Alter der Erblindung bzgl. der räumlichen Abhängigkeit! da eine rolle spielt,
    steht natürlich auf einem anderen Blatt.

    Dein Konzept zur Darstellung würde mich natürlich interessieren.
    Vermutlich machen sich die Sr Entwickler auch ihre Gedanken darüber.

    Alex

    Antworten
  9. Alexander Gaßner

    Hi nochmal Heiko
    ein wenig habe ich ggf. an deinem O-Baum-Anliegen vorbeigeschrieben.
    sozusagen Old Scoool!
    Aber nach der hoffentlich sprechenden Windowsfensterhierarchie
    stellt sich zus. in DL die Frage,
    ob und wie wir darüberhinaus noch etwas darstellen wollen und können.
    Aber zurück zu unserem Baum!
    Du hast ja den Facebookeffekt schon sehr schön beschrieben.
    Jeder der mal einen Web-Mailclient hat ausprobieren dürfen,
    wie INotes o.a. Webdienste, kann dies nachvollziehen.
    Vermutlich werden wir keine geeignete Ki erfinden können,
    welche uns die 500 Links Knöpfe u.a. wieder in eine sinnvoll
    auslesbare Struktur stellt oder
    ein Braillegerechtes Drucklayout erzeugt.
    D.h. die Fensterhierarchie haben wir, wie du schon schriebst,
    hier ja nicht mehr.
    Wie könnte eine Lösung also aussehen.
    Man müßte unsere Links Knöpfe u.a. mit einem geeigneten Label versehen,
    Sagen wir mal BrailleMeenü, oder und anschl. mit einer dezimalen Klassifikation,
    damit ich sie ohne fremdes zutun eines Dritten wieder
    in eine sinnvolle Struktur stellen könnte.
    Dazu noch die Frage, wie erkennen die Entwickler eigentlich,
    ob ein Handy oder ein Pc mit 32 zöller zugreift?
    Der Browser und seine Auflösung sind ja nur ein Anhaltspunkt.
    Der Mediatyp hat sich wohl garnicht durchgesetzt.
    in selfhtml gibt es den wohl noch,
    da gibt es neben Drucklayout auch Braille. o.ä.
    aber ich fürchte, keinen menschen interessiert dies.
    Da wäre der zus. Struktur-Label ggf. leichter umsetzbar.
    Alex

    Antworten

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>