WCAG 2 - was ändert sich?

Die vom W3C im Mai 1999 verabschiedeten Web Content Accessibility Guidelines 1.0 sind inzwischen nicht nur in Gesetze und Verordnungen in verschiedenen Ländern eingeflossen, sondern bilden auch die Basis für viele Testwerkzeuge.

Tags: , ,

Stand: 07.07.2003, Autor: tc

Alle diese Verordnungen und Testwerkzeuge haben ein gemeinsames Problem: viele der in den WCAG 1 gemachten Vorgaben sind entweder zu restriktiv oder irrelevant, zu unverständlich, sie entsprechen nicht mehr dem Stand der Technik, oder sie sind international nicht durchsetzbar.

Trotzdem ist diese W3C-Empfehlung der einzige anerkannte und gültige de-fakto-Standard zur Barrierefreiheit im Internet und durch Verordnungen wie die BITV oder die amerikanische Section 508 sind viele Anbieter damit zur Konformität verpflichtet.

Die WCAG-Arbeitsgruppe des W3C hat diese Problematik natürlich auch erkannt und arbeitet schon seit geraumer Zeit an einem Nachfolger. Nach allgemeinem Konsens wird dieser die Versionsnummer 2.0 tragen, und es wird, anders als bei anderen W3C-Standards wie HTML oder XHTML, keine Zwischenversion 1.1 oder "Second Edition" geben.

Die wichtigsten Änderungen von 1 nach 2

Was sind denn nun die wichtigsten Änderungen? Solange es in Deutschland kein privatrechtliches Anti-Diskriminierungsgesetz gibt, das einen ähnlichen Standard wie die BITV setzt, ändert sich für nicht-staatliche Anbieter zunächst erst mal garnichts.

Grafik: Logo des W3C und der Web Accessibility InitiativeAuch wenn das W3C noch so sehr darauf besteht, die Ergebnisse seiner Arbeit sind trotzdem keine internationalen Normen, sondern nur freundliche Empfehlungen ohne bindenden Charakter. Selbst in USA geht die Meinung darüber auseinander: dort hat sich das W3C auch schon von Gerichten sagen lassen müssen, dass ihre Empfehlungen eben keine gerichtsverwertbaren Standards sind (vgl. Access Now, Robert Gumson et al. vs. Southwest Airlines).

Etwas anderes ist die Lage natürlich, wenn die Erfüllung der WCAG als Auswahlkriterium bei Ausschreibungen und Auftragsvergaben hinzugezogen werden - in diesem Fall ist die Einhaltung der Vorgaben durch das Endprodukt vertraglich abgesichert und damit bindend. Die jetzige Struktur und die Inhalte der aktuellen Version sind jedoch für viele Auftraggeber und Anbieter kaum brauchbar und führen auch nicht unbedingt zu einem barrierefreieren Resultat, sondern verleiten viele Anbieter zu Ausreden oder faulen Kompromissen.

Fehlerbereinigung

Nach dem jetzigen Standard kann man ja bekanntermaßen immer nur entweder den WCAG-Konformitätslevel A, oder AA oder AAA erfüllen und dies durch ein entsprechendes Prüfsiegel kundtun. Durch diese rigide Festlegung entfällt aber für Anbieter von Webseiten der Anreiz, zum Beispiel A komplett zu erfüllen und dazu noch einige Teile von AA und andere Teile von AAA, weil Prüfprogramme wie Bobby dann trotzdem meckern. Bei den jetzigen WCAG 1 fehlt also der Anreiz, mehr als unbedingt nötig zu tun.

Andere Länder, die nach dem britischen Common Law-Prinzip verfahren, haben es da bedeutend einfacher. In Australien zum Beispiel steht sinngemäß im Gesetz: »You have to be accessible. If it's broken, fix it. If you need to know how, consult the WCAG« (Sie müssen barrierefrei sein. Wenn es nicht funktioniert, reparieren Sie es. Wie das geht, können Sie in den WCAG nachlesen).

Das hat unter anderem den enormen Vorteil, dass man bei einer Änderung der WCAG nicht gleich die ganze Verordnung überarbeiten muss, da nur das referenzierte Dokument ausgetauscht wird - auch das W3C macht schon mal Fehler oder Technologien ändern sich schneller als erwartet.

Zudem dreht sich die Version 1 der Guidelines fast ausschließlich um HTML und dort insbesondere um Techniken, die mittlerweile hoffnungslos veraltet sind. Die Version 2 bewegt sich hier nun auf einer abstrakteren Ebene, so dass die Vorgaben für alle nur erdenklichen Web-Techniken einsetzbar sind und man nicht mehr Gefahr läuft, bei einer Änderung der Techniken obsolet zu werden.

