Sie sind hier: Start > Artikel

Übersetzung: ›Zur Hölle mit WCAG 2‹

Im Folgenden finden Sie die Übersetzung des Artikels »To Hell with WCAG 2« von Joe Clark, der zuerst bei A List Apart erschienen ist. Bitte beachten Sie auch die Anmerkungen des Übersetzers, Dr. Andreas K. Bittner.

Tags: WCAG, Webstandards

Autor: jc, Übersetzung: akb

Zur Hölle mit WCAG 2

Die erste Version der Zugänglichkeitsrichtlinien für Web-Inhalte (Web Content Accessibility Guidelines 1.0 oder kurz WCAG 1.0) wurde nach einem langen Konsultationsprozess im Jahr 1999 veröffentlicht – und war schnell veraltet. Die nun vorgeschlagene zweite Version – WCAG 2.0 – ist das Ergebnis eines fünfjährigen Arbeitsprozesses, moderiert durch die Zugänglichkeitsinitiative des W3C (Web Acccessibility Initiative, kurz WAI), die aber nie zum Ziel kam.

Weil man versuchte, alles für alle Web-Inhalte zu regeln, sind die WCAG 2 im Grunde unverständlich für einen Web-Entwickler, der standardkonform arbeitet oder arbeiten möchte. WCAG lässt sich auf die Grundlagen einer verantwortungsbewussten Web-Entwicklung, wie sie inzwischen von ›Standardistas‹ allgemein akzeptiert werden, zurückführen. Doch WCAG 2 ist keine ausreichende Verbesserung. Und es hat sich nicht gelohnt, so lange zu warten.

Enttäuschungen vorprogrammiert

Solltest du selbst ein sogenannter standardkonformer Web-Entwickler sein, bist du natürlich vertraut mit dem Thema Zugänglichkeit im Web (web accessibility) und dem einzigen internationalen Standard zum Thema, den Zugänglichkeitsrichtlinien für Web-Inhalte. Deren erste Version, WCAG 1, hat soeben ihren siebten Geburtstag gefeiert und wird bald ausgedient haben. WCAG 1 muss dringend überarbeitet werden.

Am 27. April 2006 veröffentlichte die WAI die erste Runde einer unendlichen Dokumentenreihe, die für die Überarbeitung erforderlich sind, damit die WCAG 2.0 der neue Standard werden kann.

Falls du auf eine Rundum-Erneuerung gehofft haben solltest, wirst du enttäuscht sein. Immerhin wurde eine Menge offener Themen geklärt und viele Richtlinien mit niedriger Priorität sind nun solide formuliert. Das Problem: Standardistas wissen inzwischen längst, wie sie das ehemals unsichere Gebiet dieser weniger wichtigen Richtlinien durchqueren. Die neuen WCAG 2 versagen bei den echten Kloppern. Interessanterweise – und das liegt wahrscheinlich an der jahrelangen, peniblen Redaktionsarbeit – sind die echten Klopper nun gut verborgen, sodass ein weniger informierter Leser die WCAG 2 tatsächlich vernünftig findet. Sie sind es nicht, und du als Web-Entwickler, der täglich standardkonform arbeitet, wirst schnell merken, dass es nahezu unmöglich ist, die WCAG 2 umzusetzen.

Wo du die Dokumente findest

Einer alten Tradition des W3C folgend, sind die aktuellen WCAG 2-Dokumente verwirrend und zudem schwer zu finden. (Ich notiere unten auch die Anzahl der Seiten – gemäß amerikanischem Letter-Format, gedruckt als PDF aus einem Browser (Safari mit unveränderten Voreinstellungen) sowie die Anzahl der Wörter – ohne Markup). Für diesen Artikel habe ich alle drei Dokumente gedruckt und gelesen.

Web Content Accessibility Guidelines 2.0 ist das aktuelle Hauptdokument und es ist das einzige, das »normativen« Charakter hat, also als Standard im Sinne des W3C gelten kann. Es wird, im üblichem W3C-Jargon, als letzter Aufruf zur Entwurffassung (Last Call Working Draft) bezeichnet. (Umfang: 72 Seiten, 20.800 Wörter)
Understanding WCAG 2.0 (WCAG 2.0 verstehen) ist ein Dokument, das vorgibt, die WCAG 2 zu erklären. (165 Seiten, 51.000 Wörter)
Techniques for WCAG 2.0 liefert »allgemeine« Techniken. (221 Seiten, 88.000 Wörter)

