accessCast

Am Mikrofon wie immer Manfred Heinze, die Musik im Hintergrund kommt diesmal aus der Creative Commons-Bibliothek, am Schluß gibt's noch mehr davon.

Eine der häufigsten Fragen rund um das Thema Barrierefreiheit ist, wie man als Entscheider oder Kunde die Qualität dessen überprüfen kann, was der Dienstleister bzw. die Agentur abgeliefert hat. Dabei scheitert eine vernünftige Antwort oft schon daran, dass die Richtlinien zur Barrierefreiheit zwar ein gutes Mittel zur Qualitätssicherung sind, aufgrund ihrer technischen Natur aber einen ausgebildeten Tester zur Interpretation der Ergebnisse benötigen. Daher haben wir heute ein paar einfache Tests zusammengestellt, die keine besonderen Kenntnisse in Markup-Sprachen wie HTML voraussetzen.

Einige Fragen, die Sie sich zu Beginn des Projekts stellen sollten

Falls es sich um ein bestehendes Projekt handelt sind die wichtigsten Fragen: Wie schlimm ist Ihre Website? Wie viel Ihrer Website ist zugänglich bzw. wie viel ist unzugänglich?

Egal ob nun die Barrierefreiheit im Vordergrund steht, oder ob andere Gründe wie zum Beispiel inhaltliche Erweiterungen oder Design-Änderungen den Ausschlag für einen Relaunch gegeben haben – Sie sollten zunächst alle Inhalte inventarisieren, um überhaupt einen Überblick über die vorhandenen Inhalte und Funktionen zu bekommen.

Dabei sind sich Usablility-Experten mittlerweile einig: die zentrale Einstiegsseite, neudeutsch Homepage, ist bei einer solchen Überarbeitung so ziemlich die unwichtigste Seite in ihrem ganzen Angebot. Bei der Suche nach Barrieren sollten Sie mehr Fokus auf die eigentlichen Inhaltsseiten oder die zentralen Funktionen des Angebots legen (die üblicherweise nicht auf der Homepage zu finden sind). Hier finden sich die Inhalte und Funktionen, die Benutzer auf Ihrem Angebot suchen. Also müssen diese, wie zum Beispiel ein Bestellprozess bei einem Shopping-Angebot oder die einzelnen Artikel bei einer Content-lastigen Seite, auch mit höherer Priorität bei der Beseitigung von Barrieren behandelt werden.

Ein nützliches Werkzeug um die wichtigsten Baustellen einer Website zu identifizieren ist der W3C-Log Validator, der als Open Source veröffentlicht wurde und kostenlos zum Herunterladen erhältlich ist. Mit diesem Werkzeug können die meist-besuchten Seiten eines Angebots gefunden werden und an weitere Prüf-Tools wie Validatoren geschickt werden. Diese finden ja bekanntlich schon solche Fehler wie »vergessene« alt-Attribute und ähnliches, sodass man hier einen schnellen Überblick über den Handlungsbedarf auf der technischen Ebene erhält. Der Output lässt es auch zu, dass man die vorgefundenen Fehler auf einzelne Themenbereiche herunterbrechen kann, um diese dann einzeln anzugehen.

Einige Fragen, die Sie sich während des Projekts stellen sollten

In den Prüfschritten der BIENE 2006 finden sich einige Punkte, die man hervorragend zu einer ersten (wenn auch groben) Qualitätskontrolle einsetzen kann. Sie sind alleine schon deswegen so empfehlenswert, weil die Durchführung der Tests keine großen Ansprüche an die technische Ausrüstung mit Soft- und Hardware stellen. Sie können auch von jemandem durchgeführt werden können, der nicht Diplom-Informatiker oder erfahrener Accessibility-Tester ist (im Volksmund auch Kunde oder Projektmanager genannt). Ein paar Prüfschritte haben wir mal für Sie aus dem Verfahren rausgesucht und geben Tipps, wie man die Tests selber durchführen kann.

Diese Fragen sollte ein Kunde auch noch mal bei der Abnahme des Endprodukts stellen, selbst wenn diese in früheren Phasen schon mal beantwortet wurden. Fehler können sich durchaus später erneut einschleichen.

Auf parallele seitenübergreifende Alternativ-Auftritte wird verzichtet (BIENE-Grundvoraussetzung)

Prüfen Sie, ob auf einen parallelen seitenübergreifender Alternativ-Auftritt verzichtet wird. Das Vorhandensein eines seitenübergreifenden Alternativ-Auftritts führt zum Ausschluss vom Wettbewerb.

Ein offenes Wort an alle, die Web-Auftritte beauftragen: wenn der Dienstleister Ihres Vertrauens die Frage nach der Barrierefreiheit mit »Da machen wir einfach eine Nur-Text-Version« beantwortet, sollte Sie dies nachdenklich stimmen.

