accessBlog

News mit dem Tag »Hilfsmittel«

07 Mai 2013

Für viele Menschen sind mobile Endgeräte einfach nur praktische Kommunikations- und Informationsmittel, für Menschen mit Behinderung sind sie oft viel mehr: sie erleichtern das Leben an vielen Stellen und ermöglichen eine selbstbestimmte Teilhabe.

Mails abrufen, das Wetter checken oder schauen, was die Freunde auf Facebook machen, früher hat man das fast nur am heimischen PC gemacht. Doch fast unmerklich hat das mobile Internet unseren Alltag erobert.

Smartphones sind vielmehr kleine Computer als Telefone. Zusammen mit einem mobilen Internetzugang gibt es heute kaum noch etwas, wofür man das Smartphone nicht verwenden kann. Für Menschen mit Behinderung ist das nicht nur praktisch, es kann ihnen den Alltag oft entscheidend vereinfachen.

Die Vorzüge mobiler Endgeräte

Die mobilen Geräte haben gegenüber den großen Computern einige Vorteile. Die Oberfläche ist auf wichtige Elemente reduziert und dadurch leichter verständlich und zugänglich. Die vielseitige Nutzbarkeit der Smartphones verdankt sich jedoch auch der zahlreichen eingebauten Sensoren: Oft sind GPS, Kompass oder Beschleunigungssensoren integriert, über die Bluetooth-Schnittstelle können viele zusätzliche Erweiterungen verbunden werden.

Doch ihren durchschlagenden Erfolg bei Menschen mit Behinderung verdanken die Smartphones der integrierten Hilfssoftware: Viele Geräte haben Spracheingabe, Sprachausgabe oder Bildschirmvergrößerung in die Betriebssysteme integriert. Für vergleichbare Funktionen mussten früher hunderte oder gar tausende Euro ausgegeben werden. Die Idee einer Nutzbarkeit für alle ist in Smartphones und Tablets besser umgesetzt als bei jeder anderen Geräteklasse.

Mittlerweile gibt es viele spezielle Apps für Menschen mit Behinderung, die das selbständige und selbstbestimmte Leben erleichtern.

  • Für Gehörlose ist es in vielen Situationen schwierig, einen Gebärdendolmetscher zu organisieren. Mit speziellen mobilen Apps können sie bei Bedarf einen Text-Dolmetscher zuschalten und damit zum Beispiel Vorlesungen an der Uni verfolgen oder den Arztbesuch erledigen (z.B. VerbaVoice).
  • Es gibt verschiedene Apps für Menschen mit sprachlichen Einschränkungen. Dabei handelt es sich zum Beispiel um Hilfen zur unterstützten Kommunikation. Die App Sono Flex bietet dem Benutzer eine Kombination von Grafiken mit Sprachausgabe: Wenn eine dieser Grafiken angetippt wird, liest das Smartphone den entsprechenden Text vor. Dadurch können viele Alltagsaufgaben besser bewältigt werden.
  • Für Menschen, die auf einen Rollstuhl angewiesen sind, ist es oft schwierig, zum Beispiel ein barrierefreies Café zu finden. Mit Apps wie Wheelmap können sie gezielt nach für sie zugänglichen Orten suchen.
  • Auch für Blinde ergeben sich neue Möglichkeiten. Durch die aktuellen Geräte von Apple wurden erstmals mobile Geräte mit integrierter Sprachausgabe und Vergrößerungssoftware erschwinglich. Mittlerweile ersetzen diese Geräte zusammen mit speziellen Apps einen ganzen Fuhrpark an teuren Hilfsmitteln. Dabei gibt es Apps zur Navigation, zur Farberkennung, zum Lesen von Beipackzetteln und vieles mehr. Durch die verbreiteten Touchscreens wird es Blinden zum ersten Mal möglich, den grafischen Aufbau von Webseiten zu erfassen.

Natürlich benutzen Menschen mit Behinderung nicht nur spezielle Apps. Skype wird sowohl von Blinden als auch von Gehörlosen gerne eingesetzt. Ansonsten sind auch Apps zum Bestellen von Taxis, zum Musik-Streaming oder Spiele beliebt – es gibt praktisch keine App, die nicht auch von Menschen mit Behinderung genutzt wird. Das meist auftretende Hindernis ist die oft mangelnde Zugänglichkeit, vor allem auch dann, wenn neue Geräte oder Betriebssysteme auf den Markt kommen.

Neue Technik schafft neues Bewusstsein

Mit dem Zugang zur Technik hat sich aber auch das Selbstbewusstsein von Menschen mit Behinderung verändert. Früher haben sich gelegentlich einzelne Menschen beschwert, wenn eine Website nicht barrierefrei war. Heute gibt es große Communities, die sich oft gemeinsam an die Entwickler von Apps wenden, um diese auf die schlechte Zugänglichkeit ihrer Anwendungen aufmerksam zu machen. Die App-Entwickler werden dadurch oft erst auf das Thema Barrierefreiheit und die Gruppe der Kunden mit einer Behinderung aufmerksam. Viele Entwickler nehmen solche Anregungen aus der Community gerne auf.

Gleichzeitig haben Smartphones bei vielen Menschen den Entwickler-Geist geweckt. Ein blinder angehender Physiotherapeut bastelte zum Beispiel eine Halterung, um das iPhone als einfachen Scanner verwenden zu können, ein Programmierer aus England hat eine Anwendung entwickelt, mit der das Smartphone als einfaches Hörgerät genutzt werden kann.

Wir stehen erst am Anfang

Durch mobile Endgeräte verwischen allmählich die Grenzen zwischen Online und Offline. Ein Blinder kann zum Beispiel ein Foto von einem ihm unbekannten Objekt machen, es bei facebook einstellen und seine sehenden Freunde fragen, worum es sich handelt. Die App Wheelmap wird nicht nur mobil genutzt, um barrierefreie Orte zu finden, sondern Nutzer können selber Orte einstellen und bewerten. Ohne die Nutzung von Smartphones wäre diese Anwendung kaum so erfolgreich. Der Dienst VerbaVoice wird zur kommunikativen Brücke zwischen Menschen, die sich ansonsten schwer oder gar nicht verständigen könnten.

Die Dynamik ist enorm, wenn man bedenkt, dass Smartphones erst seit relativ kurzer Zeit einer breiten Öffentlichkeit zur Verfügung stehen. Wir stehen erst am Beginn einer spannenden Entwicklung.

06 Mai 2013

Das Testen von Webprojekten und mobilen Apps ist eine neue Herausforderung im täglichen Arbeitsalltag eines jeden Entwicklers. Die große Vielfalt der Geräte und Betriebssysteme, die in den letzten Jahren erschienen sind, macht dies noch schwieriger. Weil man kein Vermögen für zahlreiche unterschiedliche Testgeräte ausgeben möchte, eröffnen seit einiger Zeit immer mehr »Open Device Labs« ihre Pforten.
Sven Wolfermann erläutert, was das bedeutet und welche Vorteile dies vor allem auch für diejenigen bringt, die sich mit App- und Webentwicklung beschäftigen.

Hinter der Idee für das erste »Open Device Lab« steht der Gedanke eines »offenen Testlabors« für mobile Geräte. Sie entstand vor ca. einem Jahr in den Agenturräumen von Clearleft in Brighton (UK). Jeremy Keith, der Gründer von Clearleft, wollte die Geräte, die sich in seiner Agentur befanden, nicht nur für die eigene Mitarbeiterschaft, sondern auch für andere Entwickler zum Testen von Webanwendungen und Apps offen zugänglich machen. Was Jeremy Keith anfangs nicht gedacht hätte war, wie viele Entwickler dieser Idee folgten und ihm aus eigenen älteren Beständen Geräte spendeten, so dass die Geräteanzahl schnell wuchs und eine Bandbreite an unterschiedlichsten Herstellermarken und Versionen zur Verfügung stand.

Warum ist das Testen auf echten Geräten überhaupt notwendig?

Für jedes mobile Betriebssystem gibt es sogenannte Emulatoren, um die Entwicklung und Programmierung einer Anwendung zu testen. Um die responsive Website oder mobile Webapp im Desktop-Browser zu testen, gibt es für die Webentwicklung mittlerweile sehr gute Entwicklertools. Allerdings lassen sich Eigenschaften wie Multi-Touch-Gesten, hohe Pixeldichten (Retina-Displays von Apple), oder Prozessorleistung nicht simulieren und müssen zwingend auf echten Geräten getestet werden, um Fehler erkennen zu können. Viele Besonderheiten von Browser/Betriebssystemkombinationen, gerade auf Android-Betriebssystemen, lassen sich ebenfalls nicht zweifelsfrei simulieren und müssen unter realen Bedingungen ausprobiert werden. Dabei sollten speziell auch Größen von Buttons oder Links überprüfen, da die Bedienbarkeit und Performance auf mobilen Geräten eine große Rolle spielt. Außerdem können die Apps oder Websites dann auch mit den Eingabehilfen für Menschen mit Behinderung getestet werden. Dazu gehören etwa die Sprachausgabe, Sprachsteuerung oder Bildschirmvergrößerung.

Weiterhin sollte man unbedingt die Lesbarkeit der Texte überprüfen. Das iPad mini beispielsweise stellt die gleiche Anzahl an Pixeln viel kleiner dar als sein großer 10-Zoll-Bruder. Leider ist es auch durch die Abfrage der Geräteparameter nicht möglich, das iPad mini zu identifizieren, so dass man auch für diese »klein gezoomte« Ansicht eine gute Lesbarkeit vorhalten sollte. Dies kann man nicht am Desktop-Browser simulieren.

Speziell bei der Vielzahl der Smartphones gibt es teilweise große Unterschiede. Hier reicht die Pixeldichte mittlerweile von 0.75 bis 3.0 (Full HD). Gerade bei der Verwendung von Medien (Bilder, Videos) stellt das ein Problem dar, und eine akzeptable Lösung für das Projekt und die Zielgruppe muss gefunden werden.

Am Ende kommt man aber an Tests auf den einzelnen Geräten nicht vorbei, die meisten Emulatoren sind für diesen Zweck nicht ausreichend.

Der Mehrwert eines »Open Device Labs« liegt insofern auf der Hand. In einer Zeit steigender Verbreitung mobiler Endgeräte und wachsender Zugriffe über Smartphones und Tablets ist es enorm wichtig, seine Projekte auf unterschiedlichen Geräten sorgfältig zu testen. Dass der Bedarf da ist, zeigt die Nachfrage nach solchen Angeboten. Der Idee des »Open Device Labs« folgen seither schon über 50 andere Labs weltweit.

Wo finde ich Open Device Labs?

Ob es in der Nähe schon ein Open Device Lab gibt, kann man auf der Webseite opendevicelab.com überprüfen. Deutsche Open Device Labs gibt es mittlerweile in Berlin, Frankfurt, München, Hamburg, Düsseldorf, Köln, Dortmund und Nürnberg.

Ist die eigene Stadt noch nicht vertreten und möchte man ein eigenes ODL anbieten, sollte man sich zuerst Gedanken über den Standort machen. Er sollte für alle frei zugänglich sein, möglichst an einem zentralen Ort liegen und genug Platz für die Testgeräte bereithalten. Ein unbenutzter Büroraum oder eine Bürogemeinschaften sind dafür ideal. Durch eine Initiative von Andre Jay Meissner und Bruce Bowman gibt es zudem eine Anlaufstelle für begeisterte Firmen, um ein eigenes ODL zu starten. Auf der Webseite lab-up.org kann man sich informieren, welche Schritte notwendig und sinnvoll sind, um ein Open Device Lab anzubieten. Zudem kann Lab-Up auch Kontakte zu Herstellern knüpfen, die manchmal auch Geräte sponsern.

Da es für einige Firmen aus vielen Gründen nicht möglich ist, Ihre Projekte außer Haus zu testen, gibt es jetzt auch ein mobiles ODL, bei dem man einen Gerätepark mieten kann. Informationen dazu findet man unter odl.maddesigns.de.

19 Sep 2011

PDF-Dokumente sind der Quasi-Standard für plattformunabhängige, digitale Dokumente. Vor allem für Blinde und Sehbehinderte sind sie aber eher schwierig zu benutzen. PDF-Dateien sind so gut wie nie barrierefrei. Das liegt daran, dass die meisten kostenlosen oder kostenpflichtigen Programme zur Erzeugung von PDF-Dateien die Barrierefreiheit nicht unterstützen. Broschüren oder Bücher nachträglich barrierefrei zu machen ist ein aufwendiger Prozess.

Die Grundlage für barrierefreie PDFs sind Tags. Ähnlich wie in HTML wird durch Tags eine Struktur über das Dokument gelegt, so dass es wie eine Webseite navigiert werden kann.

Weiterlesen …

Barrierefreiheit versus Benutzbarkeit

Viele PDF-Dateien sind grundsätzlich benutzbar, auch wenn sie nicht barrierefrei sind. Für Blinde erscheint dann der Text als Fließtext ohne Überschriften, Listen oder sonstige Strukturen. Doch es gibt auch genügend Dokumente, die gar nicht benutzbar sind. Die häufigsten Probleme sind:

  • Das Dokument besteht aus einer Rastergrafik und nicht aus Text.
  • Das Dokument ist gegen die Entnahme von Text kopiergeschützt.
  • Das Dokument ist mehrspaltig oder enthält einen unbekannten Zeichensatz.

Beim Lesen solcher PDFs können die seltsamsten Störungen auftreten. Bei einem PDF wird nach jedem Wort ein Punkt statt einem Leerzeichen eingefügt, bei einem mehrspaltigen Text werden die Zeilen falsch zusammengesetzt, bei einem anderen Dokument steht jedes Wort in einer eigenen Zeile. Bei geschützten Dokumenten oder Rastergrafiken hingegen hat der Screenreader schlicht keine Möglichkeit, auf den Inhalt zuzugreifen.

Ob ihr nicht-barrierefreies PDF problematisch ist können Sie ganz leicht selber testen: Versuchen Sie, Ihr PDF-Dokument als Text zu speichern. In den meisten Leseprogrammen finden Sie eine entsprechende Möglichkeit im Datei-Menü. Wenn die Option ausgegraut oder nicht aufrufbar ist, ist Ihre Datei geschützt. Wenn die resultierende Text-Datei leer ist, handelt es sich vermutlich um eine Rastergrafik. Und wenn Sie einen unlesbaren Text erhalten stimmt etwas mit Ihrem Spalten- oder Zeichensatz nicht.

Unstrukturierter Text ist kein Ersatz für PDF, sondern ein schlechtes Provisorium. Eine Tabelle zum Beispiel ist in einer Textdatei vollkommen unbrauchbar.

An welcher Stelle sollte man ein PDF einsetzen?

PDF ist tatsächlich sinnvoll, wenn es um große Mengen an Informationen geht, die gestaltet sein sollen. Die aktuellen Webstandards erlauben nur eingeschränkten Einfluss auf Farbgestaltung oder Typographie, vor allem, wenn das Dokument mit allen Browsern auf allen Plattformen gleich aussehen soll. Oftmals werden PDF aber eingesetzt, weil es für den Redakteur gerade bequemer ist.

Wenn ein Text viele Seiten umfasst, keine unmittelbar wichtigen Informationen enthält, das Layout wichtig ist und der Text nicht ständig aktualisiert werden muss, kann man ihn als PDF anbieten. In allen anderen Fällen sollte immer eine HTML-Version bevorzugt werden.

Wenn Sie einige Regeln beachten, können Sie die Nutzung von PDF-Dokumenten wesentlich erleichtern.

Das PDF soll zugänglich sein

Die kostenlosen Produktivitätsprogramme OpenOffice bzw. LibreOffice können von Haus aus barrierefreie PDF erstellen. Auch Microsoft Office kann ab der Version 2007 getaggte PDF erstellen. Dazu müssen die in der Textverarbeitung vorhandenen Formatvorlagen für Überschriften und Listen verwendet werden; es können auch Alternativtexte für Bilder vergeben werden.

Für komplexere Dokumente wie etwa Flyer oder Broschüren müssen allerdings die Produkte von Adobe eingesetzt werden. Wenn es aus finanziellen oder technischen Gründen nicht möglich ist, ein strukturiertes PDF bereit zu stellen, sollten Sie zumindest – wie oben beschrieben – auf die Benutzbarkeit achten.

Das PDF soll sprechend benannt werden

Viele Nutzer sammeln PDF-Dokumente zur späteren Lektüre. Wenn die Dokumente nicht sprechend benannt sind, müssen sie geöffnet werden, um zu erfahren, um welches Dokument es sich handelt.

Vor allem Blinde mögen es nicht, PDF-Dateien im Browser zu öffnen. Die Browseranzeige ist nicht barrierefrei, zudem kann die komplette Tastatursteuerung über den Browser verloren gehen, so dass der Browser neu gestartet werden muss. Blinde ziehen es deshalb vor, PDFs zu speichern und mit dem Leseprogramm zu öffnen.

Aus diesem Grund sollten Sie auch immer ankündigen, wenn sich hinter einem Link ein PDF verbirgt. Überraschungen dieser Art sind nicht nur bei Blinden unbeliebt.

Das PDF soll klein sein

Die 50 MB große PDF-Datei ist, DSL hin, DSL her, sehr langsam beim Download. Das mag bei Druckvorlagen angemessen sein, die eine hohe Auflösung und Bildqualität von 300 dpi oder höher haben sollen. Für das Internet ist diese Datei zu groß, es dauert lange, sie zu öffnen und mit ihr zu arbeiten. Achten Sie vor allem darauf, die Bilder internetgerecht zu komprimieren.

Das PDF soll keine Informationen enthalten, die nicht auf der Website stehen

Aus der Sicht der Benutzerfreundlichkeit ist es sinnvoll, wichtige Informationen immer so einfach wie möglich zugänglich zu machen. Das heißt, die Informationen sollen auf der Webseite stehen, wenn sie wichtig sind. Es spricht nichts dagegen, sie ergänzend in ein PDF zu packen, aber das sollte keine Priorität haben.

Der große Vorteil von Webseiten besteht darin, dass sie leichter barrierefrei zu machen sind als PDF. HTML wird von den meisten Hilfstechniken gut unterstützt, was man von PDF nicht behaupten kann.

Das PDF soll nicht geschützt sein

Wenn das PDF nicht barrierefrei gemacht werden kann, sollte es zumindest nicht vor dem Kopieren von Text geschützt werden. Für Blinde ist es ansonsten nicht möglich, auf den Text zuzugreifen. Aber auch andere Nutzer werden dadurch gestört, wenn sie etwa Text für ein Zitat kopieren möchten.

Denken Sie an mobile Endgeräte

Immer mehr Menschen sind überwiegend mit kleinen und nicht sehr leistungsfähigen Endgeräten im Internet unterwegs. PDFs werden von diesen Geräten nur eingeschränkt dargestellt, weil die Grafik nicht leistungsfähig genug ist. PDF ist ein Format für große Displays. Die wenigsten Menschen werden ein mehrseitiges PDF auf ihrem Smartphone lesen. Das ist ein weiterer Grund, wichtige Informationen direkt auf der Webseite bereit zu stellen.

22 Aug 2011

Barrierefreiheit allein reicht heute nicht mehr. Auch die Ansprüche von Menschen mit Behinderung an Webseiten und Anwendungen steigt. Obwohl es einige Berührungspunkte zwischen Barrierefreiheit (Accessibility) und Benutzerfreundlichkeit (Usability) gibt, handelt es sich doch um zwei Arbeitsgebiete mit unterschiedlichen Methoden und Anforderungen. Dennoch lässt sich die Usability speziell für Menschen mit Behinderung verbessern, so dass am Ende auch die Bedienbarkeit – und damit die Barrierefreiheit – verbessert wird. In diesem Artikel wollen wir zeigen, wie die Usability von Webseiten mit Menschen mit Behinderung getestet werden kann.

