eclipse RCP-Applikationen einfach barrierefrei machen

Einfach barrierefrei machen? Das wäre zumindest die Vision.

Im Rahmen meiner Bachelor-Arbeit, für welche bereits der «Empfehlungskatalog für barrierefreie Desktop-Applikationen» ausgearbeitet wurde, ging es im zweiten Teil um die technische Umsetzung dieser Empfehlungen im Application-Framework eclipse RCP.

Gerade für Accessibility im Zusammenhang mit eclipse RCP gibt es kaum öffentlich zugängliche Dokumentationen. So musste zuerst durch eine intensive Suche und viel Trial & Error Klarheit geschaffen werden, welche technischen Möglichkeiten es gibt. Möglichkeiten um den Screenreader JAWS sprechen zu lassen, Wege um eine gute Navigationsfähigkeit zu erzeugen. Eine einfache, inhaltsleere Proof-of-Concept-Applikation diente dabei als Spielwiese und Test-Bed.

Die Massnahmen zur Erzeugung von Barrierefreiheit sollten möglichst sanft in eine bestehende Applikation eingebunden werden können. Daher wurde ein Modul entwickelt, welches in RCP-Applikationen implementiert werden kann: Das Modul regelt das Setzen von Texten, die vom Screenreader gelesen werden, und strukturiert die Tastatur-Navigation – zwei zentrale Funktionen für Barrierefreiheit.

In der Proof-of-Concept funktioniert das Modul gut. Umso genauer die Struktur der Applikation beschrieben werden kann, desto besser kann das Modul seine Fähigkeiten ausüben. Die Implementation des Moduls in beook, einer RCP-Applikation für digitale Lehrmittel, zeigte, dass die Applikation unbedingt technischen Finessen entsprechen muss, damit das Modul funktionieren kann. Um mit der vorhandenen Dynamik einer Applikation umgehen zu können, muss aber auch das Modul noch weiterentwickelt werden, um noch generischer Möglichkeiten abdecken können.

Das Modul ist somit noch kein Wundermittel für die einfache Erzeugung von Barrierefreiheit. Aber ein Baustein dazu.

Quellcode auf GitHub bereit

Für alle Programmierer, Entwickler und Entdecker steht auf GitHub der gesamte Quellcode der Proof-of-Concept-Applikation wie auch des Accessible Moduls bereit. Ebenso kann ein Zip mit der lauffähigen Proof-of-Conept-Applikation heruntergeladen werden. Das Git-Repository finden Sie hier: github.com/chrissharkman/accessibility

Bis das Modul in beook definitiv zur Anwendung kommt, müssen noch einige Hürden übersprungen werden. Und damit wäre es noch nicht erledigt, damit wäre erst eine minimale Barrierefreiheit erreicht. Die Vision, eine komplett barrierefreie Applikation für digitale Lehrmittel zu haben, bleibt bestehen.

Die komplette Bachelor-Arbeit «Accessibility für digitale Lehrmittel – Barrierefreiheit erhöhen in eclipse-RCP-Applikationen» wie auch die Vorarbeit «Blind am Computer» können unter tb.chrissharkman.ch heruntergeladen werden.

Erste Erfahrungen mit der Apple Watch

Die Möglichkeiten einer Smartwatch haben mich als technikbegeisterten Menschen schon länger neugierig gemacht. Leider gab es aber bis jetzt kein Modell, das auch nur annähernd zugänglich war.

Als die Apple Watch angekündigt wurde, habe ich natürlich viel Hoffnung in das Produkt gesetzt, denn bekanntlich sind die neueren Produkte von Apple mittels VoiceOver für Blinde bedienbar. Ich habe also Ende Mai meine Bestellung aufgegeben und trage meine Apple-Uhr nun seit dem 17. Juni am Handgelenk.

Die Uhr fühlt sich hardwaremässig gut verarbeitet an, und auch das Sportarmband liegt angenehm auf der Haut. Die drei Bedienelemente  sind gross genug und können gut erreicht werden.

Ein Blick ins Online-Benutzerhandbuch verrät, dass VoiceOver bereits beim Konfigurieren der Uhr benutzt werden kann. Die Einrichtung ist ziemlich einfach und geht schnell von der Hand. Nach etwa zehn Minuten war meine Uhr einsatzbereit.

So, nun aber genug Allgemeines. Bestimmt fragt Ihr euch nun, was die Uhr denn konkret “bringt”.
Aufnahme von Daniele mit der Apple Watch am linken Handgelenk.
Grundsätzlich ist es schwierig, einen einzelnen konkreten Anwendungsfall zu nennen, denn es sind viele subtile kleine Erleichterungen, die mir das Gefühl einer zusätzlichen Hilfe vermitteln.

  • Bin ich unterwegs und mein Telefon klingelt, drücke ich kurz auf die Krone,  wische über den Bildschirm und VoiceOver sagt mir, wer anruft. Das ist wesentlich bequemer, als das Handy in die Hand nehmen zu müssen. Ausserdem wird das Risiko, dass das iPhone aus der Hand fällt, minimiert.
  • Befinde ich mich an einer Bushaltestelle, kann ich mir mittels der  Wemlin-App von der Uhr sagen lassen, wann der nächste Bus einfährt.
  • Möchte ich wissen, ob eine Bar in der Nähe ist, kann ich die App Foursquare auf der Uhr fragen, und ich sehe, ob zumindest in unmittelbarer Nähe eine solche zu finden ist.

Bestimmt denkt Ihr nun, dass sich das alles toll anhört. Ja, ist es auch.

Leider gibt es aber doch ein paar nervige Umstände, die Apple dringend verbessern muss.

  • Das grösste Problem sind die unheimlich langen Ladezeiten. Es kann nicht sein, dass ich  deutlich länger auf eine Information  warten muss, als wenn ich das iPhone in die Hand nähme.
  • Bei langen Mails, gibt es für VoiceOver keinen Befehl, um alles vom Anfang bis zum Ende lesen zu können.
  • Um den Bildschirmvorhang zu aktivieren, muss ich gezielt die
    Einstellungen aufrufen; es gibt dafür keine dedizierte Geste.
  • Man muss oft probieren und raten, wo sich mittels Force-Touch eine zusätzliche Aktion auslösen lässt.

Fazit

Im Allgemeinen hat Apple mit der Watch gezeigt, dass das Produkt durchaus Potential hat. Gerade für Sehbehinderte wäre ein rascher Zugriff auf wichtige Informationen am Handgelenk sicherlich interessant. An den Ladezeiten muss aber noch dringend geschraubt werden. Zurzeit fehlen überdies noch Apple Watch – Optimierungen von nützlichen Apps wie beispielsweise jene der SBB.

 

 

Empfehlungskatalog für barrierefreie Desktop-Applikationen

