Die Lösung ergab sich erst, als ich meine Lebensgefährtin bat, sich diese Seite mit mir zusammen anzuschauen. Für sie war nach dem ersten Laden keiner der “Remove”-Buttons oder die Eingabefelder für die Passwörter sichtbar. Als ich anfing, mit dem virtuellen Cursor von NVDA hindurchzunavigieren, erschienen plötzlich die Buttons und Eingabefelder. Wanderte ich rückwärts, verschwanden sie wieder. Navigierte ich mit Tab, erschienen sie und blieben sichtbar.

Das “Verstecken” der Inhalte wurde hier also auf eine Weise erledigt, die die Inhalte zwar für Sehende versteckte, für Screen Reader aber nicht. Weiterhin wurde nicht berücksichtigt, dass sich für Tastaturbenutzer ein anderes Interaktionsmodell ergibt als für Mausbenutzer. Es wurde die falsche Technik zum Verstecken von Inhalten angewandt.

Ich will mal versuchen, ein bisschen Licht ins Dunkel zu bringen und gleichzeitig ein paar grundsätzliche Missverständnisse aufzuklären, mit denen ich seit über 10 Jahren immer wieder konfrontiert werde.

Die Grundlage

Zum Verständnis unbedingt erforderlich ist das Folgende: Screen Reader und andere assistive Technologien für Menschen mit Behinderungen nutzen eine Sammlung von Objekten, die den Inhalt einer Webseite widerspiegelt, um dem Anwender den Zugang hierzu ermöglichen. Diese Objekte sind hierarchisch gegliedert, wie in einem Baum. Der Stamm ist das Dokument, die Kindelemente sind vielleicht einzelne Sektionen, Überschriften, navigationsblöcke usw. Dieser Baum stellt eine Untermenge des durch den HTML-Code der Seite erstellten Baums des Document Object Model (DOM) des Browsers dar. Da die Objekte für Barrierefreiheit nicht für jedes Element eine Entsprechung benötigen, ist die Abbildung nicht ganz 1:1. In Fachkreisen wird diese Untermenge als Accessible Tree bezeichnet. Die Browser-Engine, z. B. Gecko bei Mozilla-basierten Browsern, versieht diese Objekte jedoch mit weiteren Eigenschaften, die für den Menschen mit Behinderung unbedingt notwendig sind.

Hierzu werden nicht nur die Informationen aus den Attributen des jeweiligen HTML-Tags herangezogen, sondern auch Stilinformationen. So werden Informationen zu Textattributen aus dem CSS abgeleitet, Farben usw. ebenfalls daraus ermittelt.

Einige Eigenschaften werden nicht berücksichtigt, z. B. die letztendliche Positionierung einzelner Elemente. Ein Div-Container kann also z. B. auf der Startseite oben rechts in der Ecke neben der Navigation angezeigt werden, der Screen Reader wird ihn jedoch an der Stelle des Dokumentflusses anzeigen, an dem er im Quelltext steht. Die Positionierung per CSS hat auf die Lesereihenfolge des Screen Readers keinen Einfluss. Siehe hierzu auch diesen Eintrag von mir, in dem ich das am Beispiel einer Lightbox erkläre.

Verstecken ist nicht gleich verstecken

Einige CSS-Anweisungen werden jedoch strikt befolgt. Im IE macht dies der Screen Reader, bei Firefox macht es die Gecko-Engine schon vorab. Und dies ist schon seit über 10 Jahren so. Elemente, die mit “display: none;” oder “visibility: hidden;” gestylt werden, werden nicht mit in den Accessible Tree aufgenommen. Erst wenn sich z. B. durch eine JavaScript-Anweisung ihr Styling ändert, werden sie an entsprechender Stelle in den Baum eingefügt, und es wird ein Ereignis ausgelöst, das dem Screen Reader mitteilt, dass hier ein neues Element oder eine Gruppe von Elementen erschienen ist.

Andere Anweisungen zum “Verstecken” von Elementen wie “left: -9999px; top: -9999px;” werden hingegen nicht berücksichtigt. Diese Elemente sind für Screen Reader genauso sichtbar wie solche, als stünden sie sichtbar fürs Auge auf dem Bildschirm.

Also nochmal, damit’s niemand überliest: Elemente, die mit “display: none;” oder “visibility: hidden;” gestylt sind, werden auch vor Screen Reedern immer versteckt! Dies gilt ohne Ausnahme für NVDA, JAWS usw. unter Windows, Orca unter Linux, und VoiceOver auf Mac und iOS. Die letzte JAWS-Version, die das nicht konnte, war, glaube ich, Version 4.02, die im April oder Mai 2001 erschien. Seitdem machen das alle alle alle JAWS-Versionen und alle anderen Screen Reader, die ich kenne, richtig. Warum sich ein das Gegenteil behauptendes Gerücht bis heute so hartnäckig in der Webentwickler-Szene hält, ist mir ein absolutes Rätsel. “display: none;” oder “visibility: hidden;” eigenen sich also nicht, um dem Screen Reader Zusatzinhalte anzubieten. Er wird sie schnöde ignorieren!