Wahrnehmbarkeit bei wechselndem Hintergrund (BIENE-Prüfschritt 12.2)

Prüfen Sie in einem Windows-Kontrastmodus, ob alle Inhalte, vor allem informative Graphiken, unabhängig von der Farbe des Hintergrunds gut sichtbar sind.

Der Hintergrund für diesen Prüfschritt: viele Menschen mit Sehbehinderung surfen mit höchst individuellen Farbeinstellungen, um negative Effekte für ihre jeweilige Form der Sehbehinderung zu kompensieren. Ein mögliches Szenario sind die sogenannten Kontrastschemata unter Windows, bei denen das Design einer Seite radikal verändert wird. In der Systemsteuerung finden Sie diese unter Anzeige -> Darstellung -> Schema, dort wählen Sie zum Beispiel »Windows Kontrast #1«. Im Internet Explorer müssen Sie nun noch unter »Extras -> Internetoptionen -> Eingabehilfen« die Checkbox »Farbangaben auf Webseiten ignorieren« ankreuzen und Sie sind fertig für den Test.

Surfen Sie nun alle wichtigen Bereiche Ihrer Website ab (also auch zum Beispiel einen kompletten Bestellprozess) und überprüfen Sie, ob Sie wirklich noch sämtliche Informationen finden und ob die Orientierung auf dem Angebot noch möglich ist. Achten Sie dabei besonders auf grafische Texte, die bei diesen Einstellungen schwarz auf schwarz erscheinen könnten. Alles da? Dann haben Sie diesen Schritt bestanden.

Skalierbarkeit der Schriftgröße über die Browserfunktionalität (BIENE-Prüfschritt 13.1)

Prüfen Sie, ob mindestens Fließtext und Navigationselemente ausreichend vergrößert dargestellt werden und ob bei vergrößerter Ansicht die Lesbarkeit durch das Layout unterstützt wird.

Der Hintergrund für diesen Prüfschritt: viele Menschen sind auf bestimmte (d.h. größere oder auch kleinere) Schriftgrößen angewiesen. Bestimmte Arten der Umsetzung erlauben es nicht ohne weiteres, dass der Benutzer die Schriftgröße verändern kann, wenn ihm diese zu groß oder zu klein erscheint. Dazu kommt, dass viele Layouts nicht mehr brauchbar sind, wenn der Benutzer eigene Schriftgrößen eingestellt hat, da das Angebot nur mit einer Schriftgröße getestet wurde. So kann es zu Überschneidungen von Inhalt kommen, Texte verschwinden und werden unleserlich.

Der Test hierzu ist wirklich denkbar einfach: laden Sie die Website im Internet Explorer und drücken Sie 2x Strg + und von dort aus 4x auf Strg − oder drehen Sie bei gedrückter Strg-Taste am Mausrädchen. Achten Sie darauf, ob es unerwünschte Überschneidungen gibt oder Content ganz verschwindet. Wenn alles in Ordnung ist, dann können sie zum nächsten Schritt gehen. Ist dies nicht der Fall, dann können Sie den Test an dieser Stelle abbrechen und jemand muss noch mal Hand an das CSS legen.

Keine Layout-Tabellen als Seitengerüst (BIENE-Prüfschritt 14.1)

Prüfen Sie, ob auf den Einsatz von Layout-Tabellen verzichtet wird.

Der Hintergrund für diesen Prüfschritt: Layout-Tabellen sind eine Technik aus den Anfangstagen des Webdesigns, die so falsch ist, dass wir gar nicht wissen wo wir mit der Aufzählung der Nachteile beginnen sollen. Also lassen wir es bei dieser Feststellung: Tabellen sollen ausschließlich zur Darstellung tabellarischer Daten verwendet werden, nicht jedoch zum Aufbau eines Seitengerüsts. Falls Sie Ihre geschäftliche Korrespondenz oder das Layout von Broschüren in Excel erstellen, dann können Sie diesen Prüfschritt überspringen, für alle anderen hier die Testanleitung:

Ziehen Sie das folgende Lesezeichen in die Links-Leiste des Internet Explorers: Tabellen anzeigen. Laden Sie nun Ihre Website. Wenn Sie dann den Link aufrufen werden eventuell vorhandene Tabellen mit einer gestrichelten roten Linie umrandet (wie im folgenden Screenshot zu sehen ist).

Falls Sie bei der inhaltlichen Kontrolle der Tabellen zu dem Schluss kommen, dass es sich nicht um eine Datentabelle (also z.B. Börsenkurse, Wetterdaten etc. handelt), dann hat Ihre Website den Test leider nicht bestanden und die Web-Entwickler müssen noch mal ran.

Verwendung von LABEL bei Kontroll- und Eingabefeldern in Formularen (BIENE-Prüfschritt 15.2)

