accessBlog

News mit dem Tag »Sehbehinderung«

03 Mai 2013

Der Social-Media-Dienst Twitter wird auch von blinden und sehbehinderten Menschen gerne genutzt. Für schnellen, mehr oder weniger tiefsinnigen Gedankenaustausch, aber immer knapp formuliert in maximal 140 Zeichen.

Twitpicdescription – ein Tool, das Twitter-Nutzern mit Sehbehinderung Bilder zugänglich machen kann …

Neulich in meiner Timeline (so nennt man die Nachrichtenübersicht bei Twitter): Eine blinde Twitter-Nutzerin bittet einen Bekannten in ihrer Timeline um die Beschreibung eines Bildes, das er soeben getwittert hatte. Sie wollte einfach die Diskussion verstehen, die sich auf das Bild bezog, das sie ja nicht sehen konnte. Nach einigem Hin und Her kamen Aussagen wie »Das geht nicht bei verlinkten Bildern«. Und noch etwas später: »Ich frage mich jedoch, ob ich wirklich aus Solidarität auf meine visuellen Scherze verzichten sollte.«

Der Hintergrund dieser Konversation: Auf Twitter kann man auch Bilder veröffentlichen. Dem Charakter von Twitter entsprechend handelt es sich dabei oft um lustige oder provozierende, häufig zu Kommentaren oder Diskussionen anregende Bilder. Man kann den Frust der blinden Frau verstehen, die die Diskussionsbeiträge zwar lesen, aber nicht verstehen konnte, weil die Diskussionsgrundlage, das Bild, für sie nicht zugänglich war. Aber auch die Reaktion „… auf meine visuellen Scherze will ich nicht verzichten [… nur weil auch blinde Menschen meine Tweets lesen]« ist verständlich. Es gibt Bilder, die für sich sprechen, die man nicht kommentieren darf, ohne die Pointe vorwegzunehmen. Wissen sollte man in diesem Zusammenhang auch, dass blinde Menschen häufig eine erstaunliche Fähigkeit entwickelt haben, sich aus wenigen Hinweisen »ein Bild zu machen«. Aber ganz ohne Hinweise – in diesem Fall ohne eine Beschreibung des Bildes – kann das nicht gelingen.

Da Twitter selbst keine entsprechende Möglichkeit bietet und ich mich mit der Aussage »Das geht nicht« nur ungern zufrieden gebe, habe ich ein Online-Tool geschrieben, das genau den beschriebenen Fall abdeckt: www.twitpicdescription.de oder w7t.de Das Tool ist kostenlos online verfügbar und weitgehend selbsterklärend. Es erfordert allerdings vom Anwender, vom Ersteller der Bildbeschreibung, etwas Mühe, und vor allem Problembewusstsein.

Der URL – die Adresse des Bildes im Web, z. B. bei Twitter – muss ausfindig gemacht und zwischengespeichert werden (in der Regel reicht dazu ein Mausklick rechts). Und – das dürfte vielen Menschen tatsächlich Mühe bereiten – es muss eine Bildbeschreibung formuliert werden. Knapp, aber so aussagefähig, dass der blinde Leser sich daraus ein zutreffendes Bild machen kann.

Zum Thema Problembewusstsein: Nicht jedes Foto auf Twitter verlangt nach einer Beschreibung. Bestimmt nicht die vielen Reisefotos, und noch weniger das Foto von der Pizza des Tages. Aber ein Foto der Tageszeitung mit der aktuellen Schlagzeile, ein geistreicher Cartoon oder ein Foto mit einer speziellen Aussage könnten lohnende Objekte sein. Glücklicherweise tragen gerade solche Bilder oft ihre eigene Bildbeschreibung in sich. Man denke an die Sprechblasen in Cartoons oder die lustige Beschriftung eines Plakats. Aber Bilder bleiben Bilder, ob mit oder ohne Text, und Bilder können auch von modernen Screenreadern (Bildschirmlesegeräten) nicht ausgelesen werden, bleiben blinden und sehbehinderten Menschen also unzugänglich. Als Beispiel für die vom Tools erzeugte Ausgabe eine mit twitpicdescription.de beschriebene Grafik: Web-Adresse: w7t.de/a/50fdad8ea81bc.php Die Bildbeschreibung in obigem Beispiel wurde im Tool als »Beschreibung unsichtbar, nur für Screen Reader lesbar« markiert. Sehende Betrachter lesen nur den knappen Hinweis auf eine existierende Bildbeschreibung, nicht aber die Beschreibung selbst. Sie lautet in Klarschrift: »Probleme intellektueller Paare: Sie: Lass uns doch mal wieder ausgehen. Er: Wovon?« – So einfach kann es sein!

10 Okt 2011

Die Praxis zeigt, dass Formulare häufig weder benutzerfreundlich noch barrierefrei sind. In unserer Formularserie hatten wir das Testen von Formularen bereits ausführlich behandelt. An dieser Stelle wollen wir aufzeigen, welche Probleme in der Praxis entstehen können, wenn Formulare nicht ausreichend getestet wurden. Wir nehmen hier ein Beispiel, das es so gegeben hat. Es handelt sich dabei um eine einfache Umfrage, die mittlerweile nicht mehr online steht.

Weiterlesen …

Bei dem Formular handelt es sich um eine Umfrage mit vielen Checkboxen, ein paar Radio-Buttons, zwei Eingabefeldern, einem Auswahlfeld und einem Absendebutton. In einem kurzen Einleitungstext wird der Inhalt und Zweck der Umfrage zusammengefasst. Die Umfrage selbst besteht aus mehreren Blöcken, pro Block kann zwischen etwa zehn Optionen per Checkbox ausgewählt werden.

Screenshot des Formulars

Das Formular wird nicht clientseitig validiert, das heißt, Fehler bei der Eingabe werden erst nach dem Absenden des Formulars und dem Neuladen der Seite angezeigt.

Fehler 1: Ungeschickte Auswahl von Formularelementen

Das Formular umfasst mehrere Blöcke mit Checkboxen. Man kann alle Checkboxen auswählen, wobei jede Checkbox eine Option darstellt. Außerdem gibt es eine Checkbox für ›alles‹, man kann also alle Optionen des Blocks auswählen.

