Archiv der Kategorie: Barrierefreiheit & Zugänglichkeit

Sollten Webseiten mit Screenreadern getestet werden?

Diese Frage wird in einem englischsprachigen Weblog gestellt. Darauf gibt es eine recht eindeutige Antwort. Nein, es sei denn, die Website wird primär von Blinden und Screenreader-Nutzern aufgesucht.

Bis heute verwechseln viele Webdesigner und Frontend-Entwickler Barrierefreiheit mit blindenfreundlich. Das ist teilweise berechtigt: Menschen mit motorischen Einschränkungen verwenden oft die Tastatur statt der Maus, so dass sie ähnlich wie Blinde durch eine Website tabben. Andererseits: wenn jemand aus motorischen Gründen keine Maus benutzen kann, wird er wohl auch Schwierigkeiten haben, eine Tastatur zu bedienen.

Das wird vor allem dann relevant, wenn man wie bei Access-Keys üblich zwei oder drei Tasten gleichzeitig drücken muss, um eine Aktion auszulösen oder einen seiteninternen Bereich anzuspringen. Übrigens käme wohl kein webdesigner auf die Idee, einem sehenden Nutzer so eine Akrobatik aufs Auge zu drücken.

Bei dem Thema Barrierefreiheit bleiben vor allem Menschen mit Lernschwierigkeiten und geringen Internet-Erfahrungen komplett außen vor. Sie werden von der Vielzahl an Elementen gestört, sie wissen oft nicht, was anklickbar ist und was nicht und häufig genug ist die Navigation von Marketing- statt von Usability-Aspekten geprägt.

An dieser Stelle laufen Usability- und Accessibility eindeutig zusammen. Allerdings haben sich Usability-Tests – mehr oder weniger – fest etabliert, während man Zugänglichkeitstests mit Nutzern bisher kaum findet.

Ich frage mich allerdings auch, was einen Webdesigner oder Frontend-Entwickler zum Zugänglichkeits-Guru qualifiziert. Die Lektüre der BIT-V und der WCAG ist zwar langatmig, aber sicher nicht ausreichend. Und hier kommen wir zum Ausgangspunkt zurück: Nicht jede Website sollte mit einem Screenreader getestet werden, aber der Webworker sollte zumindest einmal intensiver mit einem Screenreader (und anderen Zugänglichkeitstechniken) gearbeitet haben.

Wir müssen es zugeben: die WCAG ist schön und gut, aber für den arglosen Leser total unverständlich. Er versteht nicht, warum Überschriften als HTML-Headline umgesetzt werden sollen, warum Formularlemente Labels brauchen und warum jeder Winkel der Seite mit der Tastatur erreichbar sein soll. Und wenn der Webworker nicht praktische Erfahrungen mit Hilfstechniken sammelt (und frisch hält), wird er vermutlich sein Pflichtprogramm abspulen, aber ohne Phantasie und Interesse. Denn er weiß, dass er etwas Bestimmtes tun muss, er kann aber nicht nachvollziehen, warum er es tun soll. So kommen Webseiten mit einem Dutzend Sprungankern am Anfang der Seite zustande, deshalb werden unsinnige Access-Keys generiert und deshalb sehen viele – vorgeblich – barrierefreie Websites so aus, als ob sie auf einem 14-Zoll-Schwarzweiß-Monitor kreiert wurden.

Querlesen für Blinde

Blinde können oftmals schneller im Web unterwegs sein als Sehende. Das mag zum Einen daran liegen, dass sie sich kaum von optischen „Eye-Catchern“ ablenken lassen. Zum Anderen liegt es aber daran, dass sie einige Vorteile des Screenreaders in Kombination mit der Tastatur nutzen können.
Mit einiger Übung kann man mit der Tastatur wesentlich schneller arbeiten als mit der Maus. Der Touchscreen mag einiges für sich haben, man darf aber gespannt sein, ob man mit ihm wirklich komplexe Aufgaben wie das Formatieren eines Textes, das Beschneiden oder gar Manipulieren eines Fotos oder andere Bearbeitungsaufgaben besser, schneller und komfortabler als mit einer Tastatur lösen kann.

Der Marktführer bei Screenreadern Jaws bietet ein paar interessante Funktionen an. Ich bin mir gar nicht sicher, ob viele Menschen diese Funktionen tatsächlich kennen, manchmal stößt man durch Zufall – etwa durch das versehentliche Drücken mehrerer Tasten – auf neue Funktionen, die man vorher noch nicht entdeckt hatte.