Prüfen Sie, ob die Zuordnung von Beschriftungen zu den Eingabefeldern und Kontrollelementen mit LABEL umgesetzt ist.

Der Hintergrund für diesen Prüfschritt: Menschen mit motorischer Behinderung benutzen unter Umständen alternative Eingabe- und Zeigegeräte. Sie sind darauf angewiesen, dass interaktive Elemente eine gewisse Größe haben, um zuverlässig bedient werden zu können. Durch die Verwendung von LABEL in HTML wird die interaktive Fläche auf die Größe der Beschriftung ausgedehnt, wie dies auch in anderen Anwendungen generell der Fall ist (vgl. Fitts' Law). Für Nutzer von anderen Hilfsmitteln wie zum Beispiel Screenreadern oder Lupenprogrammen ist die Verknüpfung von Bedienelementen mit ihren Beschriftungen (eng.: Label) eine zwingende Notwendigkeit, um diese korrekt zuordnen zu können.

Auch für diesen Prüfschritt brauchen Sie keine besonderen Hilfsmittel oder andere Programme: testen Sie in Ihren Formularen, ob Sie per Maus Checkboxen oder Radiobuttons auslösen können, indem Sie auf die daneben stehende Beschriftung klicken. Gelingt dies, dann sind Ihre Bedienelemente vorschriftsmäßig verknüpft. Wenn Sie schon dabei sind können Sie hier gleich mittesten, ob sich die gesamte Website bzw. Anwendung ausschließlich per Tastatur (d.h. ohne Maus) bedienen lässt.

Sichtbarkeit des Fokus (BIENE-Prüfschritt 17.3)

Prüfen Sie, ob der Fokus in jeder Position deutlich sichtbar ist. Berücksichtigen Sie bei der Prüfung auch die Formulare.

Der Hintergrund für diesen Prüfschritt liegt auch wieder bei der für die barrierefreie Nutzung wichtigen Tastaturbedienbarkeit. Wenn Sie sich per Tastatur durch die Seiten bewegen: sehen Sie immer, wo ihre aktuelle Position auf der Seite ist? Die Hervorhebung kann zum Beispiel durch eine farbliche Hervorhebung von Links, eine deutliche Umrandung oder ähnliches geschehen. Erscheint die Abfolge der Inhalte auch bei Tastaturbedienung logisch oder springt der Fokus wie wild geworden zwischen verschiedenen Spalten hin und her?

Prüfung der Document-type-declaration (BIENE-Prüfschritt 34.1)

Prüfen Sie, ob eine Document-type-declaration vorhanden ist, sofern sie nach W3C-Empfehlungen benötigt wird. Sie soll sich auf eine veröffentlichte DTD beziehen.

Lassen Sie sich nicht von der Formulierung abschrecken – diese sind primär für die Tester während des Wettbewerbsverfahrens gedacht, und die wissen was es damit auf sich hat. Gemeint ist hier die grundlegende Möglichkeit, ein Dokument durch den Validator zu schicken, damit dieser die Einhaltung der Grammatikregeln von (X)HTML überprüfen kann.

Natürlich kann es im Eifer des Gefechts passieren, dass Entwickler oder Redakteure Inhalte veröffentlichen, die nicht den formalen Kriterien der HTML- und CSS-Empfehlungen entsprechen – dafür gibt es Validatoren, die solche Fehler finden. Allerdings kann man keine generelle Aussage darüber machen, ob eine Seite mit hunderten Validierungsfehlern besser oder schlechter ist als eine mit nur wenigen. Solche langen Fehlerreporte können auch durch Vererbungen von Fehlern entstehen, wenn irgendwelche Tags nicht korrekt geschlossen sind. Die darauf folgenden Fehler verschwinden dann wie von Zauberhand, sobald man den ursprünglichen Fehler behebt.

Allerdings gibt es ein paar »Vorfälle«, die nicht passieren sollten: so finden HTML-Validatoren z.B. fehlende alt-Attribute, mit denen Bilder oder Grafiken auch für Menschen zugänglich gemacht werden müssen, die diese Bilder nicht sehen können. Wenn Sie also bei der Validierung Fehlermeldungen wie:
»Required attribute alt not found«
antreffen, dann haben Sie massiven Nachbesserungsbedarf. Wie hoch dieser im Einzelfall ist lässt sich ohne Kenntnis des dahinterstehenden Systems kaum sagen, aber in der Regel sollte ein hochwertiges Redaktionssystem solche dicken Klopse nicht mehr durchlassen.

So, das war die achtundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Wir hoffen, dass wir Ihnen auch diesmal wieder ein paar wertvolle Tipps mitgeben konnten. Wenn Sie selber Anmerkungen oder Ergänzungen zu unserem heutigen Thema haben dürfen Sie diese gerne in den Kommentaren zur Sendung hinterlassen.

Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BIENE, Barrierefreiheit und Testen. Bis zum nächsten Mal.