Letzte Runde für WCAG 2

In dieser zweiten Stufe des bis zur fertigen Empfehlung fünfstufigen Verfahrens geht es darum, dass andere W3C-Arbeitsgruppen und die interessierte Fachöffentlichkeit Kommentare und Verbesserungsvorschläge abgeben. Um das Verständnis des Entwurfs zu vereinfachen geben wir Ihnen im Folgenden einen Überblick über Struktur und Inhalte der WCAG 2.

Die wesentlichen Unterschiede

Im Gegensatz zu den nach wie vor gültigen WCAG 1 sollen die WCAG 2 unabhängig von bestimmten Techniken sein und dabei helfen, mehr als nur einzelne W3C-Empfehlungen barrierefrei umzusetzen. Dazu wurden die bisherigen 14 Vorgaben noch stärker zusammengefasst und sind nun unter den folgenden vier Prinzipien vereint:

1. Inhalt muss wahrnehmbar sein (»Content must be perceivable«)
2. Elemente der Benutzerschnittstellen im Inhalt müssen bedienbar sein (»Interface components in the content must be operable«)
3. Inhalte und Bedienelemente müssen verständlich sein (»Content and controls must be understandable«)
4. Inhalte sollten robust genug sein, um mit aktuellen und zukünftigen Benutzeragenten zu funktionieren (inklusive assistiver Werkzeuge) (»Content should be robust enough to work with current and future user agents [including assistive technologies]«)

Diese vier Prinzipien beinhalten die eigentlichen Richtlinien (Guidelines), die es zu erfüllen gilt, um den jeweiligen Prinzipien gerecht zu werden. Diese Richtlinien wiederum enthalten Erfolgskriterien (Success Criteria) in verschiedenen Abstufungen. Hierbei handelt es sich um testbare Aussagen, in denen definiert wird was ein Anbieter machen muss, um die Richtlinie zu erfüllen. Anhang B der WCAG 2 enthält dazu eine Checkliste von Erfolgskriterien, die auch einen guten Überblick über die gesamte Struktur der Richtlinien gibt.

Abstufungen der Barrierefreiheit:
WCAG 1-Prioritäten und Checkpunkte

Die WCAG 1 (deutsche Übersetzung) sortierten ihre Checkpunkte nach drei Prioritäten, jenachdem wie stark die Auswirkungen einer Barriere auf Menschen mit Behinderung ist.

• Priorität 1 (WCAG A) muss erfüllt sein, ansonsten ist es für eine oder mehrere Gruppen von Menschen mit Behinderung unmöglich, das Angebot zu nutzen.
• Priorität 2 (WCAG AA) sollte erfüllt sein, ansonsten ist es für eine oder mehrere Gruppen schwierig, das Angebot zu nutzen.
• Priorität 3 (WCAG AAA) kann erfüllt werden, um die letzten verbliebenen Hürden bei der Nutzung eines Angebots zu beseitigen.

Abstufungen der Barrierefreiheit:
BITV-Prioritäten und Anforderungen

Die von den WCAG 1 abgeleitete bundesdeutsche BITV besteht dagegen nur aus zwei Prioritäten, die für unterschiedliche Webressourcen abgestuft anzuwenden sind:

Dabei sind die Standards mit der Priorität 1 zwingend einzuhalten, die der Priorität 2 zusätzlich bei zentralen Navigations- und Einstiegsangeboten.

Angebote, die die in der Anlage 1 dieser Verordnung unter Priorität I genannten Anforderungen und Bedingungen erfüllen, würden bei den Web Content Accessibility Guidelines1.0 des W3C die Konformität AA erreichen. Angebote, die die Prioritäten I und II erfüllen, würden nach den Web Content Accessibility Guidelines 1.0 die Konformität AAA erreichen.

Weitere Informationen finden Sie in der Begründung zur BITV.

Abstufungen der Barrierefreiheit:
WCAG 2 Erfolgskriterien

An die Stelle der Checkpunkte tritt in den WCAG 2 nun das Konzept der Erfolgskriterien, die ebenfalls in 3 Stufen unterteilt sind:

• Erfolgskriterien der Ebene 1:
  1. erreichen die Mindestanforderungen an die Barrierefreiheit durch Auszeichnungen, Skripte oder andere Technologien, die mit Benutzeragenten interagieren oder den Zugang durch diese herstellen, inklusive assistiver Technologien.
  2. können sinnvoll auf alle Webinhalte angewendet werden.
• Erfolgskriterien der Ebene 2
  1. erreichen eine verbesserte Ebene der Barrierefreiheit durch ein oder mehrere der folgenden:
     1. Auszeichnungen, Skripte oder andere Technologien, die mit Benutzeragenten interagieren oder den Zugang durch diese herstellen, inklusive assistiver Technologien.
     2. die Gestaltung der Inhalte und deren Präsentation
  2. können sinnvoll auf alle Webinhalte angewendet werden.
