Navigation

Service-Menü

Sprachversionen

Suche



Inhalt

Infothek

Richtlinien
Konformität in den WCAG 2.0 und in der BITV 2.0

27.09.2011

Die BITV 2.0 ist nach ihrem Inkrafttreten in die Kritik geraten, da sie nicht die drei Konformitätsstufen der WCAG 2.0 übernommen hat und Teile der WCAG 2.0 nur in der Begründung der BITV enthalten sind. Ist die Kritik stichhaltig?

Richtlinien zur Barrierefreiheit wie die WCAG und die BITV haben das Ziel, die Zugänglichkeit von Webangeboten überprüfbar und damit messbar zu machen. Die festgestellte Konformität eines Angebotes bedeutet, dass es (zumindest weitgehend) den Anforderungen der jeweils zugrunde liegenden Richtlinien entspricht. Für die BITV leistet das der BITV-Test.

Drei Konformitätsstufen, zwei Prioritäten

Ein öfters genannter Kritikpunkt ist die Diskrepanz zwischen den drei Konformitätsstufen A, AA, und AAA der WCAG 2.0, und den lediglich zwei Prioritäten der BITV 2.0. Anbieter, welche die Konformitätsstufe A der WCAG umsetzen und dies mit einen Konformitätstest belegen wollen, finden in der deutschen Gesetzgebung keine Entsprechung. Denn bei der BITV ist die Priorität 1 verbindlich, also die Stufen A und AA der WCAG zusammen genommen.

In einem Artikel zur BITV 2.0 von Kerstin Probiesch findet sich die Schlussfolgerung, dass die BITV aufgrund dieser Diskrepanz 'Barrierefreiheit als Prozess' nicht unterstütze. Der Gedanke ist wohl, dass Organisationen sich häufiger um Barrierefreiheit bemühen würden, wenn sie ihre Webangebote schon auf WCAG Level A (oder einer gedachten Entsprechung der BITV) prüfen und besiegeln lassen könnten, und dass der einmal beschrittene Weg dann auch eher zur Umsetzung von Level AA führen würde.

Natürlich ist aber auch der gegenteilige Effekt denkbar: Ein Siegel, welches Barrierefreiheit auf Level A bezeugt, würde den Anschein erwecken, das Angebot sei in allen wesentlichen Punkten nachweislich barrierefrei, man habe also genug getan.

In der Begründung versteckte Anforderungen

Eine weitere Kritik an der BITV 2.0 ist, dass die Konformitätsanforderungen, die in den WCAG 2.0 Teil der normativen Recommendation sind, nicht in die Verordnung selbst, sondern nur in die nicht rechtsverbindliche Begründung der Verordnung aufgenommen wurden. So steht im Webkrauts-Artikel von Jan Hellbusch zur BITV 2.0, in der Begründung wären zentrale Anforderungen enthalten, ohne die die Konformität von Webangeboten überhaupt nicht mehr prüfbar sei. Konkret: In der Konformitätsanforderung 5 würde der Gedanke des 'Progressive Enhancement' postuliert, der aus dem Verordnungstext selbst nicht abzuleiten sei.

Fordern die WCAG 2.0 denn 'Progressive Enhancement'?

Die Anforderung 5 (Nicht störend) sagt lediglich, dass das An- oder Abschalten von Techniken, auf die man sich nicht verlässt (etwa ein interaktives Element, dass über einen Browser-Plugin eingebunden ist) nicht andere Inhalte der Seite beeinträchtigen dürfen, auf die man sich zur Erreichung der Konformität verlässt. Das WCAG-Dokument Understanding Conformance erläutert, was gemeint ist, in Understanding Requirement 5. Ein nicht zugängliches Element darf zum Beispiel keine Tastaturfalle schaffen, die den Zugang zu Inhalten unterhalb dieses Elements versperrt.

Wenn man sich aber zum Erreichen der Konformität auf Barrierefreiheit unterstützende Technologien wie JavaScript verlässt, etwa in skriptgenerierten Dialogen oder Lightboxen, so ist diese Situation nicht von Anforderung 5 betroffen, denn diese zielt nur das An- und Abschalten von Techniken, auf die man sich nicht verlässt (für die es also, auf der Seite selbst oder direkt verlinkt, eine zugängliche alternative Version nach Konformitätsanforderung 1 gibt). Ein Gebot des Progressive Enhancement geht aus der Anforderung 5 deshalb nicht hervor.

Sind Anforderungen in der Begründung der BITV rechtsverbindlich?

Haben denn die Aussagen zu Konformitätsanforderungen, Alternativversionen und Barrierefreiheit unterstützenden Technogien, die sich in der Begründung der BITV 2.0 finden, einen rechtsverbindlichen Charakter?

Streng genommen nein. Der knappe und technologieneutrale Verordnungstext verlangt jedoch nach Auslegung und Interpretation, etwa in der Ausgestaltung von konkreten Prüfverfahren wie dem BITV-Test. Und hier ist die Begründung der Verordnung die erste Anlaufstelle, wenn es darum geht, die Verordnung zu interpretieren: etwa, wenn es um Alternativversionen geht oder um die Frage, ob die in einem Angebot eingesetzten Technologien bereits hinreichend die Barrierefreiheit unterstützen.

Noch ist die Begründung der BITV 2.0 nicht veröffentlicht worden. Dies wäre ein wichtiger Schritt, gerade um die Nähe der Verordnung zu den WCAG 2.0 zu verdeutlichen.

Konformität in den WCAG und der BITV

In den WCAG 1 waren die drei Prioritäten A, AA, AAA noch als Muss-, Soll-, und Kann-Anforderungen definiert. In den WCAG 2.0 bezeichnen diese Level einfach verschieden anspruchsvolle Konformitätsstufen. Ein Angebot, dass auf Stufe A konform sein will, muss alle A-Level Anforderungen (und nicht mehr) erfüllen; wenn Konformität auf Stufe AA erreicht werden soll, müssen alle A- und AA-Level Anforderungen erfüllt werden, und so weiter.

Der Abschnitt Konformität der WCAG 2.0 findet sich nicht im Verordnungstext der BITV 2.0 wieder, sondern ist in die (noch nicht veröffentlichte) Begründung verschoben worden. Wir betrachten im Folgenden die einzelnen Anforderungen an Konformität (Conformance requirements), um das Ausmaß der Unterschiede zwischen WCAG und BITV genauer zu ermitteln.

Anforderung 1: Konformitätsstufen (Conformance level)

Die Begründung der BITV 2.0 stellt klar, dass die in Anlage 1 geforderte Priorität 1 den Konformitätsstufen A und AA der WCAG entsprechen, und die der Priorität 2 der Konformitätsstufe AAA der WCAG.

Wo bleibt 'Single A'?

Damit ist klar, dass nach der BITV eine Entsprechung zur Konformitätsstufe A der WCAG 2.0 nicht vorgesehen ist. Ein wichtiger Grund: Die neue BITV 2.0 sollte keinen Rückschritt gegenüber den bislang verbindlichen Anforderungen der BITV ermöglichen.

Sicher wäre es ebenso möglich gewesen, die Konformitätsstufen A, AA und AAA als drei Prioritäten zu übernehmen und für die Bundesbehörden die beiden ersten verbindlich zu fordern. Vielleicht hat der Gesetzgeber befürchtet, durch eine Umgestaltung der Prioritäten bei den Bundesbehörden Verwirrung zu stiften. So ist nun Prio 1 weiterhin das, was alle Angebote erfüllen müssen, und Prio 2 das, was für "zentrale Navigations- und Einstiegsangebote" gilt, wie auch immer dieser Ausdruck konkret interpretiert wird.

'Single A' reicht nicht aus

Die Konformitätsstufen der WCAG passten also nicht recht zu den zwei Prioritäten der BITV. Man mag bedauern, dass demnach eine dem Level A der WCAG entsprechende Umsetzung für die BITV nicht prüfbar ist. Andererseits kann man argumentieren, dass auf der WCAG-Konformitätsebene A zentral wichtige Anforderungen besonders für Sehbehinderte fehlen oder erst durch alternative Ansichten oder Einstellungen kompensiert werden können. Dies Betrifft vor allem 1.4.3 Kontrast (Minimum), 1.4.4 Textgröße ändern und 2.4.7 Fokus sichtbar. Die Wichtigkeit dieser Anforderungen ist von Organisationen von Menschen mit Behinderungen immer wieder angemahnt worden.

