Accessibility-Tests in der Praxis
Barrieren einreißen

Allgemein

Wer barrierefreie Webseiten entwickelt, sollte sich nicht ausschließlich auf die offiziellen Accessibility-Regeln fokussieren, sondern sich in die Zielgruppe hineinversetzen. Der Artikel zeigt, wie Sie Ihre Website auf Herz und Nieren testen.

Ausgangspunkt: Zielgruppe

Accessibility-Tests in der Praxis

Accessibility ist heute selten ergebnisorientiert, sondern regelorientiert. Die meisten Webdesigner hangeln sich entlang der Regelwerke und Checklisten des W3C (www.w3.org) oder der deutschen Übertragung, der BITV (www.einfach-fuer-alle.de/artikel/bitv), und erfüllen Prüfpunkte. Das ist natürlich in Ordnung, schließlich sind die allgemeinen Regeln für Accessibility oberster Maßstab für das Siegel »Accessibility-konforme Website«. Diese Regeln und auch die potenziellen Nachfolger muss man allerdings auch kritisch betrachten.

Aber eigentlich dürfen die Regeln nur eine Ausgangsbasis bilden. Sie sind nur der Startpunkt zu barrierefreien oder zumindest barrierearmen Websites. Dieser Artikel geht deswegen einen anderen Weg: Ausgangsbasis ist die Zielgruppe, also alle Menschen, für die eine besser zugängliche Website entstehen soll. Um sich in die Zielgruppe hineinzuversetzen, erfahren Sie mehr über die Vielzahl an Test- und Simulations-Tools und lernen die Hürden kennen, auf die Menschen mit Behinderungen im Web stoßen.


Für wen optimieren?

Accessibility-Tests in der Praxis

Prinzipiell ist die Antwort natürlich klar, für wen man seine Websites optimiert: für alle. Denn genau das ist ja das Ziel von Zugänglichkeit: Barrierefreiheit, das heißt, der Abbau aller Hindernisse. Etwas defensiver formuliert sollte eine Website möglichst barrierearm sein, also für möglichst viele Menschen problemlos zu erfassen und zu nutzen sein.

Die eigentliche Accessibility-Optimierung geschieht allerdings nicht für alle Nutzer, sondern mit Blickrichtung auf Behinderungen oder Einschränkungen, die sie davon abhalten, eine nicht optimierte Website zu nutzen. Die Grenze ist hier fließend: gute Accessibility-Optimierung kann jedem Surfer zugute kommen, da eine Website dadurch besser navigierbar ist und sich allgemein die Bedienbarkeit erhöht. Auf der anderen Seite sind bei schlecht gemachter Optimierung auch negative Auswirkungen denkbar. Wird beispielsweise ein aussagekräftiges Diagramm aus Accessibility-Gründen in einen komplexen Text umgewandelt, ist damit keinem geholfen. Behalten Sie also immer im Blick, dass eine gute Website für noch mehr Menschen nutzbar werden soll, ohne andere Nutzer einzuschränken.

Ein wenig mehr über die Zielgruppe verraten die offiziellen und geschätzten Zahlen. Das statistische Bundesamt zählt die Inhaber eines Schwerbehindertenausweises, allerdings erst bei einer Behinderung ab 50 Prozent. Im Jahr 2003 sind das allein in Deutschland 6,639 Millionen Menschen (www.destatis.de/basis/d/solei/soleiq27.php), also über acht Prozent der Bevölkerung. Natürlich ist eine Statistik mit Vorsicht zu genießen. Die Differenzierung, um welche Art von Behinderung es sich handelt, ist nicht besonders gut. Rein demografisch sind knapp 50 Prozent davon über 65 Jahre alt. Andererseits zählen zur Statistik nur die Menschen mit mindestens 50-prozentiger Schwerbehinderung. Nicht erfasst sind also beispielsweise viele Menschen, die einfach nur schlecht sehen oder an einer Art von Farbenblindheit leiden. Außerdem zählen natürlich nur diejenigen dazu, die einen Schwerbehindertenausweis beantragt haben.


Regeltests

Accessibility-Tests in der Praxis

Wie schon erwähnt, bilden die Accessibility-Regeln die Basis für eine barrierearme Website. In der Praxis sollten Sie immer damit beginnen, alle WCAG- beziehungsweise BITV-Regeln zu erfüllen. Ein Beispiel dafür, wie das geht, haben Sie bereits im Artikel »Nicht ausklammern« (Ausgabe 2/2006, Seite 61 oder als PDF auf der Heft-CD) kennen gelernt.

