Das Internet hat einige Hürden zu bieten, die ein inklusives Miteinander erschweren. Hier gibt es eine kleine Auswahl derer, die zu den Nervigsten gehören.

Falsche Sprachauszeichnung

Die Sprachauszeichnung bewirkt, dass Screenreader in der Lage sind, Inhalte mit einer entsprechenden Stimme vorzulesen, also einer Stimme, die akzentfrei bzw. muttersprachlich klingt. So wird das Wort Refrain beispielsweise richtig ausgesprochen, wenn es mit dem Attribut lang=fr ausgezeichnet ist. Wird das außer Acht gelassen, hört es sich ungefähr so an, als gäbe man einem Grundschüler etwas Fremdsprachiges zum Vorlesen. Ein Beispiel dafür gibt das folgende Video, in dem ein deutscher Text mit englischer Sprachauszeichnung versehen ist, was dazu führt, dass der Inhalt unverständlich wird.

 

Eine immer häufiger auftretende Praxis ist die Interaktion mittels modaler Dialoge. Bei dieser Methode wird Inhalt (typischerweise Formulare) in einem Layer geöffnet, der den darunter liegenden Inhalt verdeckt. Sei es die Wahl eines Pizzabelags oder die Eingabe von Zahlungsinformationen: Häufig findet sich dieses Interaktionsmodell an kritischen Punkten. Um so ärgerlicher, wenn es zu einer Barriere wird. Typischerweise interagiert der Screenreader überhaupt nicht mit dem Overlay. In vielen Fällen bleibt sogar der Hinweis aus, dass ein solches aufgetaucht ist. Man bewegt sich also nach wie vor auf der darunterliegenden Seite, ohne zu ahnen, dass eigentlich etwas anderes die Aufmerksamkeit fordert. Einen Eindruck vermittelt das folgende Video:

 

Wie kann man es besser machen?

Grundsätzlich muss darauf geachtet werden, dass der Fokus des Screenreader auf den neuen Dialog gesetzt wird. Wie in diesem Beispiel für einen gelungenen Dialog.

Captchas

Wir kennen und hassen sie vermutlich alle: Captchas, oder den Nachweis darüber, dass man ein Mensch ist, den man mit Strapazen und Lebenszeit bezahlt. Für blinde Nutzer liegt es natürlich nahe, statt Bildchen mit bis zur Unleserlichkeit verzerrtem Text eine Audioform anzubieten. So logisch diese Überlegung auch ist, so praxisuntauglich ist sie auch. Es treten nämlich mehrere gravierende Probleme auf:

Captcha holen und Textfeld finden

In den meisten Fällen muss man einen Link aktivieren, der das Captcha abruft. Dieses wird anschließend sofort abgespielt.

Das Problem dabei ist, dass ich mit dem Screenreader anschließend in das für den Captcha-Code vorgesehene Textfeld navigieren muss. Plötzlich habe ich also zwei unterschiedliche, sich überlagernde gesprochene Inhalte.

Hier ein einfaches Beispiel dafür:

 

Captcha wiederfinden

Das eben erlebte Beispiel ist dabei noch ein sehr einfaches. Normalerweise öffnet sich sogar ein neuer Tab. Es kommt also noch die Schwierigkeit dazu, schnell den richtigen Tab wieder zu finden, um dort das Textfeld zu suchen.

Verständlichkeit

Als wäre das nicht hart genug, wurden die Audiocaptchas in den letzten Jahren zum Großteil absolut unverständlich, was sich in den nächsten beiden Beispielen zeigt:

Nimmt man es mit Humor, kann man natürlich sagen: fair ist fair - warum soll es blinden besser gehen als sehenden Nutzern, die die Bilder ja auch kaum mehr entziffern können.

Wie geht es besser?

Ein Screenreader-Nutzer navigiert nicht anders, als ein Bot. Googles Recaptcha ist daher in den meisten Fällen auch keine Lösung. Interessanter ist da schon ein Captcha, welches simple Matheaufgaben lösen lässt.

Die beste Möglichkeit, die zudem auch im Sinne des Servicegedankens die einzig vertretbare ist: dass Unternehmen aufhören, ihr Spam-Problem zum Problem ihrer potenziellen Kunden zu machen.

Copy/Paste

Wirklich interessant wird es, wenn Texte in irgendwelchen Formaten geschrieben werden, die dann beim Kopieren in den WYSIWYG-Editor zu unsichtbaren Problemen führen, die allerdings dafür sorgen, dass der Inhalt für Screenreader-Nutzer mindestens schwer verständlich wird.

Sie wür-den so et-was Zer-hack-stüc-kel-tes ja auch nicht ger-ne le-sen wol-len, oder?

Was sich merkwürdig liest klingt durch den Screenreader so:

 

Wo kommt das her?

Einerseits passiert das, wie oben schon angedeutet, wenn aus einem Programm für Textverarbeitung heraus kopiert wird (Bindestriche der automatischen Silbentrennung werden mit kopiert), andererseits findet sich das bedingte Trennzeichen “&shy” dafür als schuldiges Element.

Grundsätzlich lässt sich sagen, dass Silbentrennung, wenn man sie denn unbedingt einsetzen möchte, ins CSS und nicht ins HTML gehört. Dann darf es gerne so oft getrennt werden, wie es beliebt ohne, dass es dazu führt, für Blinde unlesbar zu werden.

Übrigens liest es sich auch auf der Braillezeile genau mit solchen Bindestrichen, wie in dem oben angeführten Beispiel.

Fazit

Abgesehen von den Audiocaptchas lässt sich alles hier Vorgestellte relativ einfach verbessern, wenn die Aufmerksamkeit für diese Fallstricke vorhanden ist. Die Captchas sind hingegen praktisch gelebte Inklusion und zeigen sehr eindrucksvoll, dass es Techniken gibt, die für alle Nutzer ähnlich nervig sind. Letztlich sitzen wir also alle im selben Boot. Lasst uns dafür sorgen, dass es für alle ein entspannter Aufenthalt wird!