Dieser Blogeintrag richtet sich an alle LeserInnen dieses Blogs, die Webapplikationen mit fortgeschrittenen Widgets und angereicherten Inhalten in HTML, CSS und JavaScript entwickeln. Wenn ihr vorhabt, die WAI-ARIA-Rolle „application“ zu verwenden, haltet inne und überlegt zweimal, ob ihr sie wirklich braucht! Und hier kommt wieso:
Was ist das? 🔗
„application“ gehört zu den WAI-ARIA landmark roles, also Rollen, die bestimmte Navigationspunkte in Webdokumenten setzen. Sie wird dazu verwendet, Teile einer Webapplikation auszuzeichnen, die wie eine Desktopanwendung behandelt werden sollen, nicht wie ein Dokument im Web. Wenn ihr also Webapplikationen baut, die aus ungefähr über 90% Widgets bestehen und auch ansonsten keine Ähnlichkeit mit einer herkömmlichen Webseite haben, könnte die Benutzung von „application“ angemessen sein. Wenn ihr im Gegensatz dazu aber eine Benutzeroberfläche baut, die aus klassischen Eingabeelementen wie Textfeldern, Kontrollfeldern, Ausklapplisten usw. besteht und darüber hinaus weit verbreitete komplexere Widgets vorkommen, und eure Seite ansonsten aus dokumentüblichen Strukturen wie Hyperlinks besteht, lasst die Finger von role „application“! Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, wissen in der Regel mit solchen Elementen automatisch richtig umzugehen.
Warum sollte ich sie überhaupt verwenden? 🔗
Klassischerweise wandeln assistive Technologien wie Screen Reader für Blinde Webseiten in ein Ausgabeformat um, das für diese Zielgruppe einfacher zu verstehen ist. Ein zweispaltiger Text im Zeitungsstil wird in ein einspaltig vom Beginn bis zum Ende fließendes Dokument umgewandelt. Mehrspaltige Seitenlayouts werden so verschlankt, dass sie einen logischen Fluss bilden und für jemanden, der den Bildschirm nicht sehen kann, erfassbar werden, ohne dass es ein großes Durcheinander an Informationen gibt.
Um dies zu erreichen, haben assistive Technologien, speziell unter Windows, ein zweistufiges Interaktionsmodell entwickelt: virtueller Cursor oder Browse-ModusDies ist der Modus, in dem Screen Reader operieren, wenn sich der Benutzer eine Webseite anschaut. Der Begriff virtueller Cursor wird seit seiner Erfindung im jahr 1999 verwendet und bedeutet, dass der Benutzer eine Webseite mit den Pfeiltasten durchlaufen kann als würde er ein MS-Word- oder Editor-Dokument lesen. Neben dem eigentlichen Text werden semantische Informationen vorgelesen wie ob ein Element ein Link, eine Schaltfläche, Teil einer Datentabelle, ein Formularelement ist usw. Weiterhin werden auch viele Tastatureingaben abgefangen und nicht an den Browser weitergegeben. Diese werden dazu verwendet, sich innerhalb solcher virtueller Dokumente schnell zu bestimmten Elementen zu bewegen wie Überschriften, Formularelementen, Links, Listen, Tabellen usw. Dies wird üblicherweise durch den Druck auf einzelne Buchstaben erreicht. Der visuelle Fokus kann sich dem aktuellen Element, auf das der virtuelle Cursor zeigt, angleichen, wenn dieses den Fokus erhalten kann, muss dies aber nicht zwangsläufig tun; das hängt von der Implementierung und manchmal auch den Einstellungen des verwendeten Screen Readers ab.Formular- oder Fokus-ModusDieser Modus ist aktiv, wenn der Anwender mit Elementen interagiert, die irgendeine Form von Dateneingabe akzeptieren. Dies kann eine Texteingabe, das Umschalten eines Kontrollfeldes, die Auswahl eines bestimmten Auswahlschalters (radio button) oder die Auswahl in einer Ausklappliste sein. Um in diesen Modus zu gelangen, steuert der Anwender den virtuellen Cursor auf ein solches Element und drückt entweder Eingabe oder der Screen Reader aktiviert bei Erreichen eines solchen Elements den Fokus-Modus automatisch. Andere Screen Reader aktivieren diesen Modus z. B. aber nur dann, wenn explizit mit tab auf so ein Element gesprungen wird. In diesem Modus werden alle tastatureingaben an den Browser durchgereicht. Es ist so als wenn ihr ohne Screen Reader vor eurem Browser sitzt und ihn mit der Tastatur bedient. Analog wird dieser Modus wieder abgeschaltet, wenn man entweder eine Taste wie escape drückt oder der Anwendungsfokus so ein Element wieder verlässt und der Screen Reader diesen Modus vorher selbstständig eingeschaltet hatte. Es wird zum virtuellen Cursor/Browse-Modus zurückgekehrt. Hinweis: Einige Elemente wie Schaltflächen und Links benötigen das Einschalten des Fokus-Modus nicht, weil sie vom Screen reader direkt aktiviert werden können und man so eine Zeitersparnis erreicht. Die Herausforderung besteht darin, dass ihr vielleicht Widgets erstellt, die ein Erzwingen des Fokus-Modus erforderlich machen. Voraussetzung ist, dass euer Widget am besten benutzt werden kann, wenn sich der Screen Reader nicht im Browse-Modus befindet. Voraussetzung ist weiterhin, dass die Applikation so gut wie keine klassischen Dokumentinhalte enthält, und dass alle Widgets, die vorhanden sind, den nötigen Kontext bereitstellen. Als Faustregel sind hier 90 oder 95 Prozent ansetzbar. Dann, und nur dann, ist ein Einsatz der Rolle „application“ sinnvoll. Ihr habt nämlich in diesem Moment die kontrolle darüber, dass der Anwender in den Fokus-Modus gezwungen wird, und es liegt in eurem Verantwortungsbereich, ein vernünftiges Tastaturinteraktionsmodell zu entwickeln und auch die Rückkehr in den Browse-Modus zu ermöglichen. Im Gegensatz zum normalen Fokus-Modus bewirkt die Rolle „application“ nämlich, dass man nicht so einfach wieder zum Browse-Modus zurückkehren kann, um sich z. B. die umliegenden Informationen des Dokuments durchzulesen.
Wann soll ich sie denn nun verwenden, und wann nicht? 🔗
Ihr verwendet die Rolle „application“ nicht, wenn ihr eine Benutzeroberfläche baut, die nur aus in HTML eh schon vorhandenen Widgets besteht. Das gilt auch für Widget-Klone, die ihr aus WAI-ARIA-Rollen und eigenem Tastaturinteraktionsmodell zusammenbaut:
- Textfelder inklusive Passwortfeldern, Suchfeldern, Telefonnummern, E-Mail und anderen neuen input-Typen.
- Mehrzeilige Textfelder (textarea)
- Kontrollfelder (checkbox)
- Schaltflächen (button)
- Auswahlschalter (radio button), die normalerweise in ein Konstrukt aus fieldset und legend eingefasst sind
- Ausklapplisten (select und option)
- Links, Absätze, Überschriften und andere Strukturen, die es nativ in klassischen Dokumenten im Web gibt.
Ihr verwendet sie ebenfalls dann nicht, wenn eure Benutzeroberfläche dynamische, fortgeschrittene Widgets der folgenden Typen enthält. Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, unterstützen bei diesen standardmäßig ein Umschalten zwischen Browse- und Fokus-Modus analog zu nativen HTML-Widgets.
- Strukturansicht tree view)
- Schieberegler slider)
- Tabellen, die fokusierbare Elemente enthalten wie eine Liste von E-Mail-Nachrichten, interaktive Gitter und Gitterbäume usw. grid, treegrid)
- Eine Liste von Reitern tab, tablist), bei denen der Anwender mit den Pfeiltasten rechts und links einen Reiter wählt. Beachtet, dass ihr hierfür das Tastaturverhalten implementieren müsst!
- Dialogfelder und Hinweisdialogfelder dialog, alertdialog). Diese werden von Screen Readern implizit als Anwendungsbereich behandelt, sobald sich der Fokus zu einem in ihnen enthaltenen Element bewegt. Hinweis: Diese verhalten sich am besten, wenn dem Element, das die Rolle „dialog“ oder „alertdialog“ enthält, das Attribut aria-describedby gegeben wird, dessen Wert auf die ID desjenigen Kindelements verweist, das den erklärenden Text enthält. Dadurch wird dieser Text automatisch vom Screen Reader vorgelesen, bevor das Element mit Fokus gesprochen wird.
- Symbolleisten und deren Elemente, Menüs und deren Menüeinträge toolbar, menu, menuitem) und ähnliche
Ihr solltet die Rolle „application“ nur dann verwenden, wenn eure Benutzeroberfläche zum größten Teil aus interaktiven Widgets, und hier vornehmlich aus fortgeschrittenen, nicht nativen Widgets, besteht, sich wie eine Desktopanwendung verhält und keine klassischen Dokumentinhalte enthält. Beachtet, dass, obwohl sich heute vieles Webapplikation nennt, das meiste davon unter der Haube doch weiterhin dokumentenbasierte Daten darstellt. Facebook-Statusnachrichten und deren Kommentare, Twitter-Zeitleisten, Blogartikel,selbst viele Akkordeons, die dynamisch Inhalte ein- und ausblenden können, sind in der Regel so stark dokumentenorientiert, dass die Rolle „application“ hier völlig unangemessen wäre und das Benutzen und Lesen der Informationen nur behindern würde. Wir arbeiten im Web weiterhin primär mit Dokumentstrukturen, obwohl an der Oberfläche vieles inzwischen aussieht wie eine Desktopanwendung.
Kurz gesagt: Die Fälle, in denen die Rolle „application“ wirklich zur Benutzung angemessen ist, dürften sehr rar gesäht sein!
Wo packe ich es denn hin? 🔗
Setzt die role auf das nächstgelegene Elternelement eurer Widgets, z. B. das sie umschließende div-Element. Wenn nämlich nur die Widgets eingeschlossen werden, die dieses Applikations-Interaktionsmodell wirklich benötigen, wird so sichergestellt, dass der Browse-Modus wieder eingeschaltet wird, sobald der Fokus diesen als „application“ gekennzeichneten Bereich verlässt.
Setzt das Attribut nur dann auf das body-Element, wenn die gesamte Applikation zu ca. 95% Elemente enthält, die den Fokus-Modus benötigen. Sollte es hierin auch Teile geben, die als Dokument behandelt werden müssen, nutzt für diesen Bereich die Rolle „document“. Sie ist das Gegenstück zur Rolle „application“. Zusätzlich müsst ihr durch setzen des tabstop-Attributes sicherstellen, dass der Fokus in diesen als Dokument ausgezeichneten Bereich gelangen kann, wenn der Nutzer mit tab durch eure Webapplikation navigiert.
In einem solchen Fall, wo 90 oder 95 Prozent eurer Inhalte Widgets sind, kann das Benutzen der Rolle „application“ angemessen sein. Aber selbst dann solltet ihr jemanden finden, der eure Anwendung in zwei Versionen testen kann, einmal mit und einmal ohne die Rolle „application“, um herauszufinden, ob dieses Interaktionsmodell wirklich die beste Lösung darstellt.
Setzt das Attribut NIEMALS auf so ein Element wie body, wenn eure Seite weitgehend aus traditionellen Widgets oder Dokumentinhalten besteht. Dies führt nur zu Frustration und schlechter Benutzbarkeit eurer Seiten!
Einige Beispielseiten 🔗
Die Seite, die mich dazu veranlasste, diesen Artikel zu schreiben, ist die neueste Version des Googlemail-Layouts. Google behandelt das ganze Teil als „application“, so dass man zig dutzendmal tab drücken muss, um zur Tabelle mit den Mails des Posteingangs zu gelangen. Hätten sie die Rolle richtig eingesetzt, bräuchte der Anwender nur die Taste t in seinem Screen Reader zu drücken und stünde sofort auf der Tabelle mit den Nachrichten, anstatt 30 oder 40mal tab drücken zu müssen. Ja, Google statten uns mit den Tasten j und k aus. Abgesehen davon, dass man über diese erst einmal bescheid wissen muss, funktionieren sie aber nur in der Kombination Chrome und ChromeVox. In allen anderen Browsern und Screen Readern wird zwar der visuelle Fokus verschoben, es wird jedoch kein echter Fokus auf das Zielelement gesetzt, so dass dieser Fokuswechsel für Screen-Reader-Anwender unbemerkt bleibt. Anders als Google es uns glauben machen will, ist Googlemail unter der Haube immer noch weitestgehend eine dokumentenbasierte Anwendung, in der viele traditionelle Navigationsmodelle uneingeschränkt gültig sind und die Rolle „application“ völlig unangemessen ist.
Ein Beispiel, in dem die Rollen „application“ und „document“ tatsächlich richtig angewandt werden, ist das aktuelle Yahoo!-Mail-Interface. Die Nachrichtenliste befindet sich in einem Bereich, der als „application“ gekennzeichnet ist. Man navigiert mit den Pfeiltasten durch die Nachrichten und öffnet sie mit Eingabe. Der Nachrichtenbereich selbst ist, während alles rundherum eine „application“ ist, ein „document“, in dem die Kopfzeilen und der Nachrichtentext angezeigt werden. Hier wird auch der Fokus hingesetzt, so dass der Screen Reader automatisch in den Browse-Modus schaltet und der Anwender die Mail sofort in vertrauter Umgebung lesen kann.
Scherzhafter disclaimer: Yahoo! bezahlen mir kein Geld dafür, dass ich sie dauernd bewerbe und darauf hinweise, wie gut ihnen das Mail-Webinterface gelungen ist. Sie haben nur ein verdammt gutes Produkt abgeliefert, das ist alles! 😉
Abschließendes 🔗
Wenn ihr Fragen zu diesem Thema habt, scheut euch nicht, sie in Kommentaren zu diesem Eintrag zu stellen! Ich werde sie möglichst zeitnah zu beantworten versuchen und wichtige Punkte als Updates zu diesem Blogpost verarbeiten. Weiterhin gibt es die englischsprachige Mailingliste free-aria, in der solche Themen auch mit anderen Webentwicklern, Anwendern und Standards-Experten diskutiert werden können.
Dies ist ein wichtiges Thema, das, wenn es richtig gemacht wird, eine sehr gute und flüssige Arbeitsweise ermöglicht, wenn falsch angepackt jedoch auch zu echten Problemen führen kann.
Nutzt die Rolle „application“ also nur dann, wenn Tests zeigen, dass dies zu einem besseren Interaktionsmodell führt. Wenn ihr sie dann einsetzt, tut es mit Augenmaß, der Aufwand lohnt sich!