• Erfolgskriterien der Ebene 3
  1. erreichen zusätzliche Barrierefreiheit für Menschen mit Behinderungen.
  2. sind nicht auf alle Webinhalte anwendbar

Hinweis: Einige Richtlinien enthalten keine Erfolgskriterien der Ebene 1, andere enthalten keine Erfolgskriterien der Ebene 2.

Diese Methode der Gruppierung von Erfolgskriterien unterscheidet sich in mehreren wichtigen Punkten von dem den WCAG 1.0 zu Grunde liegenden Ansatz. In den WCAG 1 wird jedem Checkpunkt eine Priorität zugewiesen, der je nach Auswirkung auf die Barrierefreiheit für Nutzer abgestuft ist. Somit erscheinen Checkpunkte der Priorität 3 (WCAG AAA bzw. BITV Prio. 2) weniger wichtig zu sein als Checkpunkte der Priorität 1. Die WCAG-Arbeitsgruppe geht nun davon aus, dass sämtliche Kriterien von WCAG 2 in der einen oder anderen Form für manche Menschen mit Behinderung wichtig sind. Daher wurde das System der Checkpunkte und Prioritäten aus den WCAG 1 durch Erfolgskriterien der Ebenen 1, 2 und 3 in der oben beschriebenen Art ersetzt.

Soweit die Argumentation der WAI für den geänderten Ansatz. Allerdings können wir hier kaum Besserung für einen der gravierendsten Mängel der WCAG 1 erkennen: die Übergewichtung der rein technischen Aspekte der Zugänglichkeit von Webinhalten. Letztendlich läuft auch das neue System darauf hinaus, dass die Mindestanforderungen für alle Webinhalte (Ebene 1) höher gewichtet werden als die zusätzlichen Kriterien für spezielle Webinhalte (Ebene 3) - womit wir dann doch wieder beim dreistufigen Modell der WCAG 1 wären, nur etwas anders formuliert.

Testbarkeit der Erfolgskriterien

Ein Mangel der bisherigen Richtlinien war und ist deren Testbarkeit. Wie oft müssen Webdesigner mit Auftraggebern diskutieren, weil ein automatisiertes Prüfwerkzeug einen Fehler ausgibt wo keiner ist; wie viele Diskussionen wurden und werden in Mailinglisten und Foren geführt, wie ein bestimmter Checkpunkt zu bewerten ist; wie oft kommen 3 Tester zu 4 unterschiedlichen Ergebnissen?

Um damit aufzuräumen war eine der Grundvoraussetzungen für die Überarbeitung der WCAG die bessere Testbarkeit der Richtlinien. Auch hier ist damit nicht die vollständig maschinelle Testbarkeit gemeint, denn nach wie vor geht es bei der Barrierefreiheit um Menschen, nicht um Maschinen. Gemeint ist vielmehr, dass die Richtlinien so eindeutig formuliert sein sollen, dass mehrere menschliche Prüfer bei der Evaluation eines Angebotes auf Basis der Richtlinien zu den gleichen Ergebnissen kommen müssen.

Benutzbarkeit der Erfolgskriterien für Webdesigner

Dies wiederum führt dazu, dass sich die Richtlinien selbst kaum als Arbeitsunterlage für Webdesigner eignen, sondern eher eine Anleitung zur Ausarbeitung von Prüfverfahren sind. Was kein Mangel per se ist – wer sich als Einsteiger oder Profi in HTML & CSS einarbeiten will tut gut daran, nicht als erstes die Spezifikationen des W3C zu lesen, diese sind eher für Browserhersteller gedacht.Wer den praktischen Einsatz lernen will, kann dies wesentlich besser bei SELFHTML oder den Tutorials von Michael Jendryschik machen.

So wird diese Aufgabe noch vielmehr als bisher von Dritten geleistet werden müssen, auch wenn die WAI eine ganze Reihe begleitender Dokumente in Form von Techniken zur Umsetzung der Richtlinien in Arbeit hat. Für viele mögliche Inhalte wird das W3C auch gar keine weitergehenden Erläuterungen anbieten können, da die WCAG 2 nun unabhängig von den verwendeten Techniken und somit auch auf Formate Dritter anwendbar sind. Der Kern der WCAG selbst – die Prinzipien – bleiben bestehen, auch wenn sich die Techniken zu ihrer Umsetzung ändern.

Grundlegende Annahmen (Baseline Assumptions)