Man kann zwischen den drei Bereichen Barrierefreiheit, Benutzbarkeit und Benutzerfreundlichkeit unterscheiden. Eine Seite kann im unstrukturierten HTML daher kommen und dennoch für Menschen mit Behinderung benutzbar sein, das ist aber weder barrierefrei noch benutzerfreundlich. Eine andere Seite kann alle Kriterien der Barrierefreiheit erfüllen, aber dennoch so kompliziert in der Bedienung sein, dass kein Nutzer mit Behinderung sie freiwillig besuchen würde.

Die Barrierefreiheit legt den Schwerpunkt auf die Verbesserung der Benutzbarkeit und weniger auf die Benutzerfreundlichkeit. Alle Testverfahren, ob automatisch oder durch menschliche Tester durchgeführt, prüfen in erster Linie nach formalen Kriterien. Wenn diese Kriterien erfüllt sind, kann man den Grad der Barrierefreiheit bewerten. Aspekte der Benutzerfreundlichkeit ließen sich auch in diese Tests aufnehmen, sie spielen aber bisher eine untergeordnete Rolle.

Weiterlesen …

Typische Usability-Probleme

Schauen wir uns zunächst mal einige Usability-Probleme an, die speziell für Menschen mit Behinderung entstehen können.

  • Ein Formular kann zum Beispiel neben dem Label auch eine Vorbelegung haben. Es kann dem Screenreader-Nutzer passieren, dass er drei Mal vorgelesen bekommt, was in das Formular einzutragen ist, einmal der Text vor dem Feld, einmal das Label und einmal die Vorbelegung. Das ist keine Barriere, aber vor allem bei längeren Formularen anstrengend.
  • Sprunganker sollen wichtige Bereiche der Website leichter erreichbar machen. Mancher Anbieter übertreibt es aber mit der Zahl dieser Sprunganker, so dass die Sprunganker selbst übersprungen werden müssen.
  • Ähnlich sieht es aus, wenn wichtige Bereiche der Webseite durch Überschriften leichter ansteuerbar gemacht werden sollen. Mancher meint es zu gut und vergibt so viele Überschriften, dass der Blinde Probleme hat, den eigentlichen Inhalt der Website aufzuspüren, insbesondere wenn die Seite schlecht strukturiert ist.
  • Menschen mit motorischer Behinderung verwenden oft besondere Eingabegeräte wie die Augensteuerung. Sie ziehen es vor, möglichst wenige Schritte auf einer Webseite zu machen und möglichst wenig Text einzugeben. Auch mit einiger Übung ist es anstrengend, längere Texte über eine Bildschirmtastatur einzugeben. Diese Nutzergruppe wird durch unnötig lange oder aufwendige Prozesse abgeschreckt.
  • Ein sehr häufiges Problem sind aufklappende Navigationsmenüs oder Layer: Sehbehinderte achten oft nicht genau darauf, wo sie den Mauscursor positionieren. Deshalb passiert es recht häufig, dass die Menüs unbeabsichtigt aufgeklappt werden und sich über den Inhalt legen.

Auswahl der Testpersonen

Im Prinzip spricht nichts dagegen, mit Menschen mit Behinderungen Usability-Tests durchzuführen. Testpersonen werden nach unterschiedlichen Kriterien wie den technischen Fähigkeiten ausgewählt. Dazu kommt bei Menschen mit Behinderungen die sehr unterschiedliche Kenntnis der Hilfsmittel und deren Möglichkeiten. Es müssen also zwei Dimensionen von Problembereichen bei der Auswahl von Testpersonen bedacht werden:

  1. Die Fähigkeiten im Umgang mit Programmen wie dem Browser und
  2. die Kenntnisse über die eingesetzte Hilfstechnik.

Wir empfehlen Personen mit geringer oder mittlerer technischer Kompetenz für einen Test zu gewinnen. Wenn diese Personen zurecht kommen bzw. ihre Anforderungen umgesetzt werden, dann werden sehr wahrscheinlich auch Menschen mit mehr technischer Erfahrung zurecht kommen.

Die gesamte Spannbreite verschiedener Behinderungen, Hilfstechniken und technischen Fähigkeiten wird man wohl nicht in einer Testgruppe abbilden können. Allein die Zahl der unterschiedlichen Sehbehinderungen lässt sich kaum mit annehmbaren Aufwand abbilden. Sie sollten dennoch versuchen, die unterschiedlichen Behinderungen Sehbehinderung, Lernbehinderung, motorische Behinderung und Hörbehinderung abzubilden.

Im Rahmen eines Usability-Tests sollen typischerweise bestimmte Aufgaben wie der Kauf eines Artikels bewältigt werden. Diese Aufgaben müssen nicht speziell für Menschen mit Behinderung angepasst werden.

Der Testleiter ist gefordert

Allerdings sind vom Testleiter erweiterte Fähigkeiten gefordert. Er muss zum einen natürlich mit den Leuten kommunizieren können, also auch mit Gehörlosen oder Menschen mit Lernbehinderung. Zum anderen muss er aber auch ihre speziellen Arbeitsweisen mit dem Computer kennen, damit er Probleme erkennen kann, ohne nachzufragen oder einzugreifen. Schwierig ist es zum Beispiel einem Sehbehinderten mit starker Vergrößerung bei seiner Arbeit am Computer zu folgen. Vor allem Blinden und Sehbehinderten muss genügend Zeit zur Orientierung auf der Seite gelassen werden. Natürlich kann auch hier die Methode des lauten Denkens angewendet werden, das heißt die Testperson berichtet, was sie gerade tut und was sie damit erreichen möchte.

Methoden des Usability-Tests wie Eyetracking oder Maustracking müssen auf die Nutzungsstrategien von Menschen mit Behinderung angepasst werden. Ein Sehbehinderter verwendet die Maus auch zum Verschieben des sichtbaren Bildschirmausschnitts, so dass seine Mausbewegungen im Vergleich zum Normalsehenden ungewöhnlich aussehen. Er wird auch ein wenig mehr Zeit benötigen, um ein Objekt zu identifizieren als ein Sehender.

Fazit

Praxistests von Barrierefreiheit und Benutzerfreundlichkeit sind noch nicht so verbreitet, wie es wünschenswert wäre. Allerdings sollte die steigende Komplexität von Webseiten nicht mit dazu führen, dass ihre Bedienung immer komplizierter wird. Anspruchsvolle Angebote wie im eGoverment-Bereich werden sich mittelfristig nur durchsetzen können, wenn sie den Nutzern insgesamt ein positives Nutzererlebnis anbieten.

20 Jul 2011

Richtet man sich nach der Barrierefreie-Informationstechnik-Verordnung (Bedingung 4.1), muss ein Wechsel der Sprache im Text für Screenreader ausgezeichnet werden. Die Sprachauszeichnung erhöht aber nicht immer die Barrierefreiheit. Häufig führt sie aus Sicht von Screenreader-Nutzern sogar dazu, dass Texte nicht richtig verstanden werden.

Hintergrund

Bei allen Webseiten sollte die verwendete Hauptsprache gekennzeichnet werden. Dies geschieht über das lang-Attribut im root-Element: <html lang="de">. Neben der verwendeten Hauptsprache können aber auch einzelne Bestandteile im Text als fremdsprachig gekennzeichnet werden.

Screenreader erzeugen Sprache, indem sie vorgefertigte Phoneme aneinander koppeln. Das allein würde aber einen Text nicht verständlich machen, neben den Phonemen haben die Screenreader Wörterbücher mit Ausspracheregeln. Da Phoneme und Ausspracheregeln in jeder Sprache ein wenig anders sind, klingen spanische, englische oder deutsche Sprachausgaben sehr unterschiedlich, auch wenn im Prinzip die gleiche Stimme eingesetzt wird. Es gibt sogar unterschiedliche Schemata für einzelne Regionen mit gleicher Sprache, die Sprachausgabe für Spanien klingt ein wenig anders als die lateinamerikanische Variante. Wenn in einem deutschen Text ein Begriff als Spanisch ausgezeichnet wurde, sollte er Spanisch ausgesprochen werden, damit auch Blinde ihn verstehen – soweit die Theorie.

Weiterlesen …

In den Wörterbüchern der Screenreader ist auch die Aussprache gängiger Fremdwörter festgelegt. Das Wort Detail wird nicht ausgesprochen, wie es geschrieben wird. Es klingt eher wie Detai, das L am Ende bleibt stumm. Der Screenreader kann das inzwischen richtig ohne Sprachauszeichnung aussprechen, ebenso wie Chance, Restaurant und viele andere Wörter. Solche Wörter müssten theoretisch als Fremdwörter mit anderer Aussprache ausgezeichnet werden. Faktisch würde das aber die Verständlichkeit verschlechtern, denn Wörter wie Computer oder Software werden im Englischen anders ausgesprochen und betont als im Deutschen.

Viele Screenreader-Nutzer stellen die automatische Spracherkennung ab, weil sie einige Webseiten ansonsten gar nicht benutzen könnten. Es kommt gar nicht so selten vor, dass die Sprache einer Webseite falsch festgelegt wurde oder dass bei Redaktionssystemen eine falsche Sprache eingestellt wurde. Die falsche Einstellung führt dazu, dass eine deutsche Webseite mit englischer Aussprache vorgelesen wird.

Das Problem besteht darin, dass die Einstellung für die automatische Spracherkennung gut versteckt ist und ungeübte Screenreader-Nutzer sie nicht finden werden. Damit wird die betroffene Webseite praktisch unbenutzbar, weil die wenigsten Blinden eine deutsche Seite verstehen werden, die mit englischer Betonung vorgelesen wird.

Außerdem ist die Sprachumstellung nicht gerade angenehm, wenn nur einzelne Wörter oder Zitate geändert werden. Obwohl die vorlesende Stimme immer die gleiche bleibt, ändern sich Stimmlage, Intonation, Betonung und Aussprache, was bestenfalls eine unangenehme Überraschung auslöst und einen schlimmstenfalls aus dem Lesefluss reißt. Das heißt, wenn die Sprachausgabe mitten im Satz auf amerikanisches Englisch, britisches Englisch oder kastilisches Spanisch umschaltet, dann macht der Zuhörer diese überraschende Änderung kognitiv wahrscheinlich gar nicht oder nur verzögert mit.

Das heißt, der eigentliche Zweck wird komplett verfehlt, der Mensch am anderen Ende der Leitung hat das Wort gar nicht verstanden, weil er eben das Spanisch der Muttersprachler nicht verstehen kann oder weil er die Umschaltung kognitiv nicht mitgemacht hat.

Hinzu kommt, dass viele Blinde ihre Sprachausgabe auf ein hohes Tempo eingestellt haben. Allerdings können sie oft nur ihre eigene Sprache in diesem Tempo verstehen, während sie für fremdsprachige Texte das Tempo niedriger schalten würden.

Eine Sprachauszeichnung für einzelne Wörter oder Phrasen kann daher mehr Barrieren auf- als abbauen. Für längere Zitate, wie sie in wissenschaftlichen Texten eingesetzt werden, kann eine Auszeichnung des Sprachwechsels hingegen sinnvoll sein. Unserer Erfahrung nach ziehen es Blinde aber vor, die Kontrolle über den Screenreader zu behalten und die Sprache wenn nötig selbst umzustellen.

Fazit

Wichtiger als die korrekte Aussprache ist die Verständlichkeit. Vermeiden Sie deshalb Anglizismen oder Fremdwörter, die von der Zielgruppe nicht verstanden werden. Wenn Sie dennoch Fremdwörter verwenden, bieten Sie eine verständliche Erklärung an. Im Gegensatz zu Sprachauszeichnungen, von denen nur Blinde profitieren, kommt der Verzicht auf Fremdwörter oder deren Erklärungen allen Nutzern zugute.

11 Jul 2011

Für Entwickler barrierefreier Webseiten ist es von Vorteil, sich mit der Hilfstechnik von Menschen mit Behinderung zu beschäftigen. Im folgenden wollen wir den kostenfreien quelloffenen Screenreader Nonvisual Desktop Access (NVDA) vorstellen.

Ein Screenreader wandelt Inhalte des Bildschirms in Sprache um oder gibt sie auf einer Braille-Zeile aus. Blinde und viele Sehbehinderte können den Inhalt der visuellen Benutzeroberfläche (GUI) nicht wahrnehmen. Deshalb benötigen sie eine Brücke, welche die Inhalte des GUI in eine für sie brauchbare Form umwandelt – das macht der Screenreader.

Ein Screenreader ist ein komplexes Stück Software. Es geht nicht nur darum, alles vorzulesen, was sich gerade auf dem Bildschirm befindet. Der Nutzer muss auch komplexe Interaktionen mit dem Rechner ausführen können. Er muss Optionen umstellen, Menüs bedienen, zwischen Anwendungen wechseln, Eingaben machen oder sogar selber programmieren können. Hinzu kommt, dass graphische Oberflächen nie dazu gedacht waren, von Blinden bedient werden zu können. Der Screenreader bleibt daher immer eine Krücke. Viele Programme lassen sich gar nicht bedienen, weil sie auf Mausbedienung ausgelegt sind und ein Blinder nun einmal keine Maus bedienen kann. Zwar kann man den Cursor mühsam mit der Tastatur steuern, das bringt aber nichts, wenn man Menüpunkte und Schaltflächen nicht identifizieren kann. Damit Blinde ein Programm bedienen können, muss die jeweilige Accessibility-Schnittstelle des Betriebssystems unterstützt werden. Unter Windows ist das Microsoft Active Accessibility (MSAA) bzw. die neue Schnittstelle Microsoft UI Automation.

Weiterlesen …

NVDA

NVDA ist ein Open-Source-Screenreader für Windows und kostenlos erhältlich. Die kommerziellen Produkte kosten mehrere tausend Euro und sind daher für die Betroffenen teils unerschwinglich. NVDA ist portabel – das heißt, der Blinde kann seinen Screenreader auf einen USB-Stick oder eine CD-ROM packen, damit ins Internet-Café gehen und einfach im Web surfen. Unter den deutschsprachigen Produkten macht das NVDA unschlagbar.

NVDA hat seine Stärken vor allem im Internet. Für Office-Anwendungen ist er nur eingeschränkt geeignet, das freie OpenOffice lässt sich mit NVDA aber gut bedienen. Dafür wird er aber auch ständig weiterentwickelt und ist bei der Unterstützung neuer Techniken wie ARIA oder HTML5 häufig schneller als die kommerziellen Produkte.

Installation

NVDA kann von der Entwicklerwebsite als installierbares oder portables Programm für die verschiedenen Windows-Versionen heruntergeladen werden. Die Installation läuft wie bei Windows-Programmen gewohnt, die heruntergeladene Datei wird einfach ausgeführt.

Die Sprachausgabe eSpeak ist ein wenig gewöhnungsbedürftig und sehr weit weg von natürlicher Sprache. Man kann aber auch jede andere SAPI-Sprache verwenden. Für Windows gab es eine Zeitlang kostenlos die Sprachausgabe Steffi im Netz zum Download.

Konfiguration und Bedienung

Das Programm wird über das Startmenü oder die Datei nvda.exe gestartet. Die Einstellungen erreicht man nach dem Start des Programms über die Tastenkombination Einfg + N. In diesem Kontextmenü können Einstellungen vorgenommen und das Programm beendet werden. Für Sehende zunächst ungewohnt ist der sparsame Einsatz graphischer Benutzeroberflächen, Screenreader lassen sich vollständig über die Tastatur steuern.

NVDA hat wesentlich weniger Einstellungsmöglichkeiten als kommerzielle Screenreader, was aber auch die Bedienung und Erlernbarkeit wesentlich erleichtert. Er funktioniert am besten mit dem Browser Firefox.

Beim Surfen im Internet werden die Buchstaben auf der Tastatur zu Navigationstasten. Mit den Navigationstasten kann man bestimmte Elemente in HTML direkt anspringen. Im folgenden eine Liste der wichtigsten Kurztasten:

Funktionstaste Funktion
H Springe zur nächsten Überschrift
F Springe zum nächsten Formularelement
L Springe zur nächsten Liste
K Springe zum nächsten Link
U Springe zum nächsten unbesuchten Link
V Springe zum nächsten besuchten Link
T Springe zur nächsten Tabelle

Beim gleichzeitigen Drücken der Umschalt- oder Shift-Taste mit einer Navigationstaste springen Sie zum vorherigen Element, Umschalt + H führt zum Beispiel zur vorherigen Überschrift. Weitere Tastaturbefehle finden Sie in der Dokumentation: »NVDA 2011.1 User Guide«.

Webseiten testen

Grundsätzlich sollten Websites von echten Screenreader-Nutzern getestet werden, weil diese Programme viel Übung und Erfahrung zum korrekten Einsatz erfordern. Dennoch kann es nicht schaden, wenn Entwickler und Webdesigner ein Gefühl dafür bekommen, wie Blinde im Internet unterwegs sind.

Für das echte Screenreader-Feeling sollte man sich eine Liste mit Tastenkürzeln für Windows und NVDA ausdrucken, die Maus beiseite legen und den Bildschirm ausschalten. Am besten fängt man mit einer Seite an, die man schon kennt.

Mit den Pfeil-Tasten kann man rudimentär durch die Seite navigieren. Mit den erwähnten Navigationstasten erreicht man komfortableres Surfen. Auf vielen Websites sind zum Beispiel Navigationen als Listen umgesetzt. Wir suchen also mit ›L‹ nach einer Liste von Links, die sich wie eine Navigation anhört. Oftmals werden auch HTML-Überschriften verwendet, um einzelne Bereiche der Website wie die Navigation oder Content-Bereiche leichter erreichbar zu machen. Wir suchen also mit ›H‹ nach Überschriften.

Wenn Sie ein Einrast-Geräusch hören, hat NVDA den Formularmodus aktiviert. Im Formularmodus können Sie wie gewohnt Formulare mit der Tastatur ausfüllen, die Navigationstasten sind im Formularmodus inaktiv. Mit Einfg + Leertaste verlassen Sie den Formularmodus.

Ausführliche Testanleitungen finden Sie in der Linkliste. Auch wenn Sie nicht vorhaben, Ihre Webseiten mit Screenreadern zu testen, bringt der Einsatz von Programmen wie NVDA einen großen Erkenntnis-Gewinn.

  • Sie erfahren, warum es wichtig ist, semantisches HTML einzusetzen, denn ohne Überschriften- oder Listen-Tags bzw. ARIA hat der Blinde kaum noch Orientierungspunkte.
  • Sie erfahren, warum Elemente auch im Quelltext in der korrekten Reihenfolge angeordnet sein sollen, denn daran orientiert sich der Screenreader.
  • Sie erfahren, wie es ist, wenn Elemente linear und nicht parallel angeordnet sind. Unabhängig davon, wie Ihre Website aufgebaut ist, der Blinde kann nur ein Element nach dem anderen erschließen.
  • Und Sie erfahren etwas über Tastaturbedienung, einer der wichtigsten Säulen der Barrierefreiheit.

08 Jul 2011

In den vergangenen Jahren gab es einiges an Bewegung im Markt für Computer-Hilfsmittel für Menschen mit Behinderung. Besonders liess sich das bei den Screenreadern beobachten: wo bisher ein oder zwei führende Produkte den Markt dominierten, gibt es nun wesentlich mehr Auswahl, die auch professionellen Ansprüchen genügt. Noch vor einigen Jahren konnte man mit Sicherheit davon ausgehen, dass der Screenreader JAWS 75% oder mehr des Marktes besetzte (mit, je nach Land, einem Zweitplatzierten wie zum Beispiel Cobra / Virgo / Blindows in Deutschland, SuperNova / HAL in Großbritannien oder Window-Eyes in den USA). Nun stehen den Nutzern wesentlich mehr Optionen zur Verfügung.