Im vorliegenden Artikel geht es darum, wie Sie Ihre Website auf Barrierefreiheit testen: Sinnvoll ist für den Anfang das Validieren von XHTML und CSS. Dazu greifen Sie entweder zu den offiziellen Validatoren (validator.w3. org und für CSS jigsaw.w3.org/css-validator) oder zu den Testwerkzeugen Ihres Editors. Zwar ist Standardkonformität für Accessibility in der Praxis nicht wirklich wichtig; da die WCAG-Richtlinien allerdings den korrekten Einsatz der W3C-Standards erwarten, schließen Sie damit schon einmal eine Fehlerquelle für die Validatoren aus.

Unter den Accessibility-Tests ist der in vielen Programmen integrierte Bobby besonders bekannt. Das Ganze gibt es auch in der Online-Variante von der dahinter stehenden Firma Watchfire (webxact.watchfire.com). Die Konkurrenz schläft allerdings auch nicht. Hisoftware hat sogar zwei Online-Tests im Angebot: Cynthia Says (www.cynthiasays.com) und einen Test unter www.hisoftware.com/accmonitorsitetest. In eine ähnliche Kategorie fällt Lift (www.usablenet.com). Diesen Usability-Prüfer gibt es als Server-Variante oder als Dreamweaver-Plug-in. Eine Variante des Dreamweaver-Plug-ins ist kostenlos, der Rest der Tools beginnt preislich bei etwa 300 Dollar.

Einen etwas anderen Weg verfolgt wave.webaim.org. Hier werden die einzelnen Bereiche der untersuchten Webseite hervorgehoben und mit Symbolen wird markiert, wo sich potenzielle Accessibility-Probleme befinden. Im Gegensatz zu den kompletten Checklisten fehlen hier natürlich die expliziten Hinweise auf Prüfpunkte, die nur visuell überprüfbar sind. Dafür ist das System ausgesprochen übersichtlich. Der Prüfer ist auch als Toolbar für den Browser erhältlich. Der Accessibility Valet Demonstrator (valet.webthing.com/access/url.html) geht das Problem ähnlich an: Er gibt den HTML-Quellcode mit der Bewertung für einzelne Accessibility-Prüfpunkte aus.

Die meisten Online-Validatoren eignen sich hervorragend für Einzeltests, sind aber schon allein dadurch, dass der Anwender nur einen URL oder eine Datei angeben kann, beschränkt. Manche erlauben außerdem innerhalb einer bestimmten Zeit nur begrenzte Seitenmengen. Das ist nur logisch, da meist ein auch offline erhältliches, kostenpflichtiges Tool dahinter steht. Die Frage ist, ob sich diese Ausgabe lohnt. Bei größeren Websites ist dies sicher der Fall, vor allem, wenn der eigene Web-Editor keinen Accessibility-Check mitliefert. Der Marktführer Macromedia Dreamweaver hat beispielsweise einen Accessibility-Test direkt integriert (Datei, Seite überprüfen, Zugänglichkeit überprüfen).

Wer sich schon für die neuen Richtlinien in der Version WCAG 2.0 interessiert, kann den Online-Prüfer der Universität Toronto unter checker.atrc.utoronto.ca verwenden. Er ist bereits mit den noch im Working-Draft-Stadium befindlichen Richtlinien vertraut, kann aber selbstverständlich nicht immer die aktuelle Situation der noch im Wandel befindlichen Spezifikation abbilden.


Farben manuell checken

Accessibility-Tests in der Praxis

Immer, wenn die automatischen WCAG-Prüfer versagen, liegt das an Kriterien, die kaum automatisiert geprüft werden können. Eine davon ist der ausreichende Farbkontrast beziehungsweise die Optimierung für unterschiedliche Arten von Farbenblindheit.

Bevor die Prüfwerkzeuge zu Wort kommen, zuerst einmal zum Hintergrund. Farbenblindheit ist – zumindest aus medizinischer Sicht – nur der Name für das Unvermögen, Farben zu sehen (Achromatopsie) oder das Sehen von ausschließlich blauer Farbe (Blau-Monochromasie). Diese Formen sind allerdings die seltensten. Wesentlich häufi
ger sind die Formen der Farbenfehlsichtigkeit, die sogar unter Umständen gerade in leichterer Ausprägung vom Betroffenen überhaupt nicht bemerkt werden. Am häufigsten ist die Rotgrünschwäche, allerdings gibt es auch andere Varianten.