Mit der Tastenkombination Einfg+F7 kann man sich alle Links einer Website anzeigen lassen. Bei einigen Medien kann man so die Überschriften von Artikeln lesen, in Shops die Namen der Produkte erfahren usw.

Mit Einfg+F6 kann man sämtliche Überschriften einer Seite lesen, hilfreich zum Beispiel wiederum bei Medien oder auch dort, wo Teilbereiche der Seite mit Überschriften bedacht sind wie die Navigation.

Mit Einfg+F5 kann man sich sämtliche Formularfelder einer Website anzeigen lassen, hilfreich etwa bei langen und unübersichtlichen Formularen. Schade eigentlich, dass Jaws nicht direkt eine Eingabemaske generiert, zum Eingeben von Daten muss man zur Website zurückkehren.
Die Killerapplikation erreicht man mit Einfg+F3, da kann man sich viele Elemente der Website wie Anker, Listen oder Tabellen auflisten lassen.

So erklärt sich der Hintergrund vieler Regeln der barrierefreien Webgestaltung. Auch wenn viele Dinge sich aus em Kontext erschließen lassen, liegt dieser Kontext eben nicht immer vor. Auch, aber nicht nur deswegen, sollte man ordentliche Linktitel, Überschriften und Formularbenennungen vornehmen.

Was bringen automatische Testtools für die Barrierefreiheit – die Validierung

Mittlerweile dürfte sich jede Webagentur damit schmücken, barrierefreie Websites zu bauen. Sie machen das sozusagen im Vorbeigehen, ohne Experten zu engagieren, ohne Praxistests mit Betroffenen und ohne großartig Ahnung von BIT-V oder WCAG zu haben – behaupte ich mal, denn viele Websites ob uralt oder nagelneu erfüllen nicht einmal die minimalen Basics, zum Beispiel die Verwendung von HTML-Elementen. Vielleicht greifen einige dieser Agenturen auf mehr oder weniger automatische Testtools zurück – was besser ist als gar nichts zu tun. Grund genug, sich einiger dieser Tools anzugucken und sie hier in lockerer Folge einmal vorzustellen.Ich beginne dort, wo jeder Code-Schreiber anfangen sollte, bei der Validation.

Validatoren

Dirk Jesse hat in seinem Beitrag Alles valide oder was? schon einiges zu dem Thema Validierung gesagt, dem ich nicht viel hinzufügen kann. Dennoch möchte ich das Thema vom Blickwinkel der Barrierefreiheit betrachten.

Im ersten Schritt sollte immer überprüft werden, ob die Seiten validen Code enthalten. Das hilft vor allem dabei, fehlerhafte Tags, Attribute und Werte zu finden,was zu Fehlern in der Darstellung führt.

Valide oder nicht valide – das ist nicht mehr die Frage

Kurioserweise glauben viele Leute, valider Code sei schon barrierefrei. Ergo, nicht valider Code ist eine Barriere. Die letztere Ansicht stimmt heute nicht mehr: Dank HTML5 und WAI ARIA haben sich die Möglichkeiten für barrierefreie Websites entscheidend verbessert. Beide Standards sind allerdings noch nicht verabschiedet und validieren dementsprechend zumindest beim W3C nicht. Es gibt allerdings einen experimentellen HTML5-Validator, der explizit bei der Doctype ausgewählt werden muss, wenn man nicht den neuen Doctype von HTML5 verwendet.

Jeder Code-Leser dürfte aber in der Lage sein, ARIA oder HTML5-Fehlermeldungen von echten Fehlern unterscheiden zu können. Bei CSS3 sieht es ähnlich aus. Ich plädiere stark dafür, stabile Elemente schon heute zu verwenden, weil sie die Benutzerfreundlichkeit und Zugänglichkeit erhöhen. Außerdem wird so Druck auf die Programmierer von Browsern und das W3C ausgeübt, diese Elemente auch zeitnah einzuführen.

Nutzen

Der HTML-Validator stellt zum Beispiel sicher, dass in XHTML alle Bilder einen Alternativ-Text haben. Er kann allerdings nicht beurteilen, ob dieser Text sinnvoll ist oder nicht. Er kann auch nicht sehen, ob jemand HTML für Überschriften verwendet oder sie per CSS gestaltet. div id=“h1″ ist ebenso valide wie „h1″. Die Validierung verhindert allerdings grobe Fehler wie falsche Tag-Attribut-Paare, was kein Browser der Welt korrigieren oder interpretieren kann. Er prüft auch nicht die Trennung von Layout und Struktur, die dank CSS eigentlich Standard sein sollte. Kein Validator der Welt verhindert, dass jemand mit “ “ seine Abstände einstellt oder Absätze über „br“ statt über „p“ erzeugt, das sind typische Artefakte von WYSIWYG-Editoren.

