Die 14 Gebote

Inhaltsverzeichnis

Schon 1999 hat das World Wide Web Consortium (W3C) Richtlinien herausgegeben, die behinderten Menschen den Zugang zum Web ebnen sollen. Die US-Regierung hat frühzeitig Unterstützung signalisiert. Im letzten Jahr folgte BITV, die diesbezügliche Verordnung für Bundesministerien in Deutschland. Was ist im behindertengerechten Web anders? Und ist es nur für Behinderte?

Im Rahmen der Web Accessibility Initiative, kurz WAI, bietet das W3C eine erstaunliche Fülle von Spezifikationen und Richtlinien. Im Zentrum stehen die „Web Content Accessibility Guidelines“ (WCAG, siehe „Online-Ressourcen“). Die Herausgeber formulieren darin, wie Webseiten aufgebaut sein müssen, damit sie für Behinderte zugänglich sind. In Deutschland ist die Wahrnehmung dieser Richtlinien noch recht gering; ganz zu schweigen von der praktischen Umsetzung. Die Vermutung liegt nahe, dass dies vor allem daran liegt, dass Behinderte eine (wenn überhaupt) kleine Lobby besitzen.

Online-Ressourcen
Web Content Accessibility Guidelines 1.0:	www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
XML Accessibility Guidelines:	www.w3.org/TR/2002/WD-xag-20021003
User Agent Accessibility Guidelines:	www.w3.org/WAI/UA/UAAG10
Authoring Tool Accessibility Guidelines:	www.w3.org/TR/WAI-AUTOOLS/
Techniques for Web Content Accessibility Guidelines 1.0:	www.w3.org/TR/WCAG10-TECHS/
WCAG-Logos:	www.w3.org/WAI/WCAG1-Conformance.html
Validator für (X)HTML-Dokumente:	validator.w3.org/
Elektronische Steuererklärung (Elster):	www.elster.de

Allerdings ist das Verständnis des Begriffs „Behinderung“ oft zu eingeschränkt. Als erstes sind Benutzer zu nennen, die eine körperliche Behinderung aufweisen. Dazu können ein eingeschränktes Sehvermögen oder Blindheit ebenso zählen wie Einschränkungen, die die Benutzung einer Tastatur oder Maus verhindern. Zwar ist das Web ein vorwiegend visuelles Medium, aber Hörgeschädigte und Taube können mit akustischen Inhalten nichts anfangen.

Außerdem können Menschen ohne derartige körperliche Einschränkungen beim Surfen behindert sein. Der Zugriff über ein Telefon gestattet wie bei Blinden nur die Sprache zur Ausgabe und Navigation. Kleine Displays - etwa bei mobilen Geräten - stehen im Widerspruch zu großen Grafiken, vielleicht außerdem zu Farbinformationen. In einer lauten Umgebung, beispielsweise bei Zugriff per Mobilgerät auf einer belebten Straße, sind Audioinformationen nutzlos. Der Fahrer eines Fahrzeugs möchte vielleicht sein Web-gestütztes Navigationssystem bedienen. Das sollte ohne Sichtkontakt funktionieren.

Google, der behinderte Freund

Steve Pemberton, Leiter der HTML-Arbeitsgruppe des W3C, hat bei einem Vortrag zu diesem Thema ein weiteres Beispiel gebracht. Sinngemäß sagte er, dass jeder Webnutzer einen „behinderten“ Freund hat - Google. Die Suchmaschine ist blind und taub, spricht die Sprache nicht (egal welche) und Frames sind ihm ein Graus.

Es gibt daher eine Vielzahl von Gründen, weshalb es Sinn ergibt, Webseiten ohne Barrieren zu schaffen. Dies muss durchaus ein Anliegen des Gesetzgebers und der öffentlichen Verwaltung sein, schließlich gibt es ein Behindertengleichstellungsgesetz. Konsequenterweise hat das Bundesinnenministerium Mitte letzten Jahres eine Verordnung erlassen, die die Barrierefreiheit für Websites der Bundesbehörden bis Ende 2005 vorschreibt (siehe [1] und den iX-Artikel [2]). Die „barrierefreie Informationstechnik-Verordnung“, kurz BITV, basiert auf den WCAG. Das ist einerseits beim Lesen ersichtlich, die Verordnung erwähnt das aber auch explizit. Etwas unpräzise könnte man sagen, dass damit die erste W3C-Recommendation in deutsches Recht umgewandelt wurde - obwohl es „nur“ eine Verordnung, keine Rechtsnorm ist und „nur“ für Bundesbehörden gilt.