Rahmen der Verwendung
Dieser Empfehlungskatalog enthält konzeptionelle Grundelemente, welche zum Erstellen von barrierefreien und für Screenreader lesbaren Desktop-Applikationen wichtig sind. Zu jedem Punkt sind die geplanten Umsetzungen für die beook-Applikation aufgeführt, die bei der Weiterentwicklung von beook zu einer barrierefreien rcp-Applikation befolgt werden sollten.

Die hier aufgeführten Empfehlungen sind über Programmgrenzen hinweg gültig. Für Programme, die strukturell ähnlich sind wie beook, sind sie natürlich einfacher zu befolgen. Für andersartige Applikationen können sie aber trotzdem beherzt und abgeleitet werden. Das jeweils dazu aufgeführte Beispiel von beook soll die Empfehlung in einem konkreten Kontext zeigen. Daher soll dieser Empfehlungskatalog nicht eine reine Aufzählung von möglichen Tastenbefehlen sein, sondern das Konzept hinter der Bedienung beleuchten. Die technische Umsetzung, die je nach Programmiersprache unterschiedlich aussehen kann, wird nicht beschrieben.

Die Empfehlungen versuchen, existierende Konventionen zu berücksichtigen und spiegeln die Resultate der vorhergehenden Analyse. Ein Anspruch auf Vollständigkeit für alle erdenklichen Programmtypen und -strukturen existiert nicht, aber die Bedürfnisse für die bereits bestehende Applikation beook werden abgedeckt.

Empfehlungen

Laden der Applikation

Ladezeiten können kürzer oder länger sein – je nach Gerät und Applikation. Während dieser Zeit sollte trotz optisch sichtbarem Ladebildschirm ein akustisches Signal oder eine Sprachnachricht diesen Zustand mitteilen. Dies kann eine Prozentangabe sein, es kann aber auch eine Tonfolge oder ein anhaltendes Geräusch sein. Der einfachste Weg dazu ist, die Windows-­System­töne zu unterstützen, damit die Tongebung dem Benutzer bereits bekannt ist – und automatisch bereits ein- beziehungsweise ausgeschaltet ist.

Der Eintritt in das Programm wird in der Regel vom Screenreader angekündet, in dem die Titelleiste des geöffneten Programms gelesen wird. Somit ist das Ende des Ladeprozess auch erkennbar.

Der beook-Ladebildschirm plus ein Lautsprechersymbol.

Startbildschirm von beook: Akustisch sollte mitgeteilt werden, dass der Ladeprozess in Gang ist.

Umsetzung in beook

Für beook ist die Sprachausgabe des angezeigten Textes geplant. So wird der Benutzer informiert, was passiert. Zusätzlich wird beim Programmstart die Windows-Systemsound-Ausgabe unterstützt. Dadurch ist sichergestellt, dass bereits beim ersten Programmstart die Einstellungen für blinde und visuell eingeschränkte Personen stimmen und auch der «normal» sehende Benutzer nicht gestört wird.

Grundstellung

Um sich immer wieder zurechtfinden zu können, ist eine immer gleiche Grundstellung nötig. Wie ein Desktop mit geschlossenem Start-Menü oder Microsoft Word mit dem blinkenden Cursor im Text. Diese Grundstellung muss zu jeder Zeit über [esc] erreicht werden können. [esc]-Befehle nach dem Erreichen der Grundposition haben keine navigierende Wirkung mehr. Ein akustisches Signal kann aber melden, dass man die Grundposition erreicht hat.

Grundsätzlich soll nach dem Programmstart diese Grundstellung eingenommen sein.

Die Frage, welches bei einem vielseitigen Programm die Grundstellung ist, kann etwas schwieriger sein. Denken Sie dabei an Ihre Benutzer und was sie erwarten, wo deren «Landmark» in Ihrem Programm sein kann – und nicht unbedingt an das, was in erster Linie logisch ist.

Umsetzung in beook
Bei beook ist die Empfehlung für die Grundstellung folgendes: Fokus auf dem Portal-Button in der Seitenleiste. Dabei kann der angezeigte Inhalt unterschiedlich sein:

Wenn man sich aus einer Anbieter-Ansicht des Portals «escapen» will, dann wird rechts in der Grundstellung immer noch die Anbieter-Ansicht angezeigt, der Fokus wird aber auf den Portal-Button gelegt.

beook-Benutzeroberfläche des Portalteils, auf der mit einem Pfeil eingezeichnet ist, wie mit Escape der Fokus zurück zur Grundstellung gebracht wird.

Der [esc]-Sprung von einem fokussierten Register in der Anbieter-Detail-Ansicht führt den Fokus direkt auf den Portal-Button der Seitenleiste.

Der Wechsel von einer Anbieter-Ansicht auf die Anbieter-Übersicht stellt keinen Niveau-Sprung dar, sondern einen Funktionsaufruf. Dies wurde mit dem Ansatz konzipiert, dass ein Benutzer in der Regel seinen «Hauptanbieter» hat.

Wenn man sich aus einem Dialog zum Bearbeiten von Markierungen im Leseteil «escapen» will, dann wird rechts in der Grundstellung noch das offene Buch im zuletzt besuchten Kapitel angezeigt.

Zwei beook-Benutzeroberflächen des Inhaltsteils, auf denen mit Pfeilen eingezeichnet ist, wie mit Escape der Fokus zurück zur Grundstellung gebracht wird.

Die [esc]-Sprünge von einem fokussierten Dialogfenster, in diesem Fall die Farbauswahl für die Markierung, zurück auf die Schaltfläche des Werkzeugs in der Lesebereich-Toolbar und zuletzt auf den Portal-Button der Seitenleiste.

Warum diese Wahl? Der Portal-Button ist ein konstanter Ort, von dem aus man sich neu orientieren kann. Im gleichen Bereich befindet sich zudem auch die Buchauswahl. Eine zusätzliche Information via Sprachausgabe wäre auch noch möglich, um den Benutzer aufzuklären, ob er nun das Portal  oder den Lesebereich vor sich hat.

Tab-Navigation von Element zu Element

Eine zweistufige Tab-Navigation kann für Klarheit und Komfort in der Navigation sorgen.

Generell was die Navigation angeht: Bloss nicht das Rad neu erfinden! In Anlehnung an aria-Regions im Web und die Bereichswechsel in Microsoft Word kann man die Navigation in einer Applikation von Bereich zu Bereich mit [ctrl + tab] regeln. So springt man von Zone zu Zone. Beim Landen in einem neuen Bereich informiert die Sprachausgabe, in welchem man sich befindet.

Innerhalb jedes Bereiches wird dann mit [tab] von Element zu Element gesprungen – ohne Gefahr zu laufen, aus der gewünschten Zone unbemerkt wieder heraus zu springen. Dies gilt auch für Symbolleisten und Registerkarten, bei denen nebst mit [tab] auch eine Navigation mit den Pfeiltasten möglich sein sollte.

