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!

Yahoo! haben vor nicht allzu langer Zeit eine neue Version von Yahoo! Mail angekündigt. Im Zuge dieser Ankündigung wurde auf den einschlägigen Kanälen auch vermehrt auf eine deutlich verbesserte Zugänglichkeit dieser Webanwendung hingewiesen. Es ist nun an der Zeit, dieser verbesserten Zugänglichkeit auf den Zahn zu fühlen. Also los geht’s!

Zum Testen verwendete ich den aktuellen Firefox sowie die aktuelle Version 2011.2 des Screen Readers NVDA. Weiterhin fand ich es ratsam, mir in der englischsprachigen Hilfe zur Yahoo! Mail Accessibility, speziell hier auch die Übersicht der Tastaturkürzel, einen Überblick über die Funktionalität zu verschaffen. Die deutsche Hilfe bietet hier leider noch gar keine diesbezüglichen Inhalte, so dass ich auf die englischsprachige Version zurückgriff.

Erste Schritte

Mit diesen Informationen ausgestattet loggte ich mich in mein Yahoo! Mail-Konto ein. Ich wurde aufgefordert, auf das neue Yahoo! Mail umzustellen. Dies muss gemacht werden, um die neuen Funktionen nutzen zu können.

Es begrüßte mich der Reiter “Neuigkeiten” des neuen Yahoo-Mail-Interfaces. Dies ist eine Sammlung aktueller Schlagzeilen. Am oberen Rand gibt es jedoch auch einen Link, der den Anwender direkt in den Posteingang führt. Hier wird einem auch mitgeteilt, wie viele ungelesene Nachrichten und wie viele Nachrichten insgesamt vorhanden sind.

Der Posteingang

Ich aktivierte nun den Link, der mich zum Posteingang führen sollte. Was nun folgte war ein Umschalten in den Fokus-Modus, weg vom standardmäßig aktiven Browse-Modus (virtueller Cursor). Der Grund wurde sehr schnell offensichtlich: Die Nachrichtenliste im Posteingang ist ein sehr funktionales Widget, in dem man mit den Pfeiltasten rauf und runter durch die Nachrichten navigieren kann. Die Rückmeldungen per Sprachausgabe sind einfach traumhaft! Man bekommt automatisch alle relevanten Informationen zur gewählten Nachricht angesagt, genauso als wäre man in einem Desktop-E-Mail-Programm wie Thunderbird oder Outlook.

Es stehen, wie man aus der oben verlinkten Liste von Tastaturkürzeln ersehen kann, eine ganze Reihe weiterer Tastaturkürzel, mit denen man Funktionen ausführen kann, zur Verfügung. Entfernen löscht eine Nachricht und sorgt für sehr gutes Feedback durch die Sprachausgabe, mit r leitet man eine Antwort ein, mit w leitet man eine Nachricht weiter. Ja, diese Tastenkürzel sind anders als in Thunderbird oder Outlook, aber wenn man von Outlook auf Thunderbird wechselt, muss man ja auch neue Tastaturkürzel lernen!

Lesen einer Nachricht

Mit einem Druck auf die Eingabetaste wird eine Nachricht zum Lesen geöffnet. Und hier zeigt sich eine der absolut gelungensten Implementierungen von WAI-ARIA: Die Rollen “Application” und “Document” werden hier sehr intelligent und vor allem korrekt eingesetzt und sorgen für einen reibungslosen Wechsel zwischen Fokus- und Browse-Modus des Screen Readers. Die Nachrichtenliste muss definitiv als Applikation behandelt werden, eine individuelle Nachricht ist hingegen ganz eindeutig ein Dokument. Und genau das passiert hier auch. Nachdem die Nachricht geöffnet wurde, schaltet NVDA automatisch zum Browse-Modus um und beginnt, die Nachricht zu lesen. Handelt es sich hier um eine einfache Nachricht, befindet sich am unteren Rand gleich eine Antwort-Box, so dass man sofort auf die Nachricht antworten kann. Es gibt hier allerdings keine Zitat-Funktion. Wenn man also eine vollständige Bearbeitung wünscht, sollte man die Nachricht schließen und mit r in der Nachrichtenliste ein großes Antwort-Fenster öffnen.

Mit escape wird eine Nachricht geschlossen, und man landet wieder in der Nachrichtenliste. Dabei wird die letzte Position beibehalten, man kann also mit dem Durchsehen der Nachrichten dort weitermachen, wo man die Nachricht geöffnet hatte.

Da gibt’s aber noch mehr

Mit tab wandert man durch das Hauptfenster von Mail. Hierbei ist die Tastaturnavigation äußerst clever: Tab springt nur gruppierende Elemente wie Symbolleisten an. Möchte man die Elemente innerhalb einer Symbolleiste erkunden, nutzt man dazu die Pfeiltasten rechts und links. Enthält eine Symbolleiste also 10 Elemente, muss man diese nicht alle durchtabben, sondern springt mit tab gleich zum nächsten Gruppenelement oder anderen Widget weiter.

Kontakte