Falsch: Man darf aus irgendeinem Grund nur drei Checkboxen pro Bereich auswählen, kann aber beliebig viele aktivieren. Hat man die Checkbox ›alles‹ ausgewählt, darf keine der anderen zu diesem Block gehörenden Checkboxen ausgewählt sein.

Mit anderen Worten: ein blinder Nutzer muss mit seinem Screenreader nach dem Ausfüllen und Versenden des Formulars alle Checkboxen des fehlerhaften Blocks noch einmal durchgehen und an- bzw. abwählen, bis er auf maximal drei aktive Checkboxen oder die Checkbox ›alles‹ kommt. Er muss sich außerdem merken, wie viele Checkboxen er schon aktiviert hat, denn sehen kann er das natürlich nicht.

Dazu kommt noch ein Fehler in der Logik des Formulars: man darf entweder eine begrenzte Zahl von Optionen auswählen oder alle Optionen. Es leuchtet nicht ein, warum man sich entscheiden soll zwischen drei Optionen oder ›alles‹.

Checkboxen sollten deshalb nur eingesetzt werden, wenn die Zahl der wählbaren Optionen unbegrenzt ist.

Fehler 2: Mangelnde Ausfüllhilfe

Wenige Formulare sind wirklich selbsterklärend. Es ist daher sinnvoll, den Nutzern Ausfüllhilfen anzubieten. Die Zahl auswählbarer Optionen sollte unmittelbar nach der zugehörigen Frage genannt werden.

Bei dem genannten Formular gab es diese Ausfüllhilfen nicht. Es fehlte eine generelle Anleitung, wie das Formular auszufüllen ist. Erst in den Fehlermeldungen tauchen die Hinweise auf, wie viele Optionen ausgewählt werden dürfen.

Fehler 3: Schlechte Formulararchitektur

Bei umfangreichen Formularen ist eine Aufteilung der Blöcke auf mehrere Seiten sinnvoll. Bei diesem Formular hätte sich das angeboten, weil die Fehlerkorrektur für Blinde schlicht unzumutbar ist. Der Blinde muss jeden einzelnen Block darauf hin prüfen, ob dort eine Fehlermeldung vorhanden ist und im schlimmsten Fall jeden Block einzeln korrigieren. Das ist so mühsam und langwierig, dass es kaum jemand auf sich nehmen wird. Bei der Aufteilung auf mehrere Blöcke würde die Fehlermeldung nach dem Ausfüllen des ersten Blockes auftreten. Es müsste also nur dieser Block korrigiert werden. Außerdem würde ein Lerneffekt eintreten: der Benutzer lernt nach der ersten Fehlermeldung, dass er nur drei Checkboxen pro Block auswählen darf.

Um die Probleme mit diesem Formular zu beheben hätte bereits ein formloser Test mit einigen unbeteiligten Personen ausgereicht. Da dieses Formular ausdrücklich an Menschen mit Behinderung gerichtet war, wäre auch ein Test auf Barrierefreiheit angemessen gewesen. Wir können nur dazu raten, Formulare dieser Art ausgiebig zu testen, um unnötige Abbrüche zu vermeiden. Ein schlecht gestaltetes Formular fällt letztlich auch negativ auf den Anbieter der Webseite zurück.

08 Aug 2011

Funktionale Grafiken sind Grafiken, mit denen eine Funktion verbunden ist. Sie werden auf praktisch allen Webseiten eingesetzt, bekannt sind zum Beispiel das Drucker-, das Brief- oder RSS-Symbol, deren Funktion mehr oder weniger intuitiv erkennbar ist. Sie werden aber auch in komplexen Webanwendungen wie Google Text und Tabellen verwendet.

Die Symbole sind äußerst eingängig, weil wir sie teilweise schon aus anderen Kontexten kennen: den Desktop-Anwendungen, wo sie von Normal-Sehenden und Maus-Nutzern ausgiebig verwendet werden. Abgesehen von Blinden und stark sehbehinderten Menschen kommen diese Grafiken praktisch allen Menschen zugute, wenn sie gut gewählt und eingängig sind.

Weiterlesen …

Sie machen aus einer komplexen Interaktion mit der Website einen einfachen und intuitiven Prozess. Für Menschen mit Lernbehinderungen erleichtern sie ungemein die Bedienung der Seite.

Alternativer YouTube-Player
Screenshot des Players

Christian Heilmanns alternativer YouTube-Player erleichtert die Bedienung durch große und leicht erkennbare Bedienelemente.

Wahl der Grafiken

Um eine Grafik verwenden zu können, sollte sie hinreichend bekannt sein. Webdesigner mögen viel Energie in eine hübschere Metapher zum Einkaufskorb investieren. Das bringt aber nur etwas, wenn die Funktion »Ware in eine Zwischenablage speichern, um sie beim Abschließen des Bestellvorgangs mit weiteren Waren zu bestellen« dem Nutzer deutlich wird. Diese ausschweifende Funktionsbeschreibung macht den Sinn dieser simplen Metapher vom Warenkorb deutlich. Statt langatmige Erklärungen abzugeben, versteht jeder Mensch mit ein wenig Erfahrung im Internet-Einkauf, was der Erschaffer der Seiten mit dem Warenkorb-Symbol mitteilen möchte.

Das gilt natürlich nur für Funktionen, die hinreichend etabliert sind. Nehmen wir an, wir entwickeln eine vollkommen neue Funktion, wenn wir etwa eine neue Webanwendung etablieren. Dann können bzw. müssen wir uns eine eigene Symbolsprache ausdenken, sofern keine Vorbilder vorhanden sind. In diesem Falle kommen wir kaum daran vorbei, dem Nutzer einen Lernprozess zu unterwerfen, indem er bei der Nutzung der Anwendung nach und nach auch die Funktionen der Symbole kennenlernt und die verwendete Bildsprache versteht. Dennoch kann der Lernaufwand möglichst gering gehalten werden, indem eingängige Symbole eingesetzt werden. Für die Erstellung solcher Funktionsgrafiken sollten entsprechend Experten beauftragt werden. Auch Tests zur Verständlichkeit mit echten Nutzern sind empfehlenswert.

Die Größe der Funktionsgrafiken

