Teil 3: WCAG 2.0 - Neue Standards für Barrierefreiheit

Praktische Umsetzung

Das Standarddokument und das Erläuterungsdokument bieten nur Anhaltspunkte für die Umsetzung. Erst die Quick Reference verbindet Erfolgskriterien mit der Frage, wie man sie erfüllt. In aller Ausführlichkeit werden die Umsetzungsfragen dann im Tech-Dokument geklärt ().

Das Dokument ist nach Technologiebereichen gegliedert. Jeder Technologiebereich hat ein Kürzel: G steht beispielsweise für generelle Hinweise, H für HTML-Hinweise, C für CSS-Hinweise, SCR für client-seitige Skripte, SRV für serverseitige Skripte und F für häufige Fehler. Diese Vier sind es, die Webentwickler vor allem interessieren. Andere Bereiche sind für weniger häufig gebrauchte Technologien, beispielsweise für den Animationsstandard des W3C, SMIL, vorgesehen.

Über ARIA, den Standardisierungsansatz für Javascript und Ajax erfahren Sie im nächsten Artikel. Eine Übersicht über einige für Webdesigner wichtige Regeln vornehmlich aus dem HTML- und Fehler-Bereich finden Sie in den folgenden Abschnitten.

Layouts und Struktur

Grundsätzlich mag es ein wenig überraschen, dass Tabellen zu Layoutzwecken in den WCAG-Dokumenten nicht verboten sind. Die Bedingung ist nur, dass die Daten in strukturierter Form vorhanden sind, das heißt, dass ein Screenreader die Daten linear vorlesen kann, ohne den Nutzer durch wilde Sprünge und verschachtelte Tabellen in die Irre zu führen. Dennoch ist in der Praxis ein CSS-Layout die Basis einer barrierefreien Website.

Dies sieht auch die WAI so und empfiehlt ebenfalls CSS-Layouts. Für zwei oder drei Spalten im Inhaltsbereich wäre eine Tabelle aber denkbar. Eine Bedingung haben die WCAG allerdings für Layouttabellen: Die Möglichkeiten, eine Datentabelle mit Bedeutung wie Kopf-Tags <th> und einer Zusammenfassung (summary-Attribut) zu füllen, sollen für Layouttabellen nicht verwendet werden (Technische Empfehlung F46).

Für Tabellen zur Datendarstellung gibt es dagegen einige Regeln. Sie zielen vor allem auf das Erfolgskriterium 1.3.1 ab, Informationen und Relationen zwischen Informationen korrekt darzustellen. Eine Tabelle ist hier - vor allem für Screenreader - eine schwierige Aufgabe. So wird beispielsweise in H73 das summary-Attribut empfohlen, H39 empfiehlt den Einsatz eines <caption>-Tags - allerdings ist die optische Wirkung nicht immer gewünscht.

In diesem Fall wäre das Ausblenden per CSS aber noch eine Möglichkeit. H63 empfiehlt dazu den Einsatz von scope, um anzugeben, in welcher Richtung eine Überschrift mit <th> gilt. <th> selbst ist für strukturierte Daten natürlich auch Pflicht (H51). Hier ein Beispiel mit einigen der Funktionen:

In H43 ist zusätzlich noch geregelt, dass man mit id-Attribut und headers-Attribut eine Beziehung zwischen Kopfzelle und Inhaltszelle herstellen kann. Das heißt, Sie können mit relativ einfachen Mitteln eine komplett barrierefreie Tabelle erzeugen.

Bilder

Für Bilder ist sicherlich die wichtigste Regel, dass die Informationen noch als textliche Alternative zur Verfügung stehen müssen. Das alt-Attribut soll dabei eine alternative textliche Information liefern (H37). Das ist kein Titel, sondern eine Beschreibung von Text, der beispielsweise auf dem Bild selbst steht: