HTML-Elemente in einem Dokument richtig zu plazieren ist wichtig!

Ich bekam heute eine Frage zur Barrierefreiheit bestimmter dynamischer Inhalte gestellt, die mich zu diesem Blogeintrag veranlasst hat.

Beim Anzeigen und Verstecken dynamischer Inhalte gibt es zwei gängige Prinzipien, die sich herauskristallisiert haben: Der eine Ansatz ist, den Inhalt direkt dort in das Dokument einzufügen, wo sich der Auslöser für die Veränderung befindet. Ein Beispiel hierfür ist die englischsprachige Careers-Seite von Mozilla. Das Klicken auf einen der Links „Meet Mozilla“, „The Team“, „Life at Mozilla“ bewirkt, dass der Text zu dem jeweiligen Thema den vorherigen Text ersetzt.

Ein weiterer Ansatz ist, den neuen Inhalt einfach ans Ende des document-Elements anzuhängen und dann mit Hilfe von CSS einen Overlay-Effekt oder eine Positionierung, die optisch korrekt ist, zu erreichen. Ein Beispiel hierfür ist die Demo der jQuery Thickbox. Das Klicken auf eine der Demos wie Image, Gallery oder Keep In Mind bewirkt, dass das Bild oder der Text ans Ende des Dokuments, wahrscheinlich durch eine document.addXxx-Methode, angehängt wird.

Optisch unterscheiden sich diese Beispiele vielleicht ein bisschen im Styling, aber das Prinzip ist dasselbe: Du klickst auf etwas, und ein neues Bild oder Text erscheinen und ersetzen ggf. anderen Inhalt. Die Seite wird hierbei jedoch nicht neu geladen.

Für den Anwender eines Bildschirmleseprogrammes macht die Wahl einer der beiden Methoden jedoch einen gravierenden Unterschied. Damit ein Screen Reader einem blinden Anwender eine Webseite vorlesen kann, muss ein Durchlaufen einer Hierarchie von zugänglichen Objekten oder des Dokumentenobjektmodells, oder in manchen Fällen sogar eine Analyse des HTML-Quellcodes selbst, stattfinden. CSS wird dann herangezogen, um festzustellen, ob bestimmte Elemente sichtbar sind, als Block o. ä. formatiert werden, und welche Textformatierungen vorliegen. Positionierungsinformationen stehen jedoch immer der Reihenfolge im tatsächlichen HTML-Quellcode nach, egal ob dieser schon vorcodiert ist oder durch JavaScript erzeugt wird.

Um es noch anders auszudrücken: Sogar ein dreispaltiges Seitenlayout erscheint dem Anwender eines Screen Readers als einspaltiges Dokument von oben nach unten. Die Spalten werden aufgelöst und der Reihenfolge entsprechend formatiert.

In der Konsequenz bedeutet dies, dass im zweiten Beispiel der neue Inhalt grundsätzlich am Ende erscheint. Unter Windows ist dies das Ende des virtuellen Puffers. Unter Linux und Mac ist dies das letzte, was in einem HTML-Dokument angezeigt wird. Man muss also zum Ende des Dokuments springen bzw. mit Orca unter Linux zum letzten Element navigieren oder unter Mac OS mit VoiceOver zum letzten Element des HTML-Inhalts, mit dem man gerade interagiert, springen. Dies gilt für alle Plattformen und Browser (Firefox, IE, Safari).

Um nun also den Inhalt der Thickbox lesen zu können, löst man erst die Demo aus, navigiert mit seinem Screen Reader dann ganz ans Ende, guckt, was es dort zu sehen gibt und kehrt dann zum Anfang der Seite zurück, um mit Navigationsmethoden wie dem Springen von Überschrift zu Überschrift wieder dorthin zu gelangen, wo man ursprünglich angefangen hat mit dem Auslösen der Demo. Dies ist weder besonders effizient noch besonders intuitiv.

Dasselbe kann man auf Facebook beobachten: Wenn man einen Freund hinzufügt, erscheint die Abfrage, ob man die Anfrage wirklich versenden möchte, für den Screen-Reader-Anwender ganz am Ende der Seite. Optisch erscheint die Abfrage jedoch in der Nähe des „Als Freund hinzufügen“-Schalters.

Im Mozilla-Beispiel jedoch wird der neue Inhalt gleich unterhalb der Liste der Auswahlmöglichkeiten angezeigt, also in der Umgebung, in der der Anwender eh gerade arbeitet. Es ist so also problemlos möglich, von „Meet Mozilla“ zu „Team“ usw. zu gelangen. Die Navigation ist intuitiv und effizient.

Wenn ihr also dynamische Inhalte erzeugt, ein Accordeon-Widget programmiert usw., helft Anwendern von Screen Readern bitte bitte bitte, indem ihr ein Element wählt, das sich in der Umgebung der Action befindet und fügt die neuen Inhalte dort ein, anstatt die Inhalte einfach ans Ende des Dokuments anzuhängen oder sie von dort zu entfernen. Ihr werdet Screen-Reader-Anwendern ein sehr viel effizienteres Navigieren auf euren Seiten ermöglichen, indem ihr nicht von ihnen verlangt, zwischen Teilen der Seite hin- und herzunavigieren, die weit voneinander entfernt liegen.

Neue Wege der Zugänglichkeit zu Flash- und Java-Inhalten auf Webseiten

In seinem neuesten Entwicklersnapshot hat das NVDA-Team die Zugänglichkeit zu Flash- und Java-Anwendungen, die im Browser laufen, verbessert. Hierbei gehen Mick und Jamie neue Wege in der Art der Benutzung dieser Rich Internet Applications.

Bisher werden Flash-Inhalte von kommerziellen Screen Readern innerhalb des virtuellen Puffers, also als Teil der Webseite, dem Benutzer zur Verfügung gestellt. Java-Applets werden gar nicht im virtuellen Puffer angezeigt, sie muss man durch Tabben bei ausgeschaltetem virtuellen Cursor suchen.

Das Einschließen von Flash-Inhalten im virtuellen Puffer birgt das Problem, dass diese Inhalte, so sie denn überhaupt zugänglich sind, so dynamisch sind, dass das Lesen oft schwierig ist, da sich diese Inhalte regelmäßig verändern oder aktualisieren. Auch andere Teile der Webseite können davon betroffen sein, und je nach Screen Reader ist dann ein ständiges Wechseln der Inhalte unterm virtuellen Cursor die Folge, oder die Inhalte werden gar nicht aktualisiert und sind dementsprechend veraltet.

Nicht umsonst finden 71% der Teilnehmer der ersten Screen-Reader-Umfrage von WebAIM Flash schwer oder sehr schwer zu benutzen. Dies ist mit Abstand der höchste Wert aller in dieser Kategorie vertretenen Technologien.

NVDA verfolgt hier einen anderen Ansatz. Befindet sich Flash oder ein Java-Applet auf einer Seite, wird im virtuellen Puffer lediglich ein eingebettetes Objekt angezeigt. Um mit diesem Objekt zu arbeiten, macht man folgendes:

  1. Man navigiert mit dem virtuellen Cursor auf das eingebettete Objekt. NVDA sagt so etwas wie „Eingebettetes Objekt anklickbar“.
  2. Nun drückt man Eingabe. NVDA wiederholt den Namen des Objekts, um anzuzeigen, dass sich der Fokus jetzt hier befindet.
  3. Als nächstes drückt man Tab. Wichtig, wirklich Tab drücken und nicht etwa die Pfeiltasten, da sonst der Fokus wieder aus dem Objekt herausfällt und auf das nächste Objekt wandert, das der virtuelle Cursor unter sich findet. Erst durch Tab wird tatsächlich in das Objekt hineingezoomt und die Interaktion mit den Elementen des Flash- oder Java-Objekts gestartet.
  4. Man kann jetzt Schalter drücken oder andere Dinge in diesem Flash-Element tun, welche es zulässt. In einem gerade wiedergegebenen YouTube-Video spulen z. B. die Tasten Pfeil links und rechts vor und zurück.
  5. Will man das Objekt verlassen, drückt man NVDA+Leertaste. Hierdurch landet man wieder im virtuellen Puffer und kann weiter navigieren.

Anwendern von VoiceOver auf dem Mac kommt diese Art des Hineinzoomens bekannt vor: VoiceOver verwendet diese Technik des Interagierens in allen möglichen sich bietenden Momenten, um alles um ein bestimmtes Objekt herum auszublenden und nur die Inhalte dieses Objekts zu präsentieren.

Hinweis: Damit die obige Vorgehensweise mit Java-Applets funktioniert, muss diese natürlich die Tastaturnavigation unterstützen, mit SWING-Komponenten gebaut sein, und der Anwender muss neben der eigentlichen Java-Laufzeitumgebung auch die Java AccessBridge für Microsoft Windows installiert haben.

Dieser neuartige Ansatz des Interagierens mit solchen eingebetteten Objekten bietet eine ganze Menge Chancen, mit Flash wesentlich kontrollierter umzugehen als dies bisher der Fall war. Man interagiert hier wieder mit dem Objekt selber und hat nicht den virtuellen Puffer dazwischengeschaltet, der Tasteneingaben filtert und auch anderweitige Ungenauigkeiten zur Folge haben kann.

Für Flash- und Java-Entwickler bedeutet dies, dass sie noch mehr denn je darauf achten müssen, dass ihre Anwendungen barrierefrei sind. Mit NVDA haben sie glücklicherweise ein kostenloses Werkzeug zur Verfügung, damit dies gleich getestet werden kann.

Für Adobe, die das NVDA-Projekt ja finanziell unterstützen, sollte dies ein Anreiz sein, den Flash Player auch unter Linux und Mac OS X zugänglich zu machen. Hierfür hat maccessibility.net eine Petition laufen, die Adobe dazu auffordert, dies zumindest für die Mac-Version bald umzusetzen. Wenn Du diese Petition noch nicht unterschrieben haben solltest, wäre es toll, wenn Du Deine Unterstützung signalisieren würdest, indem Du sie unterschreibst!

Dem NVDA-Team einen herzlichen Glückwunsch zu dieser wirklich gelungenen Umsetzung!