accessCast

Am Mikrofon wie immer Manfred Heinze, die Musik im Hintergrund kommt diesmal von opsound.org, am Schluss gibt's noch mehr davon.

In der letzten Folge haben wir eine Reihe Hinweise gegeben, wie man als Entscheider oder Kunde die Qualität dessen überprüfen kann, was der Dienstleister bzw. die Agentur abgeliefert hat. Das ist natürlich nur die halbe Wahrheit, denn irgendwann in einem Projekt kommt mal der Zeitpunkt, wo man die Einhaltung bestimmter Vorgaben nachweisen muss.

Dabei sollte dies nicht erst am Ende des Projekts geschehen - wenn ein Test grundlegende Fehler aufdeckt ist es dann meistens für große Änderungen zu spät. Deswegen stellen wir heute empfehlenswerte Testwerkzeuge vor, die in keiner Design- und Entwicklungsabteilung fehlen sollten.

Die speziellen Fähigkeiten dieser Testwerkzeuge kann man generell in drei Kategorien einsortieren:

• sie ermöglichen die Analyse von potenziellen Fehlern direkt im Kontext der Seite;
• sie simulieren bestimmte Ein- und Ausgabe-Szenarien;
• sie übergeben die Seite an dritte Prüftools, die dann nach einer Liste von Kriterien maschinell testen.

Und dann gibt es noch Werkzeuge, die alles auf einmal können, und manche davon sogar richtig gut. In der Regel sind dies so-genannte Toolbars oder Erweiterungen bzw. Add-Ons, die man in seinen Web-Browser installiert.

Dazu gehören Erweiterungen, die bei keinem ernsthaften Web-Entwickler fehlen sollten wie die Web Developer Toolbar für Firefox und deren Pendant für den IE, die Developer Toolbar von Microsoft. Mit diesen können sie die üblichen Tests wie Validierung und ähnliches vornehmen, aber auch schon einige Dinge im Bereich Accessibility testen.

So kann man durch das Abschalten von CSS testen, ob die Seite dann immer noch eine sinnvolle Struktur aufweist. Bei diesem Test sollten Sie darauf achten, ob sich die Struktur einer Seite durch geeignete Elemente wie z.B. Überschriften erschließen lässt. Hilfsmittel wie Screenreader bieten Ihren Nutzern Funktionen, mit denn sich alle Überschriften eines Dokumentes isolieren lassen; der Nutzer kann hiermit eine Seite akustisch überfliegen. Die praktische Erfahrung hat gezeigt, dass von solchen Funktionen in Hilfsmitteln reger Gebrauch gemacht wird; eine Seite sollte also entsprechend gut strukturiert sein.

Ein anderer einfacher Test, den Sie mit diesen Werkzeugen durchführen können ist das Aufspüren von fehlerhaften oder ›vergessenen‹ Alternativtexten. So können Sie in der Web Developer Toolbar mit dem Befehl »Replace Images with Alt-Attributes« herausfinden, ob sich alle relevanten Inhalte noch erschließen lassen, wenn man nur den zusätzlichen Alternativtext zur Verfügung hat.

Vor diesen Tests sollte aber immer eine Validierung ihrer Dokumente erfolgen, d.h. die positive Antwort auf die Frage, ob sich Ihr HTML & CSS an die vom W3C vorgegebenen Regeln hält. Wenn Seiten nicht mal ansatzweise in die Nähe von syntaktisch einwandfreiem HMTL kommen braucht man sich auch keinerlei Hoffnungen zu machen, diese jemals barrierefrei zu bekommen. Ein Tipp: der WDG HTML Validator unter htmlhelp.com testet in einem Rutsch bis zu 100 Seiten auf einmal.

Neben den genannten Universal-Schweizermessern gibt es auch einige spezialisierte Werkzeuge, die wir Ihnen vorstellen wollen. Allerdings, das muss man einschränkend hinzufügen, haben alle diese Werkzeuge einem starken Fokus auf technische Barrieren, die vorzugsweise blinde Nutzer betreffen sowie verschiedene gestalterische Kriterien, wie sie für stark sehbehinderte Nutzer relevant sind. Inhaltliche Barrieren lassen sich – das liegt leider in der Natur der Dinge – mit keinem der heute vorgestellten Werkzeuge finden.

Übrigens: dass wir hier das direkte Testen in Hilfsmitteln wie zum Beispiel in verbreiteten Screenreadern nicht auflisten hat einen einfachen Grund: diese gehören nicht in die Werkzeugkiste eines Web-Entwicklers, sondern in die Hände von erfahrenen Nutzern solcher Hilfsmittel. Ein Screenreader ist kein Prüftool wie ein Validator.

Ein Screenreader ist streng genommen ja noch nicht mal ein Hilfsmittel, sondern der übliche Zugang eines blinden oder stark sehbehinderten Nutzers zum Computer – vergleichbar der grafischen Oberfläche für sehende Nutzer. Und genau wie diese grafische Oberfläche setzt ein Screenreader eine gewisse Einarbeitungszeit voraus, um die nötigsten Befehle zu beherrschen. Und selbst dann bekommt man als sehender Tester nicht unbedingt brauchbare Ergebnisse und oftmals sogar schlichtweg unbrauchbare, weil irreführende Testergebnisse. Die ganz spezifischen Usability-Probleme eines blinden Nutzers findet man nämlich auf diese Art und Weise nicht – dafür muss man mit echten Nutzern testen.

Tools speziell für den Firefox

Die Firefox Accessibility Extension der Universität von Illinois hat ihre klaren Stärken in der Simulation von bestimmten typischen Nutzungsszenarien, die typisch für Menschen mit Behinderungen sein können. Hier sind insbesondere die beiden linken Menüs »Navigation« und »Text Equivalents« von Bedeutung. Im ersten Menü finden sich eine ganze Reihe von Einträgen, die zum Beispiel die Möglichkeiten zur strukturierten Navigation per Überschriften-Elementen anzeigen. Es lassen sich sämtliche Links, Image Maps, Formulare und Datentabellen einer Seite zusammenfassen, aber auch Sprachwechsel und Accesskeys in einem separaten Fenster auflisten. Ebenso werden auf Wunsch Abkürzungen ausgeschrieben, sofern sie mit einem title-Attribut erklärt sind.

Noch ein Tipp: die Accessibility Toolbar ist nicht nur ein Prüftool, sondern auch für Nutzer z.B. mit motorischer Behinderung interessant. Im Menü »Keyboard« lassen sich einige zusätzliche Einstellungen zur Tastaturnavigation vornehmen, die der Firefox ab Werk nicht beherrscht, wie zum Beispiel das Anspringen von Überschriften per Tastatur.

Wie in den meisten Toolbars lassen sich auch hier die zu testenden Seiten an externe Prüfwerkzeuge übergeben. Eine Besonderheit der Accessibility Extension ist der Functional Accessibility Evaluator, der nicht nur stur nach einer der üblichen Checklisten testet, sondern auch allgemein als Best Practice anerkannte Techniken zum Aufbau von Seiten abfragt.

Tools speziell für den Internet Explorer

Falls Sie den Internet Explorer unter Windows einsetzen empfehlen wir Ihnen dringend die Web Accessibility Toolbar, die kostenlos vom Web Accessibility Tools Consortium veröffentlicht wurde. Eine ältere eingedeutschte Version finden Sie auf den Seiten von »Web for All« aus Heidelberg; falls Sie den IE 7 einsetzen benötigen Sie jedoch die Version 2.0, die zurzeit nur in Englisch zu haben ist.