Wann verwende ich denn nun was?

Sobald Elemente tatsächlich erst sichtbar werden sollen, wenn eine bestimmte Aktion bewusst ausgeführt wird, sollten, je nach Bedarf, “display: none;” oder “visibility: hidden;” verwendet werden. Ein Anwendungsbeispiel, das viele Blogger jedesmal vor der Nase haben, wenn sie selbst einen Beitrag schreiben, ist das Administrations-Backend von WordPress. Die Hauptmenüpunkte “Dashboard”, “Artikel” usw. verbergen ihre Untermenüs durch das Stylen mit einer dieser beiden CSS-Anweisungen. Erst wenn der Anwender entweder mit der Maus rüberfährt oder mit Tab drauf navigiert und Enter drückt, wird der Style entsprechend geändert, und die Untermenüpunkte erscheinen. Richtigerweise wird auf dem Hauptmenüpunkt auch das WAI-ARIA-Attribut aria-haspopup=”true” wird richtig gesetzt, so dass man sofort mitgeteilt bekommt, dass hier ein Untermenü vorliegt.

Würde hier mit einem lediglich aus dem sichtbaren Bereich verschobenen Container gearbeitet, würde ich die ganzen Untermenü-Punkte mit meinem Screen Reader zu sehen bekommen. Sämtliche Vorteile eines aufgeräumteren Interfaces wären für mich dahin. Ja, auch ich genieße die Vorzüge dynamischer Interfaces, in denen ich ein- und ausblenden kann, was ich zur zeit zum Arbeiten brauche und was nicht! Ist das entsprechende Markup vorhanden, muss ich nicht zwingend sofort sämtlichen verfügbaren Inhalt sehen. Der macht auch für mich ein Interface unaufgeräumt, unübersichtlich und schwer navigierbar!

Der falsche Weg ist der, den ich am Anfang des Artikels beschrieben habe. Die Buttons und Passwort-Felder im Kontobereich von BrowserID wurden lediglich aus dem sichtbaren Bereich verschoben, nicht wirklich versteckt.

Eine sinnvolle Anwendung von aus dem sichtbaren Bereich verschobenen Elementen ist die Verwendung sogenannter Skip Links. Dirk Jesse hat hierzu einen vorzüglichen Blogeintrag verfasst, dessen Lektüre ich dem geneigten Leser wärmstens ans Herz legen möchte! Auch dort wird kurz darauf verwiesen, wofür “display: none;” der völlig falsche Weg ist.

Fazit

Ich hoffe, dieser Artikel kann dazu beitragen, einige Verwirrung aufzulösen, die um die Verwendung von “display: none;” und negativer Positionierung besteht, wann was angewendet werden sollte und wann nicht. Die Faustregel ist: Soll etwas komplett versteckt und erst nach einer bewussten Aktion eingeblendet werden, “echt” verstecken. Soll etwas grundsätzlich für Screen Reader erreichbar sein, ohne dass man vorher eine Aktion ausführen muss, dieses Element aber nicht zwangsläufig sofort sichtbar sein, verwendet man negative Positionierung. Aber dabei auch immer schön an die Tastaturbenutzer ohne Screen Reader denken und die Elemente rechtzeitig einblenden!

Fragen? Die gibt es bestimmt! Immer her damit, denn nur “wer nicht fragt, bleibt dumm”, das wissen wir ja schon seit der Sesamstraße!

Damit war das Thema für mich aber noch nicht erledigt. Ich hatte das Gefühl, das was ich habe, ist zu groß, zu schwer, zu behäbig. Es war ein MacBook Pro 13″, von dem ich diverse Teile der Hardwareausstattung noch nie benutzt hatte:

• Ich habe noch nie in diesem Leben einen Firewire-Anschluss benutzt. Ich habe meines Wissens nach noch nie ein Firewire-Kabel in der Hand gehabt.
• ich habe keine SD-Karten, die ich in den dafür vorgesehenen Schlitz stecken könnte.
• Wie groß ein Bildschirm ist, interessiert mich als Blinden nun wirklich nicht. Hauptsache, die Tastatur hat die richtige Größe und ist nicht limitiert oder so klein, dass ich mit meinen dicken Fingern darauf nicht mehr schreiben kann.
• Das Kensington-Schloss zur Diebstahlsperre habe ich auch noch nie gebraucht. Wenn ich das Notebook unterwegs nutze, habe ich es immer “am Man”, in einer dafür vorgesehenen Tasche. Das Stehlen dieser Tasche verhindert auch so ein Kensington-Diebstahlschloss nicht.
• Ein Superdrive nutze ich zwar regelmäßiger, aber nicht so regelmäßig, dass ich es ständig bei mir haben müsste.
• 2 kg sind 2 kg sind 2 kg.