Fazit

Basis barrierefreier Websites ist fehlerfreier Code. Wer seinen Code nicht prüft, riskiert fehlerhafte Darstellung im Browser, was normalerweise einen Rattenschwanz weiterer Probleme nach sich zieht. Der Validator ist allerdings nur der Anfang und nicht das Ende der Testphase. Er schwächelt dort, wo es um semantisch sinnvolle Auszeichnungen geht und hier kommt es auf das Können des Code-Schreibers an.
Einen recht interessanten Artikel dazu gibt es bei Wait till I come. Chris und Remy Sharp diskutieren über die Bedeutung des Validierens, Chris vertritt als Protagonist der Barrierefreiheit im wesentlichen unseren Standpunkt.

Scrollen oder nicht scrollen – der Umgang mit langen Texten im Netz

Fast jedes Medium hat es einmal gemacht: mehr oder weniger sinnvolle Klickstrecken aus Bildern sollten den User zur Mausakrobatik animieren. Die Währung hieß damals Klickrate, je öfter man klickte, desto höher war der Wert der angezeigten Werbung. Das scheint zumindest teilweise korrigiert worden zu sein.

Doch bei Texten geht die Salami-Taktik weiter Die Zeit, das Süddeutsche Magazin und viele andere Websites verteilen einzelne Artikel auf mehrere Seiten.

Das galt als guter Stil, als Bildschirme noch Bildschirme waren und 14 Zoll maßen. Damals waren Mäuse mit Rädchen selten und der entnervte User musste den Cursor an den rechten Bildrand fahren, um sich beim Scrollen einen Tennisarm zu holen. Aus dieser Zeit stammt die Designweisheit, dass nichts beachtet wird, was außerhalb des Start-Screen liegt, also dem Bereich, den man ohne vertikales oder horizontales Scrollen sehen kann. Ergo müssen Texte, die über den Bildschirm reichen, in kleine Portionen aufgeteilt werden.

Ich war mal auf eine Seite gestoßen, die aus dieser Salami-Taktik ein Geschäft gemacht hat. Da stand ein etwas längerer Text kostenlos auf 20 Seiten verteilt und die komplette Fassung ließ sich als PDF käuflich erwerben.

Das klingt zwar kurios, aber gerade längere Artikel, die auf diese Weise zerstückelt werden, wird wohl kaum jemand wirklich zu Ende lesen. Vier Seiten dürften so die magische Grenze sein, wo auch der geduldigste Leser die Lust verliert. Zumal, wenn sein Surfgerät nicht so bequem ist wie ein PC. Mit einem Notebook-Touchpad oder einem Handy macht das wenig Spaß. Ärgerlich vor allem, wenn auf der letzten Seite nur ein kleiner Absatz steht, für den sich das Klicken gar nicht gelohnt hat.

Und leider bieten nur die wenigsten Seiten die Anzeige verteilter Artikel auf einer Seite an, die Zeit zum Beispiel. Viele Seiten bieten zwar eine Druckfunktion an, die einen ähnlichen Effekt hat – der ganze Artikel wird auf einer Seite angezeigt. Allerdings ist diese Funktion zumeist mit JavaScript verbunden, das den Druckerdialog des Browsers auslöst. Wer hier automatisch auf Return drückt und einen Drucker laufen hat, verschwendet einmal mehr unnötig Tinte und Papier. Die süddeutsche macht das zum Beispiel. Die Designer meinen wohl, die Menschen seien zu doof, den Drucker selber auszulösen.

Ein weiterer Nachteil verteilter Artikel besteht darin, dass man sie schlecht archivieren kann. Oder ist das die Absicht der Webbetreiber?

Ich würde heute ohne Wenn und Aber empfehlen, einen Artikel immer zusammenhängend auf eine Seite zu packen. Via Tracking kann jeder Webbetreiber feststellen, dass der User nicht bereit ist so oft zu klicken, wie der Webbetreiber es gerne hätte. Wir sind heute unheimlich klick- und tippfaul. Wer schon mal einen interessanten und längeren Diskussionsfaden im Heise-Forum konsequent lesen wollte, hat vermutlich spätestens nach dem zehnten neu aufgerufenen Beitrag aufgegeben, zumal die Hälfte der Beiträge sich auf „ROFL“, „LOL“ oder „SCNR“ beschränkt.