Das Erscheinen von kostengünstigen oder sogar freien Open-Source-Anwendungen wie NVDA oder SAToGo und Screenreadern, die gleich mit dem Betriebssystem installiert werden (wie VoiceOver unter Mac OS X & iOS oder Orca für Gnome) bedeutet für die Nutzer, dass nun mehr Menschen Zugang zu den Medien haben, die ihnen vorher aufgrund der hohen Kosten kommerzieller Hilfsmittel versperrt waren. Es bedeutet aber auch für Entwickler von Webangeboten, dass mit einer größeren Anzahl von Browser-/Hilfsmittel-Kombinationen getestet werden muss als nur mit dem sprichwörtlichen JAWS-Nutzer mit Internet Explorer und Windows XP.

Weiterlesen …

Das Problem bei der Erstellung einer Test-Matrix und der Priorisierung von Tests (und Reparaturen!) ist, dass Hilfsmittel-Hersteller traditionell nicht über Marktanteile und die Anzahl der ausgelieferten Produkte reden. Wir müssen uns hier also auf Beobachtungen, grobe Schätzungen, Hörensagen und Anekdoten verlassen.

Umfragen wie der WebAIM Screen Reader Survey von Ende 2010 unterstützen die Annahme einer Verschiebung im Markt. Die Befragung ergab, dass der Anteil von JAWS auf 59% gefallen ist (von über 75% vor zwei Jahren), VoiceOver und NVDA kletterten auf jeweils 10%. Ebenfalls interessant ist die Erkenntnis, dass 80% der Nutzer ihr Hilfsmittel innerhalb eines Jahres auf eine neuere Version aktualisiert hatten und dass 98,4% aller Nutzer JavaScript aktiviert haben.

Internet Explorer dominiert weiterhin mit 63,5%, allerdings waren dies noch vor einigen Jahren nahezu 100%. Nach wie vor ist der Marktanteil unter Menschen mit Behinderung jedoch signifikant höher als in der allgemeinen Nutzerschaft. Firefox wird mittlerweile zu 23,5% zusammen mit Hilfsmitteln benutzt, Safari kommt auf 9,6%.

Hilfsmittel am Arbeitsplatz

Man kann mit Sicherheit davon ausgehen, dass die teureren kommerziellen Produkte vorzugsweise am Arbeitsplatz genutzt werden, was folgende Testszenarien ergibt:

JAWS v.12 – www.freedomscientific.com
  • Internet Explorer (beste Unterstützung, obwohl moderne Techniken wie WAI-ARIA wesentlich von der Implementierung in anderen Browsern wie Firefox abweichen. Zudem können dynamische Änderungen des Inhaltes je nach Art der Umsetzung immer noch zu Problemen in der Nutzbarkeit mit Hilfsmitteln führen)
  • Firefox (nahezu auf Augenhöhe mit IE, mit teils besserer Unterstützungen für AJAX und ARIA)
  • Google Chrome (befriedigende Unterstützung mit aktuellen Versionen wie Chrome 12)
  • Opera (keine Unterstützung)
SuperNova (früher Hal) v.12 – www.yourdolphin.com
  • IE (Unterstützung vergleichbar mit JAWS, allerdings versteht SuperNova noch keinen WAI-ARIA-Markup)
  • Firefox (solide Unterstützung, ebenfalls kein WAI-ARIA)
  • Chrome (Unterstützung unbekannt)
Window-Eyes v.7.5 – www.gwmicro.com
  • Marktanteile & Verbreitung unbekannt
ZoomText v.9.1 – www.aisquared.com
  • IE (vollständige Unterstützung)
  • Firefox (vollständige Unterstützung)
  • Chrome (wird laut Hersteller Ai Squared nicht unterstützt)
Dragon v.11.5 – www.nuance.com
  • IE (vollständige Unterstützung)
  • Firefox (vollständige Unterstützung)
  • Chrome (wird laut Google nicht unterstützt)

Hilfsmittel im privaten Bereich

Die Tatsache dass eine Kombination aus Screenreader & Braillezeile gerne mit 5.000 € zu Buche schlägt lässt die Vermutung zu, dass Nutzer im privaten Bereich eher zu kostengünstigen oder freien Lösungen greifen. Daraus ergeben sich die folgenden Testszenarien:

Apple VoiceOver (Bestandteil von Mac OS X für Desktop- und iOS für Mobilgeräte) – www.apple.com
  • Safari (gute Unterstützung, innovativ in einigen Bereichen, in anderen mit deutlichen Lücken)
  • Chrome (teilweise Unterstützung, besonders bei Formularen »buggy«, wird allerdings häufig aktualisiert)
  • Firefox (leider keine Unterstützung)
NVDA (Windows) – www.nvda-project.org
  • Firefox (vollständige Unterstützung)
  • Google Chrome (befriedigende Unterstützung mit aktuellen Versionen wie Chrome 12)
  • Internet Explorer? (hervorragende Unterstützung der UI Automation API unter Windows 7, obwohl man argumentieren könnte, dass Nutzer, die einen OpenSource-Screenreader benutzen eher nicht den IE verwenden und stattdessen auf einen OpenSource-Browser setzen)
Orca (Linux/Gnome) live.gnome.org/Orca
  • Firefox (vollständige Unterstützung unter Linux)
Serotek System Access To Go (SAToGo) www.serotek.com
  • Web-basiert, Marktanteil & Nutzung unbekannt

Die Ebene der Browser

Schaut man sich nun die Browser-Statistiken von Diensten wie StatCounter an, so sieht man den selben Trend in der allgemeinen Nutzerschaft wie bei den Nutzern von Hilfsmitteln: die Anteile von IE fallen, alternative Browser wie Firefox, Chrome & Safari steigen. Sogar relativ aktuelle Versionen von IE verlieren Anteile (IE8 zurzeit runter auf 28% von 38% im Januar 2011). Wenn wir die verschiedenen Browser- bzw. Rendering-Engine-Kombinationen zusammenfassen, bekommen wir 47% für alle IE zusammengenommen, Firefox ist relativ stabil bei 22% und Safari bei 9% (Werte gerundet). Den stärksten Anstieg verzeichnet Google Chrome, der sich von 7% im Januar 2010 auf 21% im Juni 2011 hochgearbeitet hat.

Die Statistik hier bei ›Einfach für Alle‹ ergibt folgendes Bild:

Firefox 3 Firefox 4 IE 8 Safari 5 IE 7 Opera 11 Chrome 10 IE 9 IE 6 Chrome 11 Andere
42,66% 15,26% 13,17% 6,68% 4,12% 2,52% 1,60% 1,27% 1,09% 0,98% 11,62%

Hilfsmittel-Schluckauf

Man kann aus den Testergebnissen mit einer bestimmten Browser-/Hilfsmittel-Kombination leider nicht ableiten, dass der getestete Code genauso funktioniert, wenn man ihn mit dem gleichen Hilfsmittel und einem anderen Browser oder mit dem gleichen Browser, aber unterschiedlichem Hilfsmittel benutzt. Ein Beispiel soll das illustrieren:

Nach der HTML-Spezifikation kann man einem Formular-Element mehrere Label per <label for="#ID"> zuweisen – ein Feature das zum Beispiel bei Fehlermeldungen oder erläuternden Texten in einem komplexen Formular durchaus sinnvoll sein kann. Das Verhalten solcher mehrfachen Labels ist in den gängigen Desktop-Browsern wie erwartet: alle Labels sind klickbar und steuern bzw. fokussieren die zugeordneten Formularelemente. Allerdings geben sämtliche uns bekannten Screenreader immer nur ein Label aus: je nachdem welche Browser-/Hilfsmittel-Kombination benutzt wird ist dies entweder das erste oder das letzte Label, da es weitgehend abhängig von Browser ist, welche Information an das Hilfsmittel durchgereicht wird. Dies kann zum Verlust von Informationen oder mangelnder Funktionalität führen, wenn ein Formular nicht in allen relevanten Kombinationen durchgetestet wurde.

Unterschiede bestehen sogar innerhalb einer Familie von Rendering Engines, wie ein anderes Beispiel belegt: Sowohl Apple Safari als auch Google Chrome basieren beide auf der Webkit-Rendering-Engine. Ein einfacher Test mit dem neuen Outline-Algorithmus von HTML5 zeigt, dass Überschriften-Ebenen unterschiedlich interpretiert werden (in diesem Fall macht Chrome es richtig; Safari macht es falsch und zeigt die inneren, verschachtelten H1 in der gleichen Größe wie die äußeren H1).

Auch der umgekehrte Fall ist möglich: Google hat dem Vernehmen nach einige Accessibility-Features aus Webkit wieder ausgebaut, die in Safari reibungslos funktionierten.

Schlussfolgerung

Alleine die Anzahl der Nutzer alternativer Kombinationen sollte bereits umfassendere Tests als nur mit einem Browser rechtfertigen. Nimmt man dann noch die Tatsache hinzu, dass die Ausgabe von Browser zu Browser erheblich abweicht (selbst wenn man identische Screenreader benutzt), dann bekommt man sehr schnell eine relativ umfassende Matrix von Testdurchläufen. Ein minimaler Satz sollte also die folgenden Kombinationen beinhalten:

JAWS (aktuelle Version & aktuelle Version minus 1)
  • IE/Win 7/8/9 (v.10 ist kurz vor fertig) – diese Kombination sollte ca. ⅔ aller use cases im Bereich blinder Nutzer abdecken
  • Firefox,l,l/Win (aktuelle Version & aktuelle Version minus 1)
  • Chrome/Win (jeweils die aktuelle Version, ältere Versionen unnötig wegen automatischen Updates)
ZoomText (aktuelle Version & aktuelle Version minus 1)
  • IE/Win 7/8/9
  • Firefox/Win (aktuelle Version & aktuelle Version minus 1)
Dragon (aktuelle Version & aktuelle Version minus 1)
  • IE/Win
  • Firefox/Win (aktuelle Version & aktuelle Version minus 1)
NVDA (jeweils die aktuelle Version)
  • Firefox (aktuelle Version & aktuelle Version minus 1)
  • Chrome (aktuelle Version, ältere Versionen unnötig wegen automatischen Updates)
VoiceOver (jeweils die aktuelle Version)
  • Safari (aktuelle Version unter Mac OS X & iOS)

22 Feb 2011

