Accessible Media Stammtisch 15.10.2008

Transkript von Eric Eggert (noch nicht komplett redigiert)

Michael Stenitzer: WAI-ARIA

WAI-ARiA bietet neue Möglichkeiten für barrierefreie Webanwendungen… Ich habe oft von „Die Zukunft beginnt heute“ geredet, auch das Motto des A-Tags. Das Motto passt gut zum Web 2.0, wozu auch zu ARIA passt. Web 2.0 hat neue Herausforderungen in Sachen Accessibility zu Tage gefördert. In den letzten 5 Jahren ist viel passiert, das Bewusstsein in Sachen Standards hat uns da geholfen.

Nun haben wir komplexeste Interfaces, die auch für sehende Benutzer schwierig zu verstehen sind. Zu den Akronymen WAI = Web Accessibility Initiative, die Barrierefreiheitsabteilung des W3C. ARIA = Accessible Rich Internet Applications, also Zugängliche, funktionsreiche Webanwendungen. Browserbasierte Software. E-Mail Clients oder RSS Reader.

WHY-ARIA?

HTML ist nicht gut genug, seine Möglichkeiten sind beschränkt. Das Betriebssystem hat zw. 75 und 80 Steuerelemente, sie stehen für verschiedene Aufgaben bereit und können von Software benutzt werden. Screenreader und andere Hifsmittel können darauf zugreifen.

Bei HTML haben wir das nicht, es gibt gerade mal 12 Steuerelemente. Formularelemente, Links usw.

Bei einer Baumnavigation müssen wir uns anders helfen und sie nachbauen, genauso bei Checkboxen mit 3 Zuständen oder Schieberegler. Zudem kann ich nicht bestimmte Regionen einer Webseite auszeichnen. Das geht nur über Umwege durch unsemantische Konstrukte aus <div> und <span> sowie viel CSS & Javascript.

Bei den Bereichen benötige ich versteckte Überschriften um diese zu kennzeichnen. So geht es auch mit der Navigation, die ich hilfsweise als ungeordnete Liste auszeichne. Optisch ist das alles einfach erkennbar, ohne sind diese Konstrukte bedeutungslos.

Genauso hilft WAI-ARIA, wenn sich Bereiche der Seite ändern. Bei linearem Lesen mit einem Screenreader kann man nicht erkennen wo sich etwas geändert hat. Werden an einer Stelle der Seite Aktienkurse eingeblendet - die ich wohl im Moment eh nicht sehen will -, dann kann mich WAI-ARIA darüber informieren, das sich da was verändert hat.

Wenn man nur die Tastatur verwendet erreicht man nur Links und Formularelemente und wenn der Knopf auf dem Schieberegler keines dieser Sachen ist, kann man es nicht erreichen. WAI-ARIA hilft auch andere Elemente anwählen zu können.

Wie steht das im Zusammenhang zu WCAG2 und warum ist das nicht dort eingebunden. WCAG ist aber technologieunabhängig, WAI-ARIA ist ein Standard für Markup-Sprachen, wie HTML, XML oder XHTML. Für diese ist es eine flexible Erweiterung.

Wie funktioniert das? WAI-ARIA bietet keine neue HTML-Elemente, keine neue „Widgets“, übersetzt „Dingens“ (Tomas Caspers). Es bietet nur Attribute, die in XHTML verwendet werden können. dabei wird nur eine semantische Bedeutung vergeben. Die bedeutungslosen Elemente werden dazu zu einer Baumnavigation, Schieberegler usw.

Beispiel: Tabindex. Das gab es vorher in HTML schon. Falls es zur Technik fragen gibt: Bitte unterbrechen. Man hatte damit die Reihenfolge der Erreichbarkeit mit der Tastatur festlegen können. Das hat aber oft die sinnvolle Reihenfolge in der seite gebrochen. Das Attribut kann jetzt in jedem HTML-Element verwendet werden. Wenn ich einer H2 einen Tabindex mit -1 gebe, dann kann ich das Element mit Javascript ansteuern. Mit tabindex=0 ist das Element mit der Tastatur erreichbar und zwar in Reihenfolge der Elemente.

Bei einer Zahl>0 wird die Reihenfolge künstlich beeinflusst.

F: Funktioniert das in allen Browsern?

A: Ja, das funktioniert schon überall, der IE war vorreiter.

Der zweite Punkt bei WAI-ARIA sind Rollen, also gewisse Bedeutungen, die das role-Attribut nutzen. Beispiel: role=slider. Der Screenreader weiß dann, dass das ein Slider ist, egal wie es umgesetzt ist. Noch hat es keine Funktionalität, darum muss sich der Webentwickler selbst kümmern.

2. Beispiel: Landmark-Roles. Sie versehen Bereiche der Webseite mit einer Bedeutung, Navigation, Text und Heading. Wir haben diese Headings allerdings schon in HTML, sie sind für andere Sprachen konzipiert.

3. Beispiel: role=„tree“ - Also Bäume. Es gibt auch noch andere Bäume, dafür gibt es weitere Rollen, vielleicht ca. 50. Einige haben weniger Praxisbezug für Webseiten, andere einen sehr hohen.

Diese Role-Attribute geben also die semantische Bedeutung dieser Elemente. Dazu gibt es Unterrollen, die auch per role ausgezeichnet werden.

Zudem benötigt man States and Properties, also Zustände und Eigenschaften. Z.B. das der Schieberegler Werte von 0-100 haben kann und gerade bei 42 ist. Auch überschriftenebenen müssen so zugewiesen werden, Bäume müssen bestimmen, ob sie auf oder zugeklappt sind.

Eine weitere Sache, die schlecht in HTML umgesetzt ist sind bezeichnungen z.B. von Grafiken. Also dieser Text wird von diesem Element beschrieben. Das geht nun mit WAI-ARIA und mit den aria-labeledby-Attributen. Ähnlich wie die <label>-Elemente bei Formularen.

Auch verpflichtende Eingabefelder können damit ausgezeichnet werden. Durch aria-required=true.

F: Ist das etwas, was im Browser abgefragt wird?

A: Der Submitbutton greift nicht darauf zu, es kann Client- und Serverseitig abgefragt werden. Es ist für Screenreader und eine semantische Unterstützung im Dokument. Man kann auch nur Ganzzahlen oder ähnliches festlegen. Eine generelle Javascript-Library kann darauf dann zugreifen. Bei richtiger …

F: Kann ich das dann überprüfen?

A: Ich muss nur festlegen, dass die Attribute festgelegt sind.

Shadi: Sie sind nicht nur für Screenreader da, wo diese Attribute abgefragt werden ist aber egal, das kann auch der Browser sein, das Mobiltelefon. Es könnten dort nur Pflichtfelder angezeigt werden. Hier geht es nur um die Auszeichnung, wie das dann ausgewertet wird bleibt diesen Bibliotheken überlassen.

Nächstes Einsatzfeld: Live-Regions, also auf einer Seite aktualisierte Bereiche. ARIA kennt vier Geschmacksrichtungen wie man die Benutzer informieren kann:

• off = Keine Benachrichtung für Hintergrunddinge
• polite = Für Änderungen im Hintergrund, die danach abgefragt werden, sobald der Screenreader nutzer fertig ist
• assertive = Lautere Unterbrechung, aber weiter unterbrechbar
• rude = Direkte unterbrechung, z.B. wenn der Datenbankserver abgestürzt ist und man nicht mehr darauf zugreifen kann.

Dann gibt es noch weitere Einstellungen mit dem man Umfang dieser Unterbrechungen bestimmen kann.

Die Frage ist nun: Wie binde ich es in HTML ein. Die einfachste Version ist es einfach ins HTML die Attribute rein zu schreiben, was für die Webentwickler wichtig ist. Man kann Fehler dann schlechter finden.

Man kann die Attribute auch per JavaScript einfügen, durch addAttribute und removeAttribute. Das JS wird vor der Validierung nicht ausgeführt, dadurch werden die Elemente validierbar.

F: Wann kann man das einsetzen?

A: Man muss das mit Den Doctypes noch herausfinden, das ist im Moment das größte Problem mit der Validierung. Shadi: HTML ist nicht gut erweiterbar. Michael: XHTML1.1 ginge, aber der IE nimmt diese Seiten nicht an.

F: Kann man das auch in die Styles reinschreiben, vergeben einer Klasse?

A: Ja, das geht, aber man muss das über JavaScript abfragen. Das ist das was ich vorher meinte. Wenn ich es individuell lösen muss benötige ich eine ID. Ich kann ja nicht alle Beschriftungen von Bildern auf ein Element beziehen.

Bei tabularischen Formularfelder hab ich zwei Beschriftungen für ein Element, Zeile und Spalte.

F: Wenn ich das per JS einbinde, dann nehme ich das ja weg, wenn keines vorhanden ist.

A: Wenn kein JS da ist, dann habe ich auch keine Elemente, die sich verändern können. Für ein Slider würde es einen Ersatz geben, z.B. eine Dropdown-Box. Wenn man sich diese Sachen baut, dann muss man sich überlegen, was das HTML-Element ist, das am nächsten dran ist.

Maria Putzhuber: Wie ist das ich brauche Vorwärts und Rückwärtskompatibilität und dann wieder Vorwärtskompatibilität?!??

A: Man wird einfach das festlegen. Shadi: AJAX geht ja auch nicht ohne JS. Man muss sich darüber im klaren sein, wie weit man zurück gehen kann.

Wann geht’s los? Heute! – Aber es ist noch kein verabschiedeter Standard, auch wenn der Kern stabil ist. Shadi: Es geht hauptsächlich noch um die Anwendung im HTML. Michael: Das ist wie bei CSS und HTML, da kann man einiges noch nicht anwenden.