Das Auswählen eines Elements, das Aktivieren einer Schaltfläche, wird mit [enter] gemacht. Alternativ die [leertaste] für die identische Funktion anzubieten stiftet mehr Verwirrung als es Komfort schafft.

Umsetzung Navigation in beook
In beook sieht eine zweistufige Navigation so aus, dass mit [ctrl + tab] in der Lesereihenfolge von Bereich zu Bereich gesprungen wird. Im Inhaltsbereich ergibt sich daraus folgende Reihenfolge: 1) Seitenleiste, 2) Übersichtsspalten, 3) Inhaltsverzeichnis, 4) Lesebereich-Toolbar, 5) Lesebereich

Die beook-Benutzeroberfläche vom Inhaltsteil mit fünf gelb markierten Bereichen.

Die Tab-Reihenfolge über die Bereiche des Inhalts und des Lesebereichs, über die mit [ctrl + tab] navigiert wird: 1) Seitenleiste, 2) Übersichtsspalten, 3) Inhaltsverzeichnis, 4) Lesebereich-Toolbar, 5) Lesebereich

Jetzt könnte man bemängeln, dass der Lesebereich, der ja das Hauptelement des e-book-Readers von beook ist, erst als letzter Bereich in der Tab-Reihenfolge den Fokus bekommt. Dem können drei Elemente entgegengehalten werden: Über die Kombination [shift + ctrl + tab] kann die Richtung des Durchlaufs geändert werden. Also ist der Lesebereich nur einen Shortcut von der Grundstellung entfernt. Zudem entspricht die Reihenfolge für die Konsultation einer neuen, bestimmten Stelle bis auf den in diesem Fall überflüssigen Sprung zur Lesebereich-Toolbar sehr gut. Und drittens ist die Reihenfolge aufgrund der Programmstruktur für jemand Sehenden logisch, also so zu erwarten.

Die Tab-Reihenfolge für den Portal-Bereich ist sehr ähnlich.

Die beook-Benutzeroberfläche vom Portalteil mit fünf gelb markierten Bereichen.

Die Tab-Reihenfolge über die Bereiche des Potrals, über die mit [ctrl + tab] navigiert wird: 1) Seitenleiste, 2) Portal-Toolbar, 3) Produktverzeichnis, 4) Produkttitel, 5) Produktdetails 

Menüleiste

Die Menüleiste bietet für Benutzer die Möglichkeit, sich einen raschen Überblick über die Funktionen des Programms zu verschaffen – ähnlich einer Sitemap einer Webseite. Es ist eine gewohnte Art, über die Menüleiste an alle Befehle zu kommen. Für Power-User ist die Menüleiste auch der Ort, an dem Shortcuts nachgeschlagen werden können.

Umsetzung in beook

beook ist grundsätzlich auf die Touch-Bedienung ausgelegt. Dadurch wurden nur eine kleine Anzahl Funktionen in der Menüleiste platziert, was für die Barrierefreiheit wie auch menü-gewohnte Benutzer kein Vorteil ist. Eine generelle Ansteuerung von Funktionen, Ansichten und Einstellungen über die Menüleiste ist in betracht zu ziehen – auch wenn dies nicht unbedingt notwendig ist. Die Menüleiste sollte aber, sodenn diese Strategie gewählt wird, die Möglichkeiten sinnvoll und komplett abbilden.

Benennen von Buttons und Bereichen

Die grösste Schwierigkeit haben Screenreader mit Schaltern, die nur ein Bild aufweisen aber keinen Textinhalt haben. Bei denen ist es für Screenreader unmöglich, die eigentliche Funktion zu kennen, die durch das Drücken des Buttons aufgerufen wird.

Buttons müssen unbedingt via Tooltip oder andere Label-Möglichkeiten beschrieben werden, selbst wenn sie Text enthalten. Möglichst klare und eindeutige Beschreibungen sind wichtig. Im beschreibenden Text sollte zudem ein allfälliger Accesskey oder Shortcut erwähnt werden.

Auch Bereiche und Dropdownlisten sollten Labels oder Namen tragen, damit beim Durchtabben klar ist, wo man sich befindet. Geben Sie in der Beschreibung eines Bereichs auch an, wie man darin navigiert (ob mit [tab], den Pfeiltasten, etc.).

Umsetzung für beook

Als Bereichsbezeichnungen werden die unter «Tab-Navigation von Element zu Element» aufgeführten Bezeichnungen verwendet. Zusätzlich sollte vom Screenreader gelesen werden können, ob es sich beim Bereich um eine Schalter-Liste, einen Listeninhalt oder einen Textbereich handelt und wie darin navigiert werden kann.

Listen

Für Listen mit mehreren Hierarchiestufen ist eine Funktionsweise wie bei den Listen vom Windows Explorer anzustreben. Diese sind sehr gut für Screenreader zugänglich.

Strukturansicht des Windows Explorers: Eine Liste mit mehreren Niveaus.

Windows-Explorer-Liste mit mehreren Hierarchien

Die Bezeichnung der abgebildeten Liste lautet «Struktur­ansicht» und es wird bei jedem Element erwähnt, ob ein Element offen ist und wie viele Elemente es enthält.

Bei normalen Listen mit nur einer Hierarchiestufe ist es gut, wenn der Benutzer am Ende der Liste angelangt und dabei ein akustisches Signal ertönt. So weiss der Benutzer, wann er am Ende der Liste angelangt ist – was bei langen Listen sehr praktisch ist. Sollte er das gesuchte Element verpasst haben, dient es dem Benutzer, wenn der Fokus nach dem letzten Element bei einem erneuten Drücken der gleichen Taste wieder auf das Erste springt. Damit entfällt ein mühsames «Zurück-Navigieren». Und auch der generellen Orientierung ist dies zuträglich, Listen nicht gezwungenermassen vorwärts und rückwärts durchlaufen zu müssen.

Durch die Listen wird mit den Pfeiltasten navigiert.

Umsetzung in beook

Die Strukturansicht im Inhaltsverzeichnis bringt beste Voraussetzungen mit: Die Funktionsweise ist bereits analog dem beschriebenen Verhalten von Windows-Explorer Listen mit mehreren Hierarchien. Zusätzlich muss von der Sprachausgabe mitgeteilt werden, ob es sich beim Inhalt um eine eigene Seite oder um eine bestehende Seite handelt. Diese Unterscheidung ist derzeit nur optisch – durch eine Blaufärbung des Textes – vorhanden.

Für Listen, wie sie als Resultat in den Übersichtsspalten «Lesezeichen», «Markierungen/Notizen» und «Suche» vorkommen, soll ein «Rundlauf» implementiert werden, damit der Fokus vom letzten Element in der Liste mit erneutem Drücken der Pfeiltaste wieder zum ersten springt. Mit einem akustischen Signal sollte das Angelangen am Ende der Liste angegeben werden. Dies kann ein «Bing» sein oder eine Sprachausgabe «Ende der Liste». Um das akustische Signal besser vom Gelesenen abzuheben, wäre einem textlosen Ton den Vorzug zu geben. Optimal wäre die Einbindung eines Windows-Systemsounds.