Jede Grafik muss so groß sein, dass sie mit der Maus gut anzuklicken ist. Die Grafiken müssen einen gewissen Abstand zueinander haben und sie sollten bei normaler Auflösung auf einem mittelgroßen Bildschirm gut zu erkennen und gut anzuklicken sein. Wichtig ist auch, dass die Grafiken per Tastatur angesteuert und aktiviert werden können. Sowohl für Maus- als auch für Tastaturnutzer muss erkennbar sein, welches Element sie gerade fokussiert haben, etwa über einen Rahmen oder eine Farbänderung.

Für Menschen mit motorischen Einschränkungen, die mit einer Maus oder einem speziellen Eingabegerät arbeiten, sind zu kleine Klickflächen und zu eng beieinander stehende Elemente schwierig zu treffen. Das gilt auch für die Nutzer von mobilen Endgeräten wie Netbooks, Tablet-PCs oder gar Smartphones.

Auszeichnung

Blinde benötigen einen Alternativtext, alle anderen Nutzer brauchen den title, um bei Verwendung der Maus zu erfahren, welche Funktion sich hinter der Grafik verbirgt. Ein Briefsymbol könnte eine Kommentarfunktion, eine Leserbrief-Funktion oder ein E-Mail-Formular sein. Für Funktionstexte gilt immer das Gleiche: möglichst kurz, möglichst prägnant, möglichst eindeutig. Es kommt gar nicht so selten vor, dass der Beschreibungstext die Grafik und nicht ihre Funktion beschreibt, zum Beispiel »Pfeil nach links« statt »zurück«: Das Druckersymbol bekommt also den Alternativtext und Titel »Drucken«, das RSS-Feedsymbol wird mit »Feed abonnieren« hinreichend beschrieben.

Grafische CAPTCHAs

Auch CAPTCHAs sind funktionale Grafiken. Ihr Einsatz ist eher kritisch zu sehen. Zwar stellen viele Systeme wie ReCaptcha alternative Audiodateien zur Verfügung, diese sind aber schwer zu verstehen, zumal sie auch nur auf Englisch angeboten werden. Viele Alternativ-Mechanismen funktionieren auch gar nicht, wenn die Nutzer Flash oder JavaScript blockieren. Für Hör-Sehbehinderte sind weder graphische noch auditive Lösungen verwendbar. Wir raten daher generell von der Nutzung von graphischen CAPTCHAs ab. Sie sollten durch nichtgrafische Alternativen wie Rechenaufgaben und einen leistungsfähigen Spamschutz ersetzt werden. Nebenbei bemerkt haben mittlerweile einige Programme eine bessere Erkennungsrate als Menschen.

Fazit

Der bedachte Einsatz von Bildern und Grafiken kann für viele Menschen mit und ohne Behinderung die Nutzung einer Webseite erleichtern. Wie wir gesehen haben, ist das eine Querschnittsaufgabe. Für Platzhalter-, Dekorations- und Funktionsgrafiken sind vor allem Webdesigner und Frontend-Entwickler gefragt. Für inhaltliche Bilder müssen die Redakteure Alternativtexte und Titel vergeben, wofür eine Funktion im Redaktionssystem vorhanden sein muss. Das Regelwerk sieht zwar sehr umfangreich aus, wenn man aber einmal identifiziert hat, um welchen Grafiktyp es sich handelt, ist auch leicht zu entscheiden, wie Alternativtext, Titel und Bildunterschrift aussehen sollten.

01 Aug 2011

Inhaltliche Bilder ergänzen den Inhalt einer Website: Das Foto in einem journalistischen Artikel, das Diagramm der Umfrage-Statistik, das Organigramm der Firma. Ihr Einsatz ist sinnvoll, weil ein Bild die Aussage eines Textes unterstreichen kann und zu viel Text die Leser häufig abschreckt. Infografiken, wie sie im Datenjournalismus eingesetzt werden, können komplexe Sachverhalte und Zusammenhänge anschaulich vermitteln und sind daher eine gute Ergänzung zum klassischen Journalismus.

Weiterlesen …

Bilder in journalistischen und informativen Texten

Bei journalistischen Texten haben die Bilder eine begleitende Funktion. Sie unterstreichen den Inhalt des Textes, der Text bleibt aber auch verständlich, wenn das Bild aus irgendeinem Grund nicht angezeigt wird.

Hier reicht es aus, den Namen der abgebildeten Person, des Ortes oder Gegenstandes zu nennen. Genauer beschreiben sollte man das Bildobjekt nur, wenn es zum Verständnis des Textes beiträgt. Längere Beschreibungen kann man im Bild-Untertitel unterbringen: »Angela Merkel kritisiert die Opposition« ist für Alternativtext oder Bildunterschrift vollkommen ausreichend. Es ist richtig, dass Bilder auch Emotionen oder Stimmungen vermitteln sollen. Allerdings wird dieser Zweck bereits mit dem eigentlichen Fließtext verfolgt. Wenn die Stimmung von Text und Bild nicht übereinstimmt, sollte die Bildauswahl überdacht werden.

Wenn Sie ein abgebildetes Gemälde oder Kunstwerk beschreiben wollen, sollten Sie das ebenfalls im Fließtext tun. Davon profitieren alle Besucher der Website, zumal bei der im Web üblichen Auflösung für Bilder Details nicht gut zu erkennen sind.

Eine besondere Form journalistischer Produkte sind Bilderstrecken oder Fotoreportagen. Die meisten Blinden werden sich wohl nicht mit Bilderstrecken beschäftigen. Dennoch sollten auch diese Bilder Alternativ- und Titeltexte erhalten. Wir empfehlen außerdem, in einem Begleittext den Inhalt der Bilder zu beschreiben. Sehbehinderte erkennen den Inhalt eines Bildes oft erst, wenn sie wissen, was darauf zu sehen ist.

Informationsgrafiken

Informationsgrafiken erleichtern die Aufnahme von Informationen. Welche Aspekte bei ihrer Erstellung zu beachten sind, wollen wir anhand von Diagrammen anschaulich machen.

Für Diagramme ist entscheidend, dass alle Bestandteile deutlich zu erkennen sind, das gilt auch für die Begleittexte, die zumeist auch als Pixelgrafik eingebunden werden. Bei den Wahlergebnissen stehen die Parteinamen und Prozentangaben oft im Tortendiagramm. Das ist suboptimal, da die Tortenstücke meist in den Parteifarben gestaltet sind und oft zu geringen Kontrast bieten. Wenn Farbe als einziges Unterscheidungsmerkmal verwendet wird, können Farbfehlsichtige einzelne Diagramm-Bestandteile nicht mehr unterscheiden.