Diese Toolbar ist die bei weitem Beste unter den vergleichbaren Angeboten für diesen und für andere Browser. Neben den üblichen Befehlen zur Weitergabe der Seiten an Validatoren oder zum an- und abschalten von bestimmten Inhalten gibt es einige Funktionen, die in der Form einmalig sind. Zum einen ist da die umfangreiche Dokumentation mit sehr vielen Links zu weitergehenden Erklärungen der Hintergründe für die einzelnen Tests. Zum anderen gibt es sehr viele Funktionen zur kleinteiligen Analyse von ganz spezifischen Accessibility-Problemen wie zum Beispiel beim Aufbau und der Auszeichnung von Datentabellen und allen anderen Strukturelementen. Bestimmte für manche Hilfsmittel problematische CSS-Konstruktionen wie z.B. display:none lassen sich direkt aus der Toolbar heraus auf display:inline ändern, um damit versteckte Texte und Funktionen aufzuspüren.

Grundlegendes zum Thema Testen

Die BITV besteht bekanntlich aus 66 einzelnen Punkten (46 der Priorität 1 und 20 der Priorität 2). Von diesen einzelnen Punkten lässt sich nur ein sehr geringer Teil wirklich verlässlich maschinell testen. Für alle anderen Punkte braucht man einen menschlichen Tester, der, eventuell unterstützt von einer Software, die potenziellen Fehlerquellen durchgeht und bewertet.

Zu den maschinell prüfbaren Punkten gehören die Validität des Quelltextes, die Angabe einer natürlichen Sprache der Dokumente und die Verwendung von veralteten HTML-Elementen und -Attributen. Bei einigen Punkten kann eine Prüfsoftware lediglich erkennen, ob zum Beispiel bestimmte Konstruktionen wie Labels in Formularen überhaupt verwendet wurden – nicht aber ob sie korrekt verknüpft sind und somit für den Nutzer funktionieren.

Ähnliches gilt für die gleich zu Beginn der Verordnung eingeforderten Textalternativen: eine Software kann zwar die Verwendung feststellen, nicht aber ob der Alternativtext tatsächlich auch sinnvoll ist. Leider gehen viele Prüfprogramme so weit und geben bei leeren alt-Attributen einen Fehler aus, auch wenn es beim besten Willen keinen sinnvollen Alternativtext z.B. für eine Schmuckgrafik gibt.

Dies geht so weit, dass manche Prüfprogramme nach verdächtigen Mustern suchen, die man öfter in fehlerhaftem HTML findet. Das kann zum Beispiel die Angabe des Dateinamens im Alternativtext eines Bildes sein (die Software sucht dann nach Endungen wie .gif oder .jpeg). Wir hatten hier bei ›Einfach für Alle‹ aber auch schon mal den Fall, dass ein Prüftool eine Seite beanstandete, in der angeblich ein verdächtiger Linktext gefunden wurde. Des Rätsels Lösung: im Weblog war ein Link zu einem Artikel, der selbsterklärende Linktexte zum Thema hatte. Das Prüfprogramm fand im Text »Don‘t use click here« das Muster »click here« und gab einen entsprechenden Fehler aus. Fazit: Prüfprogramme können immer nur so gut sein wie die Regeln, nach denen sie testen. Aber manchmal schießen die Entwickler solcher Werkzeuge übers Ziel hinaus.

Diese starke Fokussierung auf die rein technischen Barrieren führt dann in der Regel zu einem weiteren Problem: die Entwickler verstricken sich in die technischen Aspekte und vergessen dabei, dass der wirkliche Sinn eines barrierefreien Webangebot ist, auf die Bedürfnisse von Menschen einzugehen.

Auch die Interaktion eines Nutzers mit einem Webangebot lässt sich mit solchen Tools natürlich nicht testen, da diese nur einzelne Aspekte gleichzeitig abprüfen können, nie aber das gesamte Zusammenspiel aller Komponenten einer Seite. Wenn bei komplexen Abläufen und Transaktionen wie zum Beispiel einem Einkauf nur eine unüberwindbare Barriere mitten im Ablauf besteht, dann ist der gesamte Prozess für Nutzer nicht zu gebrauchen, die auf ein barrierefreies Angebot angewiesen sind.

So, das war die achtundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BITV, Testen und Werkzeuge. Bis zum nächsten Mal.