Kategorien
ARIA Zugänglichkeit

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!

Werbeanzeigen
Kategorien
NVDA WordPress Zugänglichkeit

Tipp: Mit einem Screen Reader mit den dynamischen Menüs des WordPress-3.3-Adminbereiches umgehen

WordPress 3.3 führt neue, dynamische Menüs im Administrationsbereich ein. Dieser einfache Tipp soll zeigen, wie man als Blinder mit einem Screen Reader diese dynamischen Menüs bedienen kann. Hierfür verwende ich NVDA 2011.3RC und Firefox, es geht aber auch mit anderen Screen-Reader- und Browser-Kombinationen.

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!

Kategorien
ARIA Zugänglichkeit

Von WAI-ARIA nach HTML5 und zurück, oder doch nicht?

Auf dem Multimediatreff 28 in Köln am 3. Dezember hielt ich einen Vortrag über Barrierefreiheit mit WAI-ARIA und HTML5. Als Beispiel zog ich hierfür meinen einfachen ARIA-Tip #2 heran und entwickelte diesen weiter. HTML5 bietet inzwischen viele der Fähigkeiten, die WAI-ARIA mitbringt, nativ, und viele davon sogar besser.

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.

    </li

  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.

Kategorien
Hexe

Dritter Toronto-Besuch

Nach dem November letzten Jahres und dem Juli diesen Jahres sind Hexe und ich seit Samstag das dritte Mal in Toronto in Kanada. Und es fühlt sich inzwischen fast so an wie ein Nach-hause-Kommen. Wir sind jetzt das zweite Mal im Hilton Garden Inn Downtown Toronto. Das neue Büro von Mozilla Kanada liegt in der nächsten Querstraße, der Adelaide Street, ist also wirklich in einer Minute Fußweg zu erreichen.

Als wir ankamen, zeigte sich gleich wieder die Stärke eines Blindenführhundes in bekannter und neuer Umgebung. Hexe erkannte sofort die Umgebung wieder, fand ohne Zögern den Eingang zum Hotel, die Rezeption und die Fahrstühle. Da wir ein anderes Zimmer bewohnen, musste sie natürlich kurz lernen, welche Tür jetzt die richtige ist, das war aber beim zweiten Mal auch schon kein Thema mehr.

Und auch den weg zum Gassi-Park zwei Straßen weiter fand sie auf Anhieb. Sie machte schon am Hotelausgang den richtigen Richtungswechsel, fand die Ampel, die über die King Street führt, und bog auch richtig auf die Wellington Street ab.

Im Park war sie natürlich wieder von den hier viel größeren Eichhörnchen fasziniert, die frech überall herumstreunten und dann auf die Bäume flüchteten, nur um sie und auch andere Hunde von dort oben herausfordernd anzustarren. Die sind hier fast so frech wie in deutschen Großstädten die Tauben!

Auch heute morgen beim Frühstück gab es eine Wiedererkennung der Umgebung, und auch mehrere Mitarbeiter erinnerten sich an uns. Der Kellner wusste sogar noch, wie ich meinen Kaffee am liebsten trinke!

Heute Abend werde ich in dem gleichen italienischen Restaurant essen, in dem wir auch vor einem Jahr schon waren, und ich freue mich sehr drauf!

Dieser dritte Toronto-Besuch fühlt sich wirklich schon fast an wie ein zweites Zuhause. Man kennt die Umgebung mittlerweile, ich komme mit der Mentalität gut klar, und Hexe macht durch ihr sehr souveränes Verhalten und ihre Leichtigkeit beim Führen auch eine ganze Menge aus. Auch sie fühlt sich sehr wohl hier.

Kategorien
Zugänglichkeit

Mehrere nicht barrierefreie Relaunches in dieser Woche, die Wut ist groß

In dieser Woche gab es gleich mehrere Anlässe, weswegen ich das Gefühl hatte, mal einmal gepflegt über den Tisch kotzen zu wollen. Entschuldigt die derbe Ausdrucksweise, aber was anderes fällt mir zu den Relaunches des Bayerischen Rundfunks und von Der Westen nicht mehr ein.

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
    A 40 in Duisburg wird am Wochenende zum Nadelöhr

    . „hl“ steht dabei vermutlich für „Header large“ oder so.

  • Auch entsetzlich und von Eric Eggert auf Twitter gepostet:

    . 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!

Kategorien
Apple ARIA Zugänglichkeit

Mac OS X Lion ist da, Eindrücke von den neuen Barrierefreiheitsfunktionen