Neue Struktur

Der alte (aber zur Zeit natürlich weiterhin gültige) Standard besaß insgesamt 14 einzelne Richtlinien zu unterschiedlichen Aspekten der barrierefreien Webentwicklung. Die ersten Entwürfe des Nachfolgers hatten diese weiter zusammengefasst und bestanden nur noch aus 5 Richtlinien (Perceivable, Operable, Navigable, Understandable and Robust), wobei diese in der letzten Fassung dann noch weiter auf nur noch vier Richtlinien zusammengefasst wurden (Perceivable, Operable, Understandable and Robust).

Jede dieser Richtlinien enthält nun mehrere Checkpunkte (z.Zt. insgesamt 18), die entweder Kernanforderungen (Core, d. h. ein deutliches Muss) oder Soll-Anforderungen (Extended) sind. Alle diese Anforderungen beziehen sich nicht auf bestimmte Technologien wie HTML oder CSS, sondern sind so gehalten, dass sie auf alle bereits vorhandenen oder zukünftigen Technologien anwendbar sind.

Anweisungen oder Ratschläge, wie denn nun die einzelnen Checkpunkte in bestimmten W3C-Technologien wie HTML, XHTML oder anderen XML-Anwendungen, CSS oder SVG, aber auch in Skriptsprachen wie ECMAScript (vulgo: JavaScript) zu erfüllen sind, werden in zusätzlichen Dokumenten gegeben. Diese Technologie-abhängigen Informationen gehören aber nicht direkt zum eigentlichen Standard, sondern sind nur informativer Natur, glänzen dafür aber mit Programmierbeispielen, Codelistings und Screenshots.

Neue Erfolgskriterien

Eine wertvolle Hilfe für alle an einem Webprojekt Beteiligten werden die neuen Erfolgskriterien sein, in denen beschrieben wird, wie ein Webangebot sich verhalten muss, um die Vorgaben eines bestimmten Checkpunktes erfüllt zu haben. Wenn z. B. ein Testprogramm in der Lage ist, die Hierarchie und die logische Struktur eines Textes aus dem Quellcode zu ziehen, so ist damit die Richtlinie 1.3 erfüllt. Im Falle einer HTML-Seite würde das dann bedeuten, dass der Autor zur Auszeichnung der Überschriften die dafür vorgesehenen Überschriftenelemente h1-h6 benutzt hat.

Überprüfbare Qualitätsstandards

In der Liste der Core-Checkpunkte werden sich im Gegensatz zum Vorläufer keine Vorgaben mehr finden, die nicht eindeutig testbar und verifizierbar sind. Die aktuelle Version leidet ja bekanntlich unter dem Mangel, dass sie weder durch Maschinen, die dann doch wieder nur eine Liste mit »User Checks« ausgeben, eindeutig und unmissverständlich überprüfbar ist, noch durch 5 menschliche Prüfer, die hinterher zu 6 Ergebnissen kommen. Ziel der Neufassung ist, dass alle Anforderungen eindeutig durch maschinelle Prüfverfahren, oder da wo dies nicht möglich ist, durch geschulte Evaluatoren testbar sind.

Weicher Übergang

Es wird von der WAI weitergehende Informationen und Hilfen geben, die einen möglichen weichen Übergang von 1 nach 2 beschreiben, ohne dass man gleich sein gesamtes Webangebot über den Haufen schmeißen muss. Eine Möglichkeit dazu wäre der gerade aktuell diskutierte Ansatz, die Core-Kriterien als Muss und die Extended-Kriterien als Soll und die Best Practices als »Nice to have« ohne normativen Charakter festzulegen. Das entspräche dann zumindest von der Struktur her dem aus den WCAG 1 bekannten A-, AA- und AAA-Prinzip, allerdings natürlich mit verbesserten und umsortierten Inhalten.

Ergebnisorientiert

Bewertet wird nicht mehr das, was beim Absender losgeschickt wird, sondern das, was beim Empfänger ankommt. Erst wenn dieses Ergebnis für die weitaus meisten Menschen benutzbar ist, kann sich eine Website wirklich barrierefrei nennen.

Deutliche Konformitätserklärungen

Anbieter, die sich zur Einhaltung der WCAG 2 verpflichten, müssen also den Mindeststandard der Core-Checkpunkte erfüllen und können darüber hinaus in einer Konformitätserklärung beschreiben, welche weitergehenden Kriterien man freiwillig oder auf Grund einer bestimmten Nutzerstruktur erfüllt hat. Also zum Beispiel core plus extended 1.3, 2.1, 2.2 und 4.5.