beook Inhaltsspalte mit geöffneter Übersicht der Notizen: Vier gelbe Notizzettel werden in der Liste angezeigt, wovon die zweite selektiert ist.

Übersichtsspalte «Notizen» im Inhaltsverzeichnis-Bereich: Eine Auflistung der gelben Notizzettel, der aktuelle Fokus liegt auf dem zweiten Eintrag.

Textlicher Inhalt

Bei dem in der Analyse behandelten Programm beook ist der textliche Inhalt zentral. Die Hauptfunktion ist schliesslich das bequeme Lesen von digitalen Lehrmitteln. Daneben gibt es natürlich allerlei Applikationen, deren Kern aus Formularfeldern, Listen, Menüs und generell aus wenig Text bestehen. Doch auch diese Programme haben textliche Inhalte, zu Beispiel bei Hilfe-Texten, Anleitungen und Dokumentationen oder auch bei Texteditoren, die für grössere Textmengen gedacht sind.

Bei all diesen Elementen empfiehlt es sich, eine Navigationsfähigkeit ähnlich einem Browser zu schaffen: Das Springen von Titel zu Titel, Listen zu Listen, Grafik zu Grafik etc. sollte über konventionelle Accesskeys möglich sein. Optimal ist es, wenn Screenreader die semantische Struktur des Textinhalts erfassen können und nicht nur mit optischen Auszeichnungen wie zum Beispiel «fett», «grösser» oder «kleiner» gearbeitet wird.

Gerade für Hilfe-Texte und Anleitungen, die oft nicht direkt im Layout der eigentlichen Applikation angezeigt werden, eignen sich html-basierte Dokumente gut. Mit einem einfachen, geöffneten HTML-Dokument mit dem Standard-Browser des Benutzers kann vermieden werden, auf eine nicht barrierefreie Webseite weitergeleitet zu werden, wo sich ein Benutzer verlieren kann.

Umsetzung in beook

Der Inhalt im Textbereich hat eine komplette html-Struktur, die in einem integrierten Browser angezeigt wird. Dadurch kann mit dem Screenreader wie gewohnt mit den Accesskeys im Inhalt navigiert werden.

Bei weiteren Textinhalten sollen die derzeit verschiedenen Typen von Textinhalten vereinheitlicht werden. So sollen die Informationen des Menüs «Über» genau gleich wie der lokal vorhandene «Hilfe-Text» und andere Erklärungen als strukturell sauberes HTML im integrierten Browser angezeigt werden.

Der Link zum vorhandenen Online-Support-Portal soll ein möglichst direkter Link sein – und nicht auf der Willkommensseite von beook.ch landen.

Texteditor

Verwendete Texteditoren für längere Texte, die eine Struktur haben müssen, sollten grundsätzlich das Verwenden von Stilvorlagen fördern. Dank sauber erstellten Stilvorlagen kann direkt eine korrekte semantische Struktur entstehen. Dabei trägt schon nur das korrekte Auszeichnen von Titelhierarchien, Listen und Links viel zur Barrierefreiheit bei.

Umsetzung in beook

In beook wäre eine Anpassung des derzeit vorhandenen Texteditors zum Erstellen von neuen Seiten anzustreben. Der eingebettete CK­editor kann über die Tastatur nicht bedient werden. Optimal wäre eine barrierefreie Bedienung des Programms im Programm. Realistischer ist wohl eine über Shortcuts definierte Bedienung, die während dem Bearbeiten im Eingabefeld die wichtigsten Menüs aufrufen kann (u.a. Formatvorlagen, Liste, Symbole einfügen).

 

Eigene Seite in beook mit offenem Texteditor.

Der geöffnete CK­editor zum Erstellen einer eigenen Seite, mit geöffneter Formatvorlagen-Dropdownliste

Bei implementierten, externen Opensource-Produkten ist die Abhängigkeit von deren Entwicklung stets ein Knackpunkt.

Bei einer Anpassung der eigenen Seite-Funktionalität wäre zusätzlich Folgendes in Betracht zu ziehen: Ist eine eigene Seite erst einmal geschrieben, sollte diese als «flaches» HTML gezeigt werden, ohne in einem Eingabefeld integriert zu sein. Nur so kann gewohnt – wie in bestehenden Seiten im Leseteil auch – in den eigenen Seiten mit Browser-Accesskeys navigiert werden, ohne Gefahr den Inhalt ungewollt zu verändern.

Eigene Seite mit geschlossenem Texteditor.
Die eigene Seite mit geschlossenem Editor und dem Inhaltstext, der sich in einem riesigen Eingabefeld befindet.

Shortcuts

Tastenkombinationen erlauben es zwar, dass Power-User schnell an Ihre Menüs kommen. Betreffend «Barrierefreiheit» spielen sie aber eine sekundäre Rolle: Als oberstes Gebot gilt: Alle Funktionen müssen mit der normalen Tastaturnavigation erreichbar sein. Es gilt nicht zu vergessen, dass blinde und sehbehinderte Benutzer bereits eine gewisse Anzahl an Shortcuts kennen müssen, um den jeweiligen Screenreader zu bedienen. Bekannte Shortcuts wie [ctrl + c], [ctrl + v] und [ctrl + o] zu implementieren ist gängig, die dann auch die erwarteten Befehle Kopieren, Einfügen und Öffnen ausführen.

Sollten dennoch «neue» Shortcuts gesetzt werden, muss sichergestellt sein, dass ein Menü-Punkt oder Button zum Aufrufen der gleichen Funktion existiert, am besten mit Sprachausgabe der zugewiesenen Tastenkombination. Eine Funktion darf nicht exklusiv über den Shortcut erreicht werden. Es wird abgeraten, die Beschreibung der definierten Tastenkombinationen einfach in ein «Hilfe-Menü» oder in ein «Manual» auszulagern. Sie müssen dort beschrieben sein, wo sie gebraucht werden!

Umsetzung in beook

Um die Benutzerfreundlichkeit zu erhöhen, sind für die Navigation in den Übersichtsspalten Shortcuts vorgesehen. Wechsel zwischen den Übersichtsspalten sind bei der intensiven Nutzung von beook eine häufige Handlung. So kann ein ständiges Navigieren zum Bereich der Übersichtsspalten umgangen werden.

Ansonsten sind keine weiteren programmspezifischen Shortcuts vorgesehen, ausser sie sind bereits klare Konvention, wie zum Beispiel [alt + F4] zum Beenden des Programms.

Accesskeys