Apple hat soeben die neueste Version seines Betriebssystems Mac OS X, Lion, veröffentlicht. Eine gute Gelegenheit, einen Blick auf die neuen Barrierefreiheitsmerkmale der jüngsten Raubkatze zu werfen!

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!

Kategorien
Zugänglichkeit

Positive Überraschung: Privatwirtschaftliches Unternehmen mit barrierefreiem Webauftritt

Bei meiner aktuell laufenden Wohnungssuche bin ich auf das Angebot des Wohnquartiers am osterbekkanal in Hamburg gestoßen. Beim ersten Aufruf der Seite fiel mir auf, dass es Skip-Links gibt, die Seite eine Überschriftenstruktur hat und auch ansonsten sehr übersichtlich gegliedert ist.

Die wahre Überraschung erlebte ich, als ich neugierig auf einzelne Wohnungen wurde und wissen wollte, ob die hinterlegten PDFs eventuell noch mehr Informationen als nur den bloßen Grundriss enthalten. Als das PDF herunterlud und sich öffnete, begann mein Screen Reader sofort mit dem Lesen der PDF-Datei! Kein lästiges Dialogfeld des Adobe Readers „Lesen eines Dokuments ohne Tags“, kein „Dokument wird verarbeitet“-Fortschrittsbalken nach Bestätigung des vorigen Dialogs. Nein, die PDF-Datei öffnete sich ohne weiteres Murren, was bedeutet, dass sich jemand die Mühe gemacht hat, sie zu taggen und somit barrierefreier zu gestalten! Das erschloss mir nicht den Grundriss selber, aber einige weitere Informationen. Und allein die Tatsache, dass hier mit Barrierefreiheits-Tags versehene (AKA „durchsuchbare“) PDFs hinterlegt sind, ist eine große Überraschung, die es positiv hervorzuheben gilt! 99,9% aller im Netz befindlicher PDFs sind nicht getaggt, und das schließt viele von Behörden und anderen Regierungsorganisationen zur Verfügung gestellte PDFs mit ein! Das Tagging selbst verlangt (bewusst überspitzt formuliert) fast einen eigenen Studienabschluss. 😉

Und hier ist ein privatwirtschaftliches Unternehmen, das für den Auftritt für dieses Wohnquartier nicht nur diese, sondern auch noch einige weitere Richtlinien zur barrierefreien Webgestaltung erfüllt:

  • Es gibt mit der Tastatur navigierbare und sichtbar werdende Skip-Links.
  • Verschiedene Sektionen wie die Navigation werden mit versteckten Überschriften für Screen Reader eingeleitet.
  • Der zur Zeit hervorgehobene Menüpunkt ist zwar nicht optisch hervorgehoben, wird aber in der Hauptüberschrift deutlich sichtbar wiederholt.
  • Die Schriften sind skalierbar.
  • Die Kontraste sind ausreichend.
  • Die Seite macht auch ohne Farben eine gute Figur.

Vielen Dank an Kerstin für die visuell feststellbaren Punkte, die ich oben aufgeführt habe!

Ich möchte einfach mal hervorheben, dass ich sehr positiv angetan bin vom Webauftritt für dieses Wohnquartier! Es geht also, man kann eigeninitiativ barrierefreie Webinhalte auch als privatwirtschaftliches Unternehmen gestalten, ohne zwangsweise der BITV zu unterliegen!

Ich hoffe, dass sich an diesem Vorbild so manches andere Unternehmen jeder Branche ein Beispiel nimmt!

Super gemacht, weiter so!

Kategorien
Allgemein Apple Zugänglichkeit

Neues Bezahlsystem mit Bezahlcode ein Gewinn für die Barrierefreiheit

Ich bin seit einiger Zeit Betatester für die iPhone- und iPad-Anwendung iOutBank. Das folgende ist ein Ausblick auf die kommende Version von iOutbank, speziell für das iPhone, die einen riesigen Schritt für mehr Barrierefreiheit beim Bezahlen per Überweisung darstellen kann, wenn entsprechend die Firmen mitziehen. Ich habe von der Stöger IT GmbH die Genehmigung, über dieses noch nicht veröffentlichte Feature zu bloggen.

Zunächst einmal folgt ein kleiner Einblick darin, wie ich als Blinder heute eine Überweisung tätige:

  1. Rechnung kommt mit der Post oder als PDF.
  2. Rechnung wird auf Scanner gepackt bzw. das PDF wird geöffnet.
  3. Wenn das PDF ordentlich ausgezeichnet ist, was die wenigsten sind, kann ich die Rechnung sofort verarbeiten. In den meisten Fällen muss ich aber die PDF-Rechnung durch eine Texterkennung jagen, um den Text überhaupt lesen zu können. Mit der Papierrechnung muss ich das auf jeden Fall tun.
  4. Die generierte Textdatei durchsuche ich nun nach den Daten wie Kontonummer, BLZ, genauen Namen der Firma, Rechnungsbetrag und Rechnungsnummer.
  5. Jetzt logge ich mich in mein Online-Banking-Portal ein und wähle „Überweisung“.
  6. Wenn ich Glück habe, kann ich mit Copy & Paste die Daten in die einzelnen Felder übernehmen. Wenn ich Pech habe, muss ich Dinge wie Bankleitzahl oder Kontonummer in kleineren Portionen kopieren oder im Kopf behalten, nämlich immer dann, wenn aus Gründen der optischen Verschönerung und besseren Lesbarkeit mit den Augen Leerzeichen in den Ziffernfolgen stehen. Und ich kenne bisher kein Onlinebanking-Portal, das so klug wäre, die Leerzeichen beim Einfügen rauszufiltern oder ggf. für übliche Ziffernaufteilungen in den Eingabefeldern genug Platz zu lassen. Die Folge sind abgeschnittene Kontonummern oder Bankleitzahlen, die ich erst noch mühsam nachbearbeiten und vervollständigen muss.
  7. Ist alles ausgefüllt, dann noch die indizierte TAN eingeben und die Überweisung absenden. Bei Firmen, mit denen ich öfters Zahlungsverkehr habe, kann ich die Empfängerdaten speichern und mir in Zukunft vielleicht einige Tipparbeit sparen.

Vor einigen Wochen nun sprach mich der Inhaber der Stöger IT GmbH an, dass da eine neue Funktion in IOutbank käme namens Bezahlcode-Unterstützung. Er verwies mich dann auch auf die Webseite bezahlcode.de, auf der das Verfahren näher erklärt wird und sogar ein Bezahlcode-Generator zum Ausprobieren vorhanden ist.

Ich habe dann mal einen Test gemacht und mir selbst eine Rechnung gestellt. Der Bezahlcode war auf der Seite schnell generiert, die entsprechende Grafik in die Zwischenablage kopiert und in ein Word-Dokument eingefügt.

Als nächstes die neueste Beta von iOutbank gestartet, die entsprechenden Knöpfe betätigt und die Kamera ca. 10-20 cm über das ausgedruckte Blatt Papier gehalten. Ein bisschen hin und her bewegt, und nach wenigen Sekunden ertönte ein Signal, und iOutbank teilte mir mit, dass es einen Bezahlcode identifiziert hat. Nach dem Bestätigen wurde automatisch ein Überweisungsfenster geöffnet und die Daten eingetragen. Es war alles da: Name, Kontonummer, Bankleitzahl, Betrag und Verwendungszweck! Kein Abtippen, keine Gefahr von zahlen- oder Buchstabendrehern. Ich hätte die Überweisung jetzt einfach absenden, eine i-Tan eingeben und die Überweisung tätigen können.

Einen Audioeindruck (ganz bewusst kein Video!) gibt es in diesem AudioBoo von mir.

Ich hoffe sehr, dass sich dieser Bezahlcode durchsetzt und in Zukunft auf jeder Rechnung zu finden sein wird! Dies wird blinden und sehenden Anwendern das Bezahlen von Rechnungen ganz erheblich erleichtern und gerade Blinden viel viel Arbeit, Frust und evtl. doppelt auszuführende Überweisungen ersparen (weil eine z. B. wegen Zifferndrehern oder unvollständiger Kontonummer zurückgebucht wird).

Und hiermit möchte ich einen Aufruf an alle Firmenmitentscheider, die diesen Blog lesen, starten, diesen Bezahlcode in Zukunft zu unterstützen! Es wird weitere Anwendungen geben, die diese Bezahlcodes werden auswerten können, nicht nur die iPhone-Anwendung, und Sie werden Ihren Kunden damit einen sehr großen Dienst erweisen, egal ob diese blind sind oder nicht!

Kategorien
Blindheit

Besuch in der AGO(Art Gallery of Ontario)

Während meines Aufenthalts in Toronto vom 13. bis 19. November besuchte ich unter anderem auch die Art Gallery of Ontario, welche unter anderem multisensorische Führungen für Menschen mit Behinderungen anbietet.

Zu so einer Tour brachen Jennison Asuncion und ich am Donnerstag, den 18.11., auf. Unsere Tour Guides Jessica und Doris nahmen uns im Foyer in Empfang und führten uns über die geschwungene Rampe in den 1. Stock. Allein diese Rampe war schon ein Erlebnis: Das Geländer war aus sehr reichem Holz gebaut, das sich schon sehr edel anfühlte. Die Rampe wechselt mehrmals die Richtung.

Die Führung begann mit einem Besuch der Sammlung von Ken Thomson. Wir bekamen Glasviolen in die Hand, die aus mehreren Schichten bestehen, wovon die innere Schicht bemalt ist. Die Gefäße enthalten Geruchsproben und wurden unter den reichen Orientalen zu ihren Hochzeiten wohl auch gern als Schnupffläschchen verwendet. 😉

Als nächstes besuchten wir die Canadian collection, eine Sammlung von Werken kanadischer Künstler. Wir beschäftigten uns hier mit einem Bild des Malers Lawren Harris, einem Gründungsmitglied der Group Of Seven. Das Bild entstand 1928 und zeigt eine Landschaft mit Bergen im prominenten Hintergrund, Wolken, die sich fast wie Klauen auf die Bergkuppen stürzen, und einem wellenbewegten Wasser, das direkt auf den Betrachter, der am Ufer steht, zuzuschwappen scheint. Als kleines Experiment hat die AGO zwei Relief-Reproduktionen des Bildes angefertigt, die die verschiedenen Elemente des Bildes mit verschiedenen Texturen darstellten. Wir wurden nach unserer Meinung gefragt und waren beide der Ansicht, dass ein Hybrid der beiden Reliefs das Optimum für eine taktile Reproduktion dieses Bildes darstellen würde.

Danach fühlten wir uns zwei Skulpturen von nach Kanada eingewanderten europäischen Bildhauerinnen an: Eine Skulptur einer trauernden Frau, die etwas abstrakter gehalten war, mit Namen „Grief„, also „Trauer“, und eine Skulptur eines Reiters, der im Einsatz ums Leben gekommen ist. Der Reiter gehört zu einem Typ sehr angesehener Kavallerie-Einheiten der 2. Hälfte des 19. Jahrhunderts in Nordamerika. Der Reiter, der über die Mähne des Pferdes gebeugt ist, der Schutzschild auf seiner linken Seite, die Konturen des Pferdes, alles sehr klar und wenig abstrakt herausgearbeitet.

Den Abschluss bildete ein Besuch der Galleria Italia mit Werken des Künstlers Giuseppe Penone. Der Baum, der in dieser Galerie ausgestellt ist, wurde so bearbeitet, dass die innersten Bestandteile des Baumes, seine früheste Vergangenheit, fühlbar werden und in der Gegenwart weiterleben können. An verschiedenen Stellen dieser Skulptur fühlt man die unterschiedlichen Lebensstadien dieses Baumes sehr gut.

In dieser Galleria Italia herrscht eine unglaubliche Akustik. Ich konnte mir nicht helfen und musste sie ein bisschen Testen. Einen kleinen Eindruck hiervon vermittelt vielleicht mein AudioBoo. Außerdem machten Tour Guide Jessica bzw. ein Security noch ein paar Fotos:

Die Handschuhe, die wir auf den Bildern tragen, sind zum Schutz der Kunstwerke vor direktem Hautkontakt. Die Handschuhe sind „gefühlsecht““ und nehmen so gut wie nichts von der Wahrnehmung.

Alles in allem war dieser Besuch ein sehr lohnender. Er war sehr vielfältig und gut strukturiert, es gab viel anzufassen und zu lernen. Es ist wünschenswert, wenn solche Touren auch von Museen in Europa viel öfter angeboten werden könnten!

Kategorien
Hexe

Erster Tag in Toronto

Ich befinde mich zur Zeit beruflich in Toronto, Ontario, Kanada. Am Samstag, 13.11., sind Hexe und ich über Frankfurt nach Toronto geflogen. Obwohl es diesmal im Flieger ziemlich eng war, haben wir den 8 1/2-stündigen Flug gut überstanden.

Die Einreise nach Kanada ist außerhalb der EU die angenehmste, die ich bisher erlebt habe. Dies ist, nach zwei Einreisen in Vancouver, mein ins gesamt dritter Kanada-Besuch, und jedes mal habe ich das Gefühl, bei Freunden zu Gast zu sein. Es findet eine Passkontrolle statt, man wechselt ein paar Worte mit dem jeweiligen Kontrolleur, aber mehr passiert auch nicht, wenn man nichts zu verzollen hat. Hexe und ich sind einfach so ins Land gelassen worden. Es finden keine erkennungsdienstlichen Maßnahmen wie Fingerabdrücke nehmen oder Fotografieren statt. Alle sind sehr freundlich und total entspannt.

Was gleich auffällt sind die zweisprachigen Ansagen in englisch und französisch. In Kanada sind beide Sprachen Amtssprachen, und obwohl Ontario primär englischsprachig ist, findet man doch überall an öffentlichen Orten zweisprachige Hinweisschilder o. ä. Mir wurde von meinem Kollegen David erzählt, dass in Quebek es Gebäude oder Plätze gibt, die stur nur auf französisch ausgezeichnet sind. Dies machte mich schmunzeln, gibt es doch auch genug Franzosen, die sich schon aus Prinzip weigern, englisch zu sprechen, obwohl sie es können. 😉

Die Taxifahrt zum Hotel Holiday Inn Bloor Yorkville verlief etwas schleppend. Das lag am dichten Verkehr: An diesem Abend spielte die Eishockey-Mannschaft Torontos gegen die Vancouvers, und die ganze Stadt war voller Fans. Und obwohl Toronto mit 3:5 verlor, gab es den ganzen Abend über überhaupt keinen Stress. Auch im Hotelrestaurant, in dem ich ein Abendessen zu mir nahm, lief der Fernseher, wo das Spiel übertragen wurde. Es herrschte überall eine gute Stimmung.

Das Hotelpersonal war von Anfang an sehr darauf bedacht, uns den Aufenthalt so angenehm wie möglich zu gestalten. Der Mitarbeiter, der mich eincheckte, bot sich sofort an, mit mir auf die Suche nach einer Grünfläche für Hexe zu gehen. Er begleitete mich auch zum auf der anderen Straßenseite gelegenen Supermarkt, um ein Hundefutter für sie zu kaufen. Er war selbst mal Hundebesitzer und konnte mir daher beratend zur Seite stehen. Hexe mag das Futter auch, und sie verträgt es ohne Probleme.

Die erste Nacht war ruhig. Ich schlief wie ein Stein, da ich im Flieger nicht geschlafen hatte.

Nach der morgendlichen Gassi-Runde gingen wir zum Frühstück. Wir saßen kaum, da gingen plötzlich die Lichter aus, die Musik verstummte, und man hörte nur noch das hektische Piepsen diverser Warm- oder Kühlhaltevorrichtungen, die anzeigten, dass ihnen der Lebenssaft ausgegangen war. 🙂 Der Stimmung tat dies keinen Abbruch, es wurden ein paar Kerzen aufgestellt, Kaffee gab es noch zur Genüge, und einige der Frühstücksköstlichkeiten konnten auch ohne funktionierenden Toaster o. ä. genossen werden.

Nach 45 Minuten war der Strom wieder da. Ich muss zugeben, dass ich doch sehr drüber schmunzeln musste. Bei meinem allerersten Kanadaaufenthalt in Whistler zum Mozilla Summit 2008 gab es in dem dortigen Hotel auch einen Stromausfall. Der Grund war damals ein Wäschereiwagen, der den Generator des Hotels k.o. gefahren hatte. Damals dauerte es 8 Stunden, bis die Stromversorgung wiederhergestellt war. Das einzige, was funktionierte, war das WLAN, das über das Notstromaggregat lief. Hinzu kam, dass einen Tag vorher ein massiver Erdrutsch die direkte Route nach Vancouver blockiert hatte und bis zu unserem Konferenzende nicht wieder freigegeben werden könne. Aber wir konnten der ganzen Welt von unserer Lage berichten! 😉

Den restlichen Vormittag verbrachten Hexe und ich gemütlich im Zimmer. Ich twitterte, ging meine Mails durch, und Hexe schlief. Die Kleine war von der Reise immer noch ziemlich platt.

Nachmittags trafen David und ich uns mit Aaron Leventhal, der zufällig auch in Toronto war, und verbrachten den Nachmittag mit Fachsimpeln, uns gegenseitig über unsere Leben auf den neuesten Stand bringend usw.

Den Abend ließen wir gemütlich bei einem Kaffee in der Hotelbar ausklingen.

Heute ist Montag, und es steht mein erster Besuch im Mozilla-Büro in Toronto an. Das Büro ist nur 5 Gehminuten vom Hotel entfernt, und ich bin schon sehr gespannt!