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

sehr lesenswert: Marco Zehe über dynamische Veränderungen auf Seiten und Screenreader. [link to post] (via @Flocke)

– Posted using Chat Catcher

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.

RT @Flocke: sehr lesenswert: Marco Zehe über dynamische Veränderungen auf Seiten und Screenreader. [link to post]

– Posted using Chat Catcher

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.

sehr lesenswert: Marco Zehe über dynamische Veränderungen auf Seiten und Screenreader. [link to post]

– Posted using Chat Catcher

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

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.