Verglichen mit dem allgemein üblichen Umfang von Büchern übertreffen die drei genannten WCAG 2-Dokumente mit insgesamt 450 Seiten jede Veröffentlichung zum Thema WCAG 1 – meine eigene eingeschlossen. Hinzu kommt: Folgt man den zahlreichen Blog-Einträgen (wie zum Beispiel (Snook, Clagnut, Sitepoint, KuraFire), hat Shawn Lawton Henry von der WAI Education & Outreach Working Group die Zuhörer ihres Vortrag bei der Veranstaltung South by Southwest 2006 vorsichtshalber gewarnt, lieber nur das Dokument »WCAG 2.0 verstehen« zu lesen, statt der aktuellen »normativen« Spezifikationen. Nachdem das Dokument »WCAG 2.0 verstehen« mehr als den doppelten Umfang hat, wie das, welches es vorgeblich erklären soll, könnte allein das schon auf ein Problem von WCAG 2 hindeuten.

Dann ist da noch ein Dokument, seit November 2005 nicht aktualisiert, das sich mit HTML-Techniken beschäftigt. Es wurde für diesen Artikel nicht berücksichtigt. Auch die »Richtlinien« der WCAG 1, die bei WCAG 2 nach einem Wechsel der Bezeichnung nun »Erfolgskriterien« heißen, werden von mir nicht beachtet.

Für meine nun folgenden Ausführungen waren Links auf die und innerhalb der Dokumente nur mit Finessen möglich. Das liegt an den zahlreichen, aber immer noch nicht ausreichenden Verweismöglichkeiten (fragment identifiers). In einigen Fällen – Seitenaufbau, lieber Steve Faulkner! – fehlte es an sinnvollen title-Attributen.

Du hast kaum Zeit für Kommentare

Nach fünfjähriger Arbeit an der WCAG 2, gab die WAI der gesamten Industrie sowie allen anderen interessierten Beteiligten einschließlich der Menschen mit Behinderungen kolossale 34 Tage, um die WCAG 2 zu kommentieren (Anmerkung des Übersetzers: Die Frist lief zunächst am 31. Mai 2006 ab, wurde dann aber bis zum 22. Juni 2006 verlängert.) Während das zwar das vorgeschlagene dreiwöchige Minimum übersteigt, ist es trotzdem zu kurz. Ferner wäre es der WCAG 2-Arbeitgruppe am liebsten, wenn du ein Formular ausfüllen könntest, am besten mit Excel, für jeden einzelnen Punkt, mit dem du nicht einverstanden bist.

Ich rate dir einfach eine E-Mail an public-comments-wcag20@w3.org zu schicken und die Archive der Mailingliste zu lesen. (Dort ist es allerdings unmöglich genau zu sagen, wer welchen Kommentar via WAI-Formular geschickt hat.) Es gibt dort eine längliche Sammelliste (hat Clark die falsch verlinkt?) aller Kommentare, die über das WAI-Formular eingegangen sind. Ich rate Leuten außerdem, um eine Verlängerung der Kommentarphase von mindestens einem Monat zu bitten; dabei könnt ihr den W3C an seine eigenen Worte erinnern (heißt: Die Kommentarphase »kann länger dauern, wenn der technische Bericht komplex ist oder wesentliche externe Abhängigkeiten aufweist«).

Der ganze Prozess stinkt

Und nun ein Wort über den Prozess, den du erst mal einschätzen können msst, um das Endergebnis zu verstehen. Die Arbeitsgruppe für die Zugänglichkeitsrichtlinien (Web Content Accessibility Guidelines Working Group) ist das schlimmste Komitee, die übelste Gruppe, Firma oder Organisation mit der ich jemals zusammengearbeitet habe. Einige meiner Freunde und ich selbst wurden verschiedentlich ignoriert, mit Ausschluss aus der Gruppe bedroht oder tatsächlich rausgeworfen und aktiv drangsaliert. Der ganze Prozess ist zum Vorteil von multinationalen Unternehmen mit ausreichendem Budget gestaltet, die es sich leisten können, zwei Stunden in der Woche über Telefon zu kommunizieren und zu den Hauptstädten dieser Welt für die jeweiligen Arbeitstreffen zu fliegen.

Der WCAG Prozess ist für jeden unzugänglich, der nicht Englisch spricht. Wichtiger noch, er ist für einige Menschen mit Behinderungen unzugänglich, insbesondere für jeden mit einer Leseschwäche (der sich durch schlecht geschriebene E-Mails und Dokumente zu den Standards kämpfen muss – ja, es gibt schon eine Beschwerde dazu.) Das gilt auch für jeden Hörgeschädigten (der nicht an den Telefonkonferenzen teilnehmen kann.) Fast niemand mit einer Lese- oder Hörschwäche trägt etwas zu dem Arbeitsprozess bei – denn das ist praktisch unmöglich.

Eigentlich sollte die WAI das Web für Menschen mit Behinderungen verbessern. Etwas läuft falsch, wenn viele Teilnehmer in einem Klima der Angst arbeiten, wie sie mir versichern. Ich habe niemals von ähnlichen Beschwerden über andere WAI-Gruppen gehört. Die WCAG-Arbeitsgruppe ist die Schurken-Truppe innerhalb des W3C, eine, die sich der Vorsitzende Tim Berners-Lee dringend vornehmen sollte.

Der Prozess ist kaputt, es sollte uns also nicht überraschen, wen das Ergebnis dieses Prozesses auch kaputt ist.

Weniger Travestie, aber weiterhin ein Ausfall

Falls du jemals zwei Stunden deines Lebens erübrigen kannst, um einen der vorherigen »Entwürfe« (draft) zu lesen, wärest du wahrscheinlich erstaunt und / oder erzürnt. Die Arbeitsgruppe hat es geschafft, nebensächliche Richtlinien zu verbessern und sich selbst dabei übertroffen, das ganze Dokument ziemlich vernünftig erscheinen zu lassen. Es ist ihnen auf spektakuläre Weise gelungen die eigentlichen Absichten zu begraben und die Kernaussagen der Richtlinien tief im Inneren des Dokuments zu verstecken.

Lasst mich auf der Basis der genannten drei Dokumente und unter Berücksichtigung der notwendigen und empfohlenen Umsetzungsschritte erklären, was die WCAG wirklich sagen:

Schon was eine Seite (page) geschweige denn eine Internetpräsenz (site) ist wird zu einem Streitfall werden.
Eine künftige Website, die WCAG 2-konform ist, braucht überhaupt kein valides HTML. (Dazu später mehr.) Allerdings wirst du den DOM-Output einer Website in verschiedenen Browsern überprüfen und beweisen müssen, das dieser jeweils identisch ist. (Anmerkung des Übersetzers: Das Spezialistenthema DOM-Output soll hier nicht weiter vertieft werden.)
Du kannst immer noch Layouttabellen benutzen. (Und nicht nur eine Tabelle – sondern Tabellen für Layout, also Plural.)
Deine Seite oder jeder Teil hiervon darf bis zu 3 Sekunden lang blinken. Einzelne Teile dürfen aber nicht zu sehr »blitzen«.
Du kannst künftig ganze Web-Technologien als ein Art »baseline« definieren, das bedeutet konkret: Jeder ohne diese Technologie hat nur geringe – oder gar keine – Anhaltspunkte mehr, sich über die Unzugänglichkeit deiner Seite zu beklagen.
Du kannst künftig ganze Unterbereiche (directories) deiner Website als »off-limits« definieren. Anders gesagt, sie sind per eigener Erklärung als unzugänglich gekennzeichnet (dazu zählen auch, nach einem Beispiel der WCAG 2, alle eigenständigen Videofilme.)
Solltest du WCAG 2-Konformität für deine Seite beanspruchen, musst du künftig eine Checkliste von Deklarationen veröffentlichen. Das erinnert mehr an ein erzwungenes Geständnis als alle anderen Zugänglichkeitsregeln die man heutzutage typischerweise findet.
Bislang ist es niemandem gelungen, sie zugänglich zu machen, aber wenn du künftig Videofilme online stellst, musst du keine Beschreibung (audio description) für blinde Menschen mehr mitliefern, zumindest nicht auf dem niedrigsten »Konformitäts«-Level. Ebenfalls müssen auf diesem Level nur vorproduzierte Videos untertitelt werden. (Im Gegensatz zu Live-Videos.)
Deine Podcasts müssen unter Umständen neu gemischt werden, damit Dialoge 20 Dezibel lauter sind als längeranhaltende Hintergrundgeräusche. (Allerdings musst du sie nicht mehr untertiteln oder beschreiben, da sie nicht mehr als »multimedial« gelten. Eine Diashow hingegen gilt nunmehr offiziell als »Video«, was die Nutzer des Bilderdienstes Flickr überraschen dürfte.
Natürlich kannst du ein paar Hundert Navigationslinks auf einer einzigen Seite unterbringen, ohne dir weitere Gedanken über die Zugänglichkeit machen zu müssen, aber wenn du zwei verbundene Dokumente hast, die jeweils drei Navigationslinks haben, musst du einen Weg für eine Sprungnavigation (Skip Navigation) anbieten.
Du kannst keine Positionierung außerhalb des Bildschirms einsetzen, um Labels hinzuzufügen (etwa bei Formularen), die ausschließlich von einigen Menschen, zum Beispiel solchen mit assistiven Technologien, wahrgenommen werden können. Jeder muss diese Informationen sehen können.
CSS-Layout, vor allem Elemente, die absolut positioniert sind und damit aus dem Dokumentenfluss herausfallen, können auf dem höchsten Konformitäts-Level einfach verboten werden. Tatsächlich müssen Source Code-Reihenfolge und Präsentationsreihenfolge selbst auf dem niedrigsten Konformitäts-Level übereinstimmen.
Auf dem höchsten Level musst du zudem einen Weg finden, um die folgenden Punkte zu berücksichtigen.
1. Definitionen für besondere Idiome und »Jargon«
2. Die Auflösung von Akronymen
3. Die Aussprache einiger Wörter
Außerdem musst du ein Alternativdokument bereitstellen, wenn ein Leser mit »niedrigerem Bildungsstand« (im Original: lower secondary education level) dein Hauptdokument nicht verstehen kann. (Tatsächlich erlaubt WCAG 2 wiederholt getrennte zugängliche und unzugängliche Seiten. In einigen Fällen musst du also nicht notwendigerweise deine unzugänglichen Seiten verbessern, wenn du eine zusätzliche Seite produzierst.)

Da alle drei Dokumente noch im Entwurfstadium sind, kann sich alles bisher Gesagte natürlich noch ändern. Aber ehrlich, das wird nicht passieren. Ein Arbeitsentwurf der in der Phase des »letzten Aufrufs« ist, wird im Grunde als fertig angesehen. Es ist »ein Signal ... dass die Arbeitsgruppe nun glaubt, alle wichtigen technischen Anforderungen erfüllt zu haben [und] alle wesentlichen Abhängigkeiten zu anderen Arbeitsgruppen berücksichtigt hat.« Die WCAG Arbeitsgruppe wird sich zu diesem Zeitpunkt bei bedeutenden Diskussionspunkten nicht mehr bewegen.

WCAG 2: Durch Definitionen versenkt

Auch wenn WCAG 2 alle möglichen unrealistischen und ungeprüften Bestandteile vereint, werden dies nicht die Richtlinien versenken. Doch etwas so Mondänes wie eine Definitionen werden das hinkriegen.

WCAG 1 war streng HTML-orientiert. Jeder erkannte das als Problem, in einer Zeit, in der Formate die blinde Menschen zu hassen lieben - wie PDF oder Flash - zunehmend zugänglich werden. Also musste WCAG 2 technologie-neutral sein.

Bei der Umsetzung stellte man sich ein Paralleluniversum vor, in dem die große Menge der Web-Inhalte aufhörten lupenreines HTML, CSS oder JavaScript zu sein. Die Richtlinien erträumen nun eine Welt, in der jede Menge Flash, PDF und andere, bislang noch nicht erfundene Formate verfügbar sind, die auch zugänglich sein sollen. Um diese Traumwelt unterzubringen, wurde WCAG 2 geschrieben, umgeschrieben und wieder zurückredigiert, um ja alles zu berücksichtigen. Unterwegs ging dabei die Fähigkeit verloren, die Richtlinien auf reale Fälle, mit denen es reale Web-Entwickler täglich zu tun haben, anzuwenden. Also lupenreines HTML, CSS und JavaScript.

Ein paar Quizfragen: Was sollen die folgenden Begriffe, die hier mit ihrer offiziellen WCAG 2-Definition aufgeführt sind, tatsächlich bedeuten? (In Klammern Originalbegriffe)

Autorengeschriebene Einheit (authored unit)
Materialsammlung, die als Ganzes von einem Autor kreiert wurde (set of material created as a single body by an author)
Autorengeschriebene Komponente (authored component)
Eine autorengeschriebene Einheit, die als Teil einer anderen autorengeschriebenen Einheit gelten soll (an authored unit intended to be used as part of another authored unit)
Web-Einheit (web unit)
Eine Informationssammlung, die aus einer oder mehreren Quellen besteht, die zusammen »gerendert« werden sollen und durch einen einzigen Uniform Resource Identifier (wie eine URL) identifiziert werden kann. (a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs))
unzweideutig »geparst« (parsed unambiguously)
in nur einen Datenstruktur »geparst« (parsed into only one data structure)
programmtechnisch festgelegt (programmatically determined)
festgelegt durch Software aus Daten, die durch eine Benutzeragenten-unterstützte Weise bereitgestellt werden sodass Benutzeragenten diese Informationen extrahieren und präsentieren können - in unterschiedlichen Modalitäten (determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities)

Kannst du einen dieser Begriffe in Worte übersetzen, die jeder Leser dieses Artikel verstehen kann? Also »Dokument«, »Website«, »valide«, »wohlgeformt«, oder »Template«? Nun, ich kann es nicht. Zwischen all diesen Definitionen, wo sind unsere Templates aus validen, wohlgeformten Seiten geblieben?

Wenn du einer dieser Standardistas bist, der an zugänglichen Seiten arbeitet, bist du dann, ohne es überhaupt zu wissen, ein Autor der autorengeschriebene Einheiten verfasst, die in autorengeschriebenen Komponenten verwendet werden für programmatisch festgelegte Web-Einheiten die unzweideutig »geparst« werden können?

Schau dir WCAG 2 an und du wirst deine eigene Checklist für Verballhornungen und unverständliche Passagen brauchen. Tatsächlich sind so viele Einzelteile vonWCAG 2 schwer zu verstehen und kaum auf Websites in der realen Welt anzuwenden, dass WCAG 2 in einem Punkt um keinen Deut besser ist, als seine Vorgängerversion - beide scheitern an ihrer eigenen Forderung nach klarem und einfachen Schreiben.

Wenn du schon die Grundlagen der Richtlinien nicht verstehen kannst und wenn WCAG 2 so weit vom real-existierenden Web entfernt ist, dass sie sich nicht mal darum kümmert, Begriffe zu benutzen, die jeder Web-Entwickler versteht, wie willst du dann ernsthaft die WCAG 2 bei deiner Arbeit umsetzen? Bedenke, dass du offiziell nicht einmal auf Dokumente zu »Techniken und Erklärungen« für weitere Informationen zurückgreifen darfst. Nur die WCAG 2 selbst ist »normativ«, also verbindlich. Nur damit kannst du entweder schwimmen oder untergehen.

Und wenn du Verständnisprobleme mit der WCAG hast, bedeutet das möglicherweise, dass ein anderer des Weges kommt, mit einer abweichenden Interpretation und dir dann vorwirft, du würdest die WCAG verletzten und unzugängliche Seiten entwickeln? Das aber ist in einigen Weltgegenden gegen das Gesetz, weshalb ein gewisser Grad an Klarheit unverzichtbar ist. Aber Klarheit ist eine Sache, die du von WCAG 2 definitiv nicht erwarten darfst.

Testbarkeit

Wenn du dich durch WCAG 2 schlägst, wirst du feststellen, dass selbst eine so trügerisch einfache Angelegenheit, wie die WCAG 1-Richtlinie über klares und einfaches Schreiben nicht mehr da ist. Es gibt auch keine stärkere Richtlinie hierzu. Tatsächlich findet sich rein gar zum WCAG 2-Prinzip Nummer 3: »Inhalte und Kontrollelemente müssen verständlich sein«.

Allerdings musst du dich mit fanatischer Sorgfalt um fremdsprachige Passagen, Idiome und Ähnliches kümmern. Und wenn deine Inhalte »ein Leseverständnis voraussetzen, dass über niedrige Anforderungen eines weiterführenden Schulniveaus hinausgehen« (secondary education), musst du »zusätzliche Inhalte bereitstellen«, die dieses Leseverständnis berücksichtigen. Das ist mehr oder minder alles, was WCAG 2 für Menschen mit Lernschwierigkeiten leistet.

Auf Basis meiner eigenen Analyse und den Präsentationen von Gian Sampson-Wild scheint es, dass alle Menschen mit Leseschwierigkeiten (Dyslexie) oder anderen kognitiven Einschränkungen auf dem Altar des Testens geopfert werden sollen. WCAG 2 erzählt uns:

Alle WCAG 2.0-Erfolgskriterien können getestet werden. Während einige mit Computerprogrammen getestet werden können, müssen andere durch qualifizierte menschliche Tester überprüft werden. Manchmal kann eine Kombination aus Computerprogrammen und qualifizierten Testern angewendet werden. Wenn Menschen, die WCAG 2.0 verstanden haben, die selben Inhalte an Hand der selben Erfolgskriterien testen, sollten sie zu gleichen Ergebnissen kommen - mit einer hohen Interrater-Reliabilität.

Diese »Interrater-Reliabilität« ist nicht definiert. Müssen acht von zehn Testern übereinstimmen? Oder sechs? Oder alle zehn?

Es sieht so aus, als ob jeder annimmt, dass es einfach sei »Menschen, die die WCAG 2.0 verstehen« zu finden, die aber dennoch nicht übereinstimmen, dass bestimmte Inhalte klar und einfach geschrieben sind. Ich nehme an, es wird als quasi axiomatisch gesehen, dass Prüfung von Inhalten selten einen hohen Grad an »Interrater-Reliabilität« erreicht, die auf der unzuverlässigen menschlichen Meinung basiert. Die Arbeitsgruppe war und ist unvernünftigerweise auf automatische Testverfahren fixiert, zum Teil, weil der Gruppe Mitglieder angehören, die sich mit automatischen Testverfahren und Algorithmen beschäftigen. Die Gruppe konnte die Realität verwinden, dass beispielsweise Alternativtexte nur von Menschen bewertet werden können, war aber nicht bereit zu akzeptieren, dass das Gleiche für »content« im allgemeinen gilt.

Es ist hart, aber gerecht festzuhalten, dass die WCAG 2 Menschen mit Lernschwierigkeiten »verkauft«, damit ein Software-Werkzeug wie »Bobby«, oder ein Wettbewerbs- oder Nachfolgeprodukt eine große Zahl von Kriterien mit höherer Erfolgsquote testen kann.

Die kreative Vorstellung vom multiplen Konformitätslevel

WCAG 1 kannte drei Level der »Konformität«, die - in typischer WAI-Weise - insgesamt sechs Bezeichnungen hatten: Priorität 1 / Level A, Priorität 2 / Level AA (ärgerlicherweise als »Double-A« geschrieben, um fehlerhafte Screen-Reader-Aussprache zu vermeiden) und Priorität 3 / Level AAA (»Triple-A«). Standardistas fanden gelegentlich heraus, dass Priorität 1 und 2 tatsächlich nötig waren, um eine Website zugänglich zu machen. Priorität 3 war strikt optional (oder auch beschwerlich und im Prinzip unmöglich zu erreichen). Selbst einige Regierungen, wie die kanadische, verlangen Priorität 2-Konformität für die eigenen Websites, obwohl dies nicht unbedingt erreicht wird.

Wenn Experten Websites gemäß WCAG 1 überprüfen, beschränken sich die meisten auf die ersten beiden Prioritäten. Wenige Websites, wenn überhaupt eine, schaffen den Priorität 3-Test. Zwei Organisationen - Disability Rights Commission und Nomensa - fanden keine Seite, die Priorität 3 erfüllte. (Anmerkung des Übersetzers: Nomensa ist eine britische Organisation, die sich mit Usability und Acessibility im Web beschäftigt. Wie auch die Disability Rights Commission testet sie kommerzielle und behördliche Websites auf Zugänglichkeit).

Für einen vernunftbegabten Beobachter heißt das: Priorität 1 und 2 sind eigentlich ein einziges Regelwerk und Priorität 3 ist irrelevant und nicht zu erreichen. Es war jedoch unmöglich, diesen Gedanlen auch in den Köpfe der Arbeitsgruppe zu verankern (oder genauer, im Kopf eines der Ko-Vorsitzenden), sodass wir es bei WCAG 2 noch immer mit drei Levels zu tun haben. Jetzt aber kommt's: Alle drei werden für wichtig erachtet.

Level 1 Erfolgskriterien
Erreichen ein Minimum an Zugänglichkeit.

Sollten zweckmäßig auf alle Web-Inhalte anwendbar sein.
Level 2 Erfolgskriterien
Erreichen ein verbessertes Niveau der Zugänglichkeit.

Sollten zweckmäßig auf alle Web-Inhalte anwendbar sein.
Level 3 Erfolgskriterien
Erreichen zusätzliche Verbesserungen der Zugänglichkeit.

Können nicht unbedingt auf alle Web-Inhalte angewendet werden

Um das nun zu übersetzen: Wir armen Einfaltspinsel haben die WCAG 1-Prioritäten-Level als tatsächliche Prioritäten-Level missverstanden. WCAG 2 versteht all ihre Richtlinien nun als »essentiell für einige Menschen«, obwohl sie immer noch in drei Level aufgeteilt werden. Und wenn du dir die WAI-Dokumente näher ansiehst:

1. Selbst wenn du alle drei Level der WCAG 2 erfüllst, könnte dabei immer noch eine nicht zugänglich Website herauskommen.
2. Du brauchst nie mehr als die Hälfte der Level 3-Richtlinien erfüllen
3. Das WCAG 2-Dokument selbst stellt mutig fest: »Es wird nicht empfohlen, dass Triple-A-Konformität jemals für einen gesamten Webauftritt verpflichtet ist.«
4. In zirkulärem Widerspruch hierzu Richtlinie 4.2.4., die dich nicht mal darauf verpflichtet, Level 3 in einigen Fällen zu erreichen.

Welchen Level möchtest du nun erfüllen? Bitte triff deine Wahl jetzt.

Eine weitere Absurdität: Die Arbeitsgruppekonnte ihre eigenen Richtlinien nicht einmal so überlisten, dass diese für alle Level gelten. Einige Richtlinien treffen nicht mal auf Level 1, dem niedrigsten Level, zu. Ich habe nachgezählt:

Levels 1 + 2 + 3 -> 7 Richtlinien
Kein Level 1 -> 1 Richtlinie
Kein Level 2 -> 2 Richtlinien
Kein Level 3 -> 1 Richtlinie
Nur Level 1 -> 2 Richtlinien
(Nur Level 2 oder nur Level 3: Keine)

Als ob es Web-Standards nie gegeben hätte

Während Leute wie du und ich seit ungefähr 1998 an vorderster Front für die Verbesserung von Web-Standards gekämpft haben - Verbesserung der Browser-Unterstützung, besseres Verständnis unter Entwicklern, Verbesserung der grundlegende Aufgabe Standards überhaupt zu erklären - hielt sich die WCAG-Arbeitsgruppe in einem Paralleluniversum auf und bastelt an Richtlinien die gleichsam zweideutig auf alles zutreffen. Aber die Arbeitsgruppe hat sich die Zeit genommen, um einige weithin akzeptierte Konzepte auszurotten.

Ja, wir wissen es schon: Eine Website mit validem HTML ist nicht automatisch zugänglich. Wir haben eine Reihe von lustigen Beispielseiten, die wir uns ansehen können (von Gez Lemon und Bruce Lawson). In der realen Welt der ahnungslosen Entwickler, die Suppe aus HTML-Tags produzieren (tag soup developers), ist die wachsende Minderheit derer, die valides HTML verstehen, eine Elite, die auch Zugänglichkeit versteht. Sie verstehen, welche Zugänglichkeitskriterien quasi nebenbei durch valides HTML erfüllt werden (wie Alternativtexte, die - aber das wissen wir auch schon - korrekt geschrieben sein müssen). Diese Web-Entwickler nehmen sich ohnehin die Zeit, die übrigen Zugänglichkeitskriterien auch zu berücksichtigen.

Sie verstehen auch die unvorhersehbaren Ergebnisse der »tag soup developers« für Browser und Screen-Reader. Sie wissen, dass ein einziges nicht kodiertes Ampersand-Zeichen (&). oder ein vergessenes Semikolon, oder ein verirrtes Unicode-Zeichen das ganze Dokument in die nicht valide HTML-Wüste schicken kann. Aber das sind unbedeutende Beispiele, die sich nicht bei HTML-Suppen-Seiten wie Amazon oder eBay wiederfinden. (Sie wissen, dass Amazon und eBay erfolgreich sind. Trotz ihres Quellcodes.) Sie wissen, dass Validität ein zerbrechliches Ding ist, dass schon wegen einer Kleinigkeit aus dem Tritt geraten kann, wegen eines einzigen Zeichens wie é oder &nbsp (sic!) oder einem & am falschen Platz. Sie wissen das alles.

Nichtsdestotrotz war vaildes HTML eine Level 2-Anforderung bei WCAG 1. Du wirst es fast nie bei einer kommerziellen Website finden. Die jüngste Untersuchung von Nomensa fand vier Beispiele unter 99 Websites, die per Hand überprüft wurden. Das ist der höchste Wert, den ich je gesehen habe. Aber Nomensa mahnte Entwickler. Obwohl HTML-Suppe noch immer die Regel ist, wollen wir sie nicht.

Die WCAG 2 drehen das komplett um. Du musst niemals valides HTML in einer WCAG 2-konformen Website haben. Alles was verlangt wird ist, dass Dokumente unzweideutig geparst werden (Richtlinie 4.1 - eine Level 1-Richtlinie ohne eine Richtlinie auf Level 2 oder 3). Das soll bedeuten, »keine unsauber verschachtelten Elemente«, aber das hättest du sicher niemals mit dem Begriff »unambiguously parsed« verbunden.

In einem HTML-Dokument kannst du weiterhin all die falsch eingesetzten, wirren Zeichen nach Belieben benutzen, aber du kannst kein <p> in einem <p> verschachteln. Du musst keines der Elemente oder Attribute, die nach den HTML-Spezifikationen erforderlich sind, benutzen. Du musst keine Elemente gemäß ihrer Spezifikation nutzen. All dies verheißt Unheil für Formulare, dem ewigen Ärgernis für alle Screen Reader-Benutzer. Ein Dokument, das aus nichts als divs und spans besteht und unzweideutig geparst wird, erfüllt die WCAG 2 ohne Fehl und Tadel.

XHTML-Dokumente sollen gemäß der Spezifikationen beim ersten Auftauchen von schlecht kodierten Web-Inhalten abrupt gestoppt werden. Aber wir wissen, dass dies in der realen Welt nicht geschieht, dort, wo XHTML wie eine Variante von HTML behandelt wird, der bloß noch schließende Schrägstriche angefügt werden. (Mit Ausnahme der ganz wenigen Perfektionisten, die XHTML wie XML betrachten.) Faktisch lässt die Anforderung also XHTML genauso durchgehen, wie HTML.

Wird dadurch das Problem etwa gelöst? Oder sieht es zumindest so aus, als ob dadurch das Problem gelöst würde, sodass Arbeitsgruppen-Mitglieder wie IBM, Oracle oder SAP, deren Software keinen verlässlichen, genuin validen HTML Code erzeugen, damit zurecht kommen? (IBM hat aktiv für eine DHTML-Technik für Zugänglichkeit geworben, die aber die HTML-Spezifikationen verletzt. Komischerweise, und sinnloserweise, rät das technische Dokument von so einem Vorgehen ab.

Glaubst du, dass die WCAG 2-Richtlinie gut genug ist, um die Arbeitsweise von HTML-Suppen-Entwicklern zu verbessern? Selbst wenn immer-und-überall-valides HTML nicht zu erreichen ist, bleibt die Tatsache, dass, wir im Jahre 2006, nie mehr Web-Entwickler hatten, die das Konzept tatsächlich begriffen haben und es auf ihren Websites umsetzen wollen. WCAG 2 macht eine Anforderung rückgängig, die, würde sie beibehalten, genau zur rechten Zeit käme.

Untertitel und Audio-Beschreibung für Multimedia

Sollte es einen Bereich geben, bei dem die Umsetzung von WCAG 1 komplett versagt habt, ist es Multimedia. Die Leute haben leichthin die Anforderungen für Untertitel (für Hörgeschädigte) und zusätzliche Audio-Beschreibung (als gesprochene Ergänzung für blinde Menschen) ignoriert. Beide sind bereits auf dem niedrigsten Zugänglichkeits-Level erforderlich. (Tatsächlich ist es beim zweiten Aspekt noch schlechter als bei den Bedürfnissen hörgeschädigter Personen. Mit einem Transkript, also ohne Untertitel, konntest du dich durchmogeln.)

Untertitel und Beschreibungen gibt es nicht in freier Wildbahn. Wenn es überhaupt einen Zugang geben sollte, dann durch Untertitel. Auf diese Weise folgen Multimedia-Inhalte im Web den Vorgaben für Fernsehen, Video- und Kinofilme in den wichtigsten demokratischen Ländern. Hier sind Untertitel geläufig. Beschreibungen sind es nicht. (Wer kann die ironische Szene vergessen, als der Accessibility-Verantwortliche von AOL, ein blinder Mann, Untertitel für »ausgewählte« AOL-Videos im Web ankündigte, aber keinerlei Audio Beschreibung?)

Für blinde oder hörgeschädigte Menschen, die Multimedia verstehen wollen, bietet die WCAG 2 keine wirkliche Verbesserung. Das Schlupfloch für »nur Transkript« wurde geschlossen, und Untertitel bleiben eine Anforderung auf dem niedrigsten Konformitätslevel für vorproduzierte Videos (im Unterschied zu Live-Videos im Internet). Aber statt eine Audio-Beschreibung, kannst du immer noch mit einem Phantasieprodukt aus der Vorstellungswelt der Arbeitsgruppe auskommen, das sich »komplette Multimedia-Textalternative inklusiver aller Interaktionen« nennt. Ein in Veruf geratenes Überbleibsel von WCAG 1, offenkundig eine Kombination aus einer Dialog-Abschrift verbunden mit Sound-Effekten (die blinde Menschen nicht brauchen), Abschriften von Audio-Beschreibungen (die hörgeschädigte Menschen nicht brauchen) sowie ein Link zu allen interaktiven Komponenten eines Videofilms.

Das Ganze soll taub-blinden Menschen helfen, die niemals nach ihren Vorlieben befragt wurden, ein Vorgehen, das ich der WAI bei einem persönlichen Treffen im Jahr 2003 empfohlen hatte. Auch wurde kein Benutzertest gemacht. (Soweit ich das den veröffentlichten Unterlagen entnehmen kann. Ich habe viele E-Mail-Anfragen an Organisationen von taub-blinden Menschen in unterschiedlichen Ländern geschickt und sie gefragt, ob sie befragt worden seien oder zu dem Thema eine Meinung hätte. Keine Antwort.)

Es gibt ungefähr drei bekannte Beispiele eines solchen Transkripts in der siebenjährigen Geschichte der WCAG (zum Beispiel DigNubia). Und es gibt in HTML auch keine Semantik für diese Transkriptionen, es sei denn man versuchte auf die Definitionsliste zu verweisen (eine verbotene Anwendung in »HTML 5«).

Auf dem zweithöchsten Konformitäts-Level sind überraschenderweise echte Audio-Beschreibungen erforderlich und, noch mal überraschenderweise, es müssen auch Live Videos untertitelt werden. Noch einen Schritt weiter (Level 3) und du musst Videos sogar in Gebärdensprache (welche?) übersetzen und, neben anderen Dingen, auch das gleiche frei erfundene Transkript anbieten. Du musst niemals Live-Videos beschreiben.

Ich war niemals dafür, dass Hunderte Live-Radiostationen im Internet sich selbst untertiteln müssen. Sicherlich stellen vorproduzierte Podcasts eine offenkundige Quelle für unzugängliche Multimedia-Inhalte dar. Tatsächlich wird Multimedia nun definiert als »Audio- oder Video synchronisiert mit anderen Medienarten und / oder mit zeitabhängigen interaktiven Komponenten.« Wenn dein MP3-Podcast nicht gleichzeitig mit anderen Dingen synchron läuft, ist er ausgenommen. Diese Bedingung wird die Mehrzahl der Podcaster, die sich jemals Gedanken zur Zugänglichkeit gemacht haben, zufrieden stellen. Beinahe alle haben entscheiden, dass es ihnen zuviel Aufwand ist, selbst wenn sie die Idee für gut befanden oder sie in dieser Zeit für die WAI gearbeitet haben.

Weiterführende Diskussion

Ich denke, das reicht für einen Artikel. Aber das ist längst nicht das Ende meiner Kommentare zu WCAG. Laufende Ergänzungen kannst du auf meiner Website verfolgen Die Kommentarfunktion dieses Beitrags, verbunden mit dem Tag WCAG2, sind weitere Möglichkeiten, sich zu äußern.

Ankündigung der WCAG-Samurai

WCAG 2 ist nicht so kaputt, dass sie nicht repariert werden könnte, aber wir habe keinen Grund zu glauben, dass ausgerchente die WCAG Arbeitsgruppe sie reparieren wird. Die Arbeitsgruppe ist zu sehr mit Firmeninteressen verwoben, zu verliebt in die Schlussfolgerungen, die wir im aktuellen »Entwurf« finden und zu kaputt im allgemeinen. Was du im Augenblick bei den WCAG 2 siehst, wird ziemlich genau das sein, was du auch in Zukunft bekommen wirst - für immer.

In ihrem augenblicklichen Zustand ist WCAG 2 für Web-Entwickler aus dem wahren Leben nicht brauchbar, besonders für standardkonforme Entwickler. Sie ist zu vage und zu unvollständig um eine verlässliche Basis für eine Regulierung durch Regierungsbehörden zu sein. Sie lässt den Entwicklern, die danach suchen, zu viele Schlupflöcher. WCAG 2 ist gescheitert und das nicht mal ehrenhaft.

Wen das alles ist, was wir bekommen, wenn die WAI die WCAG komplett neu zu schreiben versucht, vielleicht gibt es dann eine andere Option. WCAG 2 »ersetzt« nicht WCAG 1 mehr als XHTML zuvor HTML »ersetzt« hat. Vielleicht müssen wir nur die Irrtümer in WCAG 1 beheben. Das wurde bereits diskutiert, aber eine zweite Ausgabe der WCAG 2.0 oder eine WCAG 1.1 ist nie aufgetaucht.

Nun aber kann ich tatsächlich verkünden, dass dies Verbesserungen (errata) tatsächlich veröffentlicht werden, und meine Freunde und ich kümmern uns darum. Nach dem Vorbild von Zeldmans CSS-Samurai-Posse, die CSS-Design ins Blickfeld von Browser-Herstellern und Web-Entwicklern gerückt haben, werden die WCAG-Samurai Korrekturen an und Erweiterungen zu existierenden Zugänglichkeits-Spezifikationen publizieren.

Natürlich werden wir dabei kein Copyright verletzen, aber wir werden daraus auch keinen total offenen Prozess machen. Es ist ein praktikables Modell für die Entwicklung von Standards, eine Arbeitweise, die ich in einem anderen Zusammenhang gut hingekriegt habe, aber beim Thema Zugänglichkeit im Internet hat sie sich als wenig praktikabel erwiesen. Die Mitgliedschaft bei den WCAG-Samurai ist, genauso wie bei den CSS-Samurai, nur durch Einladung möglich. Wenn wir dich brauchen, hörst du von uns.

Klar ist das zumindest unfair, wenn nicht sogar elitär und hochmütig. Nenn‹ es, wie du willst. Aber wir versuchen es, in der Hoffnung, die Arbeit getan zu bekommen, an der die WAI und ihr Modell elementar gescheitert sind.

Über den Autor.

Der kanadische Journalist, Autor und Accessiblity-Berater Joe Clark hat das Buch Building Accessible Websites geschrieben, geht aber davon aus, dass Leser von A List Apart das inzwischen wissen.

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