Der so informierte Benutzer einer solchen Seite weiß dann, dass er hier mit seiner Braillezeile weiterkommt, weil die notwendigen Techniken berücksichtigt sind und er nicht erst beim gescheiterten Versuch der Betätigung des Bestellknopfes merkt, dass »Bobby approved« leider nur für die Startseite eines mehrseitigen Bestellvorgangs galt.

Die Idee, für die weitergehenden Checkpunkte (Extended) ein Punktesystem zu vergeben, wurde wieder verworfen, da hier eine Gewichtung natürlich unmöglich ist. Bei solch einem System lässt sich nie und nimmer ein Konsens herstellen, welche Checkpunkte denn nun wie hoch zu gewichten sind, so dass es am Schluss dann doch wieder auf 1 Punkt pro erfülltem Kriterium hinausgelaufen wäre - und dann kann man eine Punktebewertung auch gleich weglassen.

Anpassbarkeit an nationale Gegebenheiten

Eine wichtige Vorgabe für die Entwicklung ist, dass dieser Standard besser als der Vorläufer für den weltweiten Einsatz geeignet sein muss. Dabei geht es noch nicht mal um so oberflächliche Dinge wie die Vorgabe zur Auszeichnung von Abkürzungen und Akronymen, wo sich Amerikaner und Briten nicht einigen können, was denn nun das eine und was das andere sei.

Viel wichtiger ist, dass sich die WCAG 2 ohne weiteres in nationale Gesetzgebung und Normen umsetzen lassen und vor allem dass diese Gesetze zueinander kompatibel sind. Ansonsten wäre es durchaus denkbar, dass eine Technik in Europa ausdrücklich verlangt wird, in den USA aber verboten ist - dann hätten entweder Microsoft und IBM ein Problem oder Europa kein Betriebssystem mehr. Viele Firmen mit gemeinsamen Vertriebsorganisationen für D, A, CH oder sogar für ganz Mitteleuropa haben dann außerdem das Problem, dass man bei ihnen zwar mit der selben Währung einkaufen kann, sie aber trotzdem für jedes Land einen eigenen Online-Shop anbieten müssten, nur weil die jeweiligen Standards zur Barrierefreiheit etwas anderes als Mindestanforderung verlangen.

Auch dies ist einer der Gründe dafür, dass sich der Entwurf im Vergleich zu seinem Vorläufer so rank und schlank präsentiert: alles was nicht komplett wasserdicht verifizierbar ist (und davon gibt es in den WCAG 1 und folgerichtig in der BITV mehr als genug) kann kein Muß-Kriterium (Core) sein.

Im Augenblick evaluiert die WCAG-Arbeitsgruppe des W3C die internationalen Gesetze und Verordnungen, um zu sehen, ob und wie die WCAG 1 in die Rechtssprechung eingeflossen sind und welche Auswirkungen das auf die Entwicklung der WCAG 2 haben könnte (Übersetzbarkeit, Umsetzbarkeit in nationales Recht etc.)

Wann kann man mit der endgültigen Verabschiedung rechnen?

Nach der unverbindlichen Schätzung von W3C-Mitarbeitern ist bis Februar 2004 mit einem sog. "Last Call" (letzte Gelegenheit zur Kritik) zu rechnen. Der Status eines "Release Candidate" wäre dann voraussichtlich noch im ersten Quartal 2004 erreicht, und wenn es keine Komplikationen gibt, steht die finale Version 2.0 gegen Ende des zweiten Quartals 2004.

Wobei spätestens der Last Call so stabil sein sollte, das man damit ernsthaft arbeiten kann. Zum Prozess der Verabschiedung gehört nämlich auch, dass Beispiel-Implementationen gesucht oder erstellt werden, um die tatsächliche Umsetzbarkeit zu gewährleisten - das geht natürlich nur mit einem einigermaßen stabilen Dokument.

Warnhinweis: Bitte beachten Sie, dass es sich bei den hier zitierten Entwürfen um genau das handelt: Entwürfe. Die bisher veröffentlichten Working Drafts haben keinerlei normativen Charakter, sondern dienen nur der Diskussion in der WAI und der interessierten Öffentlichkeit. Sie sollten also nicht als verbindliche Grundlage herangezogen werden. Beim W3C finden Sie den jeweils letzten Stand der Entwürfe.

Und was passiert mit Verordnungen wie der BITV?

Im §5 der Barrierefreie Informationstechnik-Verordnung steht unter Folgenabschätzung:

»»Die Verordnung ist unter Berücksichtigung der technischen Entwicklung regelmäßig zu überprüfen. Sie wird spätestens nach Ablauf von drei Jahren nach ihrem Inkrafttreten auf ihre Wirkung überprüft.«

Das könnte die zeitnahe Übernahme der WCAG 2 bedeuten - hier sind also die zuständigen Fachministerien gefragt.

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