Es gibt aber bereits etliche Browser, die den Standard schon unterstützen. Der IE8 soll es auch dann können. Firefox kann die ersten Dinge seit Version 2.5, mit der Unterstützung von IBM. Auch Webkit und Opera sind schon sehr weit.

Die Browser sind ein wesentliches Element und haben es über weite Strecken schon berücksichtigt. Die Screenreader kennen ja schon die Standardkontrollelemente des Betriebssystem. Live Regions gibt es schon im neuen JAWS, auch FireVox eine Firefox-Extension kann einiges auch schon. Das alles ist aber ziemlich umständlich und auf den Browser beschränkt.

Wir sind auf einem guten Weg. Gerade die Toolkits, die User-Interface-Elemente haben werden das Umsetzen müssen. Sie liefern ja diese Elemente und Effekte. Der User hat die dann kostenlos dabei.

Frage Martin: Wie sieht das in YUI aus?

A: YUI 2.6.0 kann das bereits, es gibt Plugins. Auch in einigen Webanwendungen gibt es schon Implementationen, wie beim Google Reader. Ich denke wir sind nah dran, es hat aber experimentellen Charakter.

Man kann aber schon klein anfangen, zum Beispiel mit diesen Landmark-Roles, mit dem ARIA-Required.

F: Welche Programme unterstützen diese Landmark-Punkte

A: wichtig ist, dass der Browser das dem Screenreader weitergibt, optisch ändert sich ja nix. Es ist die Aufgabe des Webentwicklers dafür zu sorgen, dass man das erkennen kann. Wenn ich davon ausgehen kann, dass meine Screenreader-User aktuelle Versionen nutzen, dann kann icha uch auf versteckte Überschriften verzichten.

F: JAWS 9 oder 10

A: Wahrscheinlich JAWS 10, aber ich weiß nicht genau.

Shadi zur Rückwärtskompatibilität: Bei WCAG2 sind 5 Versionsnummern zurück festgelegt.

F: Wenn man beides hat, Landmarks und Überschriften, ist das dann keine Behinderung?

A: Nein, vielleicht eher eine Belästigung.

F: Wie bekommt der Screenreadernutzer diese Landmark-Informationen?

A: Wahrscheinlich wie Grafiken wird das ausgezeichnet.

F von Eva: Wie kann ich Navigation, Unternavigation usw. unterscheiden?

A: von Shadi: Das weiß ich nicht, das ist aber eher eine WCAG-Richtlinien-Sache. Aber wir haben das in den Techniken, über die wir reden. Der Effekt ist ja ähnlich wie wenn ich die Seite mit Headers zupflastere.

Dazu: Es ist primary, secondary usw. festgelegt.

Wir sollten diese Sachen aber zusammenhalten und nicht auf verschiedene HTML-Bereiche verteilen.

Publikum: WAI-ARIA ersetzt also nicht den Hausverstand? Nein, tut es nicht, es gibt nur mehr Möglichkeiten.

F: Geht das auch dynamisch über DOM?

A: Ja, das ist diese JavaScript-Sache. Es wird meistens dynamisch verteilt, mittlerweile, früher machte man das händisch.

F: Es ist einfacher, wenn man templatebasierte architekturen haben. Wie ist das aber mit der Serverseitigen Technologien bei denen ich keine Templates sehe (???).

A: GWT von Google beginnt jetzt mit der Implementation und es werden mehrere CMS das unterstützen. Diese Gruppen brauchen aber viel länger bis sie Accessibility benutzen.

F: Dann sind komponentenbasierte Frameworks eher schlecht?

A: Ja, je besser man aufs Template zugreifen kann, desto einfacher kann man darauf Einfluss nehmen. Davon haben sich ja auch die CMS mittlerweile verabschiedet.

F: Anderes Thema: Wie steht Barrierefreiheit Suchmaschinenoptimierung im Weg?

A: Naja, die Techniken, mit denen man Überschriften versteckt wird google ignorieren. so eindeutig ist die Sache nicht mit display: none, sie könnten vermuten, dass das ein Trick ist. Davon leben aber viele Seiten. Sie könnten da interpretieren wie das bei den Adblockern gehen, die die Klassen auswerten. Zum Beispiel „sponsor“ wird dort ausgeblendet.

F: Da gibt es keine offizielle Aussage von Google…

A: Ja, aber ich blende ja keine wirklichen Informationen aus.

Aus dem Publikum: Es gab einen Eintrag im Google Webmaster Center, dass sie es manuell prüfen, wenn es auffällig ist.

A: Bisher hab ich das nie erlebt, Barrierefreiheit hilft i.d.R. eher dem Suchmaschinen-Ranking.

F: Könnte man ja mal ein Experiment machen

A: Ja… Aber die Umstellungen von schlechten zu besseren Webseiten haben positive Auswirkungen, wir sehen das immer wieder, die Zugriffe steigen.

Fragen? Anregungen? Beschwerden?

Aus dem Publikum: Ein Dankeschön!