Abhängig ist dies davon, welche Farbrezeptoren im Auge von dem Defekt betroffen sind. Als Basis für einen Test zur Farbenfehlsichtigkeit, den Farnsworth-Test, dient übrigens der Farbkreis. Durch das Legen von Farbkarten in der Reihenfolge des Farbkreises lassen sich Fehlsichtigkeiten recht exakt festlegen. Mehr zum Farbkreis und zum Einsatz von Farbe im Web lesen Sie im Artikel »Bunte weite Welt» (Ausgabe 3/2006, Seite 54 oder als PDF auf der Heft-CD). Dort wird auch ein Beispiel mit Deuteranopie und Protanopie, zwei häufigen Formen der Rotgrünschwäche, gezeigt.

Der Test ist sehr einfach: Für Bilder gibt es online einen Selbstcheck unter vischeck.com. Er konvertiert übermittelte Bilder. Ebenfalls dort zu finden ist ein Korrekturwerkzeug, das den Rot-Grün-Kontrast erhöht und versucht, das Bild für Farbfehlsichtigkeiten zu optimieren. Davon darf man allerdings nicht zu viel erwarten. Die beste Lösung ist es, bedeutsame Informationen nicht ausschließlich mit Farbe oder zumindest nicht mit den besonders kritischen Farben Rot und Grün zu vermitteln.

Wer die komplette Website testen möchte, dem sei noch der Colorfilter unter colorfilter.wickline.org empfohlen. Hier geben Sie einen URL an und erhalten das konvertierte Ergebnis. Im Nachhinein lassen sich alle Parameter zur Art der Farbfehlsichtigkeit und zu den sonstigen Einstellungen verändern.


Hörbares Web: Screenreader

Accessibility-Tests in der Praxis

Viele der Accessibility-Richtlinien sind auf die Zielgruppe der Sehbehinderten ausgerichtet. Dass Text in der Schriftgröße skalierbar sein sollte und deswegen Internet Explorer-freundlich in em angegeben wird, gehört zum Allgemeingut. Weiter gehen die medienspezifischen CSS-Stile aural beziehungsweise speech und braille als Ausgabemedien. Und auch viele andere Accessibility-Regeln beispielsweise für Alternativtexte zu Bildern zielen auf Sehbehinderte.

Um sich einen Eindruck von den Problemen zu verschaffen, die auf diese Nutzer zukommen, verwenden Sie die Simulation unter www.webaim.org/simulations/screenreader-sim.htm. Sie liest die Testwebsite einer Universität vor und zeigt sehr gut, wie schwierig es ist, sich in einer schlecht gestalteten Website zurechtzufinden. Allerdings benötigen Sie dafür das Shockwave-Plug-in. Wer noch praktischer testen möchte, kann sich einen Screenreader installieren. Der bekannteste ist sicherlich Jaws für Windows (www.freedomscientific.com/fs_products/JAWS_HQ.asp), der allerdings in der Professional-Variante mit über 1000 Dollar zu Buche schlägt. Ein anderes Konzept verfolgt Browsealoud (www.browsealoud.com): Hier zahlt die Website und die Software zum Vorlesen ist kostenlos. Je nach Betriebssystem sind natürlich noch andere Hilfen verfügbar. Unter MacOS X gibt es beispielsweise bereits integriert die Möglichkeit, sich Menübefehle und Ähnliches vorlesen zu lassen.


Vergessene Zielgruppen

Accessibility-Tests in der Praxis

Sehbehinderungen wirken auf Außenstehende beim Betrachten einer Website als immenses Hindernis, weil es sich beim Web um ein hauptsächlich visuelles Medium handelt. Deswegen steht die Optimierung für Screenreader und Braille-Ausgabegeräte sowohl in den Accessibility-Richtlinien als auch in Fachartikeln wie diesem meist an erster Stelle. Dabei wird aber gerne vergessen, dass es noch viele andere Behinderungen und Kombinationen von Behinderungen gibt, die besonders problematisch sind. Zu nennen sind hier Formen von Lese- und Lernschwächen. Gehörlose können beispielsweise zwar meist gut sehen, haben dafür aber oft Schwierigkeiten, die Inhalte zu erfassen.