Durch einen Blogpost bei microformats.org sind wir auf eine (mögliche) Lösung für das alte Problem gestossen, dass bestimmte Microformate für Screenreader-Nutzer zu Problemen führen können (wir berichteten). Demnach ist es wohl nun endlich möglich, bei der Auszeichnung von kalendarischen Daten auf das problematische abbr-design-pattern zu verzichten.

Statt das Datum (wie bisher zwingend vorgeschrieben) mit einem semantisch fragwürdigen abbr auszuzeichnen kann man nun auch ein leeres span mit den maschinenlesbaren Informationen versehen:

 <p class="vevent">
  <span class="dtstart">
    <span class="value-title" title="2011-02-22"> </span> 
    Dienstag, 22. Februar 2011
  </span>
 </p>

Das hierzu benutzte value-title-pattern ermöglicht es Werkzeugen wie der Firefox-Erweiterung Operator, die ISO-datetime trotzdem auszulesen und z.B. in einen Kalendereintrag zu übersetzen; Screenreader hingegen sollten diese kryptischen Daten nun nicht mehr automatisch vorlesen.

»In short, by placing the machine readable ISO datetime into the title attribute of a harmless empty span element adjacent to the human readable date and time, we are able to achieve a pragmatic balance between user experience, content fidelity, and minimizing the effects of what is essentially duplicating the data (a DRY violation, something we avoid due to potential inconsistencies unless absolutely necessary for a greater principle, such as usability – humans first as it were).«

Damit umgeht man elegant das Problem, mit den bestehenden Möglichkeiten des Markups Dinge ausdrücken zu wollen, die in diesem begrenzten Wortschatz gar nicht vorgesehen sind und unter Umständen ›falsch‹ interpretiert werden – im konkreten Fall verhindert man damit, dass ein Screenreader je nach Einstellung, »Zwanzig Millionen Einhundertzehntausend Zweihundertzweiundzwanzig« statt des heutigen Datums vorliest.

Weil uns die Idee so gefallen hat, haben wir sie gleich einmal auf der aktuellen Veranstaltungs-Seite umgesetzt. Zum Vergleich: hier die Seite für das laufende Jahr 2011 mit dem geänderten Code und die 2010er-Seite mit der unter Umständen etwas weniger zugänglichen alten Variante.

12 Mai 2010

Wie klingt eigentlich eine Website? Das ist eine Frage, die vor allem Blinde beantworten können. Blinde und Sehgeschädigte gehören zu den intensivsten Nutzern des Internet. Wie sie das Netz nutzen, erfahren Sie in dieser dreiteiligen Artikelserie.

Am Beispiel von Texten wollen wir zunächst zeigen, wie Blinde eine optische Oberfläche für sich zugänglich machen. Im zweiten Teil wird es um die Nutzung multimedialer Angebote gehen. Wie Blinde selbst Inhalte im Web bereit stellen, erfahren die Leser im dritten Teil.

Die graphische Benutzeroberfläche und der Screenreader

Um einen Computer nutzen zu können, verwenden Blinde einen Screenreader. Dieses Programm gibt visuelle Inhalte wie Menüs oder Texte als Sprache oder als Blindenschrift auf einem Braille-Display aus. Die Steuerung erfolgt vollständig über die Tastatur. Die Zugänglichkeit der Programme ist sehr unterschiedlich, manche Programme lassen sich sehr gut über Tastatur und Screenreader bedienen, andere gar nicht.

Weiterlesen …

Das Internet gehört zu den wichtigsten Bereichen der Computernutzung und ist über Screenreader generell gut zu erreichen. Der Screenreader orientiert sich nicht am optischen Erscheinungsbild, sondern an der Struktur einer Website. Elemente, die für den sehenden Nutzer parallel erscheinen, sind für den Nutzer von Screenreadern linear angeordnet.

Während der Sehende mit einem Blick wichtige Elemente wie die Navigation und Text von Schmuckelementen wie Bannern oder Werbung unterscheiden kann, gilt es für den Blinden, zunächst alle Elemente der Website einmal zu erfassen, um sich auf der Website zurecht finden zu können. Der Inhalt von Bildern, Graphiken und Animationen bleibt für Blinde unsichtbar.

Texte und Foren

Normale Fließtexte stellen in der Regel kein Problem dar. Die kleine Anwendung RSS hat dabei zu einer wesentlichen Verbesserung geführt. Die Feeds erlauben das bequeme Lesen der Artikel, ohne die jeweiligen Seiten durchnavigieren zu müssen. Schwieriger sieht es bei komplexen Angeboten aus, wir wollen das hier am Beispiel von Foren deutlich machen.

Die klassischen Foren basieren auf der sogenannten Baumstruktur. Die Baumstruktur erlaubt das Erkennen von Diskussionssträngen. Der Nutzer sieht auf den ersten Blick, wer auf wen geantwortet hat. Für den Blinden ist das allerdings nicht erkennbar. Ebenfalls problematisch ist, dass Beiträge nur einzeln angezeigt werden. Der Screenreader muss bei jedem Aufruf die Seite neu einlesen und beginnt am Anfang der Seite. Der Blinde muss bei jedem Seitenaufruf nach dem Anfang des Beitrags suchen, ohne zu wissen, ob tatsächlich etwas lesenswertes in dem Beitrag steht. Manche Diskussionsfäden ziehen sich über Dutzende von Beiträgen, so dass selbst Normal-Sehende hier nicht alle Beiträge lesen würden.

Günstiger sind die Newsboards, wo die Antworten untereinander angeordnet werden, hier ist zumeist auch für den Sehenden nicht erkennbar, wer auf wen geantwortet hat. Das Projekt selfHTML hat das in seinem Forum elegant gelöst: Oben auf der Website wird der Forenbaum angezeigt, darunter werden alle Beiträge untereinander eingeblendet.

E-Mails als Austauschmedium

Viele Blinde bevorzugen für Austausch und Diskussionen E-Mails. Auf der Plattform Blindzeln gibt es über 70 Mailinglisten zu so verschiedenen Themen wie Kochen, Lesen oder Blindenhunden.

Das Mailprogramm bietet ein einheitliches Erscheinungsbild und hat viele Funktionen, die Foren und Newsboards entweder gar nicht bieten oder die für Blinde nur schwer oder gar nicht zugänglich sind:

  • die Absender sind leicht erkennbar
  • die Nachrichten lassen sich einfach nach Absender, Datum oder Thema sortieren
  • die Diskussionsstränge lassen sich anhand der Betreffzeile erkennen

Der größte Vorteil besteht darin, dass alle Funktionen des Mailprogramms per Tastatur zugänglich sind.

Der Nachteil dieser Mailinglisten ist allerdings ebenso offensichtlich: Obwohl auch Menschen ohne Sehschädigung bei Blindzeln willkommen sind, bevorzugen die meisten Sehenden für sie attraktivere Austauschmedien. Was für den Blinden übersichtlich und einfach ist, wirkt auf den Sehenden unübersichtlich und textlastig.

Die Kommunikation verlagert sich zunehmend von E-Mails hin zu Statusmeldungen über Twitter oder zum Nachrichtenaustausch innerhalb der sozialen Netzwerke.

Zudem entgehen den Blinden wichtige Informationen und Hilfsmöglichkeiten, wenn sie gezielt Foren ausweichen. Foren werden gern zur Selbsthilfe genutzt und oftmals sind die hier gegebenen Antworten hilfreicher als die Hilfeseiten professioneller Anbieter.

Komplexe Anwendungen und Interaktion

Komplexe Websites erfordern einen hohen Lernaufwand des blinden Nutzers und sind daher oft nicht attraktiv. Schwierig sind zum Beispiel Shopping-Angebote und Online-Auktionen. Grundlegende Informationen wie Preise, Artikelbeschreibung oder allgemeine Geschäftsbedingungen sind zumeist noch erschließbar. Schwierig ist vor allem die Interaktion mit der Website, wenn es um die Eingabe von Daten und die Zahlungsmodalitäten geht. Die Shop-Betreiber setzen zumeist auf Technologien, die vom Screenreader nicht unterstützt werden, die nicht mit der Tastatur bedienbar sind und deren Rückmeldungen oft nicht verständlich sind.

Die Folgen können hier sehr schwerwiegend sein, wenn etwa aus Versehen falsche Artikel bestellt werden. Deswegen bleiben viele Blinde lieber bei den Webseiten, die sie gut genug kennen, um sie bedienen und überschauen zu können.

Screenreader testen

Mittlerweile hat jeder die Möglichkeit, selbst mit Screenreadern zu experimentieren: Unter Windows gibt es die freien Screenreader NVDA und Thunder, die Linux-Distributionen Ubuntu und Knoppix haben von Haus aus die Screenreader Orca und ADRIANE an Bord. Die Apple-Betriebsysteme werden mit dem Screenreader VoiceOver ausgeliefert. Die professionelle Nutzung eines Screenreaders erfordert allerdings viel Erfahrung und Übung.

25 Mär 2010

Immer wieder erreichen uns Anfragen, warum der Webauftritt von ›Einfach für Alle‹ nicht gegen HTML 4 und CSS 2 validiert. Die Antwort ist einfach: Barrierefreiheit ist uns wichtiger als valider Code. EfA setzt auf neue Techniken aus der WAI-ARIA-Spezifikation des W3C, um die Zugänglichkeit unseres Angebots zu verbessern.

Der letzte Arbeitsentwurf der WAI-ARIA stammt vom 15. Dezember 2009. Ähnlich wie bei HTML5 gelten einige der Spezifikation schon als stabil und werden von aktuellen Browsern und Hilfsprogrammen unterstützt.

WAI-ARIA erlaubt unter anderem das Definieren von Orientierungspunkten einer Website: Wichtige Elemente wie die Navigation oder der Inhaltsbereich können eindeutig benannt und angesteuert werden. Bei Formularen erlaubt WAI-ARIA das eindeutige Kennzeichnen von Pflichtfeldern. Die endgültige Version der WAI-ARIA sieht auch das Steuern von Schiebereglern und die Verwendung komplexer AJAX-Anwendungen vor.

Diese Eigenschaften werden auch von aktuellen Browsern wie dem Firefox 3, dem Screenreader Jaws 10 und einigen anderen Browsern und Hilfsprogrammen unterstützt. Auch das am 1. Februar 2010 gestartete neue Portal der Aktion Mensch verwendet bereits WAI-ARIA.