Der Entschluss stand fest: ich wollte mich verkleinern. Eine schnelle Analyse ergab, dass ich weiterhin beim Mac bleiben wollte, das Gerät aber kleiner und leistungsfähig sein sollte.

Der Zufall wollte es, dass ein Bekannter sich mit einem Problem an mich wandte, das er durch Verdrehen einer Einstellung in den Systemeinstellungen, Tastatur, verursacht hatte. Er kam bei mir vorbei und hatte sein “Problemkind”, das MacBook Air 11″, natürlich dabei. Dies gab mir die Gelegenheit, etwas länger mit diesem kleinsten Notebook aus dem hause Apple zu arbeiten.

Die Tastatur ist vollwertig und schreibt sich flüssig. Das Gerät ist schön leicht und passt genau auf meinen Schoß. Die Leistung war nicht nur akzeptabel, sondern das Gerät lief sehr rund.

Einige weitere Gespräche bestätigten, dass die mir zuerst etwas mager vorgekommenen 4 GB Arbeitsspeicher durch den schnellen Flash-Speicher wettgemacht werden, sollte das MacBook mal in die Verlegenheit kommen, Speicherinhalte auslagern zu müssen.

Ich entschloss mich also, mir selbst ein MacBook Air 11″ zu bestellen. Ich nahm noch einige Veränderungen an der Konfiguration vor. Zum einen wollte ich den schnellsten verfügbaren Core I7-Prozessor haben, zum anderen die höchste verfügbare Flash-Speicher-Kapazität von 256 GB.

Das MacBook Air kam ein paar Tage später und klebt seitdem förmlich an mir fest. Es ist absolut “mein” Notebook: Schnell, schreibt sich sehr flüssig, wird nicht warm, ist zuverlässig, der Akku hält mindestens die 5 versprochenen Stunden durch, es ist leicht, es ist Portable, und es kommt mir sogar in Teilen leistungsfähiger vor als das MacBook Pro, das ich von der Firma bekommen habe und das ebenfalls ein SSD-Laufwerk enthält. Ob die Tatsache, dass die Flash-Speicher im Air direkt verdrahtet sind, während im Pro eine SSD-Platte in üblicher 2,5″-Bauweise benutzt wird, entzieht sich meiner Kenntnis. Der subjektive Eindruck ist jedenfalls der, dass das Air flüssiger läuft. Sogar Windows 7 in einer virtuellen Maschine mit VMware Fusion läuft so flüssig wie es nie auf meinem alten “echten” PC gelaufen ist.

Ich bereue den Kauf keinesfalls und habe das für mich beste Notebook gefunden. Es entspricht meinen Erwartungen bzw. übertrifft diese sogar noch, es hat die Möglichkeit, alle Apps, die ich brauche, auszuführen, es ist mir ein zuverlässiger mobiler Partner für all meine privaten Rechnerbedürfnisse.

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!

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!

Seit kurzem sammeln wir auch Daten darüber, wie die Barrierefreiheitsfunktionen benutzt werden, wie oft diese angefordert werden usw.

Die neueste Funktion im Rahmen dieser freiwilligen Datenerhebung bezieht sich auf das Sammeln von Daten darüber, welcher Screen Reader bei der Nutzung der Barrierefreiheit unter Windows verwendet wird. Unter Linux gibt es im Prinzip nur einen Screen reader, Orca, aber unter Windows gibt es eine ganze Fülle von Sprachausgabe- und Vergrößerungsprogrammen, die den Firefox unterstützen.

Um ein besseres Bild darüber zu bekommen, welche Programme von unseren Anwendern eingesetzt werden, haben wir diese Funktion in die Nightly-Versionen von Firefox eingebaut. In den nächsten Tagen wird diese Funktion den Aurora-Kanal erreichen und letztendlich in Firefox 12 als Vollversion erscheinen.

Wer die Nightly builds oder Aurora verwendet und uns diese Daten senden möchte, kann wie folgt vorgehen:

1. Extras-Menü, Einstellungen aufrufen.
2. Auf das Register “Erweitert” wechseln.
3. Hier den Reiter “Allgemein” auswählen.
4. Mit Tab bis auf das Kontrollfeld “Performanz-Daten senden” gehen und dieses mit der Leertaste aktivieren.
5. Mit Tab auf “OK” gehen und Leertaste drücken, um die Änderungen zu speichern und das Dialogfeld zu schließen.

Noch einmal zur Klarstellung: Diese Daten werden anonym an uns übertragen und können nicht zum Ursprung zurückverfolgt werden. Wir können also nicht feststellen, von wem die Angabe zu einem Screen Reader kam o. ä. Und natürlich sind diese Dateneinsendungen freiwillig, wir nehmen’s nicht persönlich, wenn jemand sich dazu entschließt, dieses Senden der Daten nicht zu aktivieren!