Accesskeys dienen erfahrenen Benutzern zum effizienteren Arbeiten und können in einer geschlossenen Umgebung eines Programms verwendet werden. Wie Shortcuts dürfen auch Accesskeys nie der einzige Weg sein, um eine Funktion auszuführen oder ein Menü zu wählen. Accesskeys werden ergänzend eingesetzt. Bei Menü-Punkten, Schaltflächen und Registerkarten sollten vorhandene Access­keys beim Darübernavigieren von der Sprachausgabe erwähnt werden.

Bei der Programmkonzeption sollte die Internationalisierung dieser Accesskeys berücksichtigt werden, damit diese auch möglichst Eingängig sind für die Beutzer: So macht zum Beispiel [l] für «Lesezeichen» auf Deutsch Sinn, ist aber für die englische Version unpassend, da Lesezeichen «bookmarks» heisst.

Wenn lange, textliche Inhalte in der Applikation vorkommen, kann eine Browser-Ähnliche Accesskey-Implementation in Erwägung gezogen werden – so denn dieser Textinhalt nicht bereits in einem implementierten Browser angezeigt wird. Doch Achtung: gerade wenn dies der Fall ist, sind eigene Accesskeys im Kontext der textlichen Inhalte fast nicht mehr möglich, ohne Konflikte zu schaffen.

Umsetzung in beook

Für alle Menü-Punkte in der Menü-Leiste werden klare, sprachangepasste Accesskeys gesetzt. Ebenso für die Register der Übersichtsspalten, die Schaltflächen der Lesebereich-Toolbar, die Schaltflächen in der Portal-Toolbar und die Register der Produktdetails. Zusätzlich sind zwei Accesskeys für die konstanten Elemente der Seitenleiste vorgesehen: [p] für Portal, [b] für Browser.

Funktionstasten

Als globale Art von Accesskeys werden oft die Funktionstasten verwendet – dies ist der Grund, warum sie hier ein separates Unterkapitel erhalten. Folgende Belegung ist empfohlen:

  • [F1] Hilfe aufrufen
  • [F3] Suche
  • [F4] Fenster schliessen (nicht Programm)
  • [F6] zwischen Unterfenstern beziehungsweise Tabs wechseln

Umsetzung in beook

Die Taste [F1] führt direkt zum Hilfetext, der auch über das Menü «Hilfe» aufgerufen werden kann. [F3] setzt den Cursor direkt in der Übersichtsspalte «Suche» in das Suchfeld. Die Suche ist somit auf die globalst-mögliche Suche eingeschränkt, welches die Suche in einem einzelnen Buch ist.

Kontextmenü

Kontextmenüs werden in der Regel über einen Rechtsklick der Maus aufgerufen und stehen immer in Bezug mit dem Ort des Klicks. Um der Tastatur-Navigation ebenfalls diese Möglichkeiten zu bieten, ist ein Weg über Menü-Punkte in der Menü-Leiste der logische Weg. So bleibt zum Beispiel ein selektierter Text ausgewählt, während man über [alt] in die Menü-Leiste einsteigt und dort die gewünschte Funktion aufruft.

Umsetzung in beook

Für das Kontextmenü des Lesebereichs wird in der Menü-Leiste ein neues Menü geschaffen und nimmt all die im Kontextmenü vorhandenen Punkte auf. Zusätzlich wird dieses mit der Funktion «Notiz einfügen» ergänzt.

Beenden der Applikation

Das Beenden der Applikation muss in jedem Fall über [alt + F4] möglich sein. Ein Menü-Punkt in der Menü-Leiste kann auch dazu dienen, ist jedoch nicht unbedingt nötig.

Umsetzung in beook

Die beook-Applikation hat diesen Standard-Befehl implementiert. Die Applikation schliesst sich über [alt + F4].

Accessibility-Feature: On/Off

Grundsätzlich sollte versucht werden Accessibility-Features so zu implementieren, dass sie für den normal sehenden Benutzer nicht auffallen. Wer sie aber sucht, soll sie auch finden. Denn auch ein «Normal-Benutzer» kann zum Beispiel von Shortcuts und Accesskeys profitieren.

Elemente, die zusätzlich zur Screenreader-Ausgabe hinzukommen, sollten in den Einstellungen an prominenter Stelle ein- beziehungsweise ausgeschaltet werden können. Dies weil zum Beispiel die Ausgabe von akustischen Signalen, die zusätzlich eingebaut werden, für «Normal-Benutzer» schnell störend wirken. Auch für den Wechsel von «sehr ausführlichen» auf «normale» Tool-Tipps oder Hilfs-Labels kann eine Einstellungsmöglichkeit sorgen.

Umsetzung in beook

Zweistufige Labels und Tooltips sind nicht vorgesehen. Dafür können im Einstellungsmenü die zusätzlichen, akustischen Hinweise ein- beziehungsweise ausgeschaltet werden – so denn diese nicht komplett über die Standard Windows-Systemsounds gelöst werden können.

Das Wichtigste: Selber ausprobieren!

Bevor Sie mit der Umsetzung einer barrierefreien Applikation beginnen, begeben Sie sich selbst in die Situation, ausschliesslich mit der Tastatur zu navigieren. Und dann steigern Sie das Erlebnis, in dem Sie einen Screenreader installieren und sich anschliessend eine Schlafmaske aufsetzen. Ausser natürlich, Sie gehören zu der beeindruckend hohen Anzahl blinder und visuell eingeschränkter Programmiererinnen und Programmierer, die es auf dieser Welt gibt – dann kennen Sie dies ja schon.

Erleben Sie selbst, was es heisst, wenn plötzlich kein Feedback kommt, wenn ein Programm für den Screenreader ein weisses Blatt ist. Oder wie Ihnen ein einfaches Interface plötzlich als «langer Text auf einer einzigen Zeile» doch kompliziert scheint. Und stellen Sie bald einmal fest, was stört.

Dabei ist klar, dass man durch eine stündige «Blind-Session» noch nicht zum Profi wird. Aber es hilft, Verständnis zu entwickeln um letztendlich ein (noch) besseres Resultat zu erschaffen.

Diese öffentliche Publikation ist im Rahmen der Bachelor-Arbeit von Christian Heimann entstanden. Anregungen, Feedbacks und Kritik zur Verbesserung dieses Empfehlungskatalogs sind sehr willkommen. Diese werden für den weiteren Verlauf der Bachelor-Arbeit auch bestmöglichst berücksichtigt. Bei Interesse an der vorangeganenen Analyse können Sie sich ebenfalls beim Autor melden: christian.heimann@ionesoft.ch

Die erwähnte Applikation beook kann kostenlos in der aktuellen, noch nicht barrierefreien Version heruntergeladen werden unter:
http://beook.ch

Einfach Surfen

insieme Schweiz, die Stiftung «Zugang für alle» und die Hochschule für Soziale Arbeit FHNW publizieren heute einen neuen, praxisrelevanten Leitfaden für Webprofis. «Einfach Surfen» leitet an, wie das Internet für Personen mit kognitiven Beeinträchtigungen barrie-refreier gestaltet wird.