Die derzeit aktuellen Versionen von HTMLHTML 4.01 und XHTML 1.0 – kennen die WAI-ARIA noch nicht, deshalb lassen sich unsere aktuellen Websites nicht validieren.

11 Sep 2009

Wenn Sie eine tagewochenlange Diskussion unter Webentwicklern lostreten wollen, dann müssen Sie nur mal in einem Forum oder bei Twitter die Frage stellen, ob man mehr als eine <h1> pro Seite verwenden darf, und wenn ja, wofür. Danach können Sie sich entspannt zurücklehnen und Wetten auf den Zeitpunkt abschliessen, an dem die Diskussion vollends aus dem Ruder läuft.
Dabei findet die ganze Diskussion nur deshalb statt, weil es historisch bedingte Lücken in der HTML-Spezifikation gibt. Warum das so ist, wo diese Lücken sind und wo sie herkommen, was man dagegen machen kann und wie das Thema in Zukunft aussehen wird zeigt der Artikel »Passende Überschrift hier einsetzen«.

01 Sep 2009

Opera

Opera 10 ist ab sofort ohne ›beta‹ und ›release candidate‹ dahinter als fertige Version erhältlich (Download, alternativ per FTP, Packungsbeilage). In der neuen Version ist die WAI-ARIA-Unterstützung ausgebaut worden; viele Neuerungen gab es auch im Bereich CSS – allerdings nur bis zur Version 2.1 (inklusive der HSL- und RGB-Farbräume mit Alpha-Transparenz und Web-Fonts mit @font-face); weitergehende Dinge aus CSS 3 wie das CSS-Column-Modul oder multiple Hintergrund- und Rand-Bilder sind offenbar noch nicht implementiert. Was sonst noch alles neu ist erklärt Chris Mills in der Opera Developer Community: »The Opera 10 experience«, oder im YouTube-Video »Opera 10 Reviewer's Guide«.

JAWS

Eine Nummer weiter ist ab sofort auch der Screenreader JAWS, von dem eine öffentliche Beta der Version 11 bereitsteht (Download, Packungsbeilage). Auch hier hat sich einiges im Bereich der Zugänglichkeit von Web-Applikationen getan – so werden in der neuesten Version ARIA Drag & Drop sowie ARIA Live Regions unterstützt.

27 Jul 2009

Eher was für richtige Programmierer oder solche die es werden wollten: Wenn Sie schon immer mal wissen wollten wie das eigentlich funktioniert, dass ein Screenreader was mit dem Zeugs anfangen kann das da auf dem Bildschirm zu sehen ist – bei code-magazine.com ist vor einiger Zeit ein Sonderheft zum Thema ›Windows Accessibility Focus‹ erschienen, in dem das alles erklärt wird. Die Artikel gibt es entweder als (leider nicht barrierefreies) PDF zum herunterladen oder einzeln in HTML-Form. So zum Beispiel:

Einige der Artikel sind aber auch für profane Web-Entwickler sehr gut zu gebrauchen:

10 Mär 2009

In der kleinen Laborbericht-Serie zu unserem vergangenen Relaunch hatten wir öfters eine Abkürzung benutzt, die das Potenzial hat, das nächste große Ding zu werden: WAI-ARIA (›Accessible Rich Internet Applications‹). Damit werden Ergänzungen zu HTML beschrieben, die vorhandene Lücken in den Spezifikationen stopfen sollen. So lässt sich zum Beispiel in Web-basierten Applikationen ein Schieberegler auszeichnen – ein Element, dass es in HTML (noch) nicht gibt. Dieser wird dann z.B. in einem Screenreader auch als solcher angesagt und nicht als eine Ansammlung sinnfreier div.

Der Entwurf hat mittlerweile den Status eines Last Call Working Draft erreicht; die übliche Kommentierungs-Phase läuft bis zum 24. März. Es ist also mit einer baldigen Fertigstellung zu rechnen, zumal die Browser- und Hilfsmittel-Hersteller bereits fleißig implementieren.

Deswegen ein paar gesammelte Links als Ergänzung zu unserer Serie, falls Sie tiefer in die Materie einsteigen wollen:

Weiterlesen …

Lesenswertes:

Ohne die Unterstützung durch Browser und Hilfsmittel geht es natürlich nicht:

Einen noch zum Schluss: wie man am besten mit Screenreadern testet (oder noch besser: echten Screenreader-Nutzer testen lässt) erklärt Henni Swan von Opera: »Setting up a screen reader test enviroment«.

02 Mär 2009

Wie üblich haben uns auch beim letzten Relaunch viele Rückmeldungen und kritische Anmerkungen (und in seltenen Fällen sogar Lob) per E-Mail oder über die Kontakt- und Kommentarformulare erreicht. Zu einigen Punkten hatten wir ja bereits ausführlich was geschrieben; heute geht es um einen Teil des HTML-Codes dieser Seiten, der schon öfter Anlass zu Diskussionen war: die »Tag Cloud«, auch Schlagwort- oder Stichwortwolke genannt.

Laut Wikipedia ist eine Tag Cloud »eine Methode zur Informationsvisualisierung, bei der eine Liste aus Schlagworten alphabetisch sortiert flächig angezeigt wird, wobei einzelne unterschiedlich gewichtete Wörter größer oder auf andere Weise hervorgehoben dargestellt werden.« Lustigerweise ist die Tag Cloud in der linken Spalte eines der wenigen Code-Fragmente, die nicht nur den letzten Relaunch, sondern auch einige Relaunches davor unbeschadet überstanden hat – das zu Grunde liegende Konstrukt hat sich also seit Jahren nicht geändert. Aber wie bei jedem Relaunch erreichen uns wohl-gemeinte Tipps, wie man diese Tag Clouds besser umsetzen und semantisch anreichern könnte (womit sich mal wieder die alte Regel bewahrheitet, dass die Menge des Diskussionsbedarfs immer umgekehrt proportional zur Komplexität des Problems ist).

Weiterlesen …

So auch diesmal:

»… die Größe eines Links in der Tag-Cloud habt Ihr ja mit "strong in strong in strong …" realisiert. Ich habe gerade mal mit JAWS etwas herumgespielt, vor allem mit dem Konfigurationsmanager, und da keine Einstellung gefunden, mit der ich mir die Anzahl der strong-Tags vorlesen lassen kann. Daher mein Tipp: Schreibt doch die Nummer der strong-Tags als Zahl in Klammern hinter den jeweiligen Link und schiebt das dann per CSS aus dem Viewport. In der Überschrift ›Themen:‹ schreibt Ihr das halt als ›(Beliebtheit als Zahl in Klammern)‹, ebenfalls versteckt, dahinter. Das ist zwar so knapp, dass man erst nicht weiß, ob der Zahlenwert mit der Beliebtheit steigt oder ob es hier umgekehrt proportional gesehen werden muss, aber das wird spätestens bei der vier für HTML klar.«

(Detlef Girke per E-Mail)

Zum Hintergrund des ganzen: unsere Tag Cloud besteht aus einer Liste von Einträgen, die alphabetisch sortiert als Unordered List (UL) angelegt sind, jeder Eintrag steht in einem separatem List Item (LI). Wir bekamen auch einige Mails mit Vorschlägen, statt der UL doch eine geordnete Liste (OL) zu nehmen – danke für die Vorschläge, aber das Kriterium zur Sortierung der Einträge ist das Alphabet – damit sind die (zusätzlichen) Ordnungszahlen komplett überflüssig und bringen dem Nutzer keine brauchbaren Erkenntnisse.

Eine Sortierung nach Häufigkeit würde ebenfalls keinerlei Vorteile für den Nutzer bringen. Zum einen wäre für den Nutzer die Orientierung entlang des Alphabets dahin; zum anderen würde sich diese Sortierung auch laufend ändern. Ein weiteres Problem bleibt dadurch ebenfalls ungelöst: in den vergangenen Jahren haben wir sehr viel über HTML & CSS gebloggt, entsprechend viele Treffer gäbe es bei einer Sortierung nach diesen Tags. Nun gibt es aber Techniken wie z.B. WAI-ARIA, die relativ neu sind und daher in Summe nicht so häufig im Blog vorkommen – aber genau von diesen Beiträgen möchten wir, dass sich unsere Leser damit beschäftigen und eine alleinige Sortierung nach Häufigkeit käme einer Abwertung gleich und ginge somit am Ziel vorbei. Im Ernstfall würde man damit höchstens den Digg-Effekt erreichen, bei dem alle User auf das Ding mit der höchsten Zahl draufklicken.

Im Urzustand sieht unsere listenförmige Tag Cloud folgerichtig so aus:

  1. <div id="tagcloud">
  2. <h4>Themen:</h4>
  3. <ul>
  4. <li><a href="/blog/tags/ajax/" rel="tag">AJAX</a></li>
  5. <li><a href="/blog/tags/atag/" rel="tag">ATAG</a></li>
  6. [...]
  7. </ul>
  8. </div>

Allerdings ist dies noch nicht alles, und genau daran entzündet sich die Kritik: je nach Häufigkeit des Tags enthält der Link noch ein oder mehrere <strong> – je häufiger, desto mehr <strong> sind dort hineingeschachtelt:

  1. <li><a href="/blog/tags/bitv/" rel="tag"><strong><strong>BITV</strong></strong></a></li>

Durch geschicktes Ausnutzen der Vererbungen in CSS wird der enthaltene Linktext immer größer, je öfter strong ineinander verschachtelt ist:

  1. #tagcloud li strong {
  2. font-size: 1.1em;
  3. }

