Könnte ich heute schon auf den Mac verzichten und nur mit iOS-Geräten arbeiten?

Diese Frage stellte ich mir kürzlich in einem Gedankenexperiment. Hintergrund war die Idee, die schon einige Leute im netz hatten, zu sehen, ob sie für ihre Arbeit oder private Nutzung komplett auf einen Mac oder PC verzichten und nur noch mobile und Tablet-Computer wie das iPad nutzen könnten. Gerade mit dem Update auf iOS 5, das ja eine weitgehende Unabhängigkeit von iTunes verspricht, plus dem iTunes-match-Dienst, mit dem ja auch die eigene Musikmediathek aus der Cloud kommt, könnte man wirklich annehmen, dass klappen könnte!

Vorweg sei erwähnt, dass dies ein Gedankenexperiment war, bei dem ich nur meine private Nutzung zugrunde legte. Für meine berufliche Arbeit bei Mozilla werde ich auf die Nutzung eines richtigen PCs oder Macs mit virtuellen Maschinen für diverse Betriebssysteme nie verzichten können.

Aber für die private Nutzung? Ich spielte dies in Gedanken, auch mit meiner Herzdame zusammen, durch.

  • Twitter, Facebook, WordPress & Co. gehen natürlich auf dem iPad und iPhone, entweder über eigene Apps oder über Webseiten.
  • E-Mail, Nachrichtendienste wie iMessage und WhatsApp sind ja eh nativ auf dem Mobilgerät vorhanden und werden teilweise erst nachträglich auf den Mac portiert.
  • Diverse Dienste, die unter Windows o. ä. auf Flash zurückgreifen, haben eigene Apps wie das mitgelieferte Youtube, Vimyo, usw.
  • Instant-Messaging-Clients für diverse Protokolle gibt es, auch in für mich zugänglicher Form, en masse. Skype, FaceTime, alles geht.
  • Musik kommt aus der Cloud.
  • RSS-Feeds, Zeitungen (z. B. im ePub-Format), lassen sich auf dem iPad auch mit VoiceOver eh besser lesen als mit dem Mac, weil die Zugänglichkeit der Reader besser ist.
  • Für das Schreiben längerer Texte steht mir eine Bluetooth-Tastatur zur Verfügung. Auch wenn ich ein großer Fan von Touchscreens bin, kommt man mit einer echten Tastatur doch deutlich schneller ans Ziel.
  • Auch gibt es diverse mit VoiceOver kompatible Spiele für iOS-Geräte, während mir für den Mac bisher nichts dergleichen bekannt ist.
  • Online-Banking mache ich eh schon seit 1,5 Jahren übers iPad.

Was von dem, was ich regelmäßig nutze, geht nun nicht?

  • Programmieren: Wenn ich privat was programmieren möchte, ist mmir noch kein mit VoiceOver kompatibler Editor untergekommen. Textastic, der von vielen gern benutzt wird, ist mit VoiceOver nicht bedienbar, was primär an einer noch unvollständig implementierten API für „Rich Editing“ seitens Apple liegt. Wollte ich sogar eine iOS-App selbst erstellen, käme ich um Xcode nicht herum, und das gibt’s nicht für iOS.
  • Vervollständigen der Musikbibliothek mit noch nicht gerippten CDs oder solchen, die es aus welchen Gründen auch immer noch nicht digital zu kaufen gibt, geht nur mit einem Mac oder PC.
  • Ebenfalls gibt es bisher keine Möglichkeit, Hörbücher (.m4b) auf dem iPad zu erstellen oder MP3s zu solchen zusammenzuführen. Hörbücher, außer die von Audible, Filme usw. muss man bisher weiter über iTunes aufs iOS-Gerät schaufeln.
  • Diverse Webseiten betten Videos nur im Flash-Format ein. Würden sie ein vernünftiges HTML5 Video-Element mit Fallback nutzen, wäre das uneingeschränkte Ansehen auf iOS-Geräten möglich. So muss man doch immer wieder mal auf den Mac zurückgreifen.

Dennoch beobachte ich an mir eine viel stärkere Nutzung des iPads, je mehr es kann bzw. je mehr VoiceOver-kompatible Apps und somit Anwendungsmöglichkeiten es gibt. Auch das Navigieren ist oft schneller als auf einem Mac. Durch die Nutzung des Touchscreens komme ich oft viel schneller an bestimmte Elemente, als sie auf dem Mac erst per Tastatur anzusteuern. Gerade bei Apps, die ich kenne, ist ein gezieltes Tippen auf einen bestimmten Bildschirmbereich inzwischen die schnellste Art der Bedienung für mich, mit einer Trefferquote von über 98%. Ich weiß, dass auch das Trackpad von macBooks mit VoiceOver seit Snow Leopard Touch-Gesten unterstützt. jedoch ist das Hierarchiemodell von VoiceOver auf dem Mac der schnellen Benutzung doch etwas im Wege. Interagiere ich z. B. gerade mit einer Tabelle, ist nur deren Inhalt auf dem Trackpad „anfassbar“, nicht das gesamte Fenster oder der ganze Bildschirm. Das ist bei iOS alles etwas „flacher“ gestaltet und geht daher schneller.

Das Gedankenexperiment hat Spaß gemacht und mir einige Denkanstöße gegeben, und ich dachte mir, ich teile dies mit euch, vielleicht habt ihr zu dem einen oder anderen Punkt ja noch eine Idee! 🙂

Wenn ihr die WAI-ARIA-rolle application verwenden wollt, tut dies mit Vorsicht!

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-Modus
Dies 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-Modus
Dieser 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!