Heutzutage ist ein Leben ohne Internet kaum mehr vorstellbar. Shoppen, Reisen buchen, sich informieren, Kulturelles… Immer mehr alltägliche Handlungen finden über das Internet statt. Trotzdem ist das Internet nicht für alle auf die gleiche Art und Weise zugänglich.

Personen mit spezifischen Bedürfnissen, z.B. Menschen mit einer geistiger Behinderung, mit Lern-, Konzentrations- oder Sprachschwierigkeiten sind mit unzähligen Barrieren konfron-tiert. Internationale Richtlinien zur barrierefreien Gestaltung von Internetangeboten wie die Web Content Accessibility Guidelines (WCAG) 2.0, berücksichtigen die Bedürfnisse von Men-schen mit kognitiven Beeinträchtigungen nur am Rande.

Der Leitfaden «Einfach Surfen» schliesst diese Lücke. Er präsentiert 14 Empfehlungen, um die Barrierefreiheit im Internet für Personen mit kognitiven Beeinträchtigungen zu verbessern.

EInfachSurfenBroschueren

Der Leitfaden kann unter www.insieme.ch (>Shop & Publikationen) in vier Sprachen bestellt werden. Die PDF-Versionen stehen www.einfachsurfen.ch zum Download zur Verfügung.

Entwicklung eines barrierefreien ePub3-Editors

Für Schüler mit besonderen Bedürfnissen genauso wichtig wie barrierefreie Schulbücher sind barrierefreie Unterlagen welche durch Lehrkräfte erstellt werden. Dazu gehören Hand-outs, insbesondere aber interaktive Arbeits-, Übungs- und Prüfungsblätter. Wünschenswert wäre, dass alle an Schulen eingesetzten Dokumente (immer auch) in demselben barrierefreien (elektronischen) Format vorliegen und mit denselben auf die spezifischen Bedürfnisse der einzelnen Schüler und Schülerinnen abgestimmten Lesesystemen gelesen und editiert werden können. Jegliche Lehr- und Lernmaterialien sollen «aus einem Guss» stammen.

Screenshot der Editor-Benutzeroberfläche

Um diese Lücke hat die Stiftung «Zugang für alle» in Zusammenarbeit mit dem blinden Informatiker Quentin Cosendey im Rahmen seiner Masterarbeit (EPFL) einen Editor zur Erstellung barrierefreier interaktiver Dokumente in EPUB3 entwickelt. Er soll Lehrkräften auf allen Bildungsstufen als Open-Source Software frei zur Verfügung stehen und ihnen erlauben ihre Arbeits- und Übungsblätter und insbesondere Prüfungen barrierefrei zu erstellen.

Heute werden solche meist in gedruckter Form verteilt. Die zugrundeliegenden elektronischen Dokumente sind meist PDF- oder Word-Dokumente. Beide Formate eignen sich schlecht als barrierefreie Alternativen für Mitschüler mit besonderem Bildungsbedarf. In beiden Fällen ist viel Wissen über Barrierefreiheit notwendig um geeignete Dokumente zu erstellen. Interaktive PDFs benötigen weitere zusätzliche Fähigkeiten.

Um die Lehrpersonen bei der Erstellung barrierefreier Inhalte zu unterstützen, verfügt der Editor über eine Benutzerführung die den Anwender sachte an das Thema Barrierefreiheit heranführt und ihn auf mögliche Stolpersteine aufmerksam macht.

Stand der Entwicklung

Der Anforderungskatalog an die Applikation wurde im Rahmen der Masterarbeit weitgehend umgesetzt. Unsere Erwartungen an die Qualität der Umsetzung wurde bei Weitem übertroffen. Interne und externe Evaluationen haben jedoch gezeigt, dass für die weitere Verbreitung des Editors unter Lehrpersonen noch viel Arbeit geleistet werden muss. Dies hat verschiedene Gründe:

  1. Die Entwicklung einer Software zur Erstellung von Dokumenten für Menschen, welche sich an moderne Textverarbeitungssoftware und deren Möglichkeiten gewöhnt sind, ist ein grosses Unterfangen und in sechs Monaten durch eine Einzelperson kaum zu bewältigen.
  2. Quentin Cosendey ist blind. Dies garantiert eine fundierte Barrierefreiheit des Editors selbst sowie der erstellten Dokumente, hat aber den Nachteil, dass die Usability für Sehende und die visuelle Gestaltung der Benutzeroberfläche bislang vernachlässigt wurden und in der Folge vollständig überarbeitet werden müssen.
  3. Eine ansprechende visuelle Benutzeroberfläche ist unumgänglich um eine grössere Studie zu Benutzererfahrungen bei Lehrpersonen durchzuführen um weitere Erkenntnisse zur Weiterentwicklung zu gewinnen.

Weiterentwicklung und das weitere Vorgehen

Es ist uns ein grosses Anliegen, das noch brach liegende Potenzial des ePub3-Editors auszuschöpfen. Er hat das Potenzial die noch offene Lücke zwischen der fehlenden barrierefreien Schulung-Unterlagen im System integrative Schule zu schliessen.

Deshalb ersuchen wir Sie für eine zweite Phase des Projekts um Ihre aktive und finanzielle Unterstützung. Wir freuen uns über Ihre Kontaktaufnahme unter info@access-for-all.ch.

Unser Dank

ebgb-300x128Für die finanzielle Unterstützung des Projekts bedanken wir uns herzlich beim Eidgenössischen Büro zur Gleichstellung von Menschen mit Behinderungen.

Back in Jail

So, nach einer Woche habe ich nun die Kraft gefasst, um öffentlich darüber zu schreiben. Ich habe mein Android-Experiment abgebrochen und bin nach fast 9 Monaten Android-Nutzung wieder auf iOS zurückgekehrt. Es mag sein, dass sich einige von Euch fragen warum? Ich versuche nachfolgend einige Ereignisse aufzulisten, die mich zu diesem Schritt gedrängt haben: Obwohl Android durch seine wenig eingeschränkte Nutzung für Apps viele Vorteile bietet, sind Einschränkungen in der Barrierefreiheit vorhanden. Theoretisch funktioniert zwar alles, aber praktisch sind es die kleinen unzuverlässigen Sachen, die das Ganze zu einer nervenaufreibenden Angelegenheit machen. Das automatische Scrollen von Inhalten funktioniert immer sehr unzuverlässig. Die Tastatur bietet nur einen Eingabemodus, man muss über die Buchstaben fahren und beim richtigen den Finger anheben. Gerade wenn man sich bewegt, fällt das Schreiben nicht leicht, dazu kommt, dass die Touchscreens von Android-Geräten nicht immer ganz zuverlässig reagieren. Mit der  Android Version 5.0.1 kam ein Bug hinzu, der meinen Bogen deutlich überspannte: Es ist seit diesem Update nicht mehr möglich auf sämtlichen Geräten eine Uhrzeit einzustellen. In sämtlichen Apps, die eine Uhrzeitauswahlkomponente enthalten, ist keine Auswahl einer Uhrzeit mit Talkback möglich.