Hub Figuière, ein neuer Kollege im Accessibility-Team von Mozilla, der im November bei uns angefangen hat, kümmert sich zur Zeit mit Hochdruck um die Zugänglichkeit und Unterstützung für VoiceOver unter Mac OS X Snow Leopard und Lion. In den nächsten Wochen werde ich auf diesem Blog die Verfügbarkeit einer zum Testen geeigneten Version ankündigen. Diese wird eine Menge Probleme haben. Einige davon dürften uns intern schon bekannt sein, andere jedoch höchstwahrscheinlich nicht, und genau dafür würde ich mich sehr über testende Hilfe aus der Community freuen! Die Builds werden instabil sein, es wird längst nicht alles funktionieren und für einige Zeit noch nicht produktiv einsetzbar sein. Aber mit eurer Hilfe können wir das ändern und haben jetzt auch die Manpower dazu!

Diejenigen, die unsere Community schon kennen, können diesem Meta-Bug folgen, um den Fortschritt zu beobachten.

Alle anderen können gern hier ihre Unterstützung signalisieren, sei es durch testen oder einfach nur moralisch, indem sie unter diesem Beitrag einen Kommentar hinterlassen. Ich würde mich freuen!

Diese Untermenüs ermöglichen einen schnelleren Zugriff auf die Untermenüpunkte. Man muss nicht erst einen Hauptmenüpunkt anklicken, auf das erneute Laden der Seite warten und dann auf die aufgeklappten Menüs zugreifen. Stattdessen werden die Untermenüpunkte sichtbar, indem man mit der Maus drüberfährt, sogenanntes Hovern, oder mit tab auf den jeweiligen Link springt und Enter drückt.

Das Problem für Screen-Reader-Benutzer ist, dass die Enter-Taste in der Regel vom Screen Reader abgefangen und für eine Funktion innerhalb des sogenannten virtuellen Dokuments oder Browse-Modus verwendet wird. Normalerweise wird durch Druck auf Enter ein Link aktiviert.

Genau das wollen wir ja aber nicht, denn das Aktivieren eines Links erzeugt ein Neuladen der Seite, und sämtliche Vorteile des schnelleren Zugriffs auf die dynamischen Menüs wären dahin.

Stattdessen tun wir folgendes:

1. Mit dem virtuellen Cursor auf einen dieser “Untermenü Link”-Elemente wandern.
2. NVDA-Taste+F2 drücken, um NVDA anzuweisen, den nächsten Tastendruck ungefiltert an den Browser weiterzugeben.
3. Enter drücken.
4. Mit dem virtuellen Cursor nach unten wandern und ein aufgeklapptes Menü vorfinden.

Diese Methode funktioniert analog mit anderen Screen Readern. Manche Screen Reader fokussieren jedoch nicht automatisch das unter dem virtuellen Cursor befindliche Element. Vor dem obigen Schritt 2 muss also eventuell noch eine Tastenkombination gedrückt werden, mit der der System-Fokus oder PC Cursor zum virtuellen Cursor gezogen wird.

Die oben beschriebene Methode ist ein Tastendruck mehr. Das stimmt, aber diese Vorgehensweise ist immer noch schneller als auf das erneute Laden einer Seite zu warten und dann die aufgeklappten Menüs wieder vom Anfang des virtuellen Dokuments an suchen zu müssen.

Viel Spaß beim Bloggen!

Von WAI-ARIA nach HTML5

Wer das im obigen verlinkten Artikel entwickelte Formular nicht mehr ganz parat hat, dem empfehle ich einen erneuten Blick darauf zu werfen. Die folgenden Änderungen habe ich vorgenommen, um das Formular von WAI-ARIA und HTML 4.01 auf HTML5 zu bringen:

1. Allen JavaScript-Code rausschmeißen. Die Formularvalidierung von HTML5 nimmt uns viel Arbeit ab. Da bauen wir lieber wieder was ein, wenn wir merken, dass das Formular zu wenige Features hat.
2. aria-required ändern in required. Sämtliche erforderlichen Formularfelder bekommen das WAI-ARIA-Attribut inklusive Wert gestrichen und einfach das HTML5-Formularelementattribut required verpasst.
3. Das Feld “name” bekommt ein pattern-Attribut mit einem regulären Ausdruck verpasst, der besagt, dass das Feld nur dann gültig ausgefüllt ist, wenn der eingegebene Name aus beliebigen Zeichen, einem Leerzeichen und weiteren beliebigen Zeichen besteht. Ein Name ist in unseren Breiten üblicherweise aus Vor- und Nachname zusammengesetzt, und das sollte das Formular wissen.
4. Das Feld “email” bekommt als type den Wert “email”, das Feld “website” den type “url” gesetzt. Dadurch weiß der Browser, dass er eine E-Mail- bzw. Webseiten-Adresse zu erwarten hat. Weiterhin hat dies den positiven Nebeneffekt, dass auf mobilen Geräten gleich die entsprechend verbesserten virtuellen Tastaturen eingeblendet werden. Mir ist bewusst, dass die meisten Browser zur Zeit noch nichts mit internationalen Domains anfangen können bzw. Felder mit solchem Inhalt noch nicht validieren. Wir decken der Einfachheit halber aber mal den großen Teil der allgemeinen Fälle ab.
5. Im Feld Name fügen wir noch ein Attribut x-moz-errormessage hinzu. Das Präfix besagt, dass dies kein Standard-Attribut für HTML5 ist. Mozilla-basierte Browser können aber eine bessere Fehlermeldung ausgeben. Achtung, die ist natürlich dann nicht lokalisiert, erscheint also auch in einem englischen Firefox auf deutsch!