Mit den heutigen Smartphones wiederum ist das Scrollen einfacher als das Aufrufen neuer Websites durch das Berühren eines Links. Das Thema mobiles Web zwingt uns außerdem wieder dazu, über knappe Bandbreiten, lange Ladezeiten, Verbindungsabbrüche und weitere Ärgernisse nachzudenken, die uns noch aus der Modem-Zeit verfolgen. Die meisten bekannten Websites sind von der Performance her auf DSL angelegt und laden neben dem eigentlichen Inhalt noch einen Rattenschwanz an externen Inhalten, JavaScript, Werbebildchen und allerlei anderen Merkwürdigkeiten nach. Selbst bei DSL kann es immer noch mehr als zehn Skeunden dauern, bis die Seite komplett geladen ist. Im mobilen Web dauert das entsprechend länger und so lange möchte einfach niemand warten. Es ist also schon aus ökonomischer Sicht sinnvoll, zusammenhängende Artikel auf eine Seite zu packen.

Gibt es einen allgemeinen Wortschatz?

Neuerdings muss ich wieder verstärkt an texten arbeiten. Dabei geht es um die optimale Ausdrucksweise für bestimmte Zielgruppen. Dabei ist vor allem wichtig herauszufinden, welche Wörter oder Floskeln von der Zielgruppe verstanden werden. Grob gesprochen soll die Hausfrau die Texte verstehen und der Professor soll nicht gelangweilt werden.
Bei einigen juristischen oder gesellschaftswissenschaftlichen Konstruktionen scheint die Sache recht klar. Der „Sachverhalt“ wird zwar verstanden, ist aber kein Wort, das man im allgemeinen
Sprachgebrauch verwenden würde. Neulich habe ich in einem Buch über Sozialphobie gelesen und das Wort „Diskriminierung“ gehört. Damit ist nicht die Benachteiligung, sondern nur die Unterscheidung ohne
negativen Unterton gemeint. Wie sieht es aber mit dem Begriff „Prägung“ aus, die in der frühkindlichen Erziehung eine wichtige Rolle spielt? Und weiß jeder Erwachsene tatsächlich, was „pränatal“ bedeutet?
Ich gehe da immer von meinem eigenen Sprachgefühl aus. Einerseits lese ich viel im Internet, höre viele Hörbücher und blättere hin und wieder auch durch Zeitschriften durch. Andererseits bin ich selbst durch ein
sozialwissenschaftliches Studium gegangen und merke schon, dass sich so manche Fachtermini bei mir einschleichen. Wie steht es eigentlich mit dem Begriff Fachterminus oder Fach-Jargon? Wäre hier Fach-Chinesisch verständlicher oder vielleicht doch zu banal?
Ich versuche hier pragmatisch zu sein. Wenn ich englische Sendungen oder Vorträge höre, verstehe ich meistens auch viele Wörter nicht, aber der Kontext ist mir meistens klar. Zudem sollte man nicht der Neigung vieler Akademiker nachgeben, die alle anderen Menschen für infantil halten. Vielleicht sind folgende Regeln hilfreich:

  • Verwende keine Wörter, deren Bedeutung du nicht kennst.
  • Sprich nicht über Dinge, von denen du keine Ahnung hast.
  • Respektiere deine Leserschaft, unter- und überschätze es nicht.
  • Fordere dein Publikum zum Nachdenken heraus, indem du einige komplexe Gedanken und Ideen – verständlich – in deinen Texten unterbringst.
  • Schreibe interessant und lebendig und die Leser werden dir folgen.

Weiterlesen

Zugänglichkeit – über Shells, GUIs und Audio

Das Leben des blinden Computernutzers bleibt immer spannend. Er darf sich jedes Mal aufs Neue überraschen lassen, ob er ein bestimmtes Programm bedienen kann oder nicht. Viele Programme lassen sich zumindest teilweise über Tastatur bedienen, viele andere aber nicht. Spaßig wird es, wenn sich Teile des Programms per Tastatur erreichen lassen, andere Funktionen aber hinter Icons auf der Programmoberfläche versteckt sind. Im zweifelsfall wird der Blinde nie erfahren, dass es solche Funktionen gibt. Blinde sind nämlich ebenso wenig geneigt, Dokumentationen zu lesen wie Sehende.