Das gilt auch für Legenden-Texte. Wenn Farbe als einziges Erkennungsmerkmal eingesetzt wird, können Farbfehlsichtige den Bezug zwischen Element und erklärender Legende nicht herstellen. Hier gibt es grundsätzlich zwei Lösungswege:

  1. Es gibt außer der Farbe ein weiteres Erkennungselement, zum Beispiel ein bestimmtes Muster.
  2. Element und Beschreibung werden unmittelbar miteinander verbunden, wobei die Beschreibung nicht in das Element eingebettet wird, um die Lesbarkeit zu erleichtern.

Wie kommen die Besucher zu Einfach für Alle

Durch die Farbverläufe sind die Bestandteile des Diagramms auch für Farbfehlsichtige zu erkennen.

Alternativ können die Tortenstücke auch einen kleinen Abstand zueinander haben.

Wie kommen die Besucher zu Einfach für Alle

Durch den kleinen Abstand werden die Tortenstücke leichter unterscheidbar

In jedem Fall sollten die im Diagramm dargestellten Ergebnisse auch als normale HTML-Tabelle angeboten werden, damit auch Blinde die Ergebnisse erkennen können. In keinem Fall ist es sinnvoll, die Ergebnisse im Alternativ-- oder Titeltext unterzubringen, weil das unübersichtlich ist. In unserem Fall ist ein Alternativtext wie »Herkunft der Besucher von Einfach für Alle« als Tortendiagramm« ausreichend.

Herkunft der Besucher von Einfach für Alle
Direkteingabe / nicht verfügbar27.75342,35 %
Suchmaschinen24.02436,66 %
Andere Sites13.75320,99 %

Weitere Umsetzungsbeispiele für Informationsgrafiken finden Sie in der Linkliste.

Emoticons

Emoticons werden in ihrer Bedeutung unterschätzt. Früher wurden sie über spezielle Zeichenfolgen generiert (;-) und ähnliches), heute geht man dazu über, entweder graphische Emoticons zur Einbindung in den Text anzubieten oder sie automatisch aus den Zeichenfolgen zu generieren. Einige aktuelle Screenreader erkennen die wichtigsten Zeichenketten und lesen sie zum Beispiel als »Smiley« vor. Mit den Grafiken geht das nicht, meistens haben die graphischen Emoticons auch keinen Alternativtext. Das kann durchaus problematisch sein, denn mit solchen Emoticons kann Ironie ausgedrückt werden, wer dies aber nicht erkennen kann, versteht auch nicht, dass jemand etwas ironisch gemeint hat, was zu einer endlosen Kette von Missverständnissen führen kann. Wünschenswert sind also alt-Texte für graphische Emoticons. Wenn man sie nicht all zu exzessiv einsetzt, können sie Menschen mit unterschiedlichen Behinderungen durchaus helfen, einen Text besser zu verstehen. Eine solche Funktion muss allerdings im Redaktionssystem angelegt sein, da Redakteure und Nutzer normalerweise keinen Einfluss auf die Ausgestaltung dieser Grafiken haben.

Grafiken in Gebrauchstexten

Bei Anleitungen zur Behebung von Software-Problemen oder Ähnlichem werden häufig Screenshots verwendet. Die erklärenden Texte dazu sind eher sparsam. Was der Sehende auf den ersten Blick erfasst – den Unterschied zwischen zwei Screenshots – muss der Sehbehinderte erst einmal mühsam erfassen und der Blinde hat dazu gar keine Chance. Vor allem für Sehbehinderte und Blinde ist eine exakte Beschreibung sinnvoll: Welches Menü oder welcher Dialog wird aufgerufen, welcher Karteireiter wird ausgewählt, welche Option soll aktiviert oder deaktiviert werden? Die Vorgänge sollten so detailliert beschrieben werden, dass die Aktion auch ohne den Screenshot nachvollzogen werden kann.

Alternativtexte und Bildunterschriften

Grundsätzlich sollte ein Alternativtext kurz sein. Er unterbricht meistens den Lesefluss und ist oft nicht so wichtig zum Verständnis des Textes. Längere Beschreibungen sollten in die Bildunterschrift, wo sie allen zugute kommen. Wie schon im ersten Teil erwähnt können für Alternativtext und Titel die gleichen Texte verwendet werden, die Bildunterschrift sollte sich hingegen von beiden unterscheiden.

Größe der Grafiken

Für Sehbehinderte ist es nützlich, wenn sie die Bilder vergrößern können. Zwar stellen die Browser einfache Vergrößerungsfunktionen bereit, aber wie schon im ersten Teil erwähnt verschlechtert sich die Qualität von Pixelgrafiken bei Vergrößerung. Eine Lösung besteht darin, das normale Bild mit einem Link zu einer größeren Version des Bildes zu unterlegen.

Die Erstellung und Einbindung inhaltlicher Bilder fällt in den Aufgabenbereich von Redakteuren. Sie sollten für diesen Bereich geschult und sensibilisiert werden. Auch Redaktionshandbücher und Leitfäden sollten um entsprechende Anleitungen ergänzt werden.

27 Jul 2011

Bilder und Grafiken verbessern die Benutzbarkeit und Verständlichkeit von Webseiten und Anwendungen. Häufig wird nur an den blinden Nutzer gedacht, der mit Grafiken wenig anfangen kann. Doch es gibt einige Möglichkeiten, Grafiken für Blinde schmerzfrei einzusetzen, so dass sie allen Gruppen von Menschen mit Behinderung zugute kommen. Schließlich können auch für Blinde gedachte Alternativen den Inhalt für alle Nutzer aufwerten.

Im ersten Teil der Serie werden wir uns mit dekorativen Grafiken und Platzhaltern beschäftigen. Solche Grafiken sind vor allem für das Layout der Website wichtig. Im zweiten Teil wird es um inhaltliche Bilder gehen, sie ergänzen den Inhalt eines Textes oder vermitteln Informationen in einer nicht-textuellen Form. Um funktionale Grafiken wird es im letzten Teil gehen, sie spielen eine entscheidende Rolle bei Webanwendungen.