Ein Webangebot, welches das WCAG Level AA Erfolgskriterium 2.4.7 "Fokus sichtbar" (BITV-Übersetzung: 2.4.7 "Sichtbarer Fokus") nicht erfüllt, widerspricht ganz elementaren Anforderungen von motorisch eingeschränkten und sehbehinderten Menschen. Es ist ohne alternative Einstellungen oder Hilfsmittel schlicht nicht tastaturnutzbar. Zum sichtbar Machen des Fokus bräuchte man etwa die Ansicht ohne CSS oder die Hilfe von Bookmarklets, die den Fokus unabhängig von der Seitengestaltung anzeigen. Viele, gerade ältere, Nutzer kennen oder finden solche Anpassungsmöglichkeiten jedoch nicht.

'Level AA' wird zur Minimalforderung in Europa

Der 'deutsche Sonderweg', in der BITV 2.0 ohne Rücksicht auf den niedrigsten Level A gleich das Äquivalent von WCAG Level AA vorzuschreiben, ist nicht gar so sonderbar, wenn man sich vergegenwärtigt, dass in anderen europäischen Ländern wie Frankreich, Italien oder der Schweiz ebenfalls WCAG Level AA gefordert wird. (Einen Überblick liefert eine Vergleichstabelle von Powermapper über nationale Barrierefreiheits-Standards.) Die Frage bleibt natürlich, inwieweit die BITV 2.0 als gleichwertige Umsetzung von WCAG 2.0 angesehen werden kann (siehe dazu auch den BIK-Artikel Ist die BITV 2.0 überflüssig?).

Die Bestimmungen zu Alternativversionen in WCAG und BITV

"Keine Alternativversionen" ist inzwischen eine allgemein akzeptierte Grundregel, sowohl als Forderung behinderter Menschen, die nicht möglicherweise zweitklassige oder veraltete Versionen vorgesetzt bekommen wollen, also auch als allgemeiner Grundsatz von Web-Designern und Entwicklern: das Angebot hält Inhalte nur einmal vor, kann sie aber für verschiedene Ausgabemedien verschieden darstellen.

Die WCAG 2.0 sehen in ihrer Beschreibung der drei Konformitätsstufen die Möglichkeit der Erfüllung der Konformitätsanforderungen durch 'conforming alternate versions' vor. Die konkreten Anforderungen machen das Erstellen nicht konformer Inhalte allerdings ziemlich unattraktiv, denn konforme Alternativversionen müssen dieselben Inhalte und Funktionen bieten und von gleicher Aktualität sein wie nicht konforme Inhalte. Doppelte Arbeit also.

Die BITV 2.0-Verordnung sagt zum Thema Alternativversionen nichts. Erst in der Begründung steht, dass "Sonderlösungen möglichst zu vermeiden und Alternativangebote für nicht den Standards der Anlage 1 entsprechende Inhalte grundsätzlich ausgeschlossen [sind]", wobei Styleswitcher-Anpassungen zum Beispiel von Kontrasten und Schriftgrößen nicht als Alternativversionen anzusehen sind. Die dazu gehörigen Definitionen wurden aus dem Glossar der Verordnung in den Text der Begründung übertragen.

Bei allen Angeboten, bei denen sich die Einbeziehung unzugänglicher Inhalte wirklich nicht vermeiden lässt, müsste man also zur Interpretation der Verordnung auf die Begründung der BITV zurückgreifen:

Ist die Erstellung eines barrierefreien Webangebots nach den technischen Standards der Anlage 1 für einzelne Teile nicht möglich, ist eine konforme Alternativversion auf gleicher Datenbasis zur Verfügung zu stellen, welche gleichwertige Funktionalitäten und Informationen von gleicher Aktualität enthält, soweit es die technischen Möglichkeiten zulassen. Bei der Verwendung nicht barrierefreier Technologien sind diese zu ersetzen, sobald auf Grund der technischen Entwicklung gleichwertige zugängliche Lösungen verfügbar und einsetzbar sind.

Im Text der Begründung werden in der Folge die gleichen Anforderungen an die Verknüpfung konformer Alternativversionen gestellt wie sie in den WCAG 2.0. Auch bei der Definition von "Barrierefreiheit unterstützend" für die Bewertung der tatsächlichen Zugänglichkeit insbesondere neuerer Web-Techniken bei der Nutzung von Hilfsmitteln greift die BITV 2.0 direkt auf das Glossar der WCAG 2.0 zurück.

