Seit kurzem sammeln wir auch Daten darüber, wie die Barrierefreiheitsfunktionen benutzt werden, wie oft diese angefordert werden usw.

Die neueste Funktion im Rahmen dieser freiwilligen Datenerhebung bezieht sich auf das Sammeln von Daten darüber, welcher Screen Reader bei der Nutzung der Barrierefreiheit unter Windows verwendet wird. Unter Linux gibt es im Prinzip nur einen Screen reader, Orca, aber unter Windows gibt es eine ganze Fülle von Sprachausgabe- und Vergrößerungsprogrammen, die den Firefox unterstützen.

Um ein besseres Bild darüber zu bekommen, welche Programme von unseren Anwendern eingesetzt werden, haben wir diese Funktion in die Nightly-Versionen von Firefox eingebaut. In den nächsten Tagen wird diese Funktion den Aurora-Kanal erreichen und letztendlich in Firefox 12 als Vollversion erscheinen.

Wer die Nightly builds oder Aurora verwendet und uns diese Daten senden möchte, kann wie folgt vorgehen:

1. Extras-Menü, Einstellungen aufrufen.
2. Auf das Register “Erweitert” wechseln.
3. Hier den Reiter “Allgemein” auswählen.
4. Mit Tab bis auf das Kontrollfeld “Performanz-Daten senden” gehen und dieses mit der Leertaste aktivieren.
5. Mit Tab auf “OK” gehen und Leertaste drücken, um die Änderungen zu speichern und das Dialogfeld zu schließen.

Noch einmal zur Klarstellung: Diese Daten werden anonym an uns übertragen und können nicht zum Ursprung zurückverfolgt werden. Wir können also nicht feststellen, von wem die Angabe zu einem Screen Reader kam o. ä. Und natürlich sind diese Dateneinsendungen freiwillig, wir nehmen’s nicht persönlich, wenn jemand sich dazu entschließt, dieses Senden der Daten nicht zu aktivieren!

Hub Figuière, ein neuer Kollege im Accessibility-Team von Mozilla, der im November bei uns angefangen hat, kümmert sich zur Zeit mit Hochdruck um die Zugänglichkeit und Unterstützung für VoiceOver unter Mac OS X Snow Leopard und Lion. In den nächsten Wochen werde ich auf diesem Blog die Verfügbarkeit einer zum Testen geeigneten Version ankündigen. Diese wird eine Menge Probleme haben. Einige davon dürften uns intern schon bekannt sein, andere jedoch höchstwahrscheinlich nicht, und genau dafür würde ich mich sehr über testende Hilfe aus der Community freuen! Die Builds werden instabil sein, es wird längst nicht alles funktionieren und für einige Zeit noch nicht produktiv einsetzbar sein. Aber mit eurer Hilfe können wir das ändern und haben jetzt auch die Manpower dazu!

Diejenigen, die unsere Community schon kennen, können diesem Meta-Bug folgen, um den Fortschritt zu beobachten.

Alle anderen können gern hier ihre Unterstützung signalisieren, sei es durch testen oder einfach nur moralisch, indem sie unter diesem Beitrag einen Kommentar hinterlassen. Ich würde mich freuen!

Diese Untermenüs ermöglichen einen schnelleren Zugriff auf die Untermenüpunkte. Man muss nicht erst einen Hauptmenüpunkt anklicken, auf das erneute Laden der Seite warten und dann auf die aufgeklappten Menüs zugreifen. Stattdessen werden die Untermenüpunkte sichtbar, indem man mit der Maus drüberfährt, sogenanntes Hovern, oder mit tab auf den jeweiligen Link springt und Enter drückt.

Das Problem für Screen-Reader-Benutzer ist, dass die Enter-Taste in der Regel vom Screen Reader abgefangen und für eine Funktion innerhalb des sogenannten virtuellen Dokuments oder Browse-Modus verwendet wird. Normalerweise wird durch Druck auf Enter ein Link aktiviert.

Genau das wollen wir ja aber nicht, denn das Aktivieren eines Links erzeugt ein Neuladen der Seite, und sämtliche Vorteile des schnelleren Zugriffs auf die dynamischen Menüs wären dahin.

Stattdessen tun wir folgendes:

1. Mit dem virtuellen Cursor auf einen dieser “Untermenü Link”-Elemente wandern.
2. NVDA-Taste+F2 drücken, um NVDA anzuweisen, den nächsten Tastendruck ungefiltert an den Browser weiterzugeben.
3. Enter drücken.
4. Mit dem virtuellen Cursor nach unten wandern und ein aufgeklapptes Menü vorfinden.

Diese Methode funktioniert analog mit anderen Screen Readern. Manche Screen Reader fokussieren jedoch nicht automatisch das unter dem virtuellen Cursor befindliche Element. Vor dem obigen Schritt 2 muss also eventuell noch eine Tastenkombination gedrückt werden, mit der der System-Fokus oder PC Cursor zum virtuellen Cursor gezogen wird.

Die oben beschriebene Methode ist ein Tastendruck mehr. Das stimmt, aber diese Vorgehensweise ist immer noch schneller als auf das erneute Laden einer Seite zu warten und dann die aufgeklappten Menüs wieder vom Anfang des virtuellen Dokuments an suchen zu müssen.

Viel Spaß beim Bloggen!

Anstoß für den Artikel gab diese Bemerkung von Heiko Kunert aus Hamburg, in der er bemerkte, dass es immer noch Seiten gibt, die im Firefox mit einem Bildschirmleseprogramm anders aussehen als im IE. Auf meine Nachfrage hin führte Heiko aus, dass er versuchte, den Play-Schalter beim Anschauen des Hamburg-Journals in der NDR Mediathek zu finden und dass JAWS 8.0 diesen zwar mit dem IE, aber nicht mit dem Firefox finden würde.

Zur Erklärung dieses Phänomens kommen in diesem Fall mehrere Faktoren zusammen:

Zum einen ist da natürlich der verwendete Browser. Im Idealfall wird HTML-Code in beiden Browsern gleich interpretiert, egal ob es jetzt um die visuelle Anzeige für Sehende oder die Darstellung durch das Bildschirmleseprogramm für Blinde geht. Jeder, der schon mal mit beidden Browsern unterwegs war, dass es selbst in JAWS 10 und 11, oder auch bei Verwendung des NVDA, immer mal wieder den einen oder anderen subtilen Unterschied gibt.

Zum anderen ist da in diesem Fall der Faktor Flash. Die NDR Mediathek verwendet eine Adobe Flash-Anwendung zur Anzeige des Videomaterials und auch zur Steuerung der Wiedergabe. Der von Heiko gesuchte Play-Schalter befindet sich also nicht im eigentlichen HTML, sondern in dieser Flash-Anwendung. Hier gibt es gerade mit älteren JAWS-Versionen teils gravierende Unterschiede in der Handhabung zwischen dem Internet Explorer und dem Firefox. Der Grund ist, dass das Flash-Plugin für den Firefox erst im Jahr 2008 von Adobe zugänglich gemacht wurde, das Plugin für den IE aber schon seit 2002 Zugänglichkeit unterstützt. Da liegen also mal lockere 6 Jahre zwischen.

Und damit kommen wir zum dritten Faktor, der verwendeten Version eines Screen Readers (unabhängig vom hersteller). Die hier verwendete Version von JAWS war die Version 8.0, die in den USA zuerst Ende 2006 veröffentlicht wurde. Die Veröffentlichung der deutschen Version fand irgendwann 2007 statt. Also wurde diese Version von JAWS ein bis zwei Jahre vor einer zugänglichen Version des Flash-Plugins für den Firefox veröffentlicht und ist somit gar nicht darauf eingestellt, dass es im Firefox überhaupt ein zugängliches Flash-Plugin geben könnte. Berechtigter Kritikpunkt: man hätte auch vorausschauend in JAWS die Möglichkeit bereits vorsehen können. Jeder, der aber schon mal mit Microsoft Active Accessibility gearbeitet hat, weiß ein Lied davon zu singen, dass auch das strikte Folgen der Dokumentation nicht immer zum gewünschten Ergebnis führt, ohne noch weitere kleine Veränderungen vornehmen zu müssen, damit es tatsächlich für den Anwender rund läuft. Dasselbe Rechenspiel gilt natürlich auch für Window-Eyes, die Flash ebenfalls von Anfang an im IE unterstützten (ich glaube sie waren sogar die ersten), mit dem Flash-Plugin in Firefox aber auch erst richtig umgehen lernen mussten, als es dann endlich mal in einer zugänglichen Version erschien. Und solche Verbesserungen werden von den kommerziellen Herstellern von Bildschirmleseprogrammen nur in den seltendsten Fällen auf ältere Versionen zurückportiert.

Wer den gerade erschienenen Firefox 3.6 einsetzt, wird übrigens schnell feststellen können, ob er eine aktuelle und damit zugängliche Version des Flash-Plugins installiert hat. Firefox weist jetzt auf veraltete Versionen des Flash-Plugins hin und fordert zur Aktualisierung auf. Auch wegen bekannter Sicherheitsprobleme ist so ein Schritt unbedingt zu empfehlen!

Beim Testen habe ich das beste Ergebnis übrigens mit der neuartigen Herangehensweise des NVDA an das Interagieren mit Flash-Inhalten erzielt. NVDA sieht nicht nur sämtliche Schalter sondern liest auch von allen Schaltern die Beschriftungen vor, erkennt die bereits abgelaufene und noch verbleibende Zeit und ermöglicht ein vollständiges Bedienen des NDR-Mediathek-Players.

Es ist also leider tatsächlich so, dass ein Bildschirmleseprogramm Inhalte von Webseiten unterschiedlich darstellen kann abhängig davon, mit welchem Browser die Seite aufgerufen wird. Seiteninhalte sind in diesem Fall aber eben nicht nur HTML-Inhalte, sondern auch externe Quellen wie Flash. Und dies erhöht die Variabilität und Fehleranfälligkeit der Anzeige.

Ich hoffe, mit diesem Artikel ein wenig Licht in das Dunkel des teilweise doch verwirrenden und komplexen Zusammenspiels der verschiedenen Komponenten gebracht zu haben! Fragen und Kommentare sind natürlich immer herzlich willkommen!

Viel Spaß!

1. In den Objektattributen jedes Accessibles einer Seite kann jetzt der exakte Wert für das CSS-Attribut “display” abgefragt werden. Zusätzlich zu “formatting:block”, welches weiterhin zur Verfügung steht, ist es so möglich, eine genauere Information über die Gestaltung des jeweiligen Elements zu erhalten als bisher. In Firefox 3.1 Beta ist dies schon länger verfügbar und hat jetzt auch seinen Weg in Firefox 3.0.5 gefunden.
2. Es wurde ein Fehler behoben, durch den manche Arten von Dokumentelementen nicht ordnungsgemäß den Focus übernehmen konnten. Hiermit sollten weitere als “anklickbar” gemeldete Elemente aktivierbar werden.
3. Für Screen Reader, die nicht IAccessible2, sondern die älteren iSimpleDom*-Interfaces verwenden, wurde ein Fehler behoben, der bei der Anforderung des sog. ComputedStyle, also des tatsächlich in Effekt befindlichen Stils eines Elements, auftrat. Hiermit sollte es Screen Readern, die diese Interfaces noch verwenden, jetzt besser möglich sein, Dokumentformatierungen zu sprechen. Auch diese Änderung ist schon länger in Firefox 3.1 und hat nun ihren Weg in Firefox 3.0.5 gefunden.

• Firefox 3.0.2 ist jetzt mit JAWS 7.10 kompatibel. Um möglichst allen potentiellen Anwendern den Zugang zum neuesten Firefox zu ermöglichen, wurde ein Problem identifiziert und behoben, das einen Absturz verursachte, sobald man Firefox 3.0 oder 3.0.1 mit laufendem JAWS 7.10 aufrief.
• Wenn man Firefox 3.0.1 mit der öffentlichen Betaversion von JAWS 10 einsetzte, konnte es passieren, dass bei manchen dynamisch eingeblendeten Seitenelementen JAWS diese nicht mitbekam und auch ein Aktualisieren des virtuellen Puffers nichts half. Dieses Problem wurde behoben.
• Ein Problem, dass manche Schalter, Grafiken oder anklickbare Elemente mit verschiedenen Screen Readern nicht aktiviert werden konnten, sondern die Mausemulation benötigt wurde, wurde behoben. Für die technisch interessierten: Die Methoden doAction und doDefaultAction haben bei manchen Elementen nicht richtig reagiert.
• Wenn ein Map-Element etwas anderes als Grafiklinks enthielt, wurden diese bisher nicht an Screen Reader weitergegeben. Dies passiert nun, so dass das Map-Element problemlos als allgemeiner Navigationsmechanismus auf Seiten verwendet werden kann.
• Ein selten auftretender Absturz durch bestimmte Layouttabellen wurde behoben.
• Einige weitere Fehlerbehebungen in den Programmierschnittstellen ermöglichen assistiven Technologien unter Windows und Linux eine noch sauberere Kommunikation mit dem Firefox.

Ich empfehle, dass das Update auf Firefox 3.0.2 möglichst bald eingespielt wird, damit jede(r) Anwender(in) von den Neuerungen profitiert. Viel Spaß!

Jedes legitime WebVisum-Mitglied kann diese Einladungen verschicken. Wenn ihr also bisher noch nicht bei WebVisum registriert seid, dies aber ausprobieren möchtet, um z. B. in denGenuss des Lösens von Captchas zu kommen, wendet euch doch an Freunde, von denen ihr wisst, dass sie WebVisum verwenden, und bittet sie, euch einzuladen.

Wenn ihr niemanden wisst, kann auch ich Einladungen aussprechen. Eine private Mail an marco punkt zehe at googlemail genügt.

Fragte man bisher bei meinem Blog den Link unterhalb der allerobersten Überschrift nach seinen Attributen, z. B. mit dem Windows-Tool AccProbe, bekam man folgende Antwort:


getAttributes(1) = NULL


NULL ist gleichbedeutend mit “Ich hab’ nichts zu melden”.

Ganz anders mit den nächtlichen Builds von Firefox 3.1a1pre seit der Buildnummer 2008071803. Hier bekommt man nun folgende Antwort:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:de-DE;text-align:start;font-size:12px;background-color:rgb(198\, 217\, 233);font-weight:400;text-indent:0px;color:rgb(34\, 68\, 102);font-family:"Lucida Grande"\,"Lucida Sans Unicode"\,Tahoma\,Verdana\,sans-serif;text-underline-style:underlinesolid;,start=0,end=14]


Man bekommt also zusätzlich zu den Informationen über die verwendete Schriftfamilie und deren Größe auch die Farben, ob eine Unterstreichung vorhanden ist, wie stark die Schrift ist (ein Wert von 400 besagt eine normale Schriftstärke), die Sprache, in der dieser Teil ausgezeichnet wurde, und auch Informationen zur Ausrichtung des Textes.

In Eingabefeldern, und wenn die automatische Rechtschreibkorrektur, die es seit Firefox 2.0 gibt, eingeschaltet ist, wird bei einem falsch geschriebenen Wort auch die Information “invalid:spelling;” zur Verfügung gestellt. Beim Tippen wird, sobald ein Satz- oder Leerzeichen gedrückt wird, ein Ereignis ausgelöst, wenn das soeben eingegebene Wort als Rechtschreibfehler erkannt wird. Screen Reader können dieses Ereignis auswerten und umgehend darauf hinweisen, dass ein Rechtschreibfehler aufgetreten ist. Die Korrektur kann dann gleich vorgenommen werden, und man bekommt sofort Feedback darüber, ob die Korrektur erfolgreich war.

Ein Hinweis: Gerade das Attribut “invalid:spelling;” kann sich noch ändern, je nachdem, ob die IAccessible2- und AT-SPI-Gruppen unseren Vorschlag, diese Werte an die möglichen Werte des Attributes aria-invalid anzulehnen, akzeptieren oder nicht.

In den nächsten Wochen wird dieses neue Feature sicher noch einige Verbesserungen in der Geschwindigkeit und eventuelle Bugfixes erfahren. Der erste Meilenstein ist jedoch geschafft, die Funktion steht prinzipiell zur Verfügung, und erstes Feedback des Orca-Teams und unsere eigenen Tests zeigen, dass es auch schon sehr gut funktioniert.

Sobald Thunderbird 3.0 die dem Firefox 3.1 zugrunde liegende Version Gecko 1.9.1 nutzen wird, was innerhalb der nächsten paar Wochen der Fall sein dürfte, steht diese Funktion auch beim Schreiben von E-Mails zur Verfügung. Bei entsprechenden Auswertungen der Infos durch die Screen-Reader dürfte also einer weiteren Angleichung der Funktionen, die Blinde und Sehende gleichermaßen nutzen können, nichts mehr im Wege stehen!