Abgesehen von der rechtlichen Grundlage des Gleichstellungsgesetzes bringt die Barrierefreiheit für die öffentliche Verwaltung Vorteile mit sich. Hinter Schlagworten wie E-Government und dem virtuellen Rathaus stehen schon heute praktische Umsetzungen. Immer mehr so genannte Bürgerdienste lassen sich über das Internet abwickeln; man denke nur an Elster, die elektronische Steuererklärung (siehe „Online-Ressourcen“). Zwar handelt es sich um Software, die nicht im Web, sondern lokal läuft, aber man kann sie über das Web herunterladen. Dazu muss der Webzugang barrierefrei sein. Und letztlich darf die Software keine Hürden aufweisen.

Als Geltungsbereich weist die BITV nicht nur Webseiten aus, sondern darüber hinaus „mittels Informationstechnik realisierte grafische Programmoberflächen“, „die öffentlich zugänglich sind“. Der Erfolg von Internet-Bürgerdiensten hängt maßgeblich von der „einfachen“ Nutzbarkeit ab. Gelingt es, die Barrieren zu vermindern, dürften mehr Menschen die Angebote in Anspruch nehmen; in Zukunft per Internet ohne Wartezeit zum Personalausweis und Reisepass - so die Vision.

Doch nicht nur für Behörden sind WAI-Techniken von Interesse. Industrieunternehmen, die eine ähnlich breite Zielgruppe haben wie die öffentliche Verwaltung, können von den Techniken lernen - etwa Banken, Sparkassen und Energieversorger. Online-Banking ist mittlerweile gut eingeführt. Neben der Sicherheit dürfte hier die Zugänglichkeit eine zentrale Rolle spielen. Das Ablesen von Stromzählern muss nicht mehr durch einen Mitarbeiter erfolgen. Die Hamburgischen Electricitäts-Werke beispielsweise lassen die Kunden nicht nur per Postkarte Zählerstände übermitteln, sondern auch online unter www.hew.de. Für alle genannten Organisationen gilt: Leichte Zugänglichkeit, Webangebote ohne Barrieren vergrößern die Zielgruppe und sparen Kosten. Grund genug, sich die Richtlinien genauer anzusehen.

14 W3C-Richtlinien für Websites

In der Version 1 bestehen die Web Content Accessibility Guidelines aus 14 Richtlinien, die jeweils aus mehreren Check-Punkten bestehen. Letztere sind mit den Prioritäten 1 bis 3 versehen. An erste Priorität gesetzte Punkte müssen erfüllt sein, damit es für bestimmte Benutzergruppen nicht unmöglich ist, die Inhalte zu nutzen. Punkte der Priorität 2 sollten erfüllt sein, damit es nicht schwierig ist, die Inhalte zu nutzen. Zusätzlich verbessert die Erfüllung der Punkte der Priorität 3 die Nutzbarkeit der Inhalte. Je nachdem, welche Prioritätsstufen ein Webangebot erfüllt, darf sie WCAG-Konformität der Stufen „A“, „AA“ oder „AAA“ ausweisen (siehe „Online-Ressourcen“). Die folgenden Ausführungen stellen die einzelnen Richtlinien vor, ohne auf jeden einzelnen Check-Punkt einzugehen.

1: Bieten Sie äquivalente Alternativen für akustische und visuelle Inhalte an.

Nicht textuelle Elemente müssen textuelle Alternativen besitzen. Für HTML-Grafiken kann dies das alt-Attribut übernehmen. Redundante textuelle Links müssen serverseitige Imagemaps ergänzen. Nur wenige Filme und Animationen dürften bislang diese Richtlinie erfüllen. Sie müssen nämlich synchronisierte Alternativen, beispielsweise Untertitel oder eine Audiospur besitzen.

2: Verlassen Sie sich nicht auf Farbe allein.

Diese Forderung ist recht intuitiv. Inhalteanbieter müssen darauf achten, dass ihre Inhalte bei monochromer Darstellung verwendbar bleiben.

3: Verwenden Sie Auszeichnungen und Stylesheets - und das auf richtige Weise.

Hierunter sind im Wesentlichen die Forderungen nach Standardkonformität eingeordnet. Des Weiteren sollte der Einsatz von Auszeichnungssprachen den Bildern vorgezogen werden. Beispielsweise sollte Math ML die Darstellung von mathematischen Ausdrücken beschreiben; Grafiken sind zu vermeiden. Was die Browser von diesem Vorschlag halten, hat iX kürzlich diskutiert (siehe [3]).

4: Weisen Sie die verwendete natürliche Sprache aus.

Die natürliche Sprache eines Dokuments sollte ausgewiesen sein, etwa damit Sprachsynthesizer die Aussprache anpassen können. Der Wechsel der Sprache in einem Text muss markiert sein, in HTML durch das lang-Attribut, in XML durch xml:lang.

5: Erstellen Sie Tabellen, die sich elegant umwandeln lassen.

Hier geht es um die sinnvolle Verwendung von Tabellen. Sie sollten nicht dazu dienen, Layout zu steuern, es sei denn, sie lassen sich sinnvoll linearisieren (zum Beispiel vorlesen). Des Weiteren müssen Zellen, die Zeilen- oder Spaltenüberschriften darstellen, als solche gekennzeichnet sein. In HTML etwa durch das th-Element.

6: Stellen Sie sicher, dass sich Seiten, die neue Techniken enthalten, elegant umwandeln lassen.

Webseiten müssen ohne Stylesheets, Scripts, Applets und ähnliche Objekte lesbar sein. Im Falle von dynamischen Objekten muss sich bei Veränderungen der äquivalente Inhalt ändern. Sämtliche Programmsteuerungen sollten unabhängig von dem Eingabegerät sein.

7: Stellen Sie sicher, dass der Benutzer zeitliche Änderungen des Inhalts steuern kann.

Mit höchster Priorität ist hier gemeint, dass ein Flackern der Seite oder von Teilen der Seite zu vermeiden ist. Explizit nennt die Spezifikation hier ein Flackern im Bereich von 4 Hz bis 59 Hz, was für Menschen mit Epilepsie gefährlich sein kann. Alle Check-Punkte dieser Richtlinie sind mit der Einschränkung versehen, dass die Maßnahmen so lange erforderlich sind, „bis Benutzerprogramme die Steuerung erlauben“. Da es prinzipiell niemals möglich sein dürfte, eine Aussage über alle potenziellen Benutzerprogramme zu treffen, kann man die Einschränkung getrost überlesen. Am Rande bemerkt die Richtlinie übrigens, dass die Elemente blink und marquee niemals in einer HTML-Fassung des W3C enthalten waren.

8: Stellen Sie die direkte Zugänglichkeit eingebetteter Benutzerschnittstellen sicher.

Falls in Webseiten eingebettete Objekte wie Applets eine eigene Oberfläche besitzen, muss sie geräteunabhängig zu bedienen sein.

9: geräteunabhängiger Entwurf

Webseiten sollten mit beliebigen Eingabegeräten zu nutzen sein. HTML bietet etwa für die zur Maussteuerung alternative Tastaturbedienung die Attribute tabindex oder accesskey an. Mit höchster Priorität verlangt das W3C die Verwendung von clientseitigen Imagemaps anstelle der serverseitigen, sofern das irgend möglich ist.

10: Benutzen Sie Übergangslösungen.

Hier sind Punkte aufgeführt, die sich mit Dingen befassen, die im Grunde Benutzerprogramme regeln sollten. Beispielsweise sollte man auf das Öffnen von neuen Fenstern verzichten, bis die Browser dem Benutzer erlauben, das Öffnen zu verhindern. Einige Browser bieten diese Option schon, aber wer kann eine Aussage für alle Benutzerprogramme machen ...

11: Setzen Sie W3C-Techniken und -Richtlinien ein.

Es wundert nicht, dass das W3C diese Forderung stellt. Sie ist aber keineswegs so dogmatisch, wie es auf den ersten Blick scheint. So heißt es wörtlich: „Bieten Sie in Fällen, in denen es nicht möglich ist, eine W3C-Technik einzusetzen oder die Folge Daten wären, die sich nicht elegant umwandeln lassen, eine alternative Version des Inhalts an, die zugänglich ist.“ Der Hinweis, dass das bloße Formatumwandeln, etwa von PDF oder RTF, in ein W3C-Format wie HTML nicht automatisch barrierefreie Dokumente erzeugt, fehlt keineswegs.

12: Stellen Sie Informationen über den Kontext und zur Orientierung zur Verfügung.

Mit Priorität 1 verlangt die Recommendation hier die Benennung von Frames mittels des title-Attributs. Dies soll eine Navigation ohne Frame-Darstellung erlauben.