Besonders heftig in der Diskussion sind reine Textversionen einer Website als Accessibility-gerechte Alternative. Die Kritik daran ist klar: Selbst bei einem CMS oder Redaktionssystem ist die Textversion oft nicht so aktuell oder es fehlen wichtige Informationen, die auf der normalen Seite nur mit Bildern oder Ähnlichem transportiert sind. Die zweite Kritik betrifft die ausschließliche Orientierung auf Sehbehinderungen, denn beispielsweise Menschen mit Lese- und Lernschwächen hilft eine Textwüste überhaupt nichts.

Wenn man nun aber schon kritisiert, dass diese Zielgruppen oft vergessen werden, ist auch die Frage, wie sie sich überhaupt erreichen lassen. Ein Vorschlag besteht darin, Videos mit der Gebärdensprache einzusetzen, die immerhin geschätzte 50000 Menschen in Deutschland sprechen. Zugegeben, dieser Aufwand rechnet sich wirtschaftlich nicht. Und ob er mit Hinblick auf die Gleichstellung von Behinderten im Grundgesetz für öffentliche Stellen verpflichtend gemacht werden kann, ist sehr zweifelhaft. Die wichtigsten Informationen können bei zentralen staatlichen Stellen allerdings durchaus in Gebärdensprache vorgehalten werden.


Faktor Zeit

Accessibility-Tests in der Praxis

Jenseits des großen Aufwands für die kleine und dank modernster Hörgeräte schrumpfende Zielgruppe der Gehörlosen gibt es aber noch viele andere Veränderungen, die man für Menschen mit Lese- und Lernschwächen, aber auch viele andere Formen der körperlichen Behinderung vornehmen kann.

Das Interview mit Susi Glas zeigt, dass es vor allem die Menge an Informationen und ihre Aufbereitung ist, die vielen Menschen Probleme bereiten. Das heißt auch, dass ein sehr guter Schritt in Richtung weniger Barrieren darin besteht, die Informationsstruktur der Website zu überdenken. Dabei hilft teilweise auch Software. Beispielsweise gibt es unter www.gritechnologies.com/tools/spider.go einen Suchmaschinensimulator, der zeigt, wie eine Website bei Google erscheinen könnte. Da Google wohl der beliebteste Einstiegspunkt ins Web ist, ist hier ein klarer und verständlicher Text besonders wichtig. Ebenfalls praktisch sind Navigationshilfen wie Access-Keys, die auch bei langsamer oder eingeschränkter Maus-Bedienfähigkeit schnell zum Ziel führen. Zugegebenermaßen sind letztere nicht wirklich standardisiert einzusetzen und deswegen zu Recht umstritten.

Sieht man sich an, welche Tasten im Browser bereits vergeben sind, bleiben browserübergreifend nur noch die Ziffern von 0 bis 9 als Access-Keys übrig. Und auch diese muss der Nutzer natürlich erst einmal mitgeteilt bekommen. Dennoch kann dieser alternative Weg, der den Webdesigner wenig Arbeit kostet, vielen Surfern helfen, die Hilfssoftware verwenden, um sich die Access-Keys anzuzeigen. Als Webdesigner können Sie sogar selbst aktiv Access-Keys anbieten: Ein auf PHP basierendes Tool ist das Access Key Pad, das sich in Ihre Website integrieren lässt (2bweb.de/accesskey) und Standardtastenbelegungen vorgibt.


Fazit

Accessibility-Tests in der Praxis

Accessibility ist harte Arbeit und sollte nicht auf bestimmte Behinderungen reduziert werden. Das Ziel lautet immer, so barrierearm wie möglich zu programmieren. Natürlich ist das mit großem Aufwand verbunden: Allein alle hier vorgestellten Tools ordentlich zu testen, dauert schon Tage. Dieser Aufwand wird in der freien Wirtschaft – das heißt, ohne gesetzliche Verpflichtung – nicht immer in diesem Umfang zu leisten sein. Aber auch dann sollte man sich zumindest in Grundzügen mit dem Problem beschäftigen und so viel tun wie irgend möglich. Wer sich in seine Zielgruppe hineinversetzt und mit den Menschen Kontakt hat, für die
er seine Websites optimiert, wird mit dem Herzen dabei sein.