Ich stand relativ bald vor der Wahl, ein Handy zu haben ohne die Möglichkeit, einen Wecker oder einen Kalender zu benutzen oder wieder zu iOS zurückzukehren. Dieses hat zwar auch mehr Bugs als auch schon, aber es ermöglicht immerhin, schnell und zuverlässig Tastatureingaben zu erledigen sowie Datum und Uhrzeit in sämtlichen Apps auszuwählen.

Fazit

Sicherlich muss ich wieder Einschränkungen in der Nutzung des Gerätes hinnehmen. Ich glaube aber, dass eine zuverlässige Bedienung der Funktionen, die für das Gerät vorgesehen sind, wichtiger ist als eine uneingeschränkte Nutzung. Im Grunde trifft dies ja auch auf uns zu. Für gewisse Leute ist vielleicht eine Gefangenschaft auch die bessere Option, als  irgendwo auf der Strasse im Winter zu erfrieren.

Die einfache Bedienung von Nas wird zur Barriere

Einleitung

Weboberfläche der Synology Rack Station

In meiner Freizeit konsumiere ich verschiedene multimediale Inhalte. Musik macht davon einen grossen Teil aus. Da meine CD-Sammlung immer mehr digitalisiert wird, habe ich nach einer Möglichkeit gesucht, diese Inhalte zentral an einem Ort zu lagern, um anschliessend einfach mit den verschiedensten multimediafähigen Geräten darauf zuzugreifen. Das Digitalisieren der Sammlung bietet für mich als Blinden einige Vorzüge. Es ist z.B. möglich, selbständig und speditiv einen bestimmten Titel abzuspielen, ohne im Regal nach der passenden CD zu suchen und den Track auf der passenden Disc anzuwählen. Da in meiner Wohnung in zwei Räumen ein Multiroom-System von Sonos steht, kann ich beide Räume mit anderen Inhalten meiner Sammlung beliefern. All diese Gründe haben mich dazu bewegt, mich nach einer energiesparenden Lösung umzusehen, welche meine Inhalte zentralisiert meinem Netzwerk zur Verfügung stellt.

Wahl des Geräts

Aus platzsparenden- sowie energietechnischen Gründen habe ich mich für ein Nas entschieden. Nun stellte sich die Frage: was für eines? Wie richtet man überhaupt so etwas ein? Recherchen im Internet zeigten, dass die Konfiguration dank eines Webinterfaces laut Hersteller ganz leicht möglich sei und keinerlei Shell-Kenntnisse erfordere, obwohl ein Linux als Basis dient.

Ich habe mir verschiedene Demos der Webinterfaces angeschaut. Keines konnte wirklich mit barrierefreier Umsetzung punkten. Ich habe mich dann für das Webinterface von Synology entschieden, was nicht barrierefrei ist, aber mit Ach und Krach den Anschein machte, als ob es bedient werden könne.

Nun stand ich also mit einem frisch gekauften Synology-Nas zu Hause. Im Kopf schwirrten noch die Gedanken, dass alles einfach und schnell eingerichtet werden kann.

Erfahrungen

Nach dem Einstecken der Hardware begannen auch schon die ersten Hürden. Die Software um das Synology-Nas im Netzwerk zu finden ist nicht barrierefrei. Die Elemente der Applikation werden einem gar nicht angesagt. Also musste ich mit dem Einschränken der IP-Range im Router durchprobieren, bis mir das Webinterface antwortete. Diese Aufgabe kann unter Umständen ein blinder Durchschnittsanwender schon vor unlösbare Hürden stellen.

Die Entwickler des Webinterfaces haben wohl noch nie etwas von den WCAG 2.0 gehört.”> Die Webseite des Interfaces bietet keinerlei Orientierungshilfen. Was besonders schlimm ist: fast alle Schalter werden als „unbeschriftete Schalter“ angesagt. Als
Blinder ist man also gezwungen, durch drücken und abzählen der Schalter zu lernen, was diese bewirken. Dieses Verfahren kann aber gerade in der Vergabe
von Berechtigungen sehr gefährlich sein.

Für das Einrichten von zwei Benutzern mit je 2 Ordnern habe ich 2.5 Stunden benötigt. Dies liegt nicht am fehlenden technischen Verständnis, sondern viel mehr am unzugänglichen Webinterface.

Um hier für mich einen vereinfachten Zugang zum Gerät zu haben, bin ich wohl gezwungen, mich mit der Shell auseinander zu setzen. Traurig ist nur, dass man für nicht technisch versierte Nutzer mit dem Webinterface eine Vereinfachung entwickelt hat, die Menschen mit einer Behinderung einfach verwehrt bleibt. Doch auch ich gehöre zu jenem Personenkreis, der beim Erkunden einer Benutzeroberfläche weiss, was er tun muss und kann. Die Shell verlangt, dass man exakt weiss, was man vor hat und tun möchte.

Fazit

Technik soll mich unterstützen. Wenn die Bedienung einer Weboberfläche eine Vereinfachung für die Mehrheit der Benutzer bietet, sollten auch blinde Menschen davon vollen Gebrauch machen können. Es ist schade, dass man für die Bedienung unzugänglicher Geräte ein Vielfaches der kognitiven Leistung verbraten muss.

Die Accessibility von Chrome-OS

Ein aufgeklapptes Notebook, ein Chromebook ist zu sehen mit einer daran arbeitenden Person.
Daniele Corciulo arbeitet am Chromebook

Mitte November haben wir vom SZB ein Chromebook als Testgerät erhalten. Ich hatte zwar bereits gehört, dass Chrome-OS Accessibilityfunktionen integriert haben soll, habe es aber selbst noch nie ausprobiert.

Allgemeines zum Gerät

Das Chromebook ist ein leichtes Notebook, etwa 11 Zoll gross und 550 Gramm schwer. Es läuft mit einem vergleichsweise schwachen Prozessor und besitzt meistens nur eine geringe Menge an internem Speicher, sowie Arbeitsspeicher. Dies ist aber nicht so schlimm, da sich die meisten Applikationen sowieso im Browser abspielen und somit die benötigten Ressourcen nur sehr gering sind. Als Betriebssystem dient eine Linux-Distribution, welche von Google stark angepasst wurde und möglichst eingeschränkt ist um für die Nutzer das System so einfach wie möglich zu machen. Das System ist somit innert weniger Sekunden aufgestartet und betriebsbereit. Nutzt man Google-Dienste, kann man sich mit dem Google-Account einloggen und die Einstellungen des Chrome Browsers werden übernommen. Wie vorhin angetönt, das System ist so aufgebaut dass alle Applikationen im Web ausgeführt werden. Es ist also nicht möglich Windows Programme darauf laufen zu lassen. Dies hat zur Folge, dass man auch einen neuen Screen Reader verwenden muss. Es handelt sich hier um den Screen-Reader ChromeVox.