Im ersten Teil wollen wir uns zunächst mit den verschiedenen Einsatzarten von Grafiken und Beschreibungsmöglichkeiten beschäftigen, bevor wir auf den Einsatz von Platzhaltern und dekorativen Grafiken eingehen.

Weiterlesen …

Vektor- und Pixelgrafiken

Es lassen sich zwei Arten von Grafiken unterscheiden: Vektorgrafiken werden im Computer erzeugt. Schon die Buchstaben, die Sie hier lesen, sind Vektorgrafiken, aber auch alles, was sie mit Zeichenprogrammen wie Illustrator erzeugen können. Vektorgrafiken können ohne Qualitätsverlust vergrößert werden.

Bekannte Vektorformate sind Scalable Vektor Graphics (SVG) und Adobes Flash. Sie werden zum Beispiel für Kartenanwendungen wie Open Street Map eingesetzt. SVG und Flash werden sehr unterschiedlich von den Browsern unterstützt, sie werden daher selten für Schmuckelemente eingesetzt.

Daneben gibt es die Rastergrafiken, die z.B. über einen Scanner oder eine Digitalkamera in den Computer kommen. Rastergrafiken bestehen aus einzelnen Bildpunkten (Pixel). Die Qualität dieser Grafiken sinkt deutlich, wenn sie vergrößert werden.

Pixelgrafik-Formate sind zum Beispiel JPEG, PNG oder GIF. Sie werden praktisch für alle Grafikelemente auf einer Website eingesetzt: für Fotos, aber auch für Zierelemente, Logos und vieles mehr. Wenn Vektorgrafiken in einem Pixelformat gespeichert werden, haben sie die gleichen Vor- und Nachteile wie Pixelgrafiken. Sie werden von den Browsern anstandslos angezeigt, lassen sich aber kaum ohne Qualitätsverlust vergrößern. Das ist vor allem wichtig, wenn Texte in Grafiken eingebettet werden.

Für Blinde sind in Grafiken eingebettete Texte gar nicht wahrnehmbar, für Sehbehinderte mit Vergrößerungssoftware sind sie nur schlecht lesbar. Vor allem längere Texte sollten daher nicht direkt in die Grafik eingebettet, sondern über HTML eingebunden und via CSS positioniert werden.

Vier Arten von Grafiken

Im Internet lassen sich vier Arten von Grafiken nach ihrem Einsatzzweck unterscheiden:

  • Platzhaltergrafiken
  • dekorative Grafiken
  • inhaltliche Bilder
  • funktionale Grafiken

Im Folgenden werden wir durchgängig von Grafiken sprechen, wenn es sich um dekorative oder funktionale Elemente handelt und von Bildern, wenn Abbildungen von Menschen, Gegenständen oder ähnlichem gemeint sind.

Ausgezeichnete Grafiken

Alle Pixelgrafiken werden über das Image-Tag <img> eingebunden. Grundsätzlich gibt es drei Attribute, mit denen das Image-Tag beschrieben werden kann:

  • alt = kurzer Alternativtext
  • longdesc = Lange Beschreibung
  • title = Titel / Tooltip

Alternativtexte gehören zum Standard und dienen vor allem blinden Screenreader-Nutzern. Der Titel erscheint, wenn man mit dem Maus-Cursor über ein Bild fährt. Die long description war ursprünglich dafür gedacht, längere Beschreibungen unterzubringen. Praktisch wurde sie kaum eingesetzt und ist in HTML5 zurzeit nicht mehr vorgesehen. Es gibt außerdem noch die Bildunterschrift, die aber als normaler Text unterhalb des Bildes untergebracht wird und für alle Nutzer ohne weiteres sichtbar ist.

Platzhaltergrafiken und dekorative Grafiken

Platzhalter- und Dekorationsgrafiken sind Teil des Layouts und fallen damit in den Aufgabenbereich des Frontend-Entwicklers. Ihr barrierefreier Einsatz muss also schon bei der Gestaltung der Website berücksichtigt werden.

Platzhaltergrafiken

Platzhaltergrafiken sind kleine unsichtbare Grafiken. Sie sind zumeist 1x1 Pixel groß und dienen zur Stabilisierung des Layouts. Sie wurden zum Beispiel bei Layout-Tabellen eingesetzt, um das Design stabil zu halten.

Wenn unsichtbare Grafiken eingesetzt werden, sollten sie ein leeres alt-Attribut erhalten, in diesem Fall werden sie von Screenreadern ignoriert.
<img src="spacer.gif" alt="">
Ohne alt-Attribut oder title wird der Dateiname vorgelesen, was in keinem Fall sinnvoll ist. Ein Alternativtext wie "Platzhalter" wird hingegen als störend empfunden. Idealerweise sollten Sie Platzhaltergrafiken jedoch vermeiden und die Formatierung den Style Sheets überlassen.

Dekorative Grafiken

Dekorative Grafiken dienen dazu, die Website optisch aufzuwerten. Sie sind in der Regel nicht anklickbar und es ist normalerweise keine Funktion hinterlegt. Sie befinden sich üblicherweise auf jeder Seite des Webauftritts und immer an der gleichen Position, das sind zum Beispiel Banner, Logo, Hintergrundbilder, Zierleisten und so weiter.

Diese Grafiken sind äußerst nützlich: sie sollten auf einen Blick verraten, auf wessen Webauftritt man sich gerade befindet, erhöhen den Wiederkennungswert ungemein und vermitteln deshalb Sicherheit und Orientierung – nützlich für Menschen mit Lernbehinderung oder ältere Menschen.

Logo und Banner sind gewöhnlich mit der Startseite verknüpft und sollten einen entsprechenden Alternativtext enthalten: »Logo Einfach für Alle – zur Startseite« zum Beispiel. Bei grafischen Links sollten Alternativtext und Titel verraten, wo die Links hinführen, eine Beschreibung der verlinkten Grafik ist selten sinnvoll.

Grafiken, die keine Funktion erfüllen, nicht zum Inhalt beitragen und nur der Dekoration dienen, sollten wie Platzhalter-Grafiken ein leeres alt-Attribut erhalten, damit sie Blinde nicht vom Inhalt ablenken.

