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.