Der Reiter “Kontakte” ist der Ort, an dem man seine Kontakte durchsehen, Kontakte aus anderen Konten importieren kann usw. Die Kontaktliste ist der Nachrichtenliste sehr ähnlich: Man wählt auch hier mit den Pfeiltasten einen Kontakt aus. Das Umschalten zwischen Applikations- und Browse-Modus funktioniert auch hier einwandfrei, und das Feedback durch die Sprachausgabe ist genauso durchdacht wie in Mails.

Apropos Reiter: Wann immer etwas nicht ganz so implementiert wurde, wie man es vom Desktop her gewohnt ist, gibt es automatisch gesprochene Hilfestellungen, die die Besonderheiten der Navigation und Interaktion erklären. Ist man z. B. auf der Liste der Reiter (Tabs) gelandet, wird man angewiesen, dass die Pfeiltasten links und rechts einen anderen Reiter auswählen, und dass erst ein Druck auf Eingabe diesen Reiter tatsächlich aktiv schaltet. In Windows-Anwendungen bewirkt allein das Umschalten mit den Pfeiltasten ein aktiv Schalten der entsprechenden Dialogseite. Dieser Unterschied in der Interaktion wird also sehr deutlich kommuniziert. Sehr gut gelungen!

Soziale Netzwerke

Der vierte der standardmäßig gezeigten Reiter heißt “Updates”. Hier verlinkt man sein Yahoo!-Profil mit denen, die man auf Facebook, Twitter usw. hat. Der Reiter selbst ist hauptsächlich dazu da, die Verbindungen zu konfigurieren und selbst Updates an seine sozialen Netzwerke zu schicken. Das eigentliche Lesen wird von einer separaten Webanwendung erledigt, die in einem eigenen Browsertab oder -fenster gestartet wird und eine ganz normale Webseite ist. Diese gibt einen schnellen und vor allem barrierefreien Überblick über die Timelines von Twitter und Facebook. Während beide sozialen Netzwerke immer noch Probleme bei der Zugänglichkeit ihrer Webanwendungen ausmerzen müssen, ist das Interface von Yahoo! vollständig zugänglich und lässt kaum etwas zu wünschen übrig.

Optionen setzen

Von der Hauptnavigation von Yahoo! Mail aus kann man Optionen konfigurieren, die auf Mail und andere Yahoo!-Anwendungen angewandt werden. In den Maileinstellungen kann man z. B. eine seitenweise Nachrichtenanzeige einstellen (Standardeinstellung), so dass kein Vorschaubereich oder andere Dinge angezeigt werden, die die Barrierefreiheit beeinträchtigen könnten. Hier kann man außerdem einstellen, dass der Posteingang standardmäßig nach der Anmeldung geöffnet wird. Ich habe dies so eingestellt, denn wenn ich Mail aufrufe, will ich auch Mails lesen!

Hier kann man auch weitere Konten hinzufügen, von denen Mail abgerufen werden soll. Hier ist einer der wenigen irritierenden Punkte aufgetaucht: Der Link zum Hinzufügen eines Kontos befindet sich am oberen Ende des virtuellen Dokuments, direkt oberhalb des Schalters “Änderungen speichern”. Ich hätte erwartet, den Link dort zu finden, wo auch die Erklärung für das Verwenden weiterer Konten steht.

Anwendungen von Drittanbietern

Man kann Anwendungen von Drittanbietern in Yahoo! Mail einbinden. Es gibt z. B. eine Anwendung namens “meine sozialen Netze”. Da diese Anwendungen von Drittanbietern hergestellt und ausgeliefert werden, ist nicht gewährleistet, dass sie dieselbe Zugänglichkeit bieten wie das eigentliche Yahoo! Mail. Manche können sogar vollständig unzugänglich sein. Sie können auch in Flash oder Silverlight entwickelt worden sein und nicht den Zugänglichkeitsstandards für diese Plattformen entsprechen. Yahoo! kann man dafür aber nicht die Schuld geben. Stattdessen sollte man sich an die Hersteller dieser Anwendungen wenden und sie auffordern, Zugänglichkeit in ihre Anwendungen einzubauen.

Fazit

Was Yahoo! hier abliefert ist ein sehr gutes Beispiel dafür, wie WAI-ARIA und andere Techniken zur Barrierefreiheit von HTML-Anwendungen richtig genutzt werden. WAI-ARIA wurde bisher hauptsächlich in größeren Firmen und/oder Intranet-Anwendungen, oder auf einigen spezialisierten öffentlichen Webangeboten eingesetzt und erlangte so nur eingeschränkte Verbreitung. Yahoo! Mail ist jedoch eine “Anwendung von der Stange”, die an Millionen von Nutzern ausgeliefert wird und gibt so der Technologie einen sehr breit gefächerten Einsatz.

Dies ist auch der erste webbasierte E-Mail-Client, auf den umzustellen ich mir persönlich vorstellen kann. Er ist der erste, der mir das Gefühl gibt, ihn genauso effektiv nutzen zu können wie meinen geliebten Desktop-Client. Die Angebote anderer Firmen wie die mit dem großen G sind viel zu ineffizient. An meinem Arbeitsplatz wird der Zimbra Webmail-Client eingesetzt, welcher völlig unzugänglich ist, so dass ich hier gar keine Wahl habe als einen zugänglichen Desktop-Client einzusetzen.

Yahoo! liefert hier zusammen mit der ebenfalls sehr zugänglichen Suche eine zugängliche, inkludierende Webanwendung aus, der gegenüber sich andere Anbieter in Grund und Boden schämen müssen, wenn sie ihren blinden Anwendern raten, vom Standard- zu einem Basis-Angebot zu wechseln, das natürlich drastisch im Funktionsumfang eingeschränkt ist. Dieselbe Firma, die ihren Screen-Reader-Nutzern empfiehlt, ihr Instant-Feature abzuschalten, weil sonst selbst Suchergebnisse nicht mehr garantiert barrierefrei sind. Yahoo! verfolgen hier eine Inklusions-Strategie, die unter den durch Aktionäre getragenen Webfirmen einmalig ist.

Es gibt natürlich hier und da noch unrunde Ecken zum Glätten. So ist in der deutschen Version von Yahoo! Mail das Tastaturkürzel zum Schließen eines Tabs nicht das englische Ctrl+\, sondern etwas anderes. Dies habe ich jedoch bisher nicht herausgefunden, und wie oben bereits erwähnt gibt es noch keine deutschsprachige Liste von Tastaturkürzeln. Auch der Rest der Hilfe für die Zugänglichkeit ist noch nicht übersetzt. Eine Suche innerhalb der Hilfe nach Barrierefreiheit förderte keine, eine Suche nach Zugänglichkeit nur eine allgemein gehaltene Seite zur Zugänglichkeit von Mein Yahoo! zu Tage. Aber man kann sicher sein, dass diese Dinge innerhalb kurzer Zeit bereinigt werden, so dass auch Anwender, deren Muttersprache nicht englisch ist, in den vollen Genuss des neuen Yahoo! Mail kommen.

Einen großen Applaus für Yahoo!’s Inclusive-Design-Prinzip in Mail und ihre gute Zugänglichkeit!

Neue Stimmen in vielen Sprachen

Apple bietet für Lion Stimmen in niedriger und hoher Qualität in über 40 Sprachen und Dialekten an. Diese sind in kompakter Version für viele Sprachen bereits vorinstalliert. So kommt die deutsche Variante mit der Stimme Yannick daher, die bereits aus aktuellen iOS-Veröffentlichungen vom iPhone/iPod Touch und iPad bekannt ist. Eine höherwertige Version dieser Stimme sowie die Stimmen Steffi und Anna können nachgeladen werden. All diese Stimmen, also auch die ausländischen, werden von Apple kostenlos zur Verfügung gestellt. Man wählt sie einfach im VoiceOver-Dienstprogramm unter Sprachausgabe, Standard-Stimme, Menüpunkt “Anpassen”… aus und lädt sie dann über die automatisch sich öffnende Softwareaktualisierung herunter.

Aber auch für die Freunde der bereits für Leopard und Snow Leopard verfügbaren Stimmen der á Capella Group, die über AssistiveWare heruntergeladen und käuflich erworben werden können, gibt es Entwarnung: Diese funktionieren weiterhin, bei mir nach einem Upgrade von Snow Leopard auf Lion sogar ohne neuinstallation oder erneute Aktivierung. Wem also die Nuance-Stimmen nicht gefallen, der kann weiterhin Infovox iVox nutzen. AssistiveWare sagen selbst, dass sie bis Ende des Monats ihre Produkte auf mit Lion kompatible Versionen aktualisieren wollen, meine Tests mit den Stimmen haben allerdings gezeigt, dass die reinen Stimmenpakete anscheinend weiterhin problemlos funktionieren.

Die Tatsache, dass Stimmen u. a. für Deutsch vorinstalliert sind, bedeutet, dass man jetzt in einem Apple oder Gravis Store nicht nur iPhones und iPads in seiner Muttersprache ausprobieren kann, sondern auch alle Varianten des Macs. Bei einer frischen Installation von Lion auf deutsch wird automatisch mit Yannick Compact gesprochen, so dass VoiceOver ohne Installation einer externen Sprachausgabe sofort in deutsch zu sprechen beginnt.

Einziger Wermutstropfen: Während der Installation wird diese Stimme noch nicht verwendet, hier quatscht immer noch die Decktalk-Variante “Fred” in allen Sprachen. Dies gilt aber nur für den Installationsvorgang von der Recovery-Partition, nicht für das Setup nach der allerersten Installation. Der Assistent, bei dem man u. a. nach seiner Apple-ID gefragt wird, wird bereits mit einer deutschen Stimme begleitet.

Neue Braille-Funktionen

VoiceOver liefert jetzt Brailletabellen in verschiedenen Sprachen mit, unter anderem deutsch. Auch die Kurzschriftübersetzung ist für deutsch und weitere unterstützte Sprachen verfügbar. Leider gibt es zur Zeit keine Möglichkeit, bei der Kurzschriftübersetzung die Anzeige von Großbuchstaben abzuschalten, so dass die Kurzschriftdarstellung nicht ganz der eines Standard-Buches entspricht, in der es ja keine Anzeige von Großbuchstaben gibt.

Durch Brailleausführlichkeit kann man jetzt angeben, was in verschiedenen Situationen angezeigt werden soll und somit gerade auf kleineren Displays den Platz effizienter nutzen.

Aktivitäten

VoiceOver-Aktivitäten sind Sätze von Einstellungen, auf Wunsch alle, die das VoiceOver-Dienstprogramm zur Verfügung stellt, die für bestimmte Situationen oder bestimmte Anwendungen angepasst werden können. So kann man z. B. eine Aktivität für eine Anwendung einstellen, oder man öffnet mit VO+X ein Menü aller verfügbaren Aktivitäten, weil man im Web zum Einkaufen vielleicht eine schnellere Sprechgeschwindigkeit und andere Stimme verwendet als zum Lesen von Artikeln, Blogs usw. Eine Aktivität kann hierbei durchaus auch auf mehrere Anwendungen automatisch angewendet werden.

Ziehen und Ablegen (Drag and Drop)

VoiceOver unterstützt jetzt das automatisierte Drag and Drop. Dies war bisher durch eine Kombination mehrerer Befehle bereits möglich, wurde jetzt jedoch erheblich vereinfacht.

1. Man wählt mit den VoiceOver-navigationsbefehlen oder der Tastatur das zu ziehende Objekt an und drückt VO+Komma.
2. Man navigiert mit dem VoiceOver-Cursor an die gewünschte Zielstelle am Bildschirm und drückt eine der folgenden Tasten:
   1. VO+Punkt zum Fallenlassen auf dem Objekt, auf dem sich der VoiceOver-Cursor gerade befindet. Das Resultat hängt von der Anwendung ab.
   2. VO+< (Kleiner als Das Objekt auf dem Objekt, das dem Objekt, auf dem der VoiceOver-Cursor steht, voransteht. Hierbei ist die Navigationsreihenfolge gemeint, nicht die visuelle Anordnung auf dem Bildschirm.
   3. VO+> (Größer als zum Fallenlassen auf dem Objekt, das dem Objekt unterm VoiceOver-Cursor navigationsmäßig nachfolgt.

Hierbei unterliegt der Vorgang denselben Beschränkungen wie von Windows-Screen-Readern her gewohnt: Sind nicht mehr beide Objekte visuell am Bildschirm sichtbar, weil eines in der Zwischenzeit verdeckt wurde oder weggescrollt ist, schlägt der Vorgang fehl. Auch sind nicht alle Objekte von VoiceOver zum Ziehen freigegeben: Auf den meisten Webelementen erlaubt es schon das Markieren als zu ziehendes Objekt nicht. So kann man z.B. nicht wie der Sehende in Google Plus einen Kontakt auf einen Kreis ziehen, um ihn diesem Kreis hinzuzufügen.

Schnelle Navigation mit einzelnen Buchstaben auf Webseiten

Ähnlich dem Modell von Windows-Screen-Readern kann man in VoiceOver jetzt optional einstellen, dass man durch das Tippen einzelner Buchstaben ohne Umschalttasten wie Befehlstaste zu bestimmten Elementen navigieren kann. Dies sollte Umsteigern den Umstieg noch weiter erleichtern.

Aufgeräumteres VoiceOver-Dienstprogramm

Die Benutzeroberfläche des Dienstprogrammes für VoiceOver wurde an einigen Stellen überarbeitet, um neue Funktionen elegant zu integrieren und einige Tabs übersichtlicher zu gestalten. Weiterhin gibt es jetzt eine Suchfunktion, mit der eine bestimmte Funktion leicht aufgefunden werden kann, wenn man vergessen hat, wo genau sie sich verbirgt.

Unterstützung von Anwendungen

Kalender

Die Navigation und Interaktion mit Kalenderobjekten wurde stark verbessert, auch die Überarbeitung des Kalenders selbst bringt für VoiceOver eine weitere Verbesserung der Zugänglichkeit des ohnehin schon sehr zugänglichen Kalenders.

Mail

Das neue, für meine Begriffe sehr gelungene, mail wird von VoiceOver unterstützt. Es ist also nicht nötig, außer man möchte es aus Gewohnheit tun, auf die klassische Darstellung, die man aus Snow Leopard gewohnt ist, umzuschalten. Die neue, konversationsorientierte, darstellung ist mit VoiceOver genauso nutzbar. Nach wenigen Minuten des Eingewöhnens möchte ich diese Darstellung, die auch schon vom iPad und iPhone bekannt ist, nicht mehr missen. Die Vorschau der einzelnen Mails wird automatisch vorgelesen und gibt so einen schnellen Überblick über den wichtigsten Inhalt der Mail.

Safari

Es werden jetzt Navigationspunkte (WAI-ARIA Landmarks) erkannt. Die deutsche Übersetzung ist etwas hakelig geworden, so sagt VoiceOver beim Erreichen eines Orientierungspunkts z. B. "Banner eingeben". Warum man nicht einfach die gut funktionierende Übersetzung von iOS genommen hat, erschließt sich mir nicht.

VoiceOver sagt jetzt erforderliche und ungültige Einträge an, wenn diese mit HTML5 oder WAI-ARIA ausgezeichnet sind. Auch werden WAI-ARIA Dialoge und Live Regions unterstützt.

Die Interaktion mit formatierbarem Text, z. B. beim Verfassen einer Mail in GoogleMail, wurde verbessert.

VoiceOver kommt spürbar besser und schneller mit sich dynamisch aktualisierenden Seiten wie Facebook zurecht.

LaunchPad und Mission Control

Auch die neuen Funktionen LaunchPad und Mission Control sind mit VoiceOver bedienbar. Der wirkliche Nutzen erschließt sich mir aber nur, wenn ich die Trackpad-Steuerung aktiviert habe und somit die Objekte tatsächlich berühre. Die Navigation im Gitter mit der Tastatur ist nicht effizienter als das Wählen einer Anwendung aus dem Dock oder dem Programme-Ordner im Finder, sondern eher langsamer, weil man hier keine Möglichkeit der Eingabe von Buchstaben hat, um ein Programm gezielt anzuspringen.

Die neue Rechtschreibkorrektur und Autovervollständigung

Die neue Autovervollständigung wird von VoiceOver unterstützt. Ertönt der auch vom iPhone bekannte Blubberton, kann man mit Pfeil runter die Rechtschreibvorschläge ansteuern, mit rechts und links die einzelnen Vorschläge auswählen und mit Eingabe von z. B. Leerzeichen oder einem Satzzeichen übernehmen, oder man drückt Pfeil rauf, um keinen der Vorschläge zu akzeptieren.

Kleine Detailverbesserungen

Es sind aber auch die Detailverbesserungen, die das Arbeiten unter Lion mit VoiceOver zu einem schönen Erlebnis machen. So werden bei Tabellen, denen von einem programm Zeilen hinzugefügt werden, die gewählten Zeilen nicht automatisch erneut vorgelesen, nur weil neue Inhalte dazugekommen sind. Gerade bei einem Programm wie dem Twitter-Client Syrinx ist dies eine angenehme Reduzierung der Geschwätzigkeit.

Das Vorlesen im Web geht meines Erachtens nach etwas flüssiger vonstatten als unter Snow Leopard. In manchen Situationen (ich habe noch nicht genau herausgefunden, welche) kann man sogar während des Vorlesens eines Absatzes VO+A drücken, und das Vorlesen wird nicht unterbrochen, sondern das Objekt wird zu Ende gelesen und dann mit dem nächsten weitergemacht.

Fazit

Von vielen wird bemängelt, dass Lion kein großer Fortschritt sei. In Bezug auf die Zugänglichkeit dynamischer und mit neuen Technologien wie HTML5 und WAI-ARIA zugänglich gemachter Webinhalte ist VoiceOver in Lion hingegen doch ein sehr großer Fortschritt, da die Menge an unterstützten Widgets dramatisch zugenommen hat.

Auch die neuen Oberflächen von Mail und Kalender sind, wenn man viel mit diesen Programmen arbeitet, das Upgrade definitiv wert.

Etwas weniger sinnvoll ist LaunchPad für VoiceOver-Benutzer, die die Trackpad-Steuerung nicht benutzen.

Die eingebauten und kostenlos herunterladbaren Stimmen sind ein echter Zugewinn! Man ist nicht mehr zwangsweise auf den Erwerb von Stimmen eines Drittanbieters angewiesen, sondern bekommt schön klingende und dennoch sehr reaktionsschnelle Stimmen frei haus mitgeliefert, man muss lediglich ein bisschen Zeit aufwenden, sie per Softwareaktualisierung herunterzuladen.

Für €23,99 bekommt man hier definitiv eine ganze Menge Neues fürs Geld geboten, und ich kann das Upgrade nur wärmstens empfehlen!

Dieser Blogeintrag ist eine Übersetzung des englischen Blogeintrags The poor State of Android accessibility des NVDA-Entwicklers James Teh. Sie wurde mit freundlicher Genehmigung des Autors vom Inhaber dieses Blogs erstellt. Sämtliche wiedergegebenen Meinungen entsprechen denen des Autors des englischsprachigen Artikels.

Die Mobilplattform Android finde ich wirklich spannend. Sie ist offen (was man vom iPhone nicht behaupten kann), und sie ist auf vielen Gebieten sehr erfolgreich. Ich würde mich mit ziemlicher Sicherheit für ein Android-Smartphone entscheiden, wäre da nicht der schlechte Zustand der Barrierefreiheit von Android.

Hinweis: Ich werde hier hauptsächlich die Zugänglichkeit für blinde Nutzer besprechen, denn damit bin ich am vertrautesten. Einiges hiervon gilt jedoch auch für andere Formen der Behinderung.

Am Anfang

Am Anfang gab es keinerlei Barrierefreiheit in Android. Es hätte Sinn gemacht, es vom Start weg unter Berücksichtigung der Barrierefreiheit zu designen, was die Sache stark vereinfacht hätte, aber wie es leider so oft der Fall ist, ist dies nicht geschehen. Dennoch gibt es Plattformen, die sich von dieser Nachlässigkeit erholt haben, und einige davon sogar sehr erfolgreich.

Das Eyes-Free Project

Dann erschien das Eyes-Free Project auf der Bildfläche, welches einen Satz selbst sprechender Anwendungen erstellte, welche es blinden Benutzern erlaubten, viele Funktionen eines Android-Phones zu nutzen. Von blinden Anwendern zu verlangen, diese speziellen Anwendungen zu verwenden, beschränkt die Funktionalität, auf die sie Zugriff haben, und isoliert sie komplett von der Erfahrung, die andere Anwender mit diesen Geräten machen. Dies ist nur einen kleinen Schritt von einem speziell für blinde Benutzer entwickelten Gerät entfernt. Ich schätze, es ist besser als nichts, aber auf lange Sicht ist es inakzeptabel.

Integrierte Accessibility API and Services

In Android 1.6 wurde eine Programmierschnittstelle zur Barrierefreiheit, ein Bildschirmleseprogramm (Talkback) und andere Barrierefreiheitsdienste in den Android-Kern mit eingebaut. Ein Entwickler außerhalb von Google begann außerdem mit der Entwicklung des Bildschirmleseprogrammes Spiel. Dies bedeutete, dass blinde Anwender nun Zugang zu Standard-Android-Anwendungen hatten wie jeder andere auch.

Leider ist die Barrierefreiheits-Programmierschnittstelle von Android extrem eingeschränkt. Das einzige, was sie tun kann, ist, ein Ereignis zu generieren, wenn etwas wichtiges in der Benutzerschnittstelle passiert. Ein Barrierefreiheitsdienst wie ein Bildschirmleseprogramm kann diese Ereignisse nach bestimmten Informationen befragen wie z. B. den Text des Objekts, das gerade aktiviert wurde. Außerhalb davon sind aber keine Abfragen möglich. Dies bedeutet, dass keine Informationen zu anderen sich auf dem Bildschirm befindlichen Objekten abgefragt werden können, es sei denn, sie werden aktiviert. Unter anderem macht dies das Erforschen des Bildschirms unmöglich. Sogar die inzwischen sehr betagte Microsoft Active Accessibility, die Programmierschnittstelle zur Barrierefreiheit, die in Windows verwendet wird, erlaubt trotz ihrer Einschränkungen und Defizite das Erforschen und Abfragen von und Interagieren mit Objekten.

Die Unmöglichkeit, Eingaben global abzufangen

Weiterhin ist es einem Barrierefreiheitsdienst nicht möglich, Tastendrücke oder Berührungen des Touch Screens auf globaler Ebene abzufangen. Dies bedeutet nicht nur, dass ein Barrierefreiheitsdienst keine Befehle zur Erforschung des Bildschirms, zum Unterbrechen der Sprachausgabe, zum Verändern von Einstellungen usw. per Tastatur oder Bildschirmzur Verfügung stellen kann. Es macht außerdem die Barrierefreiheit der Benutzung des Touch Screens für blinde Anwender unmöglich. Ein blinder Anwender muss in der Lage sein können, den Touch Screen zu erkunden, ohne versehentlich ein Objekt zu aktivieren. Dies kann aber nur erreicht werden, wenn das Bildschirmleseprogramm den Bildschirm gesondert behandeln kann.

Nicht barrierefreie Ausgabe von Webseiten

Der in Android verwendete Ausgabemechanismus für Webseiten, die sog. Web Rendering Engine ist nicht barrierefrei. Es ist zur Zeit wahrscheinlich sogar unmöglich, diese auf Grund der extrem eingeschränkten Infrastruktur überhaupt barrierefrei zu machen, da ein Anwender in der Lage sein muss, sämtliche Objekte einer Webseite zu erkunden. Dies bedeutet, dass der eingebaute Browser, E-Mail-Client und die meisten anderen Anwendungen, die Webinhalte anzeigen, unzugänglich sind. Dies ist für ein modernes Smartphone völlig inakzeptabel!

Barrierefreier E-Mail-Client und Webbrowser von IDEAL Apps4Android

IDEAL Apps4Android haben einen barrierefreien E-Mail-Client und einen Webbrowser veröffentlicht. Die Erweiterungen zur Barrierefreiheit des K9 E-Mail-Clients (auf dem ihre Anwendung basiert) sind inzwischen in das K9-Projekt zurückgeflossen, und das ist großartig! Der Zugriff auf das Web erfordert jedoch immer noch einen separaten Webbrowser. Und obwohl Entwickler diese zugängliche Webunterstützung in ihre eigenen Anwendungen integrieren können, ist es doch nur ein Satz selbst sprechender Skripte, welche in die Applikation eingebettet werden müssen. Dies ist eher unelegant und eher aufgepfropfte Barrierefreiheit als Barrierefreiheit, die in die Webausgabe-Engine eingebaut wäre. Dies ist keine Kritik an IDEAL. Sie haben das bestmögliche getan im Angesicht der limitierten Programmierschnittstellen und gehören hoch gelobt. Dennoch ist es eine nicht zufriedenstellende Situation.

Weitere “barrierefreie” Applikationen

Es gibt noch diverse weitere Applikationen außer den oben genannten, die als speziell barrierefreie Anwendungen konzipiert wurden, die jedoch Anwender mit einer Behinderung wiederum von denjenigen Anwendungen isolieren, die alle anderen einsetzen. Nochmal: Diese Isolation rührt primär von den extrem beschränkten Programmierschnittstellen für die Barrierefreiheit in Android her.

Die Lösung

Obwohl Android quelloffen ist, ist die Lösung des Problems für Entwickler außerhalb des Kernentwicklerteams schwer möglich, da diese Änderungen am Kern von Android erfordert. Das aktuelle Framework zur Barrierefreiheit muss erheblich erweitert oder vielleicht sogar redesignet werden, und Kernanwendungen müssen dann auch die Vorteile dieses redesignten Frameworks nutzen.

Fazit

Während in Android 1.6 und neuer erhebliche Fortschritte in Puncto Barrierefreiheit gemacht wurden, ist der Gesamtzustand immer noch sehr unzufriedenstellend. Android kann jetzt von blinden Anwendern verwendet werden, aber es ist längst nicht optimal oder einfach. Zusätzlich ist die Implementierung schlecht entworfen und unelegant. Diese Situation wird sich mit der Zeit nur noch verschlimmern, bis das Problem gelöst wird.

Ich empfinde es als sehr frustrierend, dass die Barrierefreiheit in Android in einem so schlechten Zustand ist. Es sieht so aus als wenn Google gar nichts aus der Vergangenheit der Barrierefreiheit gelernt hat. Dieses Chaos hätte vermieden werden können, wenn das Barrierefreiheits-Framework vernünftig entworfen worden wäre, anstatt des halbfertigen Stückwerks, das jetzt vorliegt. Ein gründliches Design ist ein Grund, warum die Barrierefreiheit im iPhone so hervorragend ist und “einfach funktioniert”.

Das erste, was ich bemerkte, war, dass der Login-Button auf der neuen Startseite des Online-Banking mir als “/portalstatic/spm/gfx/style/buttons/buttonFlach_Jetzt_einloggen.png [Schalter]” vorgelesen wurde. Sämtliche Labels waren den Eingabefeldern aber weiterhin korrekt zugeordnet, und sogar das Audio-Captcha zur Eingabe des Sicherheitscodes war weiterhin vorhanden.

Nachdem ich das Login durchgeführt hatte, erwartete mich dann aber die richtig böse Überraschung. Die ganze Seite ist gepflastert mit grafischen Links, die sich so oder ähnlich anhören: “04_SB8K8xLLM9MSSzPy8xBz9CP0os3gDU3cvAw93IwP3EFMTA08LH0NzC19jAwNfI_2CbEdFAH8_-FQ! [Grafik Link]“. Wenn mir daraus jemand ableiten kann, was dieser spezielle Link tut, ist er/sie gut!

Ich schrieb daraufhin eine Mail an das Service-Team.

Nachdem ich dann auf Twitter mehrere Beobachtungen mitgeteilt hatte und auch unverholen mein Entsetzen über dieses Bremsen von 100% auf 0% Barrierefreiheit zum Ausdruck gebracht hatte, erhielt ich diesen Hinweis von der Sparda-Bank Nürnberg:

@MarcoZehe den barrierefreien Zugang zum SpardaNet-Banking gibt es bei Bedarf weiterhin. Kurze Mail an den Support dann gibt es den Link.

Es stellte sich heraus, dass die Mail an den Support nicht notwendig war. Auf der oben bereits erwähnten neuen Startseite des “modernen” Sparda Banking gibt es folgenden Absatz: “Hier melden Sie sich für kurze Zeit noch im Classic Banking an.” Es folgt ein grafisch nicht korrekt ausgezeichneter Link zum bisher gewohnten Banking.

Wer aufmerksam gelesen hat, dem ist das “für kurze Zeit” in dem obigen Zitat nicht entgangen! Wie lang wird diese Zeit sein? Ein Monat? Sechs Monate? Ein Jahr? Eine Woche?

Und nun kommen wir zum eigentlichen Grund, warum dieser Relaunch des Online-Bankings ein technischer und PR-mäßiger Super-Gau ist.

Wir schreiben das Jahr 2010. Seit über 10 Jahren predigen Organisationen wie von der Aktion Mensch und viele engagierte und technisch sehr gute Webentwickler und -agenturen die Standards der Barrierefreiheit im Webdesign und der Webprogrammierung. Seit 1999 gibt es die WCAG 1.0 des W3C, die im Dezember 2008 durch die WCAG 2.0 ersetzt wurden. Die BITV 1.0 soll noch in diesem Jahr durch die BITV 2.0 ersetzt werden. Unternehmen wie Amazon.de haben es seit Jahren nicht mehr nötig, alternative Textversionen für ihre Angebote anzubieten.

Und hier kommt ein Relaunch, der eine 100%ige Rückwärtsrolle von einem vorbildlichen(!) Online-Banking hin zu einem tut, der für Anwender assistiver Technologien überhaupt nicht mehr bedienbar ist. Und ein Verweis auf eine Alternativfersion, die der vorbildlichen Vorversion entspricht, von der aber nicht klar ist, wie lange diese tatsächlich noch weiter existieren bzw. gepflegt werden wird.

Zum einen ist es schon immer betriebswirtschaftlich und organisatorisch sehr unklug gewesen, Alternativversionen für bestimmte Personenkreise zur Verfügung zu stellen. Die Erfahrung zeigt, dass diese alternativen Angebote gern bei Aktualisierungen vergessen werden. Nun ist diese Aktualisierung bei einem Onlinebanking-Portal vielleicht nicht ganz so häufig wie z. B. auf einer Seite wie Amazon oder irgendeinem Newsportal. Aber es bleibt das Gefühl, man könnte was verpassen. Den größten Gau in diesem Bereich leistet sich GoogleMail, wo nämlich die für Blinde konzipierte HTML-Version viele(!) der Features des Standard-Interface komplett nicht zur Verfügung stellt.

Zweitens ist es betriebswirtschaftlich schlicht unvernünftig, im Jahr 2010 die Barrierefreiheit nicht gleich ins Grundkonzept mit aufzunehmen. Die Gesellschaft wird immer älter, und die Barrierefreiheit betrifft nicht nur Blinde, sondern Menschen mit allen möglichen Einschränkungen, von denen viele mit zunehmendem Alter auftreten. Weiterhin kommen immer mehr Senioren ins Netz, die darauf angewiesen sind, dass sie mit ihren Möglichkeiten der Maus- und Tastaturbedienung die Angebote bedienen können. Und auch Pensionäre machen Online-Banking! Und ich wage mal die Behauptung, dass die Damen und Herren im Management, die diese Entscheidungen die Sparda-Bank betreffend zu fällen haben, entweder schon selbst in einem Alter sind, wo diese Aussagen bald zutreffen könnten, oder Eltern haben, bei denen sie diese Notwendigkeit beobachten können. Man muss keine Menschen mit Behinderungen kennen, man braucht sich nur in der eigenen Familie oder Verwandtschaft umschauen!

Eine Agentur mit entsprechendem Know-How hätte das neue Online-Banking von vornherein barrierefrei gestalten können, und es hätte trotzdem “chic” ausgesehen. Diese Agenturen gibt es in Deutschland. Hier wurde jedoch offensichtlich eine Agentur gewählt, die dieses Know-How entweder nicht besitzt oder die Wichtigkeit einer inklusiven Vorgehensweise nicht herausgestellt hat. Initial wäre das Angebot vielleicht etwas teurer geworden. Aber das, was da jetzt betrieben werden muss, ist auf lange Sicht teurer:

Entweder lässt man den barrierefreien Zugang unbegrenzt(!) weiterlaufen und muss so immer zwei Angebote auf dem aktuellen Stand halten.

Oder man muss die Barrierefreiheit jetzt per Flickschusterei nachrüsten, also eine des Projektes einleiten, um irgendwann den barrierefreien Zugang abschalten und die Phase 2 des neuen, dann barrierefreien Zugangs, ersetzen zu können. Eine Phase 2 kostet immer mehr Geld als eine inkludierende Vorgehensweise gekostet hätte.

Viel Spaß!

Also dann, auf einen fruchtbaren Austausch!

1. In den Objektattributen jedes Accessibles einer Seite kann jetzt der exakte Wert für das CSS-Attribut “display” abgefragt werden. Zusätzlich zu “formatting:block”, welches weiterhin zur Verfügung steht, ist es so möglich, eine genauere Information über die Gestaltung des jeweiligen Elements zu erhalten als bisher. In Firefox 3.1 Beta ist dies schon länger verfügbar und hat jetzt auch seinen Weg in Firefox 3.0.5 gefunden.
2. Es wurde ein Fehler behoben, durch den manche Arten von Dokumentelementen nicht ordnungsgemäß den Focus übernehmen konnten. Hiermit sollten weitere als “anklickbar” gemeldete Elemente aktivierbar werden.
3. Für Screen Reader, die nicht IAccessible2, sondern die älteren iSimpleDom*-Interfaces verwenden, wurde ein Fehler behoben, der bei der Anforderung des sog. ComputedStyle, also des tatsächlich in Effekt befindlichen Stils eines Elements, auftrat. Hiermit sollte es Screen Readern, die diese Interfaces noch verwenden, jetzt besser möglich sein, Dokumentformatierungen zu sprechen. Auch diese Änderung ist schon länger in Firefox 3.1 und hat nun ihren Weg in Firefox 3.0.5 gefunden.