Für Alternativtext und Titel lassen sich die gleichen Beschreibungen verwenden, der Screenreader liest nur eine der beiden Beschreibungen vor. Die Bildunterschrift – sofern vorhanden – sollte hingegen nicht die gleiche Information enthalten wie Alternativtext und title, weil sie sowohl von Mausnutzern als auch von Screenreadern doppelt wahrgenommen würde.

Was in den Alternativtext gehört oder nicht ist heiß umstritten. Manchen genügt die nüchterne Nennung von Personen- oder Ortsnamen, andere wollen die Stimmung transportiert haben. Wenn das Bild dekorativ ist, sollte es einen möglichst kurzen Alternativtext enthalten. Vor allem, wenn die Bilder in einen Text eingebettet sind, sollte man bedenken, dass lange Alternativtexte oder Bildunterschriften den Lesefluss des Blinden stören können.

Über CSS eingebundene Hintergrundgrafiken lassen sich nicht mit beschreibenden Attributen versehen und sind damit für den Blinden unsichtbar. Hier ist zu beachten, dass sehende Nutzer in der Lage sein müssen, Elemente auf der Website zu erkennen. Das kann schwierig werden, wenn das Hintergrundbild zu wenig Kontrast zu den Inhaltselementen bietet, etwa weil es mit Farbverläufen arbeitet. Achten Sie deshalb bei Hintergrundbildern darauf, dass alle anklickbaren Elemente, Formularbestandteile und Fließtexte sich gut vom Hintergrund unterscheiden lassen. Alle Farbkombinationen jenseits von Schwarz auf Weiß verschlechtern die Lesbarkeit. Der Besucher sollte außerdem auf Anhieb erkennen können, ob eine Grafik anklickbar ist – also eine Funktion hat oder nicht.

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)

20 Apr 2011

Wie Sie blinde oder sehbehinderte Nutzer mit den für sie passenden Alternativen zu visuellen Inhalten versorgen wird in den folgenden WCAG-Techniken erklärt:

Weiterlesen …

Allgemeine Techniken

SMIL-Techniken

Typische Fehler

19 Apr 2011

Die Untertitelung von audiovisuellen Inhalten gehört zum guten Ton eines barrierefreien Angebots, aber blinden oder sehbehinderten Menschen nützen diese nichts, wenn Sie die Untertitel nicht wahrnehmen können. Ähnliches gilt, wenn Audiodeskriptionen auf Grund des Hörvermögens nicht wahrgenommen werden können – dann benötigt der Nutzer eine alternative Darstellung der Inhalte. Welche Möglichkeiten es gibt lesen Sie in den folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

HTML-Techniken

Typische Fehler

13 Apr 2011

Mit vielen Formen der Sehbehinderung sind die Nutzer zwar noch nicht auf spezialisierte Hilfsmittel angewiesen, haben aber trotzdem unter Umständen Schwierigkeiten mit der Wahrnehmung zu schwacher Kontraste. Gerade im Alter nimmt die Fähigkeit, subtile Kontraste zu differenzieren stark ab. Wie Sie für ausreichende Kontraste sorgen zeigen die folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

Typische Fehler

Zu einer barrierefreien Gestaltung gehört, dass ein Design auch weiterhin funktioniert, wenn ein Besucher mit benutzerdefinierten Farben unterwegs ist. Für viele sehbehinderte Nutzer gehen bei Nichtbeachtung wertvolle Informationen oder Funktionen verloren. Ebenso betroffen ist eine große Anzahl von Nutzern mit verschiedenen Formen der Farbfehlsichtigkeit, die an einer effektiven Nutzung gehindert werden, wenn Informationen ausschließlich über Farbe transportiert werden. Wie Sie diese Fehler in Ihren Designs verhindern zeigen die folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

CSS-Techniken

Typische Fehler

08 Apr 2011

Nicht ohne Grund steht dieser Punkt in den meisten Richtlinien und Prüfverfahren an allererster Stelle: sämtliche Inhalte müssen auch in Textform vorliegen, um unterschiedlichste Arten der Wahrnehmung zu bedienen. Nur Text lässt sich in Braille übersetzen, ohne Text bleibt die Sprachausgabe stumm; wenn Text-Alternativen nicht die gleichen Informationen enthalten wie Grafiken, Fotos oder Schaubilder, dann gehen für viele Nutzer Informationen verloren oder es sind Funktionen eines Angebots nicht nutzbar. Wie Sie dies verhindern finden Sie in der folgenden Auflistung von WCAG-Techniken zu diesem Thema:

Weiterlesen …

Allgemeine Techniken

HTML-Techniken

Typische Fehler

26 Jan 2011

Im Internet finden sich viele Dokumente wie Jahresberichte, Broschüren, Verträge, Berichte und Zeitschriften. Um eine geräteunabhängige Layout-Darstellung zu garantieren wird hierfür oft das PDF-Format verwendet. Dieses Format hat für sehende Menschen einige Vorteile: die Software für die Anzeige ist kostenlos erhältlich und das Layout der Dokumente bleibt erhalten. Blinde und sehbehinderte Menschen stehen dem PDF-Format immer noch sehr kritisch gegenüber. PDF-Dokumente sind in unbearbeitetem Status oft gar nicht lesbar; ein Word-Dokument hingegen ist zwar meistens auch nicht barrierefrei, aber doch zumindest meist teilweise lesbar.

Im Netz gibt es sehr viele schlechte und nur wenige gute strukturierte Word-Dokumente; dasselbe gilt auch für schlechte beziehungsweise korrekte barrierefreie PDF-Dokumente. Die Tester der schweizerischen Stiftung »Zugang für alle« kennen die Vor- und Nachteile der beiden Formate. Dies ermöglicht ihnen, die gemachten Erfahrungen mit barrierefreien Word- und PDF-Dokumenten einander gegenüberzustellen. Die häufig zu hörende Meinung »PDF-Dokumente sind schlecht« soll durch einen Test mit Fakten hinterfragt werden.

Anhand von 20 Accessibility-Prüfkriterien hat die Stiftung einen Vergleich der beiden Formate mit dem Screenreader JAWS durchgeführt. Untersucht wurden 20 JAWS-Befehle, die für die Benutzung von Dokumenten für blinde und sehbehinderte Menschen am wichtigsten sind. Der Vergleich zeigt, dass bei 11 von 20 untersuchten Kriterien das PDF-Format von JAWS deutlich besser unterstützt wird. In Word werden lediglich zwei Funktionen besser vom verwendeten Screenreader unterstützt als im vergleichbaren PDF-Dokument.

