Aria Live Regions gehören zu den spannenderen Attributen bei Wai-Aria und haben – trotz der noch schlechten Unterstützung durch Screenreader – für einiges an Aufsehen gesorgt. Das Aria Best Practices Dokument ist ein guter Einstieg in Liveregions. Neben dem Attribut aria-live können die Attribute aria-busy, aria-relevant und aria-atomic das Vorleseverhalten im Screenreader beeinflußen. Bei Liveregions muß immer bedacht werden, daß ein ständig oder zu viel plappernder Text nervt und den User eher bei der Erfüllung seiner Aufgaben stört als weiterhilft. Dieses Problem wird allerdings vom oben genannten Best Practice Dokument mehr als ausgiebig beschrieben, so daß selten Fehlimplementierungen zu finden sind.
Wann Liveregions überhaupt Sinn machen?
Das grundsätzliche Mißverständnis von Liveregions liegt darin, daß viele Entwickler Liveregions als generelle Antwort auf das Problem von dynamischen Änderungen des Contents sehen. Sie also meinen, das ein HTML-Bereich immer als Liveregion ausgezeichnet werden sollte, wenn sich der Content, zum Beispiel aufgrund einer Ajax-Response, dynamisch ändert.
Hierbei wird allzu gerne folgender Text des Best Practices Dokuments überlesen/mißverstanden:
Live regions enable assistive technologies, such as screen readers, to be informed of updates without losing the users’ place in the content.
Damit hört sich das Feature “Liveregion” ziemlich cool an (und ist es auch). Man kann nämlich ohne den Fokus des Users ändern zu müßen, Informationen vorlesen laßen: Zum Beispiel kann ein Warenkorb darüber informieren, daß das Produkt nun erfolgreich im Warenkorb abgelegt wurde, ohne daß der User wegbewegt wird, er also weiterhin innerhalb des Produktskatalogs surfen kann. Er kann über neu eingegangene Chat-Nachrichten informiert werden, ohne daß er bei seiner eigenen Eingabe einer Nachricht gestört wird. Oder der User kann mit Hilfe der Rolle alert, welche implizit eine Liveregion ist, auf Fehler innerhalb eines Formularprozeßes aufmerksam gemacht werden, ohne ihn am weiteren Ausfüllen anderer Formularfelder zu behindern.
Leider wird die Kehrseite hieraus nicht deutlich gemacht und es kommt dadurch zur Fehlimplementierung. Diese Kehrseite könnte beispielsweise wie folgt lauten:
Liveregions ermöglichen es assistiven Technologien über geänderte Inhalte informiert zu werden, ohne daß der User mit diesen Inhalten – zumindest sofort – interagieren kann/soll/muß.
Ist der Text etwas länger, stärker strukturiert oder bietet gar Eingabemöglichkeiten wie Links, Formulare oder andere Eingabewidgets, möchte der User diesen Text nicht dumpf vorgelesen bekommen, er möchte mit diesem interagieren. Hierzu muß er jedoch den aktuellen Bereich verlaßen und zum neu geänderten Content gebracht werden. Dies ist eine Aufgabe, die von Screenreadern in Kombination mit Liveregions (noch) nicht erfüllt wird (eine gewisse Ausnahme stellt hier der Screenreader Orca dar, welcher auf Wunsch des Users auch zu einer Liveregion springt), von der Aria-Spezifikation nicht gefordert wird (obwohl es Sinn machen würde), aber letztendlich auch gar nicht erfüllt werden muß.
Für diese Art von Content-Änderung benötigt man nämlich kein Aria. Die Lösung ist kinderleicht zu impelentieren und funktioniert auch in vielen nicht Aria-fähigen Screenreader-Browser-Kombinationen. Die Lösung heißt focus.
Wenn wir beispielsweise folgendes geändertes HTML haben…
<div id="live-content"> <h2 tabindex="-1">Überschrift von neuem Content</h2> <!-- weiterer Inhalt --> </div>
können wir mit folgender Funktion …
function setFocus(elem){
setTimeout(function(){
try {
elem.focus();
} catch(e){}
}, 0);
}
den Fokus auf folgende Weise…
setFocus(document.getElementById('live-content').getElementsByTagName('h2')[0]);
ganz einfach verschieben, so daß die Überschrift des neuen Contents vorgelesen und der User mit dem neuen Content interagieren kann. Das uncolle an dieser einfachen Art für Zugänglichkeit zu sorgen, ist einzig und alleine, daß wir im Prinzip praktisch keine neue Technik einsetzen und es potentiell die Möglichkeit gibt, daß es auch in “älteren” Screenreadern funktionieren könnte.
Wer dies in möglichst vielen Screenreadern zum Laufen bringen möchte, sollte sich den großen Screenreader Fokus Test durchlesen.
Wozu das setTimeout()? Hat das irgendwelche Vorteile?
Danke,
Martin
Comment by Martin Kliehm — December 31, 2009 @ 2:59 am
ja, das hat einen riesigen Vorteil. Und ich wollte das als 4. Teil der Epic Fail-Reihe etwas genauer erklären. Es macht allerdings nichts, das vorweg zu nehmen, da dies in diesem Blog schon gefühlte zweitausendmal erklärt wurde. (Ich würde behaupten in jedem Artikel in dem die 4 Buchstaben Aria auftauchen).
Das Fokusieren bei gerade erst erschaffenen Elementen bzw. eben sichtbar gemachten Elementen funktioniert in Jaws nur, wenn dies in einem “späteren Thread”, als das Sichtbarmachen/Hinzufügen erfolgt. Mit Javascript kann man das ganz einfach durch setTimeout erledigen.
Wenn du das selber kurz antesten möchtest: Fokusieren ohne timeout und fokusieren mit timeout. Ich habe den Test ohne timeout eben erst schnell erstellt und nur mit IE 8/FF 3.5 + Jaws 10 getestet, aber die Ergebnisse, die für die anderen Systeme, jeweils unten in der Tabelle stehen müßten meines Wissens (Erfahrung macht´s) nach stimmen.
Der hier erwähnte große Fokustest versucht für diesen großen Unterschied auch eine Erklärung zu finden (ist natürlich eine reine Vermutung, aber klingt ziemlich plausibel).
Im Aria Best Practices Dokument gab es dazu auch mal einen Hinweis, allerdings finde ich diesen nicht mehr und ich schätze, daß er gelöscht wurde, was extrem schade ist, da wie gesagt ein typischer Fehler beim Aria-Einsatz. Den Text, welcher im Best Practices Dokument stand, konnte ich nur noch bei wiki.codetalks.org finden.
Nachtrag:
Es sei erwähnt, daß der Hinweis auf setTimeout bei wiki.codetalks nebulös von “strange things” – bei click events auf form controls – redet. Daher ist nicht klar, ob sie setTimeout aus denselben Gründen empfehlen, wie ich. Wenn dem nicht so ist, gibt es aber alleine schon 2 Gründe setTimeout zu nutzen.
Comment by alexander farkas — December 31, 2009 @ 6:08 am
http://www.w3.org/WAI/PF/comments/details?comment_id=240
Sollte aber aus anderen Gründen wieder aufgenommen werden….
Comment by alexander farkas — December 31, 2009 @ 7:26 am
Hallo,
ich hab mich auch schon ein bisschen mit WAI-ARIA beschäftigt und probieren gerade ein wenig mit Live Regions bei einem Ajax-Warenkorb rum.
Ich hatte bis jetzt immer den Warenkorb als aria-live=polite gekennzeichnet.
Jetzt habe ich mir aber gedacht, das es vielleicht gar nicht nötig ist, den ganzen Warenkorb als Live Region auszuzeichnen und statt dessen einfach ein alert mit yellow- Fade zu geben “Der Artikel wurde dem Warenkorb hinzugefügt.” Aber nach deinem Beitrag hier bin ich mir noch unsicherer.
Was würdest du denn vorschlagen, bei einem Warenkorb der per Ajax gefüllt wird? Also wie soll man am besten so einen Warenkorb für Screenreader User zugänglich machen?
Comment by Lars — January 4, 2010 @ 6:12 am
Die Sache die du derzeit machst als auch die Sache, die du vorhast, hören sich beide nicht schlecht an.
Im Prinzip soll der User bei einer Aktion erfahren, daß diese etwas (erfolgreich) ausgelöst hat. Dies muß natürlich sowohl für Sehende (yellow-fade möglichst in der Nähe des Klickbereichs) als auch für Blinde erfolgen.
Für Blinde sollte der Text kurz sein, aber auch gleichzeitig die wichtigen Infos haben: Also a) Produkt x wurde hinzugefügt und b) Warenkorb hat jetzt einen Stand x EURO.
Dieser Text muß hierbei kein alert sein, sondern kann eine normale liveregion sein.
Ein alert ist im Prinzip nichts anders als eine Liveregion mit der Einstellung assertive (früher das stärkere: rude) und der vorangestellten Rollenbezeichnung (im deutschen: Hinweis!). Diese Rolle ist für wichtige Informationen gedacht und vom Vorleseverhalten etwas aufdringlicher als live=”polite”. Das Updaten des Warenkorbs ist hierbei mit Sicherheit nicht so wichtig, so daß ein alert eigentlich falsch ist. Der Text könnte also auch in einem Bereich mit aria-live=”polite” stehen.
Was das alert, aber dennoch interesssant macht, ist daß es im Gegensatz zu allen anderen Liveregionen bereits ab Jaws 8 funktioniert (alle anderen erst ab Jaws 10). Worauf du beim alert achten solltest:
Liveregionen lesen im allgemeinen “verkürzte” Strukturinformationen vor. Alert liest nur Text (du kannst aber dennoch rein der Optik wegen strukturieren). Bei NVDA 0.6p2 hatte ich einmal das Problem, daß – aufgrund irgendeines semantischen Elements – der Inhalt nicht vorgelesen wurde. Ich hatte das durch die Rolle presentation auf alle Inhaltselemente gelöst.
Du kannst übrigens auch den sichtbaren Hinweis vom vorgelesenen Inhalt abkoppeln und unterschiedliches ausgeben. Wenn du beispielsweise auf http://www.aperto.de/start/referenzen.html gehst und dort mit firebug das HTML inspectest, siehst du unter dem div#wrapper mehrere HTML-Elemente. Das 2. von oben ist beispielsweise ein alert und darunter kommt ein wrapper, welcher ein live=”polite” enthält. Wenn du innerhalb der Referenzen rumklickst, siehst du wie sich der Inhalt der liveregion für einen Bruchteil einer Sekunde ändert. Der Inahlt gibt im Prinzip nichts anderes wieder, als das die Referenzen X geladen werden. Der Titel der geänderten Referenzen wird bei Success dann geladen. “Leider” ist unser Backend so schnell, daß ich überlege es rauszunehmen.
Ich hoffe das hilft dir weiter.
Grüße
Alex
Comment by alexander farkas — January 4, 2010 @ 1:39 pm