Dabei könnte alles so einfach sein, wenn die Programmierer und Entwickler die Tastatur nur als einen Zugangsweg betrachten würden, der mit der Maus gleich berechtigt ist. Spannend wird es jetzt, weil sich zwischen Maus und Tastatur nun der Dritte Weg über Touchpads etabliert. Alle komplexen mobilen Betriebssysteme werden ohne Anpassung für Touchscreens scheitern.

Es ist ein offenes Geheimnis: Benutzer von Tastatur und der Kommandozeile kommen nach einer gewissen Einarbeitung schneller zum Ziel als die Benutzer graphischer Oberflächen. Eine große Ausnahme ist die Fotobearbeitung. Die Textverarbeitung hingegen ist ein gutes Beispiel: Ein Darstellungsproblem ließe sich in HTML wesentlich schneller lösen als etwa in einem Word-Dokument.
Die Kommando-Zeile ist die Alternative zur GUI, die Tastatur ist die Alternative zur Maus, der audivitive Zugang ist die Alternative zum optischen Zugang.
Wenn man heutzutage mehrere Hundert Euro für ein Betriebssystem ausgibt, dann sollte man auch den Zugang bekommen, den man benötigt. Microsoft aber hat bis heute im Gegensatz zu anderen keinen auditiven Zugang zu seinen Betriebssystemen. Im Gegenteil, viele grundlegende Funktionen sind nur per GUI und Maus zugänglich. Das Unternehmen hat viel Geld in eine graphische Benutzeroberfläche gesteckt, die kein Mensch wirklich braucht, aber keinen Euro in einen Zugang, der auch Blinden zugute kommt.
Nebenbei bemerkt nutzen solche Zugänge auch Menschen mit Lern- oder Leseschwäche, die sich damit auch die Oberfläche erschließen oder sich lange Texte vorlesen lassen können.

Hilfsmittel für Sehbehinderte im Eigenbau

Die meisten Nicht-Behinderten kriegen selten mit, wie teuer Hilfsmittel wie Hörgeräte, Vorlesesoftware und andere unentbehrliche Technik sein kann. Das Kartell der Brillenhersteller hätte ein heilsamer Schock sein können, wird aber wirkungslos verpuffen.

Für die Preise der Hilfsmittel sind die drei Gruppen allesamt mitverantwortlich: Die Hersteller setzen ihre Preise hoch, die Kostenträger bezahlen diese Preise und die Empfänger kümmern sich nicht weiter darum.

Ein Lamento anzustimmen wird unsere Probleme aber nicht lösen. Stattdessen ist Erfindergeist und Innovationsmut gefragt. Zumindest Blinde und Sehbehinderte können sich ihre Hilfsmittel teilweise selbst zusammenschrauben.

Ein Monokular ist ein kleines Fernglas, mit dem Sehbehinderte weit entfernte Objekte lesen können. Da sind zum Beispiel die Anzeigen am Bahnhof, die Nummern von Bussen oder die Namen von Haltestellen. Die Dinger sind gar nicht billig und physikalisch in der Vergrößerung beschränkt. Jede Digitalkamera mit TFT erreicht eine bessere Vergrößerung. Die Screens und Zoomfähigkeiten selbst von Handys sind recht ordentlich, entsprechendes kann man im Laden ausprobieren. Zu achten wäre noch auf die Akkulaufzeit.

Ein Bildschirm-Lesegerät besteht aus einem Bildschirm und einer Kamera. Die Videokamera für ein Lesegerät sollte ohne Zeitverzögerung arbeiten und einen guten optischen Zoom haben. Außerdem benötigt man eine Lichtquelle, wofür sich eine Tischlampe einsetzen ließe. Mit beidem sollte man reichlich experimentieren, in diesem Falle dürfte das ganze Paket bestehend aus Bildschirm – den hat man meistens eh schon – einer GUTEN Kamera und ein starken Tischlampe immer noch leistungsfähiger und mehrseitig einsetzbarer sein als ein Bildschirmlesegerät.

Im Computer-Bereich gibt es mittlerweile reichlich Alternativen zu kommerziellen Screenreadern. NVDA für Windows, diverse Systeme für Linux und Apples voiceover für Macs. Handys kommen mit VoiceOver oder Screenreadern für Android. Kleine Netbooks lassen sich ebenfalls problemlos mit einer Linuxvariante oder NVDA ausstatten. Leider gibt es noch keinen Ersatz für Braillezeilen. Wer noch mehr Anregungen hat, wir freuen uns immer auf Hinweise.