Die kompletten Ergebnisse des Tests sind unter »Zugänglichkeit von Word- vs. PDF-Dokumenten mit JAWS«.

19 Mai 2010

Das Web 2.0 ist eine Einladung zum Mitmachen: Leser werden zu Schreibern, Hinschauer werden zu Fotografen, Menschen schließen sich zu Communities zusammen.

Große Teile des Mitmach-Web sind textbasiert. Für das Blogging und Mikro-Blogging gibt es netzbasierte Lösungen wie Wordpress oder AccessibleTwitter. Der blinde Heiko Kunert benutzt einige der Web-2.0-Tools wie Wordpress, Twitter oder Friendfeed, um unter anderem über die alltäglichen Schwierigkeiten Blinder zu berichten. Der ebenfalls blinde Programm-Entwickler Marco Zehe berichtet in seinem Weblog über seine Beteiligung an der Entwicklung des Firefox-Browsers und Aspekte der Barrierefreiheit. Der blinde Hörfunk-Journalist Marko Schlichting produziert »Markos Medienpodcast«, in dem er kritisch über die Medienkultur berichtet.

Mapping für Blinde

Die Routenplanungen für Fußgänger von GoogleMaps oder BingMaps erlauben Blinden, eine zu laufende Route bezüglich Entfernung und Namen der Straßen abzuschätzen und leistet damit einen Beitrag zur selbstständigen Mobilität. Noch weiter geht das freie Karten-Projekt OpenStreetMap. Hier haben alle Beteiligten die Möglichkeit, mit einem GPS-Tracker Material zu freien Karten beizusteuern. Die Nutzer werden auch dazu angehalten, für Blinde wichtige Punkte wie Haltestellen exakt zu kennzeichnen. Auch Blinde sind dazu eingeladen, Tracks zu spenden, schließlich wissen sie am besten, welche Orte für sie wichtig sind.

Weiterlesen …

Soziale Netzwerke

Die großen sozialen Netzwerke gelten bisher als eher unzugänglich. Die Websites sind sehr komplex aufgebaut. Außerdem werden oft CAPTCHAs verwendet, das sind in Bildern versteckte Zeichen, die der menschliche Leser eingeben muss, um zum Beispiel Freunde oder Anwendungen zu seinem Profil hinzuzufügen. Die im ersten Beitrag erwähnten Mailinglisten können ähnliche Aufgaben wie die sozialen Netzwerke Erfüllen.

Offen und zugänglich – ein Web für Alle

Die Beiträge zeigen nur einen Bruchteil der Möglichkeiten und Anwendungen im Internet. Blinde Programmierer sind unter anderem an der Entwicklung der im ersten Teil genannten freien Screenreader oder an der freien Handy-Navigation Loadstone GPS beteiligt und verwenden dazu Anwendungen zur Zusammenarbeit im Netz wie Wikis.

Jeder Blinde im Besonderen und Behinderte im Allgemeinen entwickelt seine eigenen Strategien, um mit dem Netz zurecht zu kommen. Ein häufiges Argument, Anwendungen nicht barrierefrei zu machen lautet, dass diese sowieso nicht von Behinderten verwendet würden. Eine selbst erfüllende Prophezeiung.

Barrierefreiheit ist nicht nur für Blinde und Sehbehinderte wichtig. Auch Menschen mit Lernschwäche, motorischen Einschränkungen oder ältere Menschen stoßen auf mehr oder weniger große Schwierigkeiten bei der Nutzung des Web. Deswegen gehören selbstverständlich auch Bilder, Videos oder Animationen zur barrierefreien Webgestaltung.

Im Mitmach-Web muss Barrierefreiheit weiter gedacht werden:

  • Die Websites vieler freier Redaktionssysteme sind oft schon barrierefrei. Behinderte sind aber nicht nur Konsumenten von Inhalten, sondern wollen selbst Inhalte bereit stellen. Deshalb sollte auch das Backend von Redaktionssystemen barrierefrei zugänglich sein.
  • Die Frage sollte nicht lauten, ob Behinderte eine bestimmte Anwendung einsetzen werden. Eine Anwendung sollte möglichst für alle zugänglich sein. Im Rahmen des E-Goverment und von Open Data wird das Web nicht nur gesellschaftlich, sondern auch für die politische Teilnahme entscheidend an Bedeutung gewinnen. Das E-Goverment soll Dienstleistungen der öffentlichen Verwaltung online bereit stellen, im Rahmen von Open Data sollen Daten öffentlicher und wissenschaftlicher Einrichtungen bereit gestellt werden.
  • Entscheidend für Anwendungen wie Easy YouTube oder AccessibleTwitter sind die Programmschnittstellen, die viele der großen Web-2.0-Anwendungen anbieten. Diese Application Programming Interfaces (APIs) erlauben den Zugriff auf Daten und Funktionen der Webanwendungen. APIs sind allerdings kein Ersatz, sondern eine Ergänzung barrierefreier Angebote. Sie erlauben alternative Zugriffswege und Darstellungsformen.
  • Zu einem guten Web-Angebot gehören auch multimediale Inhalte und auch diese Inhalte müssen möglichst für alle zugänglich sein.

Das Internet macht es zum ersten Mal möglich, dass sich Behinderte und Nicht-Behinderte ohne große Berührungsängste untereinander austauschen. Dafür müssen die Rahmenbedingungen stimmen und die Zugänglichkeit der Plattformen ist die wichtigste Voraussetzung.

17 Mai 2010

Obwohl das Web nach wie vor ein textbasiertes Medium ist, kommt kaum eine Website heute ohne multimediale Angebote aus. Vor allem im Bildungsbereich spielen Podcasts, Videos und Präsentationen eine immer größere Rolle.

Podcasts – hören statt sehen

Podcasts können mit geringem Aufwand produziert und angeboten werden und erfreuen sich großer Beliebtheit, weil sie problemlos mobil genutzt werden können. Für Blinde liegt der Vorteil von Podcasts darin, dass sie rein akkustisch sind, zumeist als Download angeboten werden und problemlos auf dem PC oder anderen Geräten angehört werden können.

Auch Blinde schauen Videos