Die beiden letzten Richtlinien sind offensichtlich und selbsterklärend:

13: Stellen Sie klare Navigationsmittel zur Verfügung.

14: Stellen Sie sicher, dass Dokumente klar und einfach sind.

Soweit zu den Richtlinien. Fragt sich, was der überforderte Webdesigner praktisch damit anfängt.

Umsetzung der Richtlinien

Neben den WCAG bietet das W3C zu diesem Thema eine große Auswahl an hilfreichen Dokumenten an. Dazu zählen „Techniques for WCAG 1.0“, „CSS Techniques for WCAG 1.0“ (siehe das CSS-Tutorial, in iX 3 bis 5 2003) oder „Checklist of Checkpoints for WCAG 1.0“. Damit lassen sich prinzipiell Webangebote auf Konformität zu den Richtlinien überprüfen, und für etwaige Verstöße bekommt der Leser Vorschläge zur Behebung des Mangels. Allerdings ist die Prüfung keine leichte Aufgabe, und je nach Technik eines Website ist Konformität noch schwieriger zu erreichen.

Mit dem Feststellen eines Mangels ist es ja nicht getan. Er muss behoben werden. Bei HTML-Dateien ist das recht einfach, eventuell aber mit viel Handarbeit verbunden. Im Falle großer Sites, deren Inhalte sich aus mehreren Quellen speisen, stellen sich viele Fragen: Wie müssen Systeme beschaffen sein, damit die Ausgabe, die sie produzieren, die Richtlinien erfüllt? Wie müssen Inhalte erfasst werden, damit die aus ihnen generierten Seiten zugänglich sind? Eine Umstellung auf WCAG ist sicher kein Job, den man übers Wochenende erledigt.

Webdokumente überprüfen

Ein erster Ansatz zur Prüfung besteht in Umsetzung von Richtlinie 11, dem Einsatz von W3C-Empfehlungen. Die formale Korrektheit von HTML, XHTML oder anderen XML-Sprachen lässt sich maschinell prüfen. Auch für CSS bietet das W3C seinen „Validator“ an (siehe „Online-Ressourcen“). Keinesfalls darf man sich damit aber in Sicherheit wiegen. Die Prüfung des Validator kann nur der erste Schritt auf dem Weg sein, nicht das Ziel.

Durchschlagender dürfte der Ansatz sein, die zugrunde liegenden Systeme und Daten/Dokumentformate „vernünftig“ zu entwerfen. Für XML-basierte Dokumente erarbeitet das W3C zurzeit diesbezügliche Richtlinien, die „XML Accessibility Guidelines“ (XAG). Wunder sind hier nicht zu erwarten. Wer Erfahrung in der Spezifikation von SGML/XML-Sprachen für medienneutrale Publikation besitzt, wird die XAG eher als gesunden Menschenverstand einordnen. Überhaupt sind die Web Content Accessibility Guidelines von dem Geist geprägt, der das Cross Media Publishing schon seit Jahren beseelt. Das Nutzen von Erfahrungen aus diesem Bereich dürfte mehr als „die halbe Miete“ auf dem Weg zum barrierefreien Web sein.

Stefan Mintert
ist freier Berater und Herausgeber des Buches „XHTML, CSS & Co“ (Addison-Wesley).

Literatur

[1] Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik-Verordnung - BITV), 17. Juli 2002, Bundesgesetzblatt Jg. 2002, Teil I, Nr. 49

[2] Peter Klein; Web für alle; Blick aufs Meer; Rechtsverordnung für barrierefreie Informationstechnik; iX 10/2002, S. 72

[3] Stefan Mintert; Auszeichnungssprachen; Kleines 1 x 1; Formeln im Web: Was mit MathML geht; iX 11/2002, S. 125

Mehr Infos

iX-TRACT

• Nach der barrierefreien Informationstechnik-Verordnung (BITV), die Behörden verpflichtet, ihre Webseiten für Behinderte zugänglich zu gestalten, bekommen Designer von Websites neue Aufgaben.
• Die Web Content Accessibility Guidelines des World Wide Web Consortium können helfen, den eigenen Site zugänglich und lesbar für alle Menschen zu gestalten.
• Vierzehn Regeln beschreiben, worauf Webautoren achten sollten: von Selbstverständlichkeiten (klare/einfache Dokumente und Navigation) bis zur Lesbarkeit von Tabellen, Frames und anderer Techniken (Java et al.) reicht die Palette.

(hb)