Alexander Farkas versucht in seinem Artikel WAI-ARIA – Epic Fail (Too much accessibility – good intentions, badly implemented) und vor allem in seiner Serie WAI–ARIA Epic Fail zu ergründen, warum in der Implementierung von WAI-ARIA doch noch einiges unrund ist.
Kurz kommentiert: Die Implementierung von WAI–ARIA ist ohne Screenreader-Test zwar machbar, aber wenig sinnvoll. Abgesehen davon zeichnet sich barrierefreie Entwicklung großteils durch das Testen mit Screenreadern aus. WAI-ARIA ist ein aktueller Standard, der von Elementen und Attributen her unterschiedlich gut schon von assistiven Technologien unterstützt wird – das konnte ich vor kurzem bei den Attributen für Formulare feststellen. Es war nicht immer einfach zu entscheiden, liegt es am gewählten Screenreader, Browser oder an einer Kombination von beidem, dass das WAI-ARIA-Attribut nicht vorgelesen wurde. Man hat sich also immer auf dem Laufenden zu halten, was die Implementierungstiefe betrifft, insofern muss man auch mit den aktuellsten Updates arbeiten.
Ob man jetzt eher mit der konkreten Spezifikation von WAI-ARIA oder dem von der WAI ebenso zur Verfügung gestellten Best-Practice-Dokument, sollte man jedem dann selbst überlassen. Ich fand letzthin der Gang durch die WAI-ARIA-Spezifikation sehr spannend, weil mir klar wurde, wie umfassend und detailliert der Standard letztlich dann ist. Durch die allgemeine Diskussion laufen ja eher nur die landmark roles, die live regions zu einem gewissen Teil und ein paar Attribute für Formulare – das war es dann aber auch schon. Aber davon gleich abzuleiten, gut – der gestandene
barrierefreie Entwickler setzt dann das schnell irgendwo ein und hübscht sich seine barrierefreien Seiten auf, ohne sich intensiver sowohl mit Standard als auch der praktischen Ausgabe auseinandergesetzt zu haben, ist schlicht nicht stimmig. Und ich kenne nun doch schon einige barrierefreie Entwickler.
Letztlich glaube ich, dass ein Missverständnis bei Farkas vorliegt, was das Thema Liveregions und sein Verständnis bei den barrierefreien Entwicklern betrifft. Ich denke, jeder der sich mit dem Thema beschäftigt, sich die Ausgaben angehört und die Spezifikation oder ähnliches dazu gelesen hat, weiss, dass der Nutzer nur über Änderungen auf der Webseite informiert wird, aber auch nicht mehr – also keine sonstigen Aktionen oder Fokusänderungen daran gebunden sind. Nichts andres besagt der Abschnitt in der Best-Practice – aber ich lasse mich gerne korrigieren:
Live regions enable assistive technologies, such as screen readers, to be informed of updates without losing the users‘ place in the content. Live region settings provide hints to assistive technologies about how to process updates. Note that the assistive technology is responsible for handling these updates and enabling users to override these hints.
Quelle: 5.2. Implementing Live Regions
Ich denke trotzdem, dass die Reihe von Farkas wichtig ist, weil es eben gerade bei Standards, die noch nicht vollständig in der Praxis umgesetzt sind – Browser, Screenreader – eben Graubereiche gibt, geben muss. Das meint nicht, dass wir als barrierefreie Entwickler mal wieder nicht alles gelesen oder fertig implementiert haben, sondern dass wir uns sehr wohl der Graubereiche bewusst sind und erst lernen, wie man damit am besten umgeht. Hat man sich mehrmals das Attribut aria-required in Screenreadern angehört, kann man dieses Attribut dann getrost in die Breitenwirkung geben. Erst wenn assistive Technologien auch Attribute aus HTML 5 auslesen – wie etwa required – muss man sehen, wie man mit dieser Mehrfachbelegung dann umgeht, geht es wieder darum, Standards abzuwägen. Und: ich halte es für wichtig, das immer wieder zu tun.
Hallo Sylvia,
nenne mich doch bitte einfach Alex/Alexander oder wenn du förmlich werden willst Alexander Farkas, einfach Farkas hört sich etwas komisch an.
Zu deinem Kommentar: Ich finde ihn recht interessant, da du ihn aus einer ganz anderen Perspektive siehst, als ich ihn gemeint habe.
Du schreibst folgendes:
„Ich denke, jeder der sich mit dem Thema beschäftigt, sich die Ausgaben angehört und die Spezifikation oder ähnliches dazu gelesen hat,…“ [weiß bescheid].
Im Prinzip sage ich hierzu nichts anderes. Wenn das alles passieren würde, dürfte es keine Probleme geben, aber leider ist dem nicht so.
Daraus daß nur ein kleiner Aria-Teil im Mittelpunkt der Diskussion steht, leite ich absolut nichts ab. Im Gegenteil, die von dir angesprochenen Attribute aria-invalid/aria-required und die Landmarks werden in meiner Reihe „Epic Fail“ keine Rolle spielen (wobei es zu landmarks noch einiges zu sagen gibt, was bisher nicht gesagt wurde). Ich verlange von keinem Entwickler, daß er sich die Ausgabe hier mehrmals angehört hat, da bei diesen Attributen die Fehleranfälligkeit extrem gering ist.
Ich habe auch nicht behauptet, daß das Aria Best Practices Dokument oder die Spezifikation die Vorleseeigenschaft von Liveregions nicht zutreffend beschreibt. Das Problem ist nur, daß diese Vorleseeigenschaften bei vielen Entwicklern nicht angekommen sind und daß man dies daher deutlicher machen muß.
Wie ich bereits in meinem Eingangsartikel zu der Reihe geschrieben habe, werde ich nur typische Fehler beschreiben. Also Fehler, die ich bereits häufiger im Netz oder anderswo gesehen habe.
Ich würde dir jetzt auch gerne die Beispiele nennen, aber ich hatte in meinem Eingangsartikel ja deutlich gemacht, daß ich die Praxisbeispiele schlicht und einfach nicht nennen werde, um das Problem „des an den Pranger stellens“ zu umgehen und dies nun doch über die Hintertür eines Kommentars zu tun, wäre ziemlich uncool.
Wenn du viel zu Javascript und Barrierefreiheit ließt, sollte dir – in den letzten Tagen – mindestens ein deutscher Artikel mit einer problematischen Erklärung von Liveregionen aufgefallen sein.
Hallo Alexander,
ja, Du hast recht, das Österreichische greift öfter nur zum Nachnamen, ich vergesse immer mal wieder, dass sich das hier merkwürdig anhören kann. 🙂
Nun, Dein Artikelstart war auch eher polemisch, also so habe ich ihn verstanden, und da kann es dann halt auch zu Missverständnissen kommen. Vor allem weil Du schon darauf hinweist, dass sich barrierefreie Entwickler zu wenig praktisch engagieren würden, also etwa einen Screenreader anwerfen. So hab ich das gelesen.
Ah, das dachte ich mir schon, dass Deine Serie weniger auf so Standards-Attribute, die wenig kritisch zu nutzen und einzusetzen sind, zielen wird. Wenngleich es auch im Formularbereich Attribute gibt, die nicht so einfach einzusetzen und auch zu kontrollieren sind, weil die Ursache des Fehlers nicht immer einfach zu eruieren ist derzeit noch.
Also – ich finde gut, dass Du das machst, diese Gegenlese. Vor allem weil ich weiss, dass es nicht immer so einfach ist, diese Schere zwischen Pranger und Tutorial, wie Du sie nennst, auch hinzukriegen. Ist auch eine wirkliche Gratwanderung, wie ich immer wieder feststelle.
Okay, ich könnte jetzt mal Tipps abgeben, welche Artikel zu meinst, aber da sind wir wieder in dieser unguten Schere. 😉 Aber ich werde das alles mal genauer nachlesen, was in die engere Auswahl kommen könnte.
Ich lese alles zur Barrierefreiheit, aber nur bedingt alles zu Javascript. Deshalb find ich es immer so spannend, Deine Artikel mitzulesen, Du versuchst interessante Fragen auszuarbeiten. Wichtig.
ARIA == Im Screenreader testen http://bit.ly/7srV3m
This comment was originally posted on Twitter