Die WCAG 1 wurden zu einer Zeit geschrieben, als das Web in weiten Teilen nur aus einfachem HTML bestand. Nun hat sich das Web aber seit 1999 in einer Weise verändert, die damals noch nicht absehbar war. Viele neue Techniken sind hinzugekommen, einige Techniken spielen keine Rolle mehr, und für bestehende Techniken wurden Unmengen neuer Anwendungszwecke gefunden. In letzter Zeit wird vermehrt an neuen Wegen gearbeitet, wie wir Informationen erhalten und verbreiten – Chancen, die auch gerade für Menschen mit Behinderung interessant im Sinne der digitalen Integration und Partizipation sind.

Um alle diese Möglichkeiten noch durch umsetzbare Richtlinien einigermaßen beeinflussen zu können mussten diese auf eine radikal veränderte Basis gestellt werden. Dazu gehört das neu eingeführte Konzept einer sog. Baseline Assumption. Hiermit sind grundlegende Annahmen über technische Minimalanforderungen an den oder die Benutzeragenten gemeint, die erfüllt sein müssen, um eine Webressource sinnvoll nutzen zu können.

Die Erklärung der grundlegenden Annahmen ist auch Bestandteil einer möglichen Selbsteinschätzung zur Barrierefreiheit (Accessibility Statement) und legt fest, unter welchen Voraussetzungen das Erreichen einer bestimmten Ebene der Barrierefreiheit (z. B. Level 2 bzw. WCAG AA) zustande kommt.

Mögliche Baselines sind zum Beispiel:

HTML 4.01 transitional, GIF und JPEG

Eine sehr grundlegende Annahme zur korrekten Verarbeitung von Techniken, die bei einer sehr großen Menge von potentiellen Nutzern vorausgesetzt werden können. Einerseits schränkt man hiermit die Möglichkeiten des Angebots stark ein, andererseits wird dadurch das mögliche Zielpublikum maximiert. Anwendbar für sehr einfache Angebote, die im wesentlichen aus strukturierten Texten bestehen.

XHTML 1.0 strict, CSS Level 2, JavaScript 1.2, DOM Level 2, MPEG 4, SMIL

Eine Annahme, in der über Basistechniken hinaus auch multimediale und interaktive Elemente enthalten sind. Definitiv schwieriger zu erreichen als die zuvor genannte Baseline, aber wenn hier beispielsweise sämtliche Interaktionen durch den Benutzer kontrollierbar sind und für multimediale Elemente äquivalente Alternativen angeboten werden, so kann auch ein solches Angebot den höchsten Grad der Barrierefreiheit nach WCAG 2 erreichen.

Wichtig dabei: eine Aussage wie »diese Seite funktioniert am besten in Internet Explorer 6« ist keine Baseline Assumption im Sinne der WCAG 2. Ebenfalls nicht gemeint sind weitergehende Dinge wie Bildschirmauflösung, Computererfahrung des Nutzers etc., die nicht Gegenstand der Richtlinien sind. Ebenso darf über die Baseline nichts ausgeschlossen werden, was in den Richtlinien an anderer Stelle gefordert wird (Negativbeispiele: »Nur nutzbar für Menschen ohne Farbfehlsichtigkeit« oder »Sie benötigen eine Maus, um diese Website zu bedienen«).

Der Weg von 1 nach 2

Was ist mit Angeboten, die bisher schon die WCAG 1 zumindest teilweise erfüllten? Wird es eine eingebaute Upgrade-Möglichkeit auf die WCAG 2 geben? Die einfachste Antwort auf diese Frage ist die Stichtagsregelung: mit dieser kann man ältere Bereiche als WCAG 1-konform und neu erstellte oder wesentlich geänderte Bereiche ab dem Datum der Veröffentlichung als WCAG 2-konform deklarieren, immer verbunden mit der Angabe des erreichten Grades.

In Anhang D des Entwurfs zu den WCAG 2 findet sich das Dokument »Comparison of WCAG 1.0 Checkpoints to WCAG 2.0«, in dem die Checkpunkte der beiden Versionen miteinander abgeglichen werden.

Kommentare abgeben

Soweit unsere Einführung in die WCAG2. Wenn Sie Kommentare und Verbesserungsvorschläge haben, dann sollten diese bis zum 31. Mai 2006 bei der WAI eingegangen sein; entweder per E-Mail an public-comments-wcag20@w3.org, oder über die in verschiedenen Dateiformaten bereitgestellten Formulare.

Bitte beachten Sie, dass lediglich das zentrale WCAG 2-Dokument zurzeit den Status des Last Call hat; die weiteren Dokumente, die teils lediglich informativen Charakter haben, befinden sich noch in früheren Phasen der Entwicklung. Hintergründe zur formalen Vorgehensweise und den möglichen nächsten Schritten hat das W3C an anderer Stelle veröffentlicht.

Wir würden gerne Ihre Meinung wissen: Teilen Sie uns Ihre Erfahrungen mit und diskutieren Sie diesen Artikel mit anderen Experten.