21.05.2008
Neue Richtlinien für Barrierefreiheit - warum eigentlich? Wie verlief der Entwicklungsprozess der WAG 2.0? Wie sind die WCAG 2.0 aufgebaut? Dieser Artikel bietet einen schnellen Einstieg in das Thema WCAG 2.0.
Auf dieser Seite:
Seit der Verabschiedung der WCAG 1.0 im Mai 1999 hat sich viel getan im Web: Webtechnologien wurden weiterentwickelt, Browser und Hilfsmittel sind besser geworden. Viele Anforderungen der WCAG 1.0 und damit auch der aktuellen BITV sind inzwischen überflüssig. Zudem sind die Anforderungen eng auf HTML und CSS zugeschnitten und lassen sich oft nicht ohne weiteres auf andere inzwischen weit verbreitete Techniken wie Flash oder PDF anwenden.
Die WCAG 2.0 sollen daher:
Die WCAG 2.0 haben derzeit den Status einer "Candidate Recommendation", das ist die dritte Stufe des für W3C-Empfehlungen festgelegten fünfstufigen Prozesses:
Dieser "Candidate Recommendation" ist ein sehr langer und mühsamer Entwicklungsprozess vorausgegangen. Schon 2001 wurde die Arbeit an den WCAG 2.0 aufgenommen, die Arbeitsgruppe hat sich jedoch vor allem wegen interner Querelen und dem hohen Anspruch, die neuen Richtlinien möglichst allgemein und technikunabhängig zu formulieren immer wieder verzettelt und war häufig harscher Kritik aus Fachkreisen ausgesetzt.
Insbesondere der (selbst durchaus nicht unumstrittene) kanadische Accessibility-Experte und ehemaliges Mitglied der WCAG-Arbeitsgruppe Joe Clark attackierte die WCAG 2.0 mehrfach mit polemischen Brandartikeln. Mitte 2006 schlug sein Text "To Hell with WCAG 2" international hohe Wellen in den Accessibility-Blogs. Darin erklärte er den damals aktuellen "Last Call Working Draft" der WCAG 2.0 für gescheitert und kündigte an, mit einer neu gegründeten Expertengruppe namens "WCAG Samurai" einfach die WCAG 1.0 zu überarbeiten, anstatt das Rad komplett neu zu erfinden. Dafür brauchten die WCAG Samurai immerhin fast zwei Jahre im Februar 2008 wurden ihre "WCAG Samurai Errata" veröffentlicht. Diese entsprechen mit ihren Änderungen und Streichungen im Wesentlichen der aktuellen Interpretation der WCAG 1.0 in anderen Checklisten und Testverfahren (wie der BITV-Test oder die BIENE-Kriterien). Sie bieten aber in Bezug auf künftige Technologien keine Lösungsansätze, der Bedarf nach neuen Richtlinien bleibt bestehen.
In der Zwischenzeit wurde die Arbeit an den WCAG 2.0 allen Unkenrufen zum Trotz vorangetrieben. Nach der katastrophalen Aufnahme des "Last Call Working Drafts" von 2006 wurde der nächste, im Mai 2007 veröffentlichte Entwurf auf den Status eines einfachen "Working Drafts" zurückgestuft. Die Fachwelt reagierte mit zahlreichen jetzt konstruktiveren Kommentaren und Änderungsvorschlägen, die bis Ende 2007 von der WCAG-Arbeitsgruppe in den Entwurf eingearbeitet wurden. Das Ergebnis war ein neuer "Last Call Working Draft", der im Dezember 2007 endlich veröffentlicht werden konnte.
Natürlich wurde auch der neue "Last Call"-Entwurf wieder zur Diskussion gestellt. Nach der Veröffentlichung konnten bis Anfang Februar 2008 Kommentare eingereicht werden, auch BIK hat sich mit einigen Änderungsvorschlägen beteiligt. Doch die deutlich geringere Anzahl, die Themen und der sachliche Stil der eingegangenen Kommentare zeigen ebenso wie die insgesamt positiven Einschätzungen in den Blogs: inzwischen ist mit den WCAG 2.0 offenbar doch noch ein guter Konsens erreicht worden. Bei den meisten Kommentaren geht es nicht mehr um grundsätzliche Zweifel an Aufbau und Stoßrichtung der WCAG 2.0, sondern um Details. Die Fachwelt scheint sich im Großen und Ganzen einig zu sein: hundertprozentig perfekt sind die WCAG 2.0 nicht, aber sie sind viel besser als die veralteten WCAG 1.0 und bieten eine gute Grundlage für die Weiterentwicklung barrierefreier Webtechniken in den nächsten Jahren.
Angesichts der langen und schwierigen Entwicklungsgeschichte der WCAG 2.0 sind Prognosen heikel, aber derzeit deutet alles darauf hin, dass es in diesem Jahr endlich einigermaßen zügig weiter geht.
Die Arbeitsgruppe hat die eingegangen Kommentare zum "Last Call"-Entwurf schnell bearbeitet, seit dem 30. April 2008 haben die WCAG 2.0 den Status einer "Candidate Recommendation" erreicht. In dieser dritten Stufe des vorgeschriebenen Entwicklungsprozesses soll sichergestellt werden, dass die Richtlinien praxistauglich sind. In dieser Zeit sollen sie von Webentwicklern in realen Projekten angewendet werden. Sobald es Implementierungen aller Richtlinien gibt, kann der finale Entwurf, die "Proposed Recommendation" veröffentlicht werden das plant die Arbeitsgruppe derzeit für das 3. Quartal 2008.
Die "Proposed Recommendation" muss dann schließlich von den W3C-Mitgliedern abgesegnet werden, bevor sie endgültig als offizielle W3C-Empfehlung verabschiedet werden kann.
Die fällige Überarbeitung der BITV wird sich aller Voraussicht nach an den neuen WCAG 2.0 orientieren, derzeit beschäftigt sich eine Projektgruppe unter Federführung des Bundesministeriums für Arbeit und Soziales mit dem aktuellen Entwurf.
Ein Ziel des BITV-Tests ist es, aus den Vorgaben der BITV sinnvolle, prüfbare Anforderungen zu entwickeln. In vielen Punkten stimmt er schon recht gut mit den WCAG 2.0 überein, es gibt aber auch Anpassungsbedarf. Mit welchen Änderungen dadurch zu rechnen ist, ist Thema des nächsten Teils dieses Artikels.
Die oberste Gliederungsebene der WCAG 2.0 bilden die folgenden vier Prinzipien:
Jedem dieser Prinzipien sind Richtlinien (Guidelines) zugeordnet, insgesamt gibt es zwölf solcher Richtlinien. Zu jeder Richtlinie gibt es Erfolgskriterien (Success Criteria). Bei den Erfolgkriterien wird es für Webdesigner konkret: hier wird beschrieben, wie Webseiten beschaffen sein müssen, um den Richtlinien zu entsprechen. Dabei sind die Erfolgkriterien so formuliert, dass objektiv überprüfbar ist, ob sie erfüllt sind oder nicht. Ein Beispiel: Kontrastanforderungen sind anders als in den WCAG 1.0 klar definiert.
Die Prinzipien, Richtlinien und Erfolgskriterien bilden zusammen den offiziellen, normativen Teil der WCAG 2.0. Dieser wird durch weitere, nicht-normative Dokumente ergänzt, die dem besseren Verständnis der WCAG 2.0 dienen dazu gehören unter anderem "Understanding WCAG 2.0" sowie die "Techniques for WCAG 2.0".
Für Webdesigner sind insbesondere die Techniques sehr hilfreich. Hier stehen ganz konkrete Anleitungen und Tipps zur Umsetzung und Prüfung der in den Erfolgskriterien genannten Anforderungen. Ebenfalls beschrieben werden typische Fehler, die dazu führen können, dass Erfolgskriterien nicht erfüllt werden.
Neben allgemeinen, technikunabhängigen Techniques gibt es derzeit spezifische Techniques für HTML, CSS, ECMAscript, SMIL, ARIA und Web-Server. Da die Techniques nicht normativ sind, können sie laufend aktualisiert und ergänzt werden und so leichter auf dem aktuellen Stand der Technik gehalten werden. Das W3C selbst entwickelt nur Techniques für nicht-proprietäre Technologien, hofft aber, dass Hersteller anderer Technologien wie zum Beispiel Flash analog dazu ähnliche Techniques bereitstellen.
Während sich die WCAG 1.0 meist ausdrücklich auf bestimmte Technologien vornehmlich HTML und CSS beziehen, ist der normative Teil der WCAG 2.0 (also die Prinzipien, Richtlinien und Erfolgskriterien) so weit wie möglich technikunabhängig formuliert. Sie lassen sich also grundsätzlich auch auf andere Formate anwenden, beispielsweise auf Flash oder PDF.
Voraussetzung für die WCAG 2.0-Konformität ist aber, dass die eingesetzte Technologie "accessibility supported" ist.
Wann eine Technologie als "accessibility supported" gelten kann, ist nicht genau festgelegt. Wichtig ist die Unterstützung durch Browser und Hilfsmittel. Die Unterstützung muss dokumentiert sein, ihr Umfang ist aber nicht genauer festgelegt. Ein einziges unterstützendes Hilfsmittel reicht normalerweise nicht aus, die Verbreitung und Verfügbarkeit des Hilfsmittels soll berücksichtigt werden, und es kommt auch darauf an, in welcher Umgebung die Technologie eingesetzt werden soll ob sie also allgemein über das Internet verbreitet wird oder zum Beispiel nur in einem Firmennetzwerk eingesetzt wird. Die "Community" soll letztlich entscheiden, welche Unterstützung wo als ausreichend anzusehen ist.
Wie schon in den WCAG 1.0 gibt es weiterhin drei Konformitätsstufen: A, AA und AAA.
Jedes Erfolgkriterium ist einer Konformitätsstufe zugeordnet. Dabei spielt eine Rolle,
Die erste Konformitätsstufe A ist verhältnismäßig leicht zu erreichen, beispielsweise werden in dieser Stufe keinerlei Anforderungen an das Layout gestellt. Die Anforderungen der Stufe AA entsprechen in etwa dem aktuellen BITV-Test, das wird auch in Zukunft so bleiben.
Level AAA ist für die meisten großen Webangebote insbesondere solche mit vielen multimedialen Inhalten sicherlich nicht ohne weiteres erreichbar. Die WAI-Gruppe empfiehlt, die Konformitätsstufe AAA nicht generell für komplette Websites einzufordern, da es für bestimmte Inhalte nicht möglich sei, alle AAA-Erfolgkriterien zu erfüllen.
Nicht alle Zugänglichkeitsprobleme im Internet können durch Webdesigner gelöst werden. In der Einleitung zu den WCAG 2.0 wird ausdrücklich auf Folgendes hingewiesen:
In den WCAG 2.0 geht es nur um die Zugänglichkeit von Webinhalten, wie schon aus dem Namen "Web Content Accessibility Guidelines" hervorgeht.
Genau so wichtig sind die "User Agent Accessibility Guidelines (UAAG)", in denen die Zugänglichkeit von Browsern geht, und die "Authoring Tool Accessibility Guidelines (ATAG)", in denen es um Zugänglichkeitsfeatures von Autorensystemen und Entwicklungssoftware (zum Beispiel Content-Management-Systeme oder HTML-Editoren) geht.
Auch wenn ein Webangebot alle Anforderungen der WCAG 2.0 erfüllt, wird es für manche Benutzer mit bestimmten Behinderungsarten, -graden und -kombinationen eventuell trotzdem nicht nutzbar sein.