Fazit: Die Informationen der BITV 2.0 zu Alternativversionen sind zwar in der Begründung versteckt (vielleicht, um Nutzer der Verordnung gar nicht erst auf falsche Gedanken zu bringen), entsprechen dabei aber inhaltlich den Anforderungen der WCAG 2.0.

Anforderung 2: Ganze Seiten (full pages)

Die Konformitätsanforderung 2 der WCAG verlangt, dass die gesamte Seite die Anforderungen auf der gewählten Konformitätsstufe erfüllen muss. Direkt erreichbare Alternativversionen für unzugängliche Teile einer Seite gelten dabei als Teil der Seite. Die Note 4 der normativen Definition von "Konforme Alternativversion"  betont dabei, dass jede Version so konform wie möglich sein sollte. Das impliziert, dass nicht konforme Inhalte nur dann akzeptabel sind, wenn sie nicht konform umsetzbar waren.

Dies entspricht dem (allerdings nur in der Begründung erklärten) Ansatz der BITV 2.0. Im neuen BITV-Test ist dies in Prüfschritt 2.4.8b "Zweck der Alternativversion einleuchtend" umgesetzt. Wenn sich ein Angebot (oder ein Teil davon) ebenso zugänglich umsetzen ließe, sind nicht zugängliche Umsetzungen mit Alternativversion nicht einleuchtend und können zur Abwertung des Ergebnisses führen.

Die praktische Umsetzung der Anforderung "Ganze Seiten" ist nicht einfach: Moderne Webangebote haben häufig Seiten mit einer Vielzahl dynamisch aufrufbarer Zustände, die mitgeprüft werden müssen. Im BITV-Test werden bei der Seitenauswahl durch Erkunden der Interaktionsmöglichkeiten relevante Zustände gefunden. Der Aufruf der einbezogenen Zustände soll nachvollziehbar dokumentiert werden, und gefundene Probleme und Barrieren müssen im Prüfbericht klar den entsprechenden Seitenzuständen zugeordnet werden.

Fazit: Die möglichst vollständige Erfassung von Seiten einschließlich dynamischer Zustände ist ein generelles Problem, mit dem jedes Prüfverfahren zu kämpfen hat, egal, ob es auf den WCAG 2.0 oder der BITV 2.0 basiert.

Anforderung 3: Komplette Prozesse (complete processes)

Hier wird verlangt, dass alle Webseiten oder Zustände, die zu einem vollständigen Prozess gehören, zugänglich sind. Da die BITV sich grundsätzlich auf das gesamte Webangebot bezieht, ist diese Bedingung eigentlich erfüllt. Schwieriger ist die Umsetzung in der praktischen Überprüfung der Barrierefreiheit, etwa im BITV-Test. Hier muss schon während der Seitenauswahl darauf geachtet werden, dass keine Barrieren in den Prozessschritten übersehen werden, selbst wenn nicht jede Einzelseite oder jeder Seitenzustand eines Prozesses in die Seitenauswahl einbezogen und damit zur Gänze geprüft wird.

Fazit: Die möglichst vollständige Erfassung von Prozessen ist ein generelles Problem, mit dem jedes Prüfverfahren zu kämpfen hat, egal, ob es auf den WCAG 2.0 oder der BITV 2.0 basiert.

Anforderung 4: Nur Barrierefreiheit unterstützende Technologien (only accessibility-supported ways of using technologies)

Dieser Teil der Konformitätsanforderungen der WCAG 2.0 verweist darauf, dass es auf das Ausmaß der Unterstützung von Webtechniken in verbreiteten User-Agenten und Hilfsmitteln ankommt, ob eine bestimmte Technik als 'die Barrierefreiheit unterstützend' angesehen werden kann und damit zum Nachweis der Konformität dienen kann. Für Inhalte, die sich auf nicht ausreichend unterstützte Techniken verlassen, wird die Bereitstelllung von zugänglichen Alternativen gefordert.

Die Begründung der BITV 2.0 übernimmt im Abschitt "Barrierefreiheit unterstützend" die Definition von "accessibility supported" aus dem Glossar der WCAG 2.0, ohne diesen Begriff selbst im Glossar der Verordnung aufzuführen. "Barrierefreiheit unterstützend" sind Technologien demnach nur dann, wenn

  • der Nachweis einer Unterstützung in Hilfsmitteln praktisch erbracht werden kann
  • die eingesetzten Web-Techniken von Benutzeragenten unterstützt werden (mit Unterpunkten zur Verbreitung von Benutzeragenten und Plugins, der Art der Umgebung, etwa Intranet, sowie die Auffindbarkeit und Kostenneutralität von Benutzeragenten)