Mit diesen Änderungen kann unser Formular jetzt folgendes:

1. Namen, E-mail-Adresse und Webseitenadresse automatisch validieren und den Status auf “ungültig” setzen, wenn ein Feld die Anforderungen nicht erfüllt.
2. Der Firefox schickt bei mindestens einem ungültig ausgefüllten Formular dieses beim Klick auf den Button nicht ab, sondern gibt eine Fehlermeldung aus und setzt den Fokus auf das Eingabeelement, in dem noch ein Problem besteht. Bei Tests im Safari in Mac OS X Lion zeigte sich, dass dieser das Formular dennoch abschickt, obwohl ungültige Eingaben vorhanden sind. Hier weichen die Implementierungen also voneinander ab

Und zurück zu WAI-ARIA

Und was kann unser Formular noch nicht wieder? Richtig: Die Ausgabe einer Fehlermeldung bei Verlassen eines Eingabefeldes. Dies unterstützen Browser bisher nicht standardmäßig, eine Validierung bei Fokusverlust, die sofort per Fehlermeldung bescheid sagt, wenn etwas nicht in Ordnung ist. Also müssen wir das JavaScript aus dem ursprünglichen Formular wieder einbauen und wie folgt abändern:

1. Den Namen der function “checkEntryValidity” in “testIfEntryIsValid” ändern, weil der ursprüngliche Name im HTML5-Kontext mit einem reservierten Bezeichner kollidiert.

Die Parameterliste verschlanken. Die Funktion braucht nur noch die ID des zu überprüfenden Elements, weil alles andere von HTML5 erledigt bzw. bereitgestellt wird.

Die Funktion so abändern, dass:
1. Keine aria-invalid-Attribute mehr gesetzt werden.
2. Keine zeichenvergleiche mehr angestellt werden, sondern lediglich das Ergebnis des Funktionsaufrufs checkValidity() ausgewertet wird. checkValidity() gibt true zurück, wenn das Feld einen gültigen Eintrag enthält, sonst false.
3. Den bisherigen Parameter aMsg ersetzen durch einen Aufruf der Eigenschaft validationMessage des jeweiligen Elements. Diese enthält die Fehlermeldung, die Firefox auch beim Absenden des Formulars generiert und die beim Drüberfahren mit der Maus als Tooltip angezeigt wird. Enthält das Element ein title-Attribut, wird dessen Wert an diese Fehlermeldung angehängt. Ist x-moz-errormessage angegeben, enthält der erste teil von validationMessage diesen Text.
1. Den Feldern “name” und “email” wieder onBlur-Handler geben, die die Funktion testIfIsEntryValid aufruft und die ID des zu prüfenden Feldes übergibt, damit bei Fokusverlust des Feldes eine Prüfung erfolgt und ggf. ein Alert generiert wird.

Mit diesen Änderungen ist unser Formular nun wieder voll funktionsfähig, besitzt jedoch verbesserte Validierungseigenschaften als vorher. Auf mobilen Geräten werden entsprechende Tastaturen eingeblendet, wenn man die E-Mail- und Webseiten-Adressen ausfüllt.

Zusammenfassung

HTML5 bietet uns also viele Funktionen frei haus, die wir früher mit eigenem JavaScript nachbauen mussten. Der Code wird schlanker. Die Lücke, die HTML5 nicht schließt, ist die Validierung bei Fokusverlust und die Ausgabe der Fehlermeldung. Diese müssen wir weiterhin durch WAI-ARIA realisieren. Wir gehen also zu einem guten Stück von WAI-ARIA-Attributen weg, und das ist auch gut so! Dort, wo es sinnvoll ist und es eine Ergänzung darstellt, nutzen wir es aber weiterhin, um unser einfaches Formular noch benutzerfreundlicher zu gestalten. Wo man kann, sollte man WAI-ARIA also durch HTML5 ersetzen, wenn man moderne Webseiten und -applikationen entwickelt. Dort, wo es Sinn macht oder HTML5 noch Lücken lässt, sollte man WAI-ARIA aber nach wie vor einsetzen!

Sämtliche drei Beispiele sind von dieser Seite verlinkt. Viel Spaß beim Spielen und Nachbauen!