Nun bezieht sich einige Kritik darauf, dass <strong> unsemantisch sei – leider konnte uns jedoch bisher noch niemand eine echte, passendere Alternative aufzeigen. Kurzfristig hatten wir über die Verwendung von <small> & <big> zur Gewichtung der Einträge nachgedacht, aber dann davon abgesehen. Nicht weil es unpassend wäre (wobei: eventuell wäre es sogar passender und damit ehrlicher gewesen), sondern weil dies wohl einen Sturm der Entrüstung hervorgerufen hätte. Das Problem bleibt also: HTML bietet kein 100%-ig passendes Element zur semantisch korrekten Auszeichnung von Gewichtungen in Tag Clouds an. Also läuft es (wie so oft in HTML) auf eine Annäherung hinaus, die nach den Prinzipien der Einfachheit diejenige sein sollte, die am wenigsten stört (›least obtrusive‹) und dem Nutzer nichts vorgaukelt, das effektiv nicht vorhanden ist bzw. die Handhabung für den Nutzer nicht unnötig verkompliziert. Eben einfach.

Daher hatten wir uns damals nach intensivem Nachdenken für <strong> entschieden, eben genau weil mit <strong> ausgezeichneter Text in sämtlichen uns bekannten Screenreadern nicht anders vorgelesen wird als herkömmlicher Text ohne <strong> (wie übrigens bei <big> & <small> auch nicht, neben einer ganzen Reihe anderer, seit über einem Jahrzehnt spezifizierter Elemente).

Gleich mehrere Mails und IMs beschäftigten sich mit der Frage, ob man die Gewichtung dem Screenreader-Nutzer dann nicht besser durch die Ansage der Zahl der gefundenen Treffer mit diesem Tag mitteilen sollte. Auch mit diesem Vorschlag haben wir ein paar Probleme:

  1. Wenn die Zahlen einen Nutzwert haben sollen, dann müsste sich der Nutzer beim durchhören der Tag Cloud die Zahlen merken, dann nochmals zurückgehen und dann auf Basis der Zahlen als Entscheidungskriterium (Welcher Zahl? Der höchsten? Der niedrigsten? Dem Mittelwert?) entscheiden, welchem Link er folgt. Was aber nicht das eigentliche Problem des Vorschlags löst, nämlich:
  2. Warum sollte ein Nutzer einen Link anklicken, nur weil ihm die (hohe oder niedrige) Zahl irgendwie zusagt? Wenn jemand nach Tipps zu CSS sucht, dann ist es für ihn vollkommen unerheblich, ob da nun 2 oder 20 oder 200 Einträge dahinter sind. Weder wir noch der Benutzer können wissen, ob das Gesuchte gefunden wird (und zwar vollkommen unabhängig von der Anzahl; und nein, die Wahrscheinlichkeit das Gesuchte zu finden steigt nur unwesentlich mit der Zahl der verlinkten Blog-Beiträge).

Die wesentliche Information ist auch jetzt schon der verlinkte Text (›BITV‹, ›CSS‹, …), alles darüber hinaus wäre nicht Beiwerk oder zusätzlicher Komfort, sondern akustischer Müll. Wir glauben nicht, dass allzu viele Nutzer zu EfA kommen nur um nachzulesen, wie viel wir über ein bestimmtes Thema berichten – das ist vielleicht später mal für Archäologen interessant, aber nicht hier und jetzt für die Nutzer, die sich über bestimmte Themen informieren wollen.

Daher können wir auch den Nutzwert einiger Tutorials nicht nachvollziehen, die man zu dem Thema im Netz findet. Mark Norman Francis hatte im Dezember 2006 im Adventskalender von 24 ways eine Anleitung veröffentlicht, die nach seiner Auffassung alle Probleme löst und somit absolut barrierefrei zugänglich sei. Im fertigen Code-Beispiel stehen zusätzliche Informationen über die Anzahl zwar im HTML innerhalb des Links, diese werden aber per CSS aus dem Viewport geschoben.

In die gleiche Richtung geht ein neuerer Artikel »Semantische Tag Cloud« im SELFHTML aktuell Weblog, auf den Wolfgang Wiese per IM hinwies: auch hier werden zusätzliche (für grafische Browser wiederum versteckte) Infos wie »eher selten«, »ausgesprochen häufig«, usw. in die Tag Cloud geschrieben – allerdings ausserhalb der Links:

  1. <ul>
  2. […]
  3. <li><span style="font-size:169%"><a href="linkziel">Arzt-Suchdienst</a></span><span class="ignore"> ausgesprochen häufig</span></li>
  4. […]
  5. </ul>

Leider zeigen beide Ansätze bei genauerem Hinsehen, dass sie wohl kaum mit echten Screenreader-Nutzern getestet sein können, denn beide Ansätze haben grundsätzliche Probleme:

  1. Entweder lässt der Screenreader-Nutzer sich das alles vorlesen – dann steigt der Nutzer nach unserer Erfahrung ob der Menge der unnützen Zusatzinfos nach der Hälfte der Tag Cloud aus; oder
  2. Der Screenreader-Nutzer tabbt durch die Tag Cloud (von Link zu Link) – dann wiederum bleibt ihm die Zusatzinfo verborgen, wenn diese ausserhalb der Links steht. Und nein, die Infos in die Links selbst reinzuschreiben ist wie gesagt auch keine Lösung, weil dann wieder Punkt 1 greift.

Und deswegen ist die Tag Cloud so wie sie ist.

Nachtrag:

(Tipp von Rainer Schlegel via E-Mail)

09 Feb 2009

Im Chaosradio Express №107 unterhalten sich Tim Pritlove, Jan Eric Hellbusch und Tomas Caspers fast zwei Stunden lang über Grundsätzliches und Aktuelles aus dem Bereich Barrierefreiheit im Web – Was man bedenken sollte, wenn man Websites plant und gestaltet (Kommentare, Mitmachseite, Direkter Download der Mediendatei, ca. 80 MB).

Unter anderem geht es um folgende Themen: The Web Standards Project; Auswirkung der Farbwahl in Webseiten für Farbfehlsichtige; Bedeutung der Struktur und semantischem Markup für blinde Nutzer; Vorteile von barrierefreiem Design für nicht-behinderte Nutzer; Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen; Aspekte der Gebärdensprache; Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C und WAI-ARIA; Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.

31 Okt 2008

Für Webentwickler bedeutete die Umstellung von Tabellen auf CSS, dass sie alte Gewohnheiten vergessen mussten. Sämtliche Techniken und Kniffe aus den Zeiten von Layout-Tabellen sind scheinbar »verlernt«. Das richtige Umsetzen echter Datentabellen erfordert jedoch eine Rückbesinnung: man muss sich wieder mühsam in die Spezifikationen einlesen und in das Tabellenmodell von HTML hineindenken.

Wie man tabellarische Daten so aufbereitet, dass sie nicht nur hübsch aussehen, sondern auch mit den assistiven Programmen von Menschen mit Behinderung optimal nutzbar sind erfahren Sie in unserer neuen Serie: »Benimmregeln für Datentabellen«

25 Jun 2008

Wer schon mal Web-Applikationen mit einem Screenreader getestet hat, der kennt das Problem: bei asynchronen Änderungen (vulgo: AJAX) ist noch lange nicht garantiert, dass die Änderungen tatsächlich an den Screenreader weitergereicht und von diesem entsprechend vorgelesen werden. Viel öfter passiert es, dass ein veralteter Zustand der Seite aus dem Lautsprecher kommt, der nicht mehr dem aktuellen Inhalt entspricht, so wie er auf dem Bildschirm zu sehen wäre.

Kommt die Änderung hingegen durch ein synchrones Update des DOM zu Stande (z.B. indem der Screenreader-Nutzer ein Formular per Button absendet), so wird der Speicher des Screenreaders korrekt aktualisiert. Nur dann wird der richtige Inhalte vorgelesen. In Zeiten von AJAX und den kurz vor fertigen WCAG 2 hilft das aber auch nichts: Web-Applikationen müssen ganz old-school-mäßig ohne, aber eben auch mit JavaScript funktionieren und zugänglich sein. Zumal sich jede einzelne Nutzeraktion auf diese Weise mit einen Eintrag im Browser-Verlauf verewigt – was je nach Applikation auch nicht unbedingt erwünscht ist.

Und wie so oft liegt das Problem mal wieder am Browser. Genauer gesagt (Sie konnten es sich bestimmt schon denken) am Internet Explorer inklusive der aktuellen Version 7, der solche asynchonen Änderungen nicht über die entsprechende Schnittstelle nach aussen kommuniziert. Auch wenn verbreitete Screenreader wie JAWS ab Version 7.1 mittlerweile eigene Methoden haben, um Änderungen im DOM einer Seite zu beobachten und wiederzugeben, so ist die Freude darüber verfrüht: es betrifft nur einen Screenreader mit einem speziellen Browser; das Verhalten ist (wie vieles in Hilfsmitteln) undokumentiert und entspricht keinem formellen Standard – also sollte man sich besser nicht darauf verlassen.

Auftritt ARIA:

Jetzt wo selbst der kommende IE 8 den zukünftigen WAI-ARIA-Standard unterstützen wird, zeichnet sich ein wenig Entspannung ab (Firefox ab 1.5, Opera ab 9.5 und zuletzt auch Safari hatten bekanntlich hier schon vorgelegt). Also könnte man sich als Anbieter von Web-basierten Applikationen ruhig schon mal mit ARIA beschäftigen.

Mama, der Hixie hat mir das X weggenommen!

Wenn, ja wenn da nicht eine ziemliche Spaßbremse wäre – denn ob der Standard, der ja ursprünglich mal nur als temporäre Zwischenlösung gedacht war, in absehbarer Zeit fertig werden wird steht auf einem anderen Blatt Papier. Mal ganz im Vertrauen und unter uns: die HTML-Arbeitsgruppe des W3C macht im Augenblick nicht den Eindruck, als könne man sich auf den korrekten Belag einer Wurschtsemmel einigen.

Aber was soll's, eigentlich wollten wir nur eine Linkschleuder zum Thema ARIA loswerden, jetzt ist die Einleitung halt was länger geworden. In diesem Sinne:

24 Jun 2008

Für Screenreader unzugängliche Microformats fliegen raus. Zumindest bei der BBC, die ab dem nächsten Update ihrer Programmvorschau auf solche Microformats verzichtet, die das umstrittene abbr-Design-Pattern benutzen: »BBC - Radio Labs - Removing Microformats from bbc.co.uk/programmes«. Zur Erinnerung hier nochmal die Gründe: