Das Versetzen des Fokus, ist ein recht effizientes Mittel, um dynamische Änderungen im HTML Screenreader-Nutzern bekannt zu machen oder Probleme der Linearisierung beim Scripting zu umgehen (beispielsweise beim Anzeigen eines Dialogs bzw. einer Lightbox). Die Möglichkeit praktisch jedes beliebige Element zu fokusieren ist wohl einer der wichtigsten Bausteine für Wai-Aria. Das Schöne: Grundsätzlich sollte diese Technik auch in nicht aria-fähigen Browser-/Screenreader-Kombinationen möglich sein.
Gleichzeitig gibt es jedoch Unterschiede zwischen Screenreadern in der Unterstützung der focus-Methode. Der generelle Support dieser Methode ist bereits beim wohl wichtigsten Screenreader Jaws je nach Version unterschiedlich. Hier zeigt sich, daß Jaws 10 einen großen Sprung nach vorn gemacht hat und praktisch gar keine Probleme macht, währenddem Jaws 8 bzw. Jaws 9 noch einige Probleme haben. Möchte man diese älteren Versionen unterstützen, sollte man wissen, was geht und was nicht.
Zum Testaufbau
Getestet wurde mit den Jaws Versionen 8, 9 und 10 sowie mit den Browsern IE8, IE7 sowie Firefox 3.5. Zusätzlich wurde im IE8 mit Cobra 8.1 und Webformator 2.4c sowie mit NVDA 0.6p3.2 im Firefox 3.5 getestet. Abschließend wurde nochmals mit der aktuellen Beta-Version von NVDA (NVDA 2009.1beta1) getestet. Im wesentlichen hat sich herausgestellt, daß sich IE7 nicht von IE8 und Jaws 8 nicht von Jaws 9 unterscheiden, so daß die Testergbenisse zusammengefaßt werden.
- Der Fokus sollte aufgrund eines Klicks auf einen Link, als Kontrollelement, verschoben werden
- Jaws sollte die ganze Zeit über im normalen Modus arbeiten (Virtueller Cursor Modus war an, kein EINFÜGEN + Z)
- Eine zusätzliche Verwendung von Aria-Attributen, welche den Screenreader in den Applikationsmodus versetzen könnte, war verboten
- Der Buffer von Jaws wurde nicht manuell upgedatet (kein Einfügen + ESC)
Der Test galt nur als bestanden, wenn der Screenreader den Inhalt des fokusierten Bereich vorgelesen hat und sowohl der virtuelle Cursor als auch der “physikalische” Fokus richtig verschoben war. Der User also sowohl mit den Pfeiltasten als auch mit der Tab-Taste vom neu fokusierten Element aus arbeiten kann.
Welche Elemente können fokusiert werden
Normalerweise können – laut HTML 4 Spezifikation – nur Interaktionselemente, welche nicht versteckt oder deaktiviert sind, fokusiert werden (also Links, Buttons, Eingabefelder etc.). Mit dem tabindex-Wert -1 können diese für den User unfkousierbar gemacht werden, währenddem sie weiterhin durch Javascript fokusiert werden können. Alle getestet Screenreader-/Browser-Kombinationen konnten ohne Probleme diese Elemente im Test fokusieren.
Mit Hilfe des tabindex-Attributs sollen ebenfalls alle anderen Elemente fokusierbar gemacht werden können. Hat das tabindex-Attribut den Wert 0 kann dieses Element sowohl durch den Nutzer als auch durch Javascript fokusiert werden. In allen getesteten Screenreadern konnten solche Elemente durch den User fokusiert werden. In Jaws 8/9 mit Internet Explorer konnten allerdings Elemente, die normalerweise nicht foksuierbar sind, nicht mit der Javascript-Methode focus fokusiert werden (Beispiel: span[tabindex=0], span[tabindex=-1]). Als Ausnahme dieser Regel stellten sich Überschriften heraus. Befand sich das zu fokusierende Element in einer Überschrfit bzw. war es eine Überschrift, konnte dieses auch in Jaws 8/9 fokusiert werden.
Cobra 8.1 laß anchor-Elemente ohne href-Attribut manchmal als Links vor, was irritierend sein dürfte. Befand sich direkt über dem fokusierten Element eine Überschrift und das fokusierte Element war selbst keine Überschrift, wurde diese zusätzlich in Jaws als auch in Cobra vorgelesen.
Regel: Fokusiere nur Elemente, die Interaktionselemente sind oder Überschriften mit tabindex bzw. Elemente mit tabindex, die in Überschriften plaziert wurden. Mit Rücksicht auf Cobra sollten keine anchor-Elemente ohne href-Attribut fokusiert werden.
Nachfolgend der Testcase für das einfache Fokusieren.
Fokusieren von vor kurzem noch versteckten bzw. gerade erst erschaffenen Elementen
Um zwischen den Screenreadern Waffengleichheit herzustellen, wurde der Webformator so eingestellt, daß er nur wirklich sichtbare Elemente anzeigt.
Das Fokusieren von gerade noch versteckten Elementen bzw. Elementen, die erst aufgrund einer User-Aktion ins DOM eingefügt werden (beispielsweise Click -> Ajax -> innerHTML -> focus), gehört wohl zu den problematischsten aller Möglichkeiten. Im wesentlichen haben sich aber alle Screenreader, außer Jaws 8/9, recht gut geschlagen.
Damit Screenreader solche Elemente fokusieren können, müssen sie ihre Ausgabe aktualisieren, um das zu fokusierende Element zu finden. Grundsätzlich sollte die focus-Methode hierzu mit der setTimeout-Methode verknüpft werden. Dies ist weniger ein Workaround, bei dem abgewartet wird, bis die Ausgabe durch den Screenreader aktualisiert wird, sondern ein technisches Erfordernis, welches mit der Arbeitsweise von Events im Browser zu tun hat, welche u.a. Jaws 10 zum Updaten seines Buffers heranzieht. Der Testcase umfaßte hierbei mehrere Delays zum Testen (0ms, 180ms, 400ms). Letztendlich gab es hierbei jedoch in der Regel keine Unterschiede zwischen den delays. Wichtig war nur das die focus-Methode, welche im selben Thread arbeitet wie das Sichtbarmachen/Einfügen selbst, durch die setTimeout-Methode “gequeued” wird.
Jaws 10 und Cobra haben hierbei sämtliche Tests ohne Probleme absolviert.
NVDA sowie Jaws 8/9 hatten dagegen gewisse Probleme. Befand sich das zu fokusierende Elemente über dem aktuell fokusierten Kontrollelement, wurde durch Jaws 8/9 sowie NVDA 0.6p3.2 der Fokus zwar verschoben, jedoch der fokusierte Text nie gesprochen.
Die aktuelle Beta-Version von NVDA sprach zwar alle fokusierten Texte, also auch die, welche sich vor dem Kontrollelement befanden, hatte jedoch bei allen Testfällen das Problem, daß sowohl Tab-Taste als auch Pfeiltasten, nach der Fokusierung immer noch vom Kontrolelement aus starteten. Ein also Weiterarbeiten vom fokusierten Bereich aus nicht möglich war. Hierbei handelt es sich um einen Regressionsbug, der nicht in der 0.6p3.2-Version auftritt. Ich hoffe, daß dieser Bug bis zur Final behoben sein wird.
Jaws 8/9 hatte noch das zusätzliche Problem dahingehend, daß der fokusierte Text auch wenn er nach dem Kontrollelement kam, manchmal nicht gesprochen und/oder der Cursor manchmal nicht richtig verschoben wurde. Dies hatte letztendlich mit zwei Dingen zu tun:
Zum einen ist es von der Bedienung des Screenreaders abhängig, ob er seine Ausgabe rechtzeitig updatet. Wurde der virtuelle Cursor, beispielsweise mit den Pfeiltasten, über den Link gebracht und dann mit der Enter-Taste der Link ausgelöst, klappte das Fokusieren in der Regel. Wurde dagegen der “richtige” Fokus mit der Tab-Taste auf das Kontrollelement versetzt und dann mit der Enter-Taste ausgelöst, wurde die Ausgabe in der Regel nicht richtig upgedatet und es kam mit allen Delays zu Problemen.
Zum anderen Griff im Widerspruch zu dem oben gesagten ein Delay von 0 bzw. 50 nicht immer (aber in etwa 90% aller Fälle). Sobald das Delay jedoch über 100ms betrug und das Kontrollelement mit dem virtuellen Cursor ausgewählt wurde, wurden auf allen bisher getesteten Rechnern mit unterschiedlicher CPU (1 Single Core sowie 2 Core DUO), unterschiedlicher CPU Auslastung (normal bis 100%) sowie unterschiedlicher Sprachgeschwindigkeit die fokusierten Texte immer gesprochen und richtig versetzt.
Regel: Will man ältere Jaws-Versionen unterstützen (und das sollte man), sollte man das Fokusieren von gerade noch versteckten bzw. gerade erst erstellten Elementen bleiben lassen und andere Techniken nutzen.
Nachfolgend der Testcase für das Fokusieren von gerade sichtbar gemachten Elementen.
Inhalt Umschreiben und dann Fokusieren
Als eine wirkungsvolle Alternative für das Fokusieren von gerade sichtbar gemachten Elementen, bietet sich das Umtexten von bereits vorhandenen sichtbaren Elementen und das nachfolgende fokusieren dieser an. Dirk Ginader hatte diese Technik in seinem barrierefreien Tab-Beispiel gezeigt. Diese Technik bietet sich aber nicht nur für Tabs an, sondern auch für viele andere Dinge an.
Die Testfälle absolvierten letztendlich (fast) alle Screenreader. Lediglich wieder Jaws 8 und Jaws 9 hatten mit einem unwahrscheinlichen Testfall Schwierigkeiten. Befand sich innerhalb des umgeschriebenen Elements kein initialer Text verhielt sich Jaws 8/9 ähnlich begriffsstutzig wie bei gerade erst sichtbar gemachten Elementen. Da Jaws 8 und 9 allerdings gleichzeitig nur Interaktionselemente sowie Überschrfiten fokusieren können, dürfte man sowieso selten mit einem solchen Element leeren Inhalts arbeiten wollen.
Regel: Elemente, die zum Umschreiben und Fokusieren gedacht sind, sollten nicht mit leerem Inhalt “starten”.
Nachfolgend der Testcase für das Fokusieren von gerade “umgeschribenen” Elementen.
Fokusieren von gerade sichtbar gemachten/eingefügten Elementen Teil 2
Um dennoch die Möglichkeit zu haben gerade erst erstellte/sichtbar gemachte Elemente zu fokusieren, sind Workarounds denkbar. Ich habe hierzu einen Testcase mit abgewandelter setFocus-Methode zur Verfügung gestellt, welcher nach ersten Tests recht zuverlässig in Jaws 8/9 funktioniert und in anderen Screenreadern keine Probleme auslöst.
Regel: Wenn man Inhalte nicht umschreiben kann, dann – und nur dann – das modifizierte setFocus-Script ausprobieren.