Jetzt muss man sich beim Webdesign auch noch um diese Behinderten kümmern?! Wer so denkt, argumentiert nicht nur moralisch fragwürdig, sondern versteht Barrierefreiheit grundfalsch, und zwar gleich mehrfach. Erstens entspringen die meisten Hindernisse, die Behinderten den Besuch von Webseiten vergällen, entweder überholten Layout-Tricks, die sowieso nicht dem HTML-Standard entsprechen, oder unsorgfältiger Arbeit und mangelndem Qualitätsbewusstsein.
Zweitens kommen barrierefreie Webauftritte nicht nur im klassischen Sinn Behinderten zugute. Barrierefreiheit hilft vielmehr überall dort, wo die Nutzung eines Online-Angebots durch technische Hindernisse erschwert wird. Ein Beispiel sind fixe Schriftgrössen: Text in HTML-Grösse 1 mag auf einem 19-Zoll-Bildschirm in SXGA-Auflösung gut erkennbar sein; auf einem 15-Zoll-Notebook-Screen mit 1920x1200 Pixeln ist er praktisch unlesbar. Das Fazit: Schriftgrössen sollten grundsätzlich relativ definiert werden, so dass der Benutzer die Darstellung seinen Wünschen anpassen kann. Wichtig ist dies nicht nur im Content-Bereich; auch die Schrift im Navigationsmenü sollte skalierbar sein.
«Die meisten Änderungen, die Barrierefreiheit erfordert, sind eigentlich schon Bestandteil der allgemeinen Usability», betont die Accessibility-Expertin Luzia Hafen von Namics, die wir zum Thema befragt haben. Als gutes Beispiel nennt Hafen die Bundes-Website www.admin.ch
: «Sie ist ja nicht gerade ein Vorbild für tolles Design, aber die Zugänglichkeits-Richtlinien sind gut umgesetzt.»
Besonders schlecht sind für Hafen dagegen Navigationsmenüs, die ausschliesslich mit Grafik gelöst sind oder zwingend JavaScript erfordern – nach wie vor gibt es Hilfstechnologien, die mit JavaScript nicht umgehen können, das heisst, die Navigation kann nicht bedient werden. Sehbehinderte Menschen leiden unter grafisch dargestellter Schrift, weil sich diese nicht verlustfrei vergrössern lässt und die Information unlesbar wird.
Links rund um das Thema Barrierefreiheit
Ebenso unliebsam wirken viele JavaScript-gesteuerte Aufklappmenüs und andere Konstrukte, die eine allzu exakte Positionierung des Cursors erfordern: Was mit der Maus noch halbwegs bedienbar ist, gerät mit einem Touchpad zur dreisten Zumutung – auch für «normale» Surfer. Hafen: «Was sowieso schon schwierig zu bedienen ist, bekommt man auch nicht barrierefrei.»
Dies gilt in besonderem Mass für ältere Webuser: Immer mehr Senioren kommen auf den Internetgeschmack, und auch bestehende IT-Anwender werden kaum jünger. Mit dem Alter nehmen aber die sensorischen und motorischen Fähigkeiten ab; so leiden ab einem Alter von 60 Jahren rund 10 Prozent an der Sehstörung AMD (altersabhängige Makuladegeneration); mit
70 Jahren sind es bereits 20 Prozent.
«Es trifft eben nicht nur eine kleine Randgruppe von Schwerbehinderten», meint Luzia Hafen und betont die generelle Bedeutung der Barrierefreiheit: «Ob sich ein Internetauftritt speziell für Blinde lohnt, die nicht die Zielgruppe der Präsenz sind, kann im allgemeinen verneint werden. Die Frage, ob eine Website barrierefrei sein soll, würde ich dagegen mit einem ganz grossen Ja beantworten.»
Spezielle Behinderten-Websites, zum Beispiel eine Nur-Text-Version, ist den Betroffenen ohnehin ein Dorn im Auge – so etwas verstärkt nur die Ausgrenzung der Benutzer und bringt für den Anbieter unnötigen Mehraufwand. Hafen: «Es braucht kein Sonderinternet für Behinderte, sondern vereinfachten Zugang zum ganz normalen Web, keine Blinden-Spezialversion, sondern ein Internet, das für alle zugänglich ist.»
Damit dies Realität wird, muss der HTML-Code den W3C-Standards entsprechen: «Valider Quellcode ist unabdingbare Grundvoraussetzung für barrierefreie Websites. Screenreader und andere Hilfsmittel sind auf die Einhaltung der Standards angewiesen.» Luzia Hafen hält fest, dass davon auch nichtbehinderte Surfer profitieren und nennt als Beispiel Webseiten, die per WAP-Handy nicht erreichbar sind, weil nicht standardgemäss codiert wurde.
Als erstes empfiehlt sich deshalb für jede Webseite ein Check mit einem HTML-Validator. Gute Web-Editoren bieten eine integrierte Validierungsfunktion. Auch der Online-Markup-Validator des W3C ist nicht zu unterschätzen: Zwar lässt sich damit pro Durchgang nur eine Seite unter die Lupe nehmen; dafür sind die Definitionen immer auf dem neuesten und garantiert korrekten Stand.
Laut Hafen ist mit validem Quellcode schon ein Grossteil der Accessibility-Anforderungen automatisch erfüllt: «Barrierefreiheit kostet nichts. Wer auf die Qualität achtet, ist schon grösstenteils barrierefrei.»
Dennoch stellt volle Zugänglichkeit zusätzliche Ansprüche. Auch für erweiterte Accessibility-Tests gibt es eine Fülle von Tools. Die Web Accessibility Initiative (WAI) des W3C nennt gegen dreissig Online-Dienste und Testprogramme und empfiehlt, jede Seite mit zwei verschiedenen Prüftools zu testen und die Ergebnisse zusammengefasst zu berücksichtigen.
«Die korrekte Umsetzung der WAI-Richtlinien ist nur begrenzt maschinell erfassbar; rund 70 Prozent der Details muss man von Hand überprüfen», merkt Luzia Hafen an. «Als Beispiel mag das ALT-Attribut bei Bildern dienen. Ein Test-Tool weist nur nach, ob das Attribut vorhanden ist oder nicht. Ob es wirklich sinnvoll ausgefüllt wurde, kann das Programm nicht erkennen.»
Es ist beispielweise nicht nur unnütz, sondern regelrecht hinderlich, wenn der ALT-Text statt einer Inhaltsangabe nur den Dateinamen oder die Adresse des Fotostudios enthält – der Screenreader liest dann diese überflüssigen Angaben vor und erschwert dem blinden Surfer, den eigentlichen Nutzinhalt zu erkennen.
Und es wird noch trickreicher: Das ALT-Attribut ist laut HTML-Standard zwar für jedes Bild zwingend erforderlich. Vom Accessibility-Standpunkt aus bringt ein ALT-Text aber nur für inhaltstragende Bilder Nutzen. Grafiken, die ausschliesslich dekorativen Zwecken dienen, oder gar die im herkömmlichen Tabellenlayout allgegenwärtigen Spacer-GIFs sollten auf keinen Fall zusätzlich beschriftet werden. Am besten spezifiziert man für solche Bilder ein leeres ALT-Attribut (ALT=“”).
Werden die Seiten nicht statisch erstellt, sondern mit Hilfe eines CMS laufend nachgeführt, muss auch laufend nachgeprüft werden: Auch wenn das Template absolut barrierefrei gestaltet wurde, kann ein Autor die ganzen Accessibility-Anstrengungen zunichte machen, indem er beispielsweise grundsätzlich das ALT-Attribut vergisst. Die Schulung der Autoren muss Accessibility-Aspekte deshalb eingehend berücksichtigen.
Barrieren erkennt man im übrigen am besten in realitätsnahen Testszenarien: «Es macht wenig Sinn, eine barrierefreie Website zu erstellen, ohne sie je mit Behinderten zu testen.» Die Betroffenen sollten zudem möglichst früh im Entwicklungszyklus einbezogen werden und nicht erst dann, wenn die Site schon fertiggestellt ist. Nur so lassen sich grundsätzliche Mängel ohne übermässigen Aufwand beheben. Als Beispiel nennt Luzia Hafen den Session-Timeout in transaktionsorientierten Applikationen: Ein Blinder mit Screenreader braucht zum Lesen einer Seite viel länger als ein nichtbehinderter Surfer; je nach Komplexität kann es mehrere Minuten dauern, bis der Screenreader den ganzen Inhalt vorgelesen hat. Auf manchen Online-Banking-Sites ist dann aber die maximale Reaktionszeit schon abgelaufen und der Benutzer muss von vorne beginnen – Sisyphus lässt grüssen.
Der Verband der Schweizerischen Gaswirtschaft bestellte bei der Web-Agentur Namics eigentlich nichts weiter als eine moderne Website, die technisch up-to-date sein und den aktuellen Standards genügen sollte. Barrierefreiheit ergab sich mit diesen Voraussetzungen fast von selbst.
Die neue Erdgas-Site basiert auf dem Open-Source-CMS Typo 3. Das Grundgerüst der Seiten bildet ein völlig tabellenfreies Template; die gesamte visuelle Darstellung und Positionierung der Elemente ist mit Cascading Style Sheets gelöst.
1) Das Navigationsmenü kommt ohne JavaScript und DHTML aus und funktioniert damit auch mit Nur-Text-Browser oder Screenreader problemlos.
2) Obwohl die aktuelle Seite mit dunkelrotem Text auf grünlichem Hintergrund angezeigt wird, sind Kontrast und Lesbarkeit auch für Rot/Grün-farbenblinde Surfer genügend.
3) Die Überschriften sind HTML-korrekt mit Selektoren wie H1 und H2 markiert; die Schriftattribute stammen aus dem Stylesheet und nicht von einem Font-Befehl. Das erleichtert nicht nur die Sprachausgabe durch den Screenreader, sondern fördert zumindest auf statischen Seiten auch das Ranking in Suchmaschinen.
4) Alle Schriftgrössen – auch in den Navigationsmenüs und Seitenspalten – sind relativ festgelegt. Der Benutzer kann die Schriftdarstellung nach seinem Gutdünken vergrössern und verkleinern.
5) Der Content-Bereich hat keine fixe Breite, sondern passt sich der Fenstergrösse an. Auch dies ist mit CSS-basiertem Layout ohne komplizierte Tricks zu erreichen.
6) Die inhaltstragenden Bilder sind mehrfach beschriftet: Mit einer sichtbaren Bildlegende sowie mit dem ALT- und dem TITLE-Attribut – der Screenreader liest grundsätzlich den Inhalt des ALT-Attributs vor; bei Mausberührung wird je nach Browser entweder ALT oder TITLE angezeigt.
7) Erwischt: Auch auf der fortschrittlichsten Site findet sich ein Bild als Abstandshalter. Damit der Screenreader es links liegen lässt, sollte das ALT-Attribut zwar standardgemäss vorhanden, aber leer sein: ALT=““. Achtung: Wenn nichts ausgefüllt ist, plazieren Web-Editoren hier oft sinnlosen Text wie den Dateinamen des Bildes, den der Screenreader dann naturgemäss vorliest.
8) Damit der Screenreader einen Bezug zwischen einem Formularfeld und seiner Beschriftung herstellen kann, muss die Beschriftung (hier: «Suche:») via LABEL-Attribut mit dem zugehörigen Eingabefeld verknüpft sein. Ebenfalls unabdingbar: Ein Submit-Button, mit dem das Formular abgeschickt wird – wenn dazu nur die Eingabetaste zur Verfügung steht, fehlt dem Screenreader die wichtigste Information zum Handling des Formulars.
9) Auch die kleine Hilfs-Navigation ist mit reinem HTML-Text gelöst und nicht als Image-Map. Jeder Link ist zudem suchmaschinenfreundlich mit einem TITLE-Attribut versehen, das den gleichen Inhalt trägt wie der sichtbare Text.
10) Die kleinen Symbole zur Kennzeichnung von Download-Links sind nicht als IMG-Element, sondern jeweils als Hintergrundbild des DIV-Elements plaziert, das den Link-Text aufnimmt. Auf diese Weise werden sie vom Screenreader automatisch ignoriert.
11) Zu jedem Download sollten Dateiformat und Grösse angegeben werden. Sonst kann der Benutzer nicht entscheiden, ob sich das Herunterladen überhaupt lohnt – nicht alle Dateitypen lassen sich vom Screenreader vorlesen. Auch nichtbehinderte Surfer sind für diese Informationen dankbar.