Viele Leute scheinen zu glauben, Blinde würden sich keine Videos anschauen. Allerdings dürfte es kaum jemanden überraschen, dass auch Blinde oft einen Fernseher zuhause stehen haben. Videos haben einen sehr hohen sprachlichen Anteil. Viele Vorträge, Vorlesungen, Interviews oder Ausschnitte aus aktuellen Fernsehsendungen werden als Video bereit gestellt. Das Einbinden und Verweisen auf Videos gehört zum Alltag im Web 2.0.

Weiterlesen …

Flash als Barriere

Das Kernproblem bei der Zugänglichkeit der Videos besteht im verbreiteten Einsatz des Flash-Player. Videos auf YouTube lassen sich über Tastatur weder starten noch stoppen. Für Blinde wäre es besonders wichtig, die Lautstärke von Videos zu steuern, da sie bei zu lauten Videos ihre Sprachausgabe nicht mehr verstehen können.

Wie es anders geht, zeigen die Anwendungen EasyYouTube oder Accessible Interface to YouTube. Diese Anwendungen sind über den Screenreader steuerbar. Für den Browser Firefox gibt es verschiedene Erweiterungen, die das Herunterladen und bequeme Steuern der Videos zulassen. Der Online-Dienst Video2mp3 erlaubt das Konvertieren von Videos in mp3. Die Nachteile solcher Anwendungen sind aber offensichtlich:

  • Es ist nicht klar, ob diese Anwendungen mit den Benutzungsbedingungen der Anbieter und dem Urheberrecht harmonieren.
  • Diese Anwendungen sind oft auf bestimmte Plattformen zugeschnitten. Wenn man zum Beispiel Videostreams der eigenen Universität ansehen möchte, dann funktionieren auf YouTube zugeschnittene Programme nicht. Die Website Podcampus bietet Vorträge verschiedener Universitäten im Flash-Format an, ist aber von Haus aus nicht zugänglich.
  • Zudem entgehen dem Nutzer viele Informationen und Funktionen der Ursprungs-Website, mehr oder weniger nützliche Kommentare und Anmerkungen, die Anzeige verwandter Inhalte oder erweiterte Suchfunktionen mit Filtermöglichkeiten.

Bedenklich ist auch die Tendenz, Präsentationen als Flash-Animation wie auf SlideShare bereit zu stellen. Präsentationen enthalten normalerweise keine Audio-Kommentierung und die Texte der Präsentationen sind für den Screenreader nicht lesbar. Besser sind die Screencasts, dabei werden Präsentationen und Vorlesungstext parallel aufgesprochen. Davon können auch Sehbehinderte profitieren, die an ihrem eigenen Bildschirm der Präsentation wesentlich besser folgen können als einer Leinwand-Projektion. Die Screencasts werden aber zumeist ebenfalls im Flash-Format angeboten und sind damit für Blinde nicht zugänglich.

Multimedia dient nicht nur der Unterhaltung, sondern wird zunehmend auch in den Bereichen Bildung und E-Learning eingesetzt. Daher wird es für Blinde immer wichtiger, dass auch solche Angebote zugänglich sind.

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.

24 Apr 2009

Zugänglichkeit für Nutzer ohne Maus zu ermöglichen ist einer der wichtigsten Schritte beim Aufbau einer barrierefreien Webseite oder Web-Applikation. Beim Testen der Zugänglichkeit per Tastatur findet man sich immer wieder nach dem Drücken der Tabtaste in der Situation: »Wo ist mein Cursor?« oder »Welches Element hat eigentlich gerade den Fokus?«. Gerade bei Elementen, die per CSS aus dem sichtbaren Bildschirm-Bereich geschoben wurden, tabt man dann gern und lang im Dunkeln.

LogFocus – hilfreiches Bookmarklet beim Testen von Keyboard-Accessibility

Beim Aufräumen unserer Lesezeichen-Sammlung haben wir ein Skript von Dirk Ginader gefunden, das Licht in diese Situationen bringt, und das er vor einiger Zeit in ein handliches Bookmarklet gekapselt hat.

LogFocus arbeitet in allen Browsern, die eine Konsole zur Verfügung stellen: Im Firefox ist hierfür Firebug notwendig; in Safari (bzw. WebKit) muss das Develop‹-Menü aktiviert sein; für Internet Explorer empfiehlt sich das PlugIn Companion.JS und in Opera wird die eingebaute Konsole im Debugger Dragonfly genutzt.

Um das Bookmarklet zu installieren zieht man einfach den folgenden Link in die eigenen Bookmarks:

LogFocus

Von dort aus kann das Skript dann einfach per Klick auf jeder beliebigen Seite ausgeführt werden und die aktuelle Position wird in die Konsole geschrieben.

27 Mai 2008

Seit kurzem gibt es bei Wikipedia eine Hilfeseite für blinde Benutzer. Die Seite soll bei den ersten Schritten helfen. Fragen und Anregungen, die sich auf die Bedienung von Wikipedia mit einer Screenreader-Software beziehen, kann man auf die dort verlinkten Diskussionsseiten schreiben.

Viele Wikipedia-Artikel, die sich auf Blindheit oder Sehbehinderung beziehen, sollten überarbeitet und ergänzt werden. Manch ein wünschenswerter Artikel existiert bislang noch nicht. Viele Menschen informieren sich bei Wikipedia und Suchmaschinen wie Google zeigen passende Wikipedia-Artikel in der Trefferliste ganz oben an. Gute Artikel sollten also im Interesse der Öffentlichkeitsarbeit der Blinden- und Sehbehindertenselbsthilfe sein. Dabei sollte jedoch ein enzyklopädischer Stil (also keine Werbung oder reine Selbstdarstellung) und das Urheberrecht beachtet werden. Das bedeutet, dass man Textfragmente aus anderen Quellen nicht einfach unverändert übernehmen kann, es sei denn, der Urheber des Textes spendet diesen ausdrücklich an Wikipedia beziehungsweise stellt diesen unter eine freie Lizenz wie die GPL. Mehr Informationen findet man auf den entsprechenden Hilfeseiten. Auch für Artikel, die sich mit anderen Behinderungen beschäftigen, wären Überarbeitungen und Ergänzungen durch kundige Bearbeiter wünschenswert.
(bei kobinet abgeschrieben)