Mögliche Anwendung für Blinde

Grundsätzlich kann man sagen, dass alles funktioniert. Selbst meine Braillezeile wurde auf Anhieb erkannt. Der Screenreader ist von der Bedienung etwas gewöhnungsbedürftig, aber er funktioniert sehr zuverlässig.
Allerdings ist auch hier das System nur soweit zugänglich, wie es die Apps sind und da sind die Unterschiede wie überall nicht gerade unwichtig.

Da sich sowieso alles im Browser abspielt sind natürlich zugängliche Apps und Webseiten das Hauptkriterium um auch ein zugängliches Erlebnis auf dem Chromebook zu bieten.

Da die Anwendung des Chromebook vor allem auf das Surfen im
Internet beschränkt ist, kann das Gerät von Blinden vor allem als
Nachschlage-Rechner verwendet werden. Der Rechner ist rasch hochgefahren und sofort Betriebsbereit. Im Vergleich zu iOS, bietet Chrome eine bessere ARIA-Unterstützung. Da das Gerät auch eine Tastatur besitzt, kann man damit auch im Internet einfacher interagieren als auf einem Touchscreen. Auch wenn Flash immer mehr an Bedeutung verliert und nicht ganz unproblematisch hinsichtlich Barrierefreiheit ist, wird Flash im Gegensatz zum iPad auf dem Chrome-OS unterstützt. Dies kann nützlich sein, wenn Webseiten keine alternativen Player anbieten. Updates und Virenschutz gehören laut Hersteller auch nicht zu den täglichen Sorgen des Chrome-OS-Anwenders. Dies weil zum einen eine automatische Update-Funktion vorhanden ist und zum anderen, weil sowieso  nur Webapplikationen ausgeführt werden können.

Fazit

Vertraut jemand mehrheitlich auf die Cloud und sucht einen Rechner, der leicht und schnell einsatzbereit ist, ist das Chromebook sicher eine mögliche Alternative. Allerdings ist zu bedenken, dass es im Prinzip nur ein Rechner ist, der für die Internetnutzung konzipiert ist. Sobald man mehr machen möchte, muss man auf eines der vollwertigen Betriebssysteme umsteigen. Da der Screenreader bereits integriert ist, fallen auch keine Updatekosten hierfür an. Allerdings kann man auch nur den ChromeVox verwenden.

Grippe und Barrierefreiheit

Die Temperaturen sind kälter geworden und somit ist auch die
Wahrscheinlichkeit einer möglichen Grippeinfektion am ansteigen. Nachdem mein sprechendes Fieberthermometer, welches ich über einen Hilfsmittelversand bezogen hatte kaputt ging, habe ich mich auf die Suche nach einem neuen Gerät gemacht. Dies ist für mich als Blinder keine einfache Aufgabe, denn die meisten Apotheken verkaufen keine sprechenden Thermometer. Ich habe im Internet geschaut, ob es vielleicht ein Gerät gibt, welches eine Schnittstelle zu einem Smartphone hat. Dies würde es ermöglichen, ein Thermometer zu benutzen, ohne das Display lesen zu müssen. Damit so etwas funktioniert, müsste natürlich auch die entsprechende App barrierefrei sein.

Auf der Suche ist mir ein Thermometer von Beurer mit Infrarotmessung und integrierter Sprachausgabe begegnet. Ein Vergleich auf www.toppreise.ch hat gezeigt, dass das Produkt meiner Begierde am günstigsten bei www.microspot.ch verfügbar ist. Ich habe natürlich direkt die Webseite aufgerufen und versucht
das Gerät zu bestellen.

Die erste Hürde kam bereits bei der Navigation, die Kategorien waren nur mit der Maus anwählbar. Ich bat also meine Freundin mir den Direktlink zum Artikel zuzusenden, damit ich anschliessend den Bestellprozess selbstständig abschliessen kann. Es war schon kaum möglich den Artikel in den Warenkorb zu legen. Nach etwa 30 Minuten ist mir dies endlich gelungen, wobei ich hier auf Tricks zurückgreifen musste, die ich durch meine tägliche Arbeit als Accessibility-Consultant kenne. Nun war der Bestellprozess an der Reihe. Hier habe ich ein Formular angetroffen – ohne Labels. Ich habe also versucht die Angaben einzufüllen. Ich habe alle möglichen und unmöglichen Kombinationen versucht, leider ohne Erfolg. Ich wusste nach zwei Stunden immer noch nicht was falsch gelaufen war. Eine Rücksprache mit Arbeitskollegen hat gezeigt, dass Fehlerhinweise in einer Lightbox angezeigt werden und zusätzlich mit Farben gekennzeichnet sind. Lightboxen müssen zugänglich programmiert werden, damit diese mit Screenreader funktionieren. Ebenfalls müssen fehlerhafte Eingaben zusätzlich mittels eines versteckten Texthinweises angezeigt werden.

Lightbox mit Fehlermeldung (mit Screenreader nicht sichtbar)

Ich habe nun das Gerät nicht bestellt. Dieser Shop ist für mich überhaupt nicht nutzbar und ich bin somit gezwungen das Gerät bei der Konkurrenz zu kaufen, denn die haben ein Ladengeschäft. Allerdings bin ich  auch gezwungen den doppelten Preis zu bezahlen. Barrieren im Web schränken also die Marktfreiheit deutlich ein.

Ich hoffe, dass Onlinehändler erkennen, dass ein barrierefreies Angebot nicht nur soziales Engagement, sondern auch mehr potentielle Kunden bedeutet und zwar deutlich mehr, wenn man davon ausgeht dass in der Schweiz etwa 1.4 Mio (Quelle: BFS) Menschen mit einer Behinderung leben.

Barrierefreie elektronische Lehrmittel im EPUB3 Format

Zürich, 13.10.2014

Die Stiftung «Zugang für alle» freut sich, den offiziellen Abschluss des Vorprojekts «Barrierefreie elektronische Lehrmittel im EPUB3 Format» bekannt geben zu dürfen.

Das folgende Executive Summary ist ein Auszug aus der Projektstudie «Barrierefreie elektronische Lehrmittel im EPUB3-FOrmat». Hier gehts zum Download:

Projektstudie (PDF, 3MB)

Die Projekt-Website epub3.ch wird weiterhin aktiv unterhalten und gepflegt. Wir bedanken uns ganz herzlich bei allen beteiligten Projektpartnern und freuen uns auf die Weiterführung des Projekts 2015. Barrierefreie elektronische Lehrmittel im EPUB3 Format weiterlesen

Accessibility, Barrierefreies Internet, Zugang für alle