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.

11 Gedanken zu „HTML-Elemente in einem Dokument richtig zu plazieren ist wichtig!“

  1. Ich finde es ehre ungewöhnlich, dass Skripte den Inhalt an den Ende des Dokuments setzen, ist mir zumindest schon lange nicht mehr untergekommen. Und schon eher gar nicht, wenn es sich um die Display- oder Austausch-Methode handelt. 🙂

    Und vielleicht sollte man dahingehend – in die Zukunft argumentieren, dass Skripte für Screenreader direkt zugänglich sind und er den Zusammenhang quasi direkt hat, der Fokus sofort dorthin springt. 🙂

  2. Hallo Marco,

    die beiden Scripte sind dann von ihrer Wirkung her nicht unbedingt zu vergleichen. Das eine ist mehr so etwas wie ein Tab und das andere so etwas wie ein Dialog.

    Um mit HTML ein Dialogfenster vom optischen und vom Verhalten her hinzubekommen, ist es sehr naheliegend, daß man es entweder am Ende oder am Anfang eines Dokuments einfügt. Meine bisherige Taktik dies auch barrierefrei hinzubekommen lag bisher darin, zu versuchen, den Fokus auf die 1. Überschrift des Dialogs zu verschieben sobald es geöffnet wird. Wird das Dialogfenster wieder geschloßen, wird der Fokus wieder zurück zum öffnenden Link zurückversetzt. Dies funktioniert beispielsweise in Jaws 10 ganz gut.

    Ich habe hier eher das Problem, daß mir kein gescheiter Text für den Schließen-Schalter einfällt, damit klar wird, daß das Schließen ein zurück fokusieren bedeutet und es daher sinnvoll ist diesen auch zu nutzen.

    Vielleicht hast du ja einen Vorschlag.

    Grüße
    Alex

  3. Hm, Marco, vielleicht bin ich jetzt auf dem Holzweg. Aber die Thickbox Demo Seite setzt den Inline-Content in ein DIV mit display:none, der Screenreader – in meinem Fall JAWS 10 – setzt keinen Fokus in den neuen Layer, läuft die Schleife vom Anfang der Seite wieder durch, aber liest nie den Inhalt des Layers vor, weil ja display: none.

    Aber ich nutze ja Screenreader letztlich zu wenig, vielleicht gibt es da einen Trick, wie JAWS überhaupt eine Verbindung zwischen dem Thickbox-Layer und dem integrierten Layer herstellt.

  4. Hallo zusammen,

    Alex schrieb:

    Meine bisherige Taktik dies auch barrierefrei hinzubekommen lag bisher darin, zu versuchen, den Fokus auf die 1. Überschrift des Dialogs zu verschieben sobald es geöffnet wird. Wird das Dialogfenster wieder geschloßen, wird der Fokus wieder zurück zum öffnenden Link zurückversetzt.

    Das ist eine gute Strategie. Wenn Du zusätzlich WAI-ARIA einsetzen solltest, kannst Du dem Dialogfeld auch eine role „dialog“ geben, dann erkennt JAWS 10 auch, dass es sich um einen Dialog handelt.

    Du schriebst weiter:

    Ich habe hier eher das Problem, daß mir kein gescheiter Text für den Schließen-Schalter einfällt, damit klar wird, daß das Schließen ein zurück fokusieren bedeutet und es daher sinnvoll ist diesen auch zu nutzen.

    Nun, in Desktopanwendungen ist es eigentlich das erwartete Verhalten, dass man dorthin zurückkehrt, wo man gestartet ist, wenn ein Button o. ä. ein Dialogfeld öffnet. Ausnahme sind hier lediglich Menüs. Wenn ich also z. B. in Word von einem Dialog ein anderes öffne, erwarte ich nach dem Schließen dorthin zurückzukehren, wo ich war, und nicht z. B. irgendwo auf die Tableiste o. ä. geworfen zu werden.

    Genauso verhält es sich im Idealfall bei simulierten Dialogen auf Webseiten: Weiß ich, dass es sich um ein Dialogfeld handelt und schließe es, würde ich es als Bug empfinden, nicht wieder dort zu landen, wo ich gestartet bin.

    @Sprungmarker: Du läufst wahrscheinlich in den JAWS-10-Bug, dass manche Veränderungen des Styles nicht erkannt werden, bis man Einfügen+Escape zum Aktualisieren des virtuellen Puffers drückt. Das habe ich auch bemerkt, als ich das getestet habe. Löst Du also eine der Demos aus, drücke obige Tastenkombi und suche dann am Ende des virtuellen Puffers Ctrl+Ende nach dem neuen Inhalt.

  5. @Marco jetzt habe ich mit JAW10 für das Thickbox-Beispiel Inline Content den Link „Show hidden modal content“ geklickt, für Mac Parallels das Aktualisieren des Virtuellen Puffers jetzt richtig konfiguriert – das wird mir auch angesagt. Wenn ich jetzt mit CTRL + Ende auf das Seitenende springe, erhalte ich nur die Meldung „Dateiende leer“. Uff. 🙂

  6. Hallo Marco,

    ein sehr interessanter Artikel und ein Problem bzw. eine Fragestellung, welche in Zukunft noch viel öfter auf uns zukommen wird. Meine Lösung ist in der Hinsicht etwas „spartanischer“ und vielleicht auch nicht eben ideal:
    Ich verwende die Taktik, welche auf http://cakephp.org/ eingesetzt wird. Demnach sind im HTML-Quellcode H2-Überschriften mit darunter liegenden Absätzen definiert. Per JavaScript (jQuery) wird dann aus den H“-Überschriften eine horizontale Navigation angezeigt, mit welcher man die darunter erscheinenden Inhalte auswählen kann.
    Im Quellcode selber ist jedoch ein längeres Dokument mit verschiedenen Abschnitten, getrennt durch die H2-Überschriften, zu erkennen.
    Dies funktioniert ganz gut, wird aber wohl auch nur bei relativ geringen Inhalten funktionieren, da man sonst mit dem Screenreader eine ewig lange Seite durchforsten muss.
    Wie dem auch sei … RSS-Feed ist abonniert 😉

Was denkst Du darüber?