accessCast

Vor über einem Jahr veröffentlichte die Web Accessibility Initiative des W3C einen Entwurf der WCAG in Form eines so-genannten Last Call, der für erhebliche Unruhe sorgte. Last Call bedeutet in der Hierarchie der W3C-Standard-Entwürfe, dass es sich um ein weitestgehend stabiles Dokument ohne grobe Schnitzer handelt, das auf dem besten Weg zur endgültigen Empfehlung ist.

So sah es die Arbeitsgruppe – dass dies nicht so war zeigte die hohe Anzahl von Kommentaren zur Veröffentlichung des Entwurfs bis hin zu formellen Einsprüchen, die nach der Veröffentlichung eingegangen sind. Viele der Kommentare bezogen sich auf esoterische Details, einige zweifelten aber die grundlegende Struktur und Zielsetzung der Richtlinie an, in der sich zum Beispiel Menschen mit Lernbehinderungen nur unzureichend berücksichtigt sahen.

Das vergangene Jahr hat die WAI-Arbeitsgruppe genutzt, um hunderte Kommentare und Verbesserungsvorschläge zu sichten und, sofern sinnvoll, in die WCAG 2.0 einzuarbeiten. Das Resultat ist der am 17. Mai veröffentlichte Entwurf, den wir uns etwas näher angesehen haben. Links zu allen besprochenen Dokumenten finden Sie wie üblich am Ende der Mitschrift von diesem Podcast.

Einen Überblick über die Struktur und Inhalte des Entwurfs erhält man durch die Lektüre von: »Overview of Web Content Accessibility Guidelines 2.0 Documents«. Die Version mit der Änderungsverfolgung bietet den besten Einblick in die vollzogenen Änderungen bei den zentralen Richtlinien - trotz des unmöglichen Designs und des sehr gewöhnungsbedürftigen Markup. Sie zeigt gestrichene und neu eingefügte Texte, und im Kontext wird per Link auf den dafür verantwortlichen Kommentar verwiesen. So lassen sich die Hintergründe für die Änderungen erschließen.

Was ist neu?

Die wohl wichtigste Änderung: dieser Entwurf der WCAG 2.0 hat nicht mehr den Status eines Last-Call-Dokumentes, sondern wurde zu einem einfachen Arbeitsentwurf (engl.: Working Draft) degradiert. Dies geschah vor dem Hintergrund der schieren Masse der notwendig gewordenen Änderungen, die bis in grundlegende Konzepte reichten. Die schlechte Nachricht dabei: der jetzige Stand dient als Grundlage für weitere Entwürfe oder auch für einen erneuten Last Call Working Draft. Zwischen diesen und einer endgültigen, fertigen und auf allgemeinem Konsens beruhenden Richtlinie liegen noch einige Schritte, um den Formalien des W3C zu genügen. Damit dürfte klar sein: mit einer Fertigstellung der WCAG 2 ist wohl auch im Jahre 2007 erneut nicht zu rechnen.

Eine weitere wichtige Neuerung ist eine deutlichere Herausstellung der Grenzen der Barrierefreiheit. Die neue Version sagt bereits in der Einleitung, dass auch die vollständige Befolgung der Richtlinie nicht unbedingt dazu führt, dass ein Angebot die Nutzung für alle Formen der Behinderung oder Mehrfachbehinderung ermöglicht.

Ebenfalls neu ist der deutliche Hinweis, dass die WCAG nur einen Baustein in der Erreichung eines barrierefreieren Webs darstellen. In der Einleitung wird deutlich auf die Verantwortung der Hersteller von Browsern, assistiven Hilfsmitteln, aber auch Redaktionssystemen und Entwicklungstools hingewiesen.

Auch neu: das Konzept der Baseline-Assumptions wurde wieder gekippt. Diese Konstruktion wurde in einem vorhergehenden Entwurf eingeführt, um Webautoren die Möglichkeit zu geben, technische Mindestanforderungen für die sinnvolle Nutzung an die verwendeten Browser und Hilfsmittel zu stellen. Das ganze wird nun »accessibility support« genannt und beschreibt die Zugänglichkeits-Features der verwendeten Techniken wie HTML, CSS, JavaScript, Flash oder PDF. Die Bedingungen haben sich trotz der Umbenennung nicht wirklich geändert: die Technik muss öffentlich dokumentiert sein und von den gängigen Browsern und Hilfsmitteln unterstützt werden.

Damit wird eine große Verantwortung von den Webentwicklern genommen und auf die Hersteller von Browsern, Hilfsmitteln und Nicht-W3C-Formaten übertragen. Dem durchschnittlichen Webentwickler ist es kaum zuzumuten, seine Werke mit dem riesigen Spektrum von Hilfsmitteln zu testen. Statt dessen werden deren Hersteller in die Pflicht genommen für die Unterstützung anerkannter und verbreiteter Techniken in ihren Produkten zu sorgen.

Zum besseren Verständnis der Richtlinien gibt es nun unmittelbar erreichbare Links auf das Dokument »Understanding WCAG 2.0«. Dort wird die Intention der jeweiligen Richtlinie beschrieben, eventuell verwendete Fachbegriffe werden erklärt und es werden zusätzliche Techniken zur Erfüllung aber auch gängige Fehler aufgelistet.

Ein häufiger Kritikpunkt an der Last-Call-Version waren die vielen Neuschöpfungen, mit denen die Arbeitsgruppe bestimmte Sachverhalte klar definieren wollte, die aber kaum jemand verstanden hat, oder die sogar erheblich von anderen, gebräuchlicheren Definitionen abwichen. Nun wird die Bedeutung von Wortungetümern wie »Programmatically Determined« bereits in der Richtlinie erklärt, für andere unverständliche Phrasen wie »Delivery Unit« wurden bessere Ersetzungen gefunden.

Begründungen für diese und alle anderen Änderungen sind in dem Text »Summary of Changes Since the 2006 WCAG 2.0 Last Call Working Draft« auf den Seiten der WAI zu finden.

Was ist nicht neu?

Gleich geblieben ist die Struktur der Richtlinien. Die vier Prinzipien sind nach wie vor:

Wahrnehmbar, Bedienbar, Verständlich und Robust.

Unterhalb dieser 4 Prinzipien gibt es insgesamt 12 Richtlinien, die aus einer Anzahl von Erfolgskriterien bestehen, mit denen die Richtlinien und Prinzipien erfüllt werden können. Diese Erfolgskriterien sind der für Webentwickler eigentlich interessante Kern des Ganzen. Hier wird beschrieben, welche Eigenschaften ein Angebot haben muss, um die jeweilige Richtlinie zu erfüllen. Wie dies inhaltlich, gestalterisch oder technisch zu erreichen ist, wird dann in weiteren Dokumenten, den so-genannten Techniques beschrieben. Aus der Summe der erreichten Erfolgskriterien ergibt sich dann am Schluss die bereits bekannte Abstufung in WCAG Level A, AA und AAA.

Dabei fehlt auch hier nicht der deutliche Hinweis, dass ein Erreichen von Level AAA nicht automatisch die absolute Barrierefreiheit bedeutet und dass eine Nicht-Erfüllung bei sämtlichen Erfolgskriterien Barrieren für manche Nutzergruppen darstellen kann, unabhängig davon, ob das Kriterium nun bei A, AA oder AAA angesiedelt ist.

Offene Baustellen

Wie eingangs erwähnt bestehen gerade bei Menschen mit kognitiven Behinderungen erhebliche Vorbehalte gegen die Richtlinien in ihrer jetzigen Form. Die WAI-Arbeitsgruppe erkennt ihre Defizite in diesem Bereich und kündigt weitere Nachforschungen an, um diese Lücken zu schließen:

»Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.«

Übersetzt heisst dies:

»Obwohl einige der Barrieren angesprochen werden, die Menschen mit kognitiven, Sprach- und Lernbehinderungen betreffen, sei es direkt oder durch assistive Techniken, so gehen die WCAG 2.0 doch nicht auf viele Bedürfnisse von Menschen mit diesen Behinderungen ein. Es gibt Bedarf an mehr Forschung und Entwicklung in diesem wichtigen Bereich.«

Die WAI-Arbeitsgruppe steht vor einem Problem: viele Barrieren in der Web-Nutzung sind zwar für die Betroffenen deutlich und gravierend, aber individuelle Barrieren lassen sich oft nicht einfach in eine Richtlinie integrieren.

Eine ganze Reihe von Erfolgskriterien der WCAG 2.0 stehen ebenfalls noch in der Diskussion. Diese sind in den Richtlinien an der nachgestellten »Editorial Note« zu erkennen. Bei einigen sind bereits mögliche Lösungen beschrieben. Diese sind noch nicht endgültig, einige der Anforderungen könnten also durchaus noch rausgestrichen werden.

Die nächsten Schritte

Die WAI-Arbeitsgruppe bittet interessierte Fachleute, die Dokumente zu lesen und eventuelle Anmerkungen bis zum 29. Juni einzureichen. Eine Liste der Dokumente, die zur Diskussion stehen finden Sie auf den Seiten der Web Accessibility Initiative beim W3C. Besonders interessant sind die Fragen:

• Sind die Richtlinien und die Erfolgskriterien klar und verständlich? Falls nicht, wie könnte man es besser formulieren?
• Gibt es Erfolgskriterien, die nicht umsetzbar oder nicht testbar sind? Wenn ja, wie könnten sie verbessert werden?
• Gibt es Erfolgskriterien, mit denen die Zugänglichkeit eines Angebotes nicht verbessert wird, oder die sogar neue Barrieren errichten? Auch hier wieder die Bitte der Arbeitsgruppe um Verbesserungsvorschläge.

Der einfacheren Verarbeitung halber sollten Kommentare über die bereitgestellten Formulare gemacht werden.

Das war die einundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags WCAG, und BITV. Bis zum nächsten Mal.