Vorgestern hielt ich beim IKT-Forum an der Johannes-Kepler-Universität in Linz einen Vortrag über ARIA und HTML 5 in freier Wildbahn. ARIA ist ein fast fertiger Webstandard des W3C, der bereits weite Unterstützung in Browsern und assistiven Technologien wie Screenreadern hat. Auch wenn der Standard noch nicht final verabschiedet ist, sollte man die Techniken einsetzen, da sie jetzt Menschen mit Behinderungen die Zugänglichkeit zu Websites ermöglichen.
Wie immer steht meine Präsentation bei Slideshare zur Verfügung, auch zum Download. Da es dort aber gerade technische Probleme mit den Vortragsnotizen gibt, die zum Verständnis wesentlich beitragen, gibt es die gesammelten Werke einfach hier:
-
Die Wahrnehmung von Barrierefreiheit und HTML5 ist oftmals, als wären sie natürliche Feinde.
-
… oder kann im Gegenteil Barrierefreiheit zusammen mit HTML5 Superkräfte entwickeln?
-
ARIA wird ungefähr seit 2006 von vielen Screenreadern und Browsern unterstützt, und es kommen immer mehr hinzu.
-
Im Folgenden möchte ich einige Beispiele aus der Praxis vorstellen, in denen wir ARIA eingesetzt haben.
-
Insbesondere auf der Startseite von bahn.de sind viele Elemente mit ARIA angereichert. Namics hat das Konzept, Design und die Frontend-Umsetzung realisiert, während die Bahn die Integration in das CMS, ins Buchungssystem und Backend vorgenommen hat (online seit Dezember 2008, weitere Entwicklungsphasen sind vorgesehen).
-
Die neu designten Seiten der Fraunhofer Gesellschaft sind im Juni 2009 online gegangen. Sie enthalten recht viel ARIA, was nicht weiter verwundert, denn Webstandards und Barrierefreiheit sind bei Fraunhofer nicht zuletzt durch die langjährige Leitung des deutschen W3C-Büros ein wichtiger Punkt.
-
Die neue Website der Schweizerischen Bibliothek für Blinde und Sehbehinderte wird voraussichtlich im August 2009 online gehen. Selbstverständlich ist ARIA integriert.
-
-
Zuerst sollten die niedrig hängenden Früchte geerntet werden. Einige Früchte bei ARIA hängen so niedrig, dass sie einem fast in den Mund fallen.
-
Mit
aria-requiredwerden Pflichtfelder ausgezeichnet. Ein Screenreader liest dann vor: „Eingabefeld, erforderlich“. Noch ein weiterer Pluspunkt: die Sprache passt sich automatisch an, ein englischer Screenreader würde also vorlesen: „input, required“. Somit sinken die Aufwände für eine Lokalisierung.
Video:
-
Ähnlich einfach zu integrieren ist
aria-invalid. Ein Formular wird serverseitig validiert, und bei ungültigen Feldern wird das Attribut
aria-invalid="true"eingefügt. Ein Screenreader liest vor: „Eingabefeld, ungültig“.
Video:
-
Aber selbst bei diesen einfachen Schritten können Fehler unterlaufen. ARIA ist für viele Entwickler, insbesondere im Backend, noch immer eine neue Technologie. Sie sind damit nicht vertraut und übersehen vielleicht relevante Anpassungen. Das sollte man nicht unterschätzen. Als Frontend-Entwickler haben wir also die Aufgabe, diese Techniken zu erklären.
-
Hier als Beispiel das Kontaktformular von Fraunhofer. Vorgesehen ist eigentlich, dass man per Tastatur auf den Absende-Button tabben kann, das Formular mit der Eingabetaste absendet und auf der neuen Seite Fehler unter anderem mit
aria-invalidmarkiert werden. Umgesetzt ist aber ein Formular mit einem aus Usability-Sicht überflüssigen „Zurücksetzen“-Button, und der Absendebutton funktioniert ausschließlich mit dem JavaScript-Event
onclick, woraufhin sich ein JavaScript-Alert öffnet. Damit wurde aber unwissentlich eine unüberwindbare Barriere für Menschen geschaffen, die keine Maus benutzen. Nur mit der Tastatur (oder ohne JavaScript) ist dieses Formular nicht mehr abzusenden. Um Spam zu vermeiden ist JavaScript eine ungeeignete Methode, weil sie Barrieren schafft und schlechte Usability für alle Nutzer bedeutet.
-
Sehr gut funktioniert hingegen die Navigation, in der sogar ARIA-Landmark-Rollen wie „Menü“ vorgelesen werden.
-
In der Navigation haben wir sowohl die ARIA-Rolle
navigationangegeben als auch
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2), das im XHTML Role-Modul spezifiziert wird.
-
Für das Aufklappmenü haben wir einen Link benutzt, weil diese im CSS bereits gestylt sind. Mit ARIA haben wir aber die Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)zugewiesen, damit ein Screenreader ihn als „Schaltfläche“ erkennt. Zusätzlich wird ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)benötigt, damit der Button per Tabulatortaste fokusierbar wird. Mit
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)kann eine Beziehung zu einem anderen Element hergestellt werden, das von dem Button gesteuert wird. Allerdings wird diese Beziehung noch nicht von assistiven Techniken unterstützt. Macht aber nichts, in der Zukunft ist das vielleicht der Fall, und dann steht die Beziehung schon drin.
-
Nun kommen wir zu vermeintlichen Feinden von Barrierefreiheit, dem HTML 5-Element
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2). Es ist richtig, dass derzeit Canvas von Screenreadern nicht erkannt wird und selbst Alternativtexte nicht vorgelesen werden. Bei Fraunhofer haben wir das Element aber als Verzierung eingesetzt, was unproblematisch ist.
-
Auf einigen Seiten von Fraunhofer.de gibt es zwischen der Navigation und dem Textinhalt Teaser-Elemente, die schräge Kanten oben und unten besitzen.
-
Es gibt sehr viele davon in unterschiedlichen Farben und Schattierungen. Entweder hätte man also zig Hintergrundbilder produzieren müssen …
-
… oder man verwendet Canvas. Wir haben hier zunächst in der Box ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)-Element in den Hintergrund gelegt. Das hat per CSS eine Hintergrundfarbe, eine Transparenz (opacity) und ist rechteckig. Per JavaScript werden die Farben ausgelesen und das
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)-Element durch ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)-Element ersetzt, das schräge Ecken hat. Das wird in allen aktuellen Browsern unterstützt außer im Internet Explorer. Dazu gibt es eine Alternative, die wir gleich erfahren werden.
-
-
Bei der Website der Schweizerischen Blindenbibliothek gibt es einige Bedienelemente mit runden Ecken. Hier haben wir das CSS 3-Attribut
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)verwendet. Das ist schnell und flexibel einzusetzen und wird in fast allen Browsern unterstützt.
-
Natürlich wird
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)nicht vom Internet Explorer unterstützt. Hierzu erzeugen wir Hintergrundbilder mit runden Ecken mit dem proprietären Standard VML (Vector Markup Language), Microsoft’s Antwort auf SVG (Scalable Vector Graphics). Zunächst wird per Conditional Comment abgefragt, ob der Browser VML versteht. Wenn das der Fall ist, setzen wir eine Variable in JavaScript und erzeugen das VML-Element. Schließlich wird es per CSS gestylt.
Hierbei ist zu bemerken, dass im Internet Explorer 8 eine Breite oder Höhe von 100% für VML-Elemente nicht mehr funktioniert. Der Browser unterstützt nur noch Pixel- oder
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)-Werte. Interessant, dass Microsoft selbst seine eigenen „Standards“ bricht. Leider ist es etwas mühselig, dann für jeden Button je nach Textlänge eine feste Breite anzugeben. Alternativ kann man den IE8 auch in den IE7-Kompatibilitätsmodus zwingen.
-
In Opera 10 sieht die Seite derzeit ungefähr so aus: mit eckigen Ecken statt runden, aber das stört auch nicht wirklich.
-
Seit wenigen Wochen unterstützen Firefox 3.5 und der Safari-Browser auf dem iPhone mit OS 3.0 einen fast finalen Standardentwurf des W3C, Geolocation.
-
Bei der Schweizerischen Blindenbibliothek haben wir Geolocation eingesetzt entsprechend den Prinzipien des Progressive Enhancements. Nutzer, deren Browser Geolocation unterstützt, bekommen die Option, ihren Standort auf der Karte anzeigen zu lassen. Gedacht ist das vor allem für Sehbehinderte oder Blinde, die ein iPhone 3G S nutzen und die damit ihren Standort erfahren können auf dem Weg zwischen S-Bahn-Haltestelle und Bibliothek.
-
Oft benötigt man über die ARIA-Attribute in HTML hinaus noch JavaScript, um die Tastatursteuerung zu unterstützen. Man kann dazu Widgets verwenden, z.B. von jQuery UI, dojo oder YUI, die oft bereits ARIA eingebaut haben. Oder man muss diese Schritte selbst programmieren.
-
Auf bahn.de werden Registerkarten zur Navigation verwendet. Mit der Tabulatortaste kommt man auf den aktuellen Reiter. Tabbt man weiter durch, gelangt man in den offenen Reiterinhalt. Auf dem Reiter liest ein Screenreader aber auch vor: „Bahn, Registerkarte, eins von vier“. Somit weiß ein Nutzer, dass es sich um eine Reiternavigation handelt, auf der man wie in den Tabs im Browser mit den Pfeiltasten (und anderen Tasten) auf den nächsten Reiter kann. Auf der aktuellen Bahn-Seite ist leider noch eine ältere Version, die weniger intuitiv funktioniert. Aber die Entwicklung der Website geht weiter. ;-)
Video:
-
Vereinfachter Code. Bei der Bahn haben wir noch Hintergrundbilder, die per
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)eingefügt sind. Wenn zwischen dem Element mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)und dem Kinder-Element mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)andere Elemente liegen, können diese im Screenreader mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)ausgeblendet werden.
-
Damit die Reiternavigation per Tastatur funktioniert, muss per JavaScript ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)gesetzt werden. Die entsprechenden Tastatur-Events werden abgefangen. Dabei muss man differenzieren, ob eine Taste nur alleine oder zusammen mit Shift, Alt oder Strg gedrückt wurde, das macht einen Unterschied. Der Reiterinhalt wird dann eingeblendet, am besten, indem man eine Klasse hinzufügt oder entfernt.
Dann muss noch das Event-Bubbling verhindert werden. DOM-Elemente sind sehr mitteilungsbedürftig und sagen sofort ihren Eltern, wenn etwas passiert ist, immer so weiter bis zum Document-Root. Wenn ich aber mit der Pfeiltaste den Reiter wechsele, möchte ich vermeiden, dass beim Drücken der Pfeiltaste die Seite nach unten scrollt.
Schließlich muss man für ältere Screenreader noch den virtuellen Buffer aktualisieren. Beim Laden der Seiten wird die Seite in einem Puffer abgelegt. Ändert man später ein Element von
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)auf
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2), bemerkt das der Screenreader nicht. Im Formularmodus ändert sich der Inhalt aber ständig, der Puffer wird aktualisiert. Also schreibt man einfach per JavaScript in ein hidden Input-Feld irgendwelche Zufallszahlen.
-
Auf der Seite der Blindenbibliothek haben wir eine Merkzettelfunktion eingebaut. Blinde können sich schlecht mal eben Notizen auf einem Zettel machen, weswegen wir auf jeder Seite einen Button haben „zum Merkzettel hinzufügen“. Die Seiten werden sich dann in einem Cookie gemerkt. Die Bestätigung wird mit AJAX und dynamischer Textersetzung eingefügt, was Nutzer von assistiven Technologien nicht bemerken würden. Mit einer ARIA-Liveregion liest der Screenreader aber Änderungen in einem Abschnitt vor. (Anmerkung: hier sieht man einen funktionalen Prototypen, zum Zeitpunkt des Vortrags war das noch nicht „hübsch“ final umgesetzt).
Video:
-
Fazit: Barrierefreiheit und Technik (oder ansprechendes Design wie in diesem Uhrenentwurf von David Chavez) können sich sehr gut ergänzen.
-
Schöne Post, sehr schön dargestellt.
Sehr interessant ist besonders der canvas Part in Bezug auf Barrierefreiheit.
Die bei der Fraunhofer Gesellschaft eingesetzte Technik wäre meiner Meinung eine tTalk Vorstellung wert.
Gefällt mir, THX!
Hallo Martin und vielen Dank für die ausführliche Zusammenstellung (und die Arbeit die drin steckt)! Perfekt für einen aktuellen Überblick unserer Projekte.
Was mich noch mal interessieren würde:
Wie sieht es aus mit Semantik die sich in HTML5 und ARIA überschneidet? Zum Beispiel bei neuen Tags die sich überschneiden mit ARIA Attributen?
Gibts da schon Infos zu?
Hallo Felix,
manchmal scheint es nur so, als ob sich ARIA und HTML5 überschneiden: beispielsweise gibt es eine ARIA-Rolle für header und footer, aber auch HTML5-Tags. Die Rollen beziehen sich aber nur auf den Header und Footer einer Seite, während die HTML5-Tags mehrfach vorkommen und auch den header oder footer einer section bezeichnen können.
Wenn es tatsächlich Überschneidungen gibt, etwa input type=”checkbox” role=”radio”, dann trumpft immer ARIA.
Cheers,
Martin
Ahh ok, das macht Sinn. Und im Zweifelsfall nutze ich lieber zuviel Semantik (also ein HTML5 Objekt mit ARIA Attributen) oder wie du sagest “ARIA ist Trumpf”?
Danke für die Antwort und Grüße aus de Norden nach FFM
Felix
Kommt darauf an, was Du machen möchtest. Browser ignorieren ja Elemente, die sie nicht kennen. Darum bringt ein neues HTML5-Element plus ARIA-Attribut im Browser und für assistive Techniken in MSAA keinen Vorteil. Wenn Du rückwärtskompatibel sein möchtest – was ich bei der Frequenz der Änderungen in HTML5 für Kundenprojekte stark empfehlen würde – nimm’ lieber generische HTML 4- oder XHTML 1-Elemente wie DIV und füge die Semantik per ARIA hinzu.