Fazit: Hier gibt es, abgesehen von der Verlagerung dieser Teile in die Begründung, keine erkennbaren Abweichungen zwischen WCAG 2.0 und BITV 2.0.

Anforderung 5. Nicht störend (Non-Interference)

Die WCAG nennt eine Reihe von Bedingungen, die auch bei Vorhandensein nicht-zugänglicher Inhalte auf Seiten einzuhalten sind:

  • 1.4.2 (Audio-Kontrolle)
  • 2.1.2 (Keine Tastaturfalle)
  • 2.3.1 (Dreimaliges Aufblitzen – Unterschreiten der Schwellenwerte)
  • 2.2.2 (Anhalten, Beenden, Ausblenden)

Diese Erfolgskriterien finden sich als immer einzuhaltende Bedingungen vollständig in der Begründung der BITV wieder, allerdings nicht als Aufzählung, sondern in einzelnen Absätzen im Abschnitt "Zu den Anforderungen und Bedingungen der Anlage 1 im Einzelnen".

Fazit: Auch in diesem Punkt gibt es, abgesehen von der Verlagerung von Anforderungen aus der Verordnung in die Begründung, keine erkennbaren Abweichungen zwischen der BITV 2.0 und den WCAG 2.0.

Konformitätsbezeugungen (conformance claims)

Die WCAG 2.0 stellen optional noch verschiedene Möglichkeiten von Conformance Claims dar. Zu den fünf verpflichtenden Elementen eines jeden Claims gehören:

  • Datum
  • Bezug auf die Richtlinie (etwa WCAG 2.0 mit Adresse)
  • Konformitätsstufe: (Level A, AA oder AAA)
  • Beschreibung der Seitenauswahl (mit URIs) auf die sich der Claim bezieht
  • Eine Liste der Webtechnologien, auf die sich das Angebot verrlässt (etwa XHTML 1.0, CSS 2.0, ECMAScript 5)

Während die BITV 2.0 nichts zur Frage der Konformitätsbezeugungen sagt, lässt sich festhalten, dass der BITV-Test mit Ausnahme des letzten Punktes diesen Anforderungen entspricht. Statt die verwendeten Webtechnologien aufzulisten, wurden im BITV-Test Webangebote, die wesentlich auf bisher nicht vom Test erfassten Technologien (wie etwa Flash) aufsetzen, einfach nicht geprüft. Mit der Erweiterung des BITV-Tests auf andere Webtechnologien (zur Zeit ist die PDF-Säule in Entwicklung) kann sich diese Situation in Zukunft ändern.

Ergebnis 

Die Kritik an der BITV 2.0 ist teilweise berechtigt. So wäre es von Vorteil gewesen, wichtige Auslassungen zur Konformität, besonders zu Alternativversionen und zur Definition Barrierefreiheit unterstützender Technologien, in den gesetzlich bindenden Verordnungstext der BITV 2.0 zu integrieren. Betrachtet man die BITV 2.0 jedoch im Kontext ihrer Begründung, die im Zweifelsfall für ihre Interpretation ausschlaggebend ist, lässt sich feststellen, dass nur geringe Abweichungen zu den WCAG 2.0 festzustellen sind, besonders die Aufnahme der Bedingung 2.4.8 Standort, die in den WCAG 2.0 als 2.4.8 Position (BITV-Übersetzung: Standort) nur auf Level AAA gefordert wird (siehe auch den BIK-Artikel: Ist die BITV 2.0 überflüssig?).

Eine dreigliedrige Prioritätensetzung auch der BITV hätte den Vergleich mit den WCAG 2.0 sicher erleichtert. Da faktisch in vielen Ländern Europas und darüber hinaus der Level AA als Mindeststandard angesehen wird, ist das Fehlen einer Entsprechung von Level A in der BITV 2.0 praktisch vielleicht weniger bedeutend, als die Kritiker der neuen Verordnung meinen.

Ein Webangebot, dass die BITV 2.0 (Prio 1) erfüllt, erfüllt auch die WCAG 2.0 auf Level AA. Auch umgekehrt triffft das in der Regel zu, auch wenn es Fälle geben kann, in denen die BITV geringfügig "strenger" ist als die WCAG auf Level AA.