Ich freue mich selbstverständlich über Feedback! Das JS hier ist jedoch absichtlich sehr einfach gehalten, weil es nur das Konzept verdeutlichen soll und keine fertige Lösung darstellt.

Bayerischer Rundfunk

Fangen wir mal mit dem Bayerischen Rundfunk an. Aufmerksam wurde ich durch einen Tweet von Eric Eggert. Als Nordlicht ist der BR nicht unbedingt jeden Tag Ziel meiner Surfaktivitäten. Nach den ersten Hinweisen von Eric habe ich mir die Seite dann selbst angeschaut und bin doch ziemlich entsetzt. Folgende Dinge fallen sofort ins Auge bzw. für den Screen-Reader-Benutzer ins Ohr:

• Zumindest für Firefox-Nutzer gibt es Sprunglinks, die auch zu halbwegs vernünftigen Zielen auf der Seite (und ich rede erst einmal nur von der Startseite) führen. Für Tastaturbenutzer von Webkit-Browsern (Safari, Chrome) scheint dies noch problematischer zu sein, wie dieser Tweet zeigt.
• Die Überschriftenhierarchie lässt jegliche Konsistenz oder Konsequenz vermissen. So liegen die Hauptüberschrift “Bayerischer Rundfunk” und die Überschrift zur Breadcrumb-Darstellung auf Ebene 1, die Überschrift “Inhalt” sowie ein einzelner Artikel auf Ebene 2, die restlichen Artikelteaser auf Ebene 3. Die Überschrift “Hilfe und Kontakt” liegt wieder auf Ebene 2.
• Die Artikelteaser selbst bestehen aus einem Kuddelmuddel aus Text und Grafiken, eingefasst in Überschriften. Ein Beispiel, abgerufen am 28.10.2011:
  <h3>
<a href="/themen/aktuell/inhalt/bundeswehr-standortschliessungen-bayern100.html" class="link_article contenttype_standard bundeswehr-standortschliessungen-bayern100" title="zum Artikel | Aktuell">
<span class="teaser_picture">
<img width="256" height="144" alt="Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa" title="Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa" src="/themen/aktuell/inhalt/kasernenschild100~_v-image256_-a42a29b6703dc477fd0848bc845b8be5c48c1667.jpg?version=1319722326985"/>
<span class="teaser_icon">
<span class="link_target"> zum Artikel </span>
</span>
</span>
<span class="teaser_headline">
<span class="teaser_overline">Bundeswehrreform</span>
<span class="teaser_title">Suche nach einer neuen Zukunft</span>
</span>
</a>
</h3>
  • Zum einen ist die Verdoppelung des Title zum Alternativtext des Images völlig unnötiger Ballast.
  • Das ganze in einen Link zu packen macht zwar alle Bestandteile klickbar, und man kommt zum Artikel, macht den Linktext für Screen Reader aber auch so behäbig lesbar, dass das spätestens beim dritten Artikel tierisch zu nerven anfängt.
  • Und nein, der Title für den Link wird nur in den wenigsten Fällen als Ersatz für vorhandenen Linktext für Screen Reader herangezogen.
  • Dass das ganze in ein H3 gepackt wurde, erlaubt wenigstens noch die Ansteuerung per Schnellnavigation, das H3 erfüllt sonst aber, glaube ich, so gut wie keine Funktion.

  Für Screen Reader hört sich dieser Teil der Seite dann übrigens so an:

  Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa Grafik
  zum Artikel
  Bundeswehrreform
  Suche nach einer neuen Zukunft Überschrift Ebene 3

Öffnet man nun den oben auseinandergenommenen Artikel, offenbart sich wieder eine in teilen inkonsistente, aber doch etwas besser gelungene Überschriftenhierarchie. Auch hier wird wieder auf einen Artikel, in diesem Fall auf ein Interview, verlinkt, und das “Ungetüm” liest sich genauso behäbig wie die Verlinkungen auf der Startseite.

Hier wurden zwar semantisch durchaus korrekte, von der usability her aber sehr unhandliche Strukturen geschaffen. Da hat offensichtlich niemand mit einem Screen Reader für Blinde mal drübergelesen, um sich anzuhören, was da eigentlich entsteht.

Es gibt auch hier und da noch auf Pfeilen fehlende Alternativtexte, die habe ich im einzelnen jetzt aber nicht rausgesucht. Es gibt jedenfalls an diesem Relaunch von der Usability her, von der Tastaturnavigation und von den Überschriftenstrukturen genug anzumerken um festzustellen, dass hier keine wirklichen Experten am Werk waren und das Ergebnis auch nicht von fachkundiger Seite geprüft wurde. Für eine Institution der ARD, die mit staatlichen Mitteln und GEZ-Gebühren gefördert wird und somit der BITV unterliegen dürfte, ein absolut erbärmliches und nicht schönzuredendes Ergebnis!

Der Westen

Gegen das, was derwesten.de aber in dieser Woche als Relaunch abgeliefert hat, muss man zwangsläufig beim BR noch von Luxus sprechen, vorausgesetzt man würde das als Maßstab betrachten. Denn:

• Keine Skip-Links.
• Keine Überschriften, stattdessen so Monstren aus den 1990ern wie <div class="hl">A 40 in Duisburg wird am Wochenende zum Nadelöhr</div>. “hl” steht dabei vermutlich für “Header large” oder so.
• Auch entsetzlich und von Eric Eggert auf Twitter gepostet: <div class="cell"><a href="#" title="Arnsberg auswählen">Arnsberg</a></div>. Naja vielleicht sollten wir wenigstens dafür dankbar sein, dass nicht tatsächlich eine Layouttabelle verwendet wurde, oder wie?

Bei soviel Dilettantismus allein schon auf der Startseite erübrigt sich das Anschauen jeder weiteren Seite dieses im Oktober 2011 relaunchten Webauftritts. Die Note 6 steht jetzt schon fest.

Warum?

Die große Frage, die ich mir beim Lesen solcher Webauftritte stelle, ist, WARUM? Warum wird für so einen Mist so viel Geld verschwendet? Warum beherrscht nicht inzwischen jede halbwegs seriöse Webagentur in Deutschland wenigstens die Grundregeln modernen Webdesigns und warum rotzen uns immer noch so viele deutsche Webagenturen einen solchen 90er-Jahre-Dreck vor die Füße? Müssen wir uns das gefallen lassen? Denkt wirklich niemand in den Entscheidungsgremien mal daran, dass sie selbst in nicht allzu ferner Zukunft älter sein werden, Sehfehler bekommen, vielleicht eine Maus nicht mehr richtig halten werden können? Barrierefreies Webdesign ist nicht primär was für Blinde, sondern geht primär jeden etwas an, denn wir werden alle älter und nicht jünger, und wir wollen auch im Alter unsere Webauftritte bedienen können. Dazu braucht es ein weitsichtigeres Denken als das, was hier demonstriert wird. Nachhaltigkeit ist das Stichwort, und davon ist hier nichts zu spüren. Und da möchte man als jemand, der seit 15 Jahren für mehr Barrierefreiheit im Web eintritt, manchmal echt fragen, ob man nur für die Luft um einen herum aufklärt. Ich weiß zum Glück, dass es auch und gerade im Pott eine ganze Menge sehr fähiger Webagenturen gibt, die sich das Thema Barrierefreiheit zu einem Grundprinzip gemacht haben und dies all-inclusive in ihre Webauftritte mit einbauen und dass die Arbeit daher definitiv nicht um sonst ist. Es entsetzt mich jedoch, dass nach 15 Jahren bei so vielen großen und teuren Webagenturen davon anscheinend immer noch nichts angekommen ist!

Zunächst wurde ich allerdings von dem inzwischen allgegenwärtigen SIM-PIN-Problem heimgesucht. Zunächst glaubte ich, ein Montagsgerät erwischt zu haben. Übers Wochenende entdeckte ich dann jedoch im Internet, dass ich hier durchaus nicht der einzige war.

Dies hielt mich aber nicht davon ab, Siri und auch das iPhone sonst auf Herz und Nieren zu prüfen. Siri zeigt sich auch im Deutschen schon sehr fähig und reaktionsschnell. Fragen wie “Wie wird das Wetter morgen in Hamburg” oder “Brauche ich einen Regenschirm” beantwortet Siri im Deutschen genauso zuverlässig, wie dies in den von der Apple Keynote gezeigten Demos zu sehen und hören war. Das Erstellen von Terminen, Timern, das Wecken zu einer bestimmten Uhrzeit und das Erstellen und Versenden von SMS bzw. iMessages funktioniert ebenso reibungslos. Das Einrichten von Erinnerungen klappte ebenso.

Ich musste Siri auch nicht trainieren. Ich spreche ein relativ akzentfreies Hochdeutsch und hatte somit mit ihr keine Verständigungsschwierigkeiten. Wie Siri allerdings auf stärkere Dialekte wie schwäbisch, bayerisch oder fränkisch reagiert, weiß ich nicht.

Einige Dinge beherrscht Siri noch nicht, so kann es im Deutschen keine Abfragen machen wie “wie viel US$ sind 50 Euro?”, da es hierzu die Integration mit der Suchmaschine Wolfram Alpha braucht, die es bisher nur auf englisch gibt. Auch die Anbindung an die Karten-Anwendung gibt es noch nicht, also funktionieren Fragen nach in der Nähe gelegenen Restaurants o. ä. noch nicht. Auch das Finden eines Ortes, an dem man eine Leiche verschwinden lassen kann, ist im Deutschen noch nicht verfügbar. Siri fragt lediglich erstaunt: “Tatsächlich?”

Aber auch Scherzfragen kann man ihr im Deutschen stellen. So bekommt man als Antwort auf die Bemerkung “Ich finde dich sexy” ein robustes “Jeder ist berechtigt, eine Meinung zu haben.” Mehrfache Fragen nach dem Sinn des Lebens fördern Antworten zu Tage wie “42″, “darüber nachzudenken” bis hin zu “Alles deutet darauf hin, dass es Schokolade ist”. Auf die mehrfache Frage “Willst du mich heiraten?” kommen Antworten wie “Lass uns einfach Freunde sein”, “Wir kennen uns doch kaum”, “dass ist nett von dir, kann ich dir sonst noch irgendwie helfen?” oder “Entschuldige, aber in meinem Lizenzvertrag steht nichts über Ehe!”.

Die Integration mit dem iPhone geht sogar so weit, dass Siri auf ein “Gute Nacht”, das am Vormittag ausgesprochen wird, entgeistert antwortet: “Gute Nacht? Es ist 11:15!”.

Abgesehen von diesen Spielereien ist die Integration mit dem iPhone aber schon sehr gut gelungen, und Siri wird ständig weiterentwickelt. So deklariert Apple Siri selbst noch als in der Betaphase befindlich. man darf also gespannt sein, ob z. B. das Versenden von Tweets und die im Deutschen fehlenden Funktionen bald nachgerüstet werden.

Genauso stark funktioniert die Diktatfunktion. Ist Siri aktiviert, gibt es auf der Tastatur neben der Leertaste eine Taste, um ein Diktat zu starten. In jede Anwendung kann so diktierter Text eingefügt werden. Bis auf wenige Worte und Sonderbegriffe oder auch mal unsauber zusammengeschmierte Worte hat Siri bisher alles erkannt, was ich ihr diktiert habe. Dies verkürzt das Antworten auf SMS oder WhatsApp-Nachrichten oder auch das Schreiben von tweets in der Regel erheblich, da man (übrigens auch auf anderen Handys) nie so schnell schreiben kann wie man spricht. Die Erkennung ist quasi sofort verfügbar.

Siri braucht jedoch zur Arbeit Netzanbindung, da die Sprachanalyse selbst in der Cloud stattfindet und nicht lokal auf dem iPhone. Es reicht eine Verbindung per Handynetz, über WLAN geht es natürlich schneller. Auch was mit den Sprachdaten passiert, die man so an Apple überträgt, ist noch nicht abschließend von Apple beantwortet.

Abseits von Siri begeistert die neue Kamera. Es gibt eine Gesichtserkennung, die per VoiceOver sogar ansagt, wo sich das Gesicht befindet. Ein Ausrichten auf eine Person, so dass deren Gesicht im Zentrum des Bildes sein wird, ist also auch als Blinder selbständig möglich.

Auch die neue Mitteilungszentrale begeistert. Push-Benachrichtigungen werden von VoiceOver beim Eintreffen und kurzen Aufblinken am oberen Bildschirmrand selbständig gesprochen, aber sie geraten einem nicht mehr in den Weg, wenn man gerade einen Text schreibt.

Einziges Manko, das ich bisher festgestellt habe, ist eine verkürzte Akkulaufzeit. Obwohl alle Apps geschlossen sind und das iPhone neu gestartet ist, verbraucht es im Standby deutlich mehr Strom und ist am Ende eines Tages in der Regel komplett leer. Das 4 hält mit der gleichen Version von iOS und gleichen Benutzungsmustern (von Siri mal abgesehen) deutlich länger durch. [Update vom 24.10.2011]: Ich weiß inzwischen, was den erhöhten Akkuverbrauch bei mir verursacht hat. Es ist die Funktion “Sprechen” von Siri. Diese etwas verwirrend klingende Option ist lediglich dafür zuständig, Siri dazu zu befähigen, auch dann “aufzuhorchen”, wenn man sich das iPhone ans Ohr hält und gerade kein Telefongespräch im Gange ist. Siri scheint da in einem dauerhaften Lauscherzustand zu sein und auf Bewegungen des iPhones aufzupassen. Ich habe diese Funktion abgeschaltet. Somit ist Siri lediglich noch durch das längere Drücken der Home-Taste aktivierbar. Seitdem hat sich der Akkuverbrauch wieder auf ein gewohntes Maß reduziert.[/Update]

Von diesem Manko abgesehen kann ich aber sagen, dass ich den Kauf des 4S nicht bereue. Siri ist für jeden eine Erleichterung und stellt somit ein Rundum-Feature dar, mit dem z.B. Blinde, Sehende, motorisch eingeschränkte Menschen und Menschen mit Lese-Rechtschreib-Schwäche gleichermaßen eine große Erleichterung im Umgang mit dem iPhone erfahren. So schnell wie ich Siri z. B. sage, dass sie mich morgen um 8 Uhr wecken soll, kriege ich das in der Uhr-Anwendung nicht eingestellt!