Web Content Accessibility Guidelines umsetzen

WCAG 2.0 verstehen
Kommentare

Die WCAG 2.0 sind für Webentwickler, Screendesigner und Onlineredakteure sowie für Gesetzgeber relevant, aber auch Projektleiter und Entscheider profitieren vom Grundlagenwissen dieses im Dezember 2008 veröffentlichten Webstandards. Im Zuge europäischer Entwicklungen sowie der bevorstehenden Veröffentlichung als ISO-Norm wird ihre Bedeutung in den kommenden Jahren zunehmen. Dieser Beitrag gibt eine Einführung in das Konzept der WCAG 2.0, ihrer Bedeutung im Kontext von Ausschreibungen und erläutert das Zusammenspiel der verschiedenen WCAG-2.0-Teildokumente.

Die Web Content Accessibility Guidelines 2.0 (WCAG 2.0) bilden zusammen mit den Authoring Tools Accessibility Guidelines (ATAG) und den User Agent Accessibility Guidelines (UAAG) sozusagen das Dreigestirn der Standards zur Barrierefreiheit. Dabei sind die UAAG unter anderem an Browser- und Screenreader-Hersteller gerichtet, während die ATAG und die WCAG das Thema „Webinhalte“ aus zwei Perspektiven angehen [1]:

  • Die ATAG zeigen, wie Autorenwerkzeuge, z. B. Content-Management-Systeme, standardkonform und barrierefrei erstellt werden und richten sich damit an Backend-Entwickler [2].
  • Die WCAG 2.0 sind der Webstandard für barrierefreie Webinhalte und umfassen alle Dateien und Dokumente, die Nutzer auf einem Webangebot finden (können) [3].
Aufbau der WCAG 2.0

Richtlinien gehörten zugegebenermaßen noch nie zu den prickelndsten und erbaulichsten aller Themen – selbst dann nicht, wenn ihnen zwei Songs gewidmet sind [4]. Sie erzeugen im harmlosesten Fall Gähnen, werden oft als (unnötig) formalistisch und Hemmschuh oder als papier- oder besser: dateigewordene Spaßverderber angesehen. Haben sie – wie die WCAG 2.0 – dann noch einen stattlichen, gedruckten Umfang von mehreren hundert Seiten, mit einer leider nicht sehr eingängigen Sprache, winken viele schnell ab. Dennoch: Die WCAG 2.0 werden die Webentwicklung der nächsten Jahre begleiten und stehen kurz vor ihrer Anerkennung als ISO/IEC DIS 40500 [5]. Auch im Kontext EU-weiter Ausschreibungen werden sie aufgrund der Arbeit des Mandats 376 an Bedeutung gewinnen [6].

Normativ und informativ – Was ist der Standard?

Die WCAG 2.0 sind in normative und informative Teildokumente aufgeteilt, von denen nur die normativen Dokumente zum eigentlichen Standard gehören. Normativ sind:

  • Prinzipien
  • Richtlinien
  • Erfolgskriterien
  • Glossar
  • Konformitätsbedingungen

Diese Dokumente sind zwar nicht in Stein gemeißelt, aber zumindest bis zu einer neuen Version unveränderlich und normativ. Zwar erfahren die WCAG 2.0 durch die zuständige Arbeitsgruppe des W3C jährliche Updates, davon sind jedoch nur die informativen Dokumente betroffen. Zu ihnen gehören Erklärungen zum Verstehen der Richtlinien und Erfolgskriterien sowie das umfangreiche Technikendokument. Das letzte Update wurde im Dezember 2011 veröffentlicht und enthielt unter anderem Techniken für barrierefreie PDFs sowie überarbeitete und ergänzende Erläuterungen zum Charakter der Techniken.

Verfolgt man die Arbeit der zuständigen Arbeitsgruppe, z. B. über die öffentlich einsehbaren Mailinglistenarchive des W3C, dann dürfen wir uns zum nächsten Update wahrscheinlich über HTML5-Techniken, weitere ARIA-Techniken sowie überarbeitete und neue Techniken für die Barrierefreiheit von PDF freuen. Übrigens ist die Arbeit an den informativen Dokumenten der WCAG 2.0 keine Aufgabe einer geschlossenen Gesellschaft. Fragen, Vorschläge oder auch notwendige Korrekturen können als Public Comments von jedem gestellt, eingereicht und verfolgt werden [7].

Prinzipien, Erfolgskriterien und Konformitätsstufen

Perceivable, Operable, Understandable und Robust (POUR) sind die vier Prinzipien, auf denen die WCAG 2.0 aufsetzt. Zu Deutsch: Wahrnehmbar, bedienbar, verständlich und robust, was in unserer Sprache leider weder ein attraktives noch leicht merkbares Akronym abgibt. Jedem Prinzip sind Richtlinien (Guidelines) zugeordnet, und diesen wiederum Erfolgskriterien, die zu einer der drei Konformitätsstufen A, AA, AAA gehören.

Der Aufbau der Konformitätsstufen zeigt, dass Barrierefreiheit ein Prozess ist: Mit jeder Stufe steigen die Anforderungen und zugleich profitieren mehr Nutzer, was letztlich auch zu einer größeren Reichweite des Webangebots führt. Auf Konformitätsstufe A stehen vor allem Aspekte der Barrierefreiheit, bei denen sich Nutzer nicht selber helfen können. Zwei Beispiele:

  • Werden Alternativtexte für (verlinkte) Grafiken nicht oder falsch verwendet (EK 1.1.1), dann können blinde Nutzer bzw. Hilfsmittel wie Screenreader diese Barrieren nicht selber kompensieren. Zu diesen Barrieren gehören nicht nur grafische Links sondern auch die berühmt-berüchtigten CAPTCHAs – zumindest sofern keine Alternativen in Form von Audio-CAPTCHAs oder einfachen Rechen-CAPTCHAs vorhanden sind.
  • Haben Videos keine Untertitel (EK 1.2.2) bzw. Audiodeskriptionen oder mindestens Alternativen (EK 1.2.3), dann sind gehörlose und schwerhörige bzw. blinde Menschen außen vor und können sich die Informationen nicht mehr selbständig und ohne fremde Hilfe erschließen.

Auch die Tastaturbedienbarkeit (EK 2.1.1) muss bereits auf der niedrigsten Konformitätsstufe A problemlos funktionieren. Einzige Ausnahme ist, „wenn die zugrunde liegende Funktion Eingaben verlangt, die vom Pfad der Bewegung des Benutzers und nicht nur von den Endpunkten abhängig sind.“ [7]. Gleichfalls auf Stufe A muss gewährleistet sein, dass sehende und blinde Tastaturbenutzer nicht vor einer Tastaturfalle stehen (EK 2.1.2). Tastaturfallen gehören zusammen mit Audio-Steuerelement (EK 1.4.2), Grenzwert von dreimaligem Blinken (EK 2.3.1) oder weniger und Pausieren, Beenden, Ausblenden (EK 2.2.2) nicht nur zu Erfolgskriterien der Stufe A sondern außerdem sozusagen zu den K.O.-Kriterien. Selbst wenn eine Webseite jedes andere Erfolgskriterium jeder anderen Stufe erfüllt hätte: Bei einer Tastaturfalle wäre sie nach WCAG 2.0 zu keiner Stufe konform. Auf Konformitätsstufe AA folgen u. a. Erfolgskriterien wie:

  • Sichtbarer Fokus beim Durchtabben einer Seite (EK 2.4.7)
  • Mindestwerte für Kontrastverhältnisse (EK 1.4.3)

Dies vermittelt den Eindruck, als seien Belange sehender Tastaturbenutzer oder sehbehinderter Menschen nach WCAG 2.0 weniger relevant. Schaut man sich diese Aspekte der Barrierefreiheit im Kontext möglicher Browsereinstellungen an, dann wird klar, dass Nutzer nicht „völlig ausgeliefert“ sind, sondern – sei es über Browsereinstellungen, eigene Style Sheets bzw. in Browsererweiterungen gegossene Userstyles und Userscripts – Einfluss nehmen können.

Ist Konformitätsstufe A ausreichend?

Nach WCAG 2.0 können Anbieter – sofern natürlich gesetzlich oder vertraglich keine anderen Bedingungen bestehen – die Konformitätsstufe selber festlegen. Dennoch: Lassen Sie es nicht bei Stufe A bewenden! Sofern Nutzer nicht aus Spaß oder zur Übung eigene Styles oder Scripts für Webseiten oder gar ganze Websites schreiben, sondern Userstyles und -scripts, Browser- oder Systemeinstellungen verwenden müssen, reden wir über einen notwendigen Einsatz assistiver Techniken. Diese assistiven Techniken, z. B. der Einsatz eines Stils für den sichtbaren Fokus, führen zwangsläufig dazu, dass auf Original-Layouts verzichtet werden muss und die User Experience eine andere ist bzw. der Zugang zu den Inhalten nicht mehr gleichwertig ist.

Gerade für Anbieter sollte es interessant sein, die Webseiten möglichst vielen Menschen und auf möglichst gleichwertige Art und Weise zur Verfügung zu stellen. Nebenbei profitieren von einem sichtbaren Fokus alle Tastaturbenutzer und von deutlichen Kontrastverhältnissen nicht nur Menschen mit Sehschwächen, sondern und abhängig von den Lichtverhältnissen auch Nutzer mobiler Endgeräte.

Die Eingangsfrage lässt sich also so beantworten: Das Setzen auf Konformitätsstufe A ist nach WCAG 2.0 zwar möglich, sollte jedoch nicht als ausreichend angesehen werden. Mithin setzen die Länder, die die WCAG 2.0 in nationale Gesetzgebungen übernommen haben, auf Konformitätsstufe AA und auch in den Dokumententwürfen des Mandats 376 für Ausschreibungen im ICT-Bereich wurde Stufe AA als Maßstab festgelegt.

Konformitätsstufe AAA – ein unerreichbares Ideal?!

Aspekte der Barrierefreiheit der Konformitätsstufe AAA werden oft als „(nicht erreichbares) Ideal“ bezeichnet; andere wiederum können leicht realisiert werden. Zu den komplexesten und in der Umsetzung schwierigsten Aspekten gehört die Verständlichkeit von Texten. Sie macht beim Auflösen von Abkürzungen (EK 3.1.4) und dem Verzichten auf oder Erläutern von ungewöhnlichen Wörter (EK 3.1.3) noch nicht halt. Je mehr Autoren beteiligt sind, desto mehr Personen müssen sich von manch liebgewordener Schreibweise trennen. In unserer kompositafreudigen Sprache betrifft dies lange Begriffe und Wörter, die von Schopenhauer als Wortdreimaster und von Mark Twain als „Prozessionen aller Buchstaben des Alphabets“ bezeichnet wurden. Nun hatten beide den Vorteil, dass sie die Wörter oder Begriffe zumindest verstanden. Für Menschen mit Lernschwierigkeiten hingegen ist eine komplizierte Sprache sozusagen eine Art Fremdsprache, und wer sich jemals mit dem Amtsdeutsch beschäftigt hat, wird, was diese Textsorte angeht, hier einstimmen können.

Viele weitere Aspekte der Verständlichkeit von Texten nach WCAG 2.0 spielen nicht nur im Web eine Rolle, sondern gehören zum Repertoire der so genannten „Kontrollierten Sprache“ in der Technischen Dokumentation und allgemein zu Empfehlungen für verständlichere Texte.

Wann sind die Konformitätsstufen erfüllt?

Im Unterschied zur deutschen Barrierefreien Informationstechnik 2.0 (BITV 2.0) geben die WCAG 2.0 in Konformitätsbedingung 1 klare Vorgaben, wann eine Konformitätsstufe (Conformance Level) erfüllt ist:

  • Eine Webseite hat Konformitätsstufe A erreicht, wenn alle Erfolgskriterien dieser Stufe vollständig erfüllt sind oder eine konforme alternative Version zur Verfügung steht.
  • Eine Webseite hat Konformitätsstufe AA erreicht, wenn alle Erfolgskriterien der Stufen A und AA vollständig erfüllt sind oder eine konforme alternative Version zur steht.
  • Eine Webseite hat Konformitätsstufe AAA erreicht, wenn alle Erfolgskriterien der Stufen A, AA, AA vollständig erfüllt sind oder eine konforme alternative Version zur steht.

Die WCAG 2.0 folgen also dem Prinzip „ein bisschen schwanger gibt es nicht“, wobei sich klar auf Einzelseiten bezogen wird. Die konforme, alternative Version sieht auf den ersten Blick wie ein Schlupfloch aus. Gemeint ist hier jedoch nicht eine schnöde Textversion für eine gesamte Website – auch dann nicht, wenn sie als so genannte „barrierefreie Version“ daherkommt. Alternative Versionen sind u. a. für folgende und durchaus realistische Szenarien gedacht:

  • Historische Dokumente, z. B. Briefwechsel: Eine akzeptable, alternative Version wäre eine ergänzende Fassung dieser zumeist grafisch vorhandenen Dokumente als Text.
  • Diagramme: Sie visualisieren komplexe Daten und machen diese verständlicher; eine alternative Version für blinde Nutzer wäre eine zusätzliche Aufbereitung der Daten in Form einer Datentabelle, die auf einer separaten Seite oder der gleichen Seite zur Verfügung gestellt wird.

Neben weiteren Aspekten wie gleiche Informationen und Funktionen müssen alternative Versionen selber die Erfolgskriterien der gewählten Konformitätsstufe erfüllen. Wären die Texte einer alternativen Version nicht kontrastreich genug, dann könnte noch Konformitätsstufe A erfüllt sein, aber nicht mehr AA. Wäre der Aufbau der Datentabelle nicht standardkonform, dann wäre Erfolgskriterium 1.3.1 nicht erfüllt und damit Konformitätsstufe A ebenfalls nicht vollständig.

Dass Techniken so eingesetzt werden sollen, dass sie nicht stören, versteht sich von selber. Und: Wer hat sich nicht schon über automatisch ablaufende Musik oder Videos geärgert? Für blinde Nutzer sind solche „Spielereien“ nicht nur ärgerlich, sondern stören die Sprachausgabe und das Lesen der eigentlichen Inhalte.

Nun geben die WCAG 2.0 nur Evaluierungskriterien für Webseiten und Prozesse vor. Bei einzelnen Webseiten muss jedes Erfolgskriterium der gewählten Konformitätsstufe erfüllt sein und bei Prozessen (z. B. Bestellungen in Online Shops) jedes Erfolgskriterium der gewählten Konformitätsstufe auf jeder Seite, die Teil des Prozesses ist. Was aber bedeutet das für die formale Attestierung der Barrierefreiheit von Websites, und welche Konsequenzen lassen sich generell für eine WCAG-2.0-Testmethode ableiten? Mit dieser Frage beschäftigt sich die „Evaluation and Methodology Task Force“, einer Untergruppe der WCAG Working Group. Die knapp 30 Experten diskutieren und erarbeiten seit August 2011 die WCAG Evaluation Methodology (WCAG-EM), eine Methode für das Prüfen von Barrierefreiheit nach WCAG 2.0.

Die Techniken – ein Quell von Missverständnissen

Für Entwickler ist oft vor allem das Technikendokument interessant, denn es enthält konkrete Umsetzungsbeispiele sowie typische Fehler. Techniken, die als ausreichend (sufficient) deklariert sind, zeigen wie die Erfolgskriterien sicher erfüllt werden können. Dabei liegt die Betonung auf „können“, denn diese Techniken sind optional. Theoretisch muss keine der gelisteten Techniken verwendet werden und die Webseite kann trotzdem WCAG-2.0-konform sein. Als Entwickler oder als Redakteur (beispielsweise, wenn es um Textverständlichkeit geht) können Sie eigene Techniken verwenden, neue entwickeln oder (noch) nicht dokumentierte Techniken einsetzen. Letztlich kommt es darauf an, ob die entsprechenden Erfolgskriterien erfüllt sind oder nicht. Vor allem bei eigenen und neuen Techniken ist selbstverständlich unerlässlich, diese mit typischen Hilfsmitteln und „echten“ Nutzern zu prüfen.

Natürlich kann man sich fragen, wie denn sonst als über das H-Element Überschriften in HTML ausgezeichnet werden sollten. Dies macht jedoch umgekehrt die Techniken nicht zum Pflichtprogramm. Sie können also durchaus (noch) nicht dokumentierte HTML5-Techniken, CSS3-Techniken oder JavaScript-Techniken verwenden – sofern diese mit assistiven Technologien und Techniken und damit für Menschen mit Behinderungen funktionieren. Auch PDF-Techniken des PDF/UA-Standards können verwendet werden, ohne damit im Widerspruch zu den WCAG 2.0 zu stehen – selbst dann, wenn diese im Widerspruch stehen würden.

Es sind solche optionalen Wege die WCAG 2.0 zu erfüllen, die der WCAG 2.0 Working Group bekannt sind. Würden umgekehrt ausreichende Techniken als quasi-normativ oder gar normativ angesehen, dann würde man in Konsequenz nicht nur die Arbeit von Entwicklern, sondern generell Innovation behindern. Das würde natürlich auch bedeuten, dass derzeit keine HTML5-Techniken oder sprachenspezifische Techniken für verständliche Texte eingesetzt werden dürften.

Dennoch: Das Technikendokument bietet Anhaltspunkte und Lösungen und enthält neben Klassikern, wie dem korrekten Einsatz von HTML-Strukturelementen, CSS- und JavaScript-Techniken sowie PDF- und ARIA-Techniken. Wie so oft führen manchmal mehrere Wege zum Ziel und welche Techniken am sinnvollsten sind, kann vom spezifischen Webprojekt oder der spezifischen Webseite abhängen. Manchmal kommt man mit Kombinationen am besten zum Ziel, manchmal reicht eine.

[ header = WCAG 2.0 verstehen – Teil 2 ]

Ein einfaches Beispiel

Stellen Sie sich vor, Sie müssten sich bei umfangreichen Websites für das Lesen eines Artikels jedes Mal durch die Haupt- und Subnavigation tabben. Nicht nur, dass sich der Spaß in argen Grenzen hält: Es ist eine Barriere für jeden Tastaturbenutzer. Deswegen gibt es das Erfolgskriterium „Blöcke umgehen“ (EK 2.4.1), womit z. B. solche Navigationsbereiche gemeint sind. Optionale Techniken sind u. a.:

  • das Einsetzen von mindestens einem Sprunglink zum Inhalt
  • das Auszeichnen von Hauptinhaltsbereichen für Screenreader-Nutzer durch versteckte Überschriften
  • der Einsatz von ARIA-Landmarks
  • mehrere Sprunglinks zu den Hauptbereichen

Betrachten wir die Sprunglinktechnik näher, denn bei falschem Einsatz hat man sozusagen die Möglichkeit, gegen mehrere Erfolgskriterien zu verstoßen und umgekehrt natürlich diese zu erfüllen. Dass Sprunglink-Batterien zu allem und jedem noch so kleinen Seitenbereich wenig sinnvoll sind, leuchtet sofort ein und das verbietet schon die Usability. Ein Batterie von, sagen wir, 8 oder 10 Sprunglinks würde zudem selber zu einem Block werden, den der Nutzer umgehen können muss. Die Sprunglinktechnik korrespondiert nicht nur mit besagtem Erfolgskriterium, sondern auch mit dem sichtbaren Fokus. Sind es mehrere Sprunglinks, dann wird ein Listenelement nötig, das Information und Beziehungen verdeutlicht (EK 1.3.1). Sprunglinks können versteckt sein, müssen aber zumindest beim Antabben sichtbar sein und wie andere Inhalte auch, einen Mindestkontrast von 4,5:1 zum Hintergrund haben – zumindest bei der hier typischen normalen Schriftgröße. Ist dies nicht der Fall, dann sind Sprunglinks zwar vorhanden und die Blöcke können übersprungen werden, aber für Konformitätsstufe AA wäre das nicht ausreichend. Beziehen sich die Linktexte der Sprunglinks auf die sichtbare Position, z. B. ein Link mit dem Text „zum rechten Seiteninhalt“, dann wäre bereits Konformitätsstufe A nicht erfüllt (EK 1.3.3). Sprunglinks sind übrigens auch für Nutzer mobiler Endgeräte wichtig, z. B. wenn ein Smartphone-Nutzer auf die Seite zugreift. In diesem Fall wäre es natürlich positiv, wenn sie direkt sichtbar wären.

Sollen Sprunglinks oder auch andere Inhalte zwar von Screenreadern und damit von blinden Nutzern erfasst werden können, aber vor Sehenden versteckt werden, stehen mehrere Techniken zur Verfügung. Die schlechteste und ein immer noch häufiger Fehler ist die Verwendung von display:none oder visibility:hidden. Diese Angaben eignen sich nur, wenn Inhalte explizit auch vor Screenreadern versteckt werden sollen. Screenreader können zwar nicht viel CSS, verhalten sich aber hier standardkonform. Als Techniken eignen sich das Schieben der Inhalte aus dem Viewport oder die Clip-Technik. Beide sind beispielsweise in HTML5 Boilerplate enthalten und können wahlweise verwendet werden. Angesichts der Updatefreudigkeit mancher Browser sollte anhand von Testcases regelmäßig geprüft werden, ob sie noch funktionieren.

Verstehen, was man tut

Wichtiger als das Abarbeiten oder gar Abhaken von Techniken und Erfolgskriterien ist das Verstehen der Barrierefreiheit. Angesichts oft geringer Zeitspannen ist es mehr als verständlich, wenn auf bewährte und dokumentierte Techniken gesetzt wird. Wird aber nur auf das „Was?“ (Erfolgskriterium) und das „Wie?“ (Techniken) geschaut, versäumt man das „Warum?“ (Verstehen). Und: Nur, wenn das „Warum“ verstanden wurde, können vorhandene Techniken adäquat, erfolgreich und auch in anderen als den dokumentierten Kontexten eingesetzt werden.

Als Beispiel sei die Informationsvermittlung über mehrere Kanäle genannt: So greifen redaktionelle Angaben wie „Weitere Inhalte finden Sie rechts“ ebenso zu kurz wie „Aktualisierungen sind in Rot gekennzeichnet“. Screenreader werten Seiten linear aus, weswegen Informationen, die über Richtungsangaben gegeben werden, problematisch für blinde Nutzer sind. Aktualisierungshinweise, die nur über Farbe gegeben werden, sind für mehrere Gruppen problematisch:

  • Menschen mit Schwächen in der Farbwahrnehmung
  • Menschen, die im Web mit benutzerdefinierten Farbeinstellungen unterwegs sind
  • Blinde Nutzer

Erfolgskriterien müssen also verschiedene Bedingungen erfüllen. Jedes einzelne wird daher von einem Teildokument „Erfolgskriterium X verstehen“ begleitet, das sich im Gesamtdokument „WCAG 2.0 verstehen. Ein Leitfaden zum Verständnis und zur Implementierung der Richtlinien für barrierefreie Webinhalte 2.0“ befindet. Zudem enthalten diese Dokumente wichtige Informationen über Assistive Technologien und Arbeitsweisen von Menschen mit Behinderung im Web. Wird das „Warum?“ berücksichtigt, dann können außerdem eigene Techniken erfolgreicher entwickelt werden – angesichts der rasanten Webentwicklung und dem zwingenden „Hinterhinken“ von WCAG-2.0-Updates ein wichtiges Thema.

Die Senioren werden’s richten

Warum überhaupt Barrierefreiheit, geht’s da nicht um Randgruppen? Dieses Vorurteil ist sozusagen unkaputtbar. Zwar sind viele der derzeit immerhin ca. 10 Millionen Menschen mit einer Behinderung ältere Menschen und möglicherweise nicht im Web aktiv. Untersuchungen zeigen aber, dass gerade Menschen mit Behinderung sehr webaffin sind. Aufgrund des demografischen Wandels wird zudem die Zahl der älteren Nutzer generell steigen und gerade, aber nicht nur, Betreiber von Online Shops sollten sich darauf einstellen. Wer sind diese Senioren? Hier denkt man schnell an die, die bereits heute unter Begriffen wie „Silver Surfer“ zusammengefasst werden. In Wahrheit reden wir aber auch über uns. Wer möchte schon gerne in ein paar Jahren auf das Surferleben verzichten, sich ärgern oder für alles und jedes eigene Styles oder Scripts basteln. Bereits ab einem Alter von ca. 45 Jahren gilt: Je älter, desto Strg++. Schön, wenn dann bis zu einer Vergrößerung von 200 Prozent das Layout nicht zusammenbricht und noch alle Texte verfügbar sind, ohne dass sie von anderen Bereichen überlagert werden (EK 1.4.4).

Wenn Sie zu den 8 bis 10 Prozent der Männer mit Rot-Grün-Schwäche gehören, dann wissen Sie sicher bereits jetzt eine Informationsvermittlung nicht nur über Farbe zu schätzen – auch, wenn es nicht nur um den Klassiker „Drücken Sie den grünen Button, nicht den roten“ geht. Sollten Sie über 35 sein, dann fallen Ihnen vielleicht bereits jetzt erste Veränderungen in der Farbwahrnehmung auf.

Ausschreibungen und Verträge

Falls Sie denken: „Barrierefreiheit betrifft mich trotzdem nicht“, dann könnte die EU Sie mit den oben bereits erwähnten „European Accessibility Requirements for Public Procurement of Products and Services in the ICT Domain“ des Mandats 376 eines Besseren belehren.

Ein leider oft vernachlässigter Aspekt folgt nach dem Gewinn einer Ausschreibung: Das Verfassen von Verträgen. Weder als Entwickler oder Agentur noch als Auftraggeber sollten Sie Ihre jeweiligen Vertragspartner im Unklaren lassen. Nicht geeignet sind solche Formulierungen: „Das Webangebot/die Applikation soll barrierefrei sein“ oder „Wesentliche Aspekte der Barrierefreiheit müssen erfüllt sein“. Die vermeintliche Freiheit kann sich bei Beschwerden schnell ins Gegenteil verkehren. Hier sorgen klare Verträge dafür, dass alle Beteiligten wissen, was zu tun ist und deutlich ist, wer – sofern etwas nicht beachtet wurde – die Rechnung zahlt.

Unterschiede zwischen WCAG 2.0 und BITV 2.0

In Europa klafft eine Lücke zwischen Harmonisierungsbestrebungen der EU und nationalen Gesetzgebungen, denn nicht alle Länder der EU haben die WCAG 2.0 1:1 übernommen. Einen Sonderweg ist Deutschland mit der Barrierefreien Informationstechnik Verordnung 2.0 gegangen. Zu erwarten ist zudem, dass nicht alle Bundesländer die BITV 2.0 1:1 übernehmen werden und damit weitere Fragmentierungen entstehen. Die Folge: Barrierefreiheit bedeutet nicht überall das gleiche. Die BITV 2.0 wartet mit mehreren Unterschieden zu den WCAG 2.0 auf. Der deutlichste ist der Unterschied in der Bewertung des Charakters der Techniken. Nach WCAG 2.0 sind diese – wie oben dargestellt anwendbar und optional – nach BITV 2.0 jedoch „anzuwendende“ Techniken. In der Begründung zur BITV 2.0 heißt es: „Die anzuwendenden Techniken zur Umsetzung der WCAG 2.0 und entsprechend die Techniken zur Umsetzung der Anlage 1 zur BITV 2.0 sind in den „Techniques“ zur WCAG 2.0, einem veränderbaren Dokument, zusammengefasst.“ Hier wird die Zukunft weisen, welche Bedeutung diese Sichtweise für die Webentwicklung in Deutschland hat, denn immerhin befindet sich dieser Passus in der nicht-rechtsverbindlichen Begründung. Entwickeln Sie für die Privatwirtschaft, dann empfiehlt es sich, auf WCAG 2.0 und hier auf die Konformitätsstufe AA zu setzen und damit einen eigenen Beitrag zur Harmonisierung zu setzen.

Was ist mit PDF?

In Sachen PDF hat sich in den letzten Jahren einiges bewegt und wird sich weiter mit dem PDF/UA-Standard bewegen. Mit axesPDF gibt es zumindest für den Fall, dass das Dokument aus Word kommt, ein sehr erfolgversprechendes Tool und mit dem PDF Accessibility Checker ein Prüftwerkzeug, das deutlich besser als die integrierte Prüfung der Adobe Software ist.

Wann ist PDF ein Thema? – Eigentlich immer, denn so lange PDF nicht explizit und ausschließlich für den Druck gedacht ist, wissen Sie nicht, ob es nicht vielleicht doch im Web „landet“. Sobald ein PDF im Web ist, wird es Webcontent und somit Thema für die WCAG 2.0. In diesem Fall muss das PDF natürlich alle Erfolgskriterien der gewählten Stufe erfüllen. Für PDF-Techniken gilt selbstverständlich das Gleiche wie für alle Techniken: Sie sind optional und der PDF-UA-Standard wird weitere Techniken für barrierefreie PDF bieten.

Um nur einen Punkt herauszugreifen: Natürlich empfiehlt es sich in jedem Format auf eine logische Überschriftenstruktur zu achten. Weder die HTML-Spezifikation noch die WCAG 2.0 schreiben jedoch vor, dass es nur eine H1 geben dürfe. Nach PDF/UA dagegen darf die H1 nur einmal verwendet werden. Wenn eine Spezifikation sagt, verwende nur eine Überschrift und verschachtele die Elemente entsprechend der Spezifikation, dann wäre zwar EK 1.3.1 bei einem Dokument, das dem nicht folgt, erfüllt, aber nicht 4.1.1.

Ausblick

Barrierefreiheit ist Webstandard und Qualitätsmerkmal, kann nicht in Phase 2 ausgelagert werden und ist angesichts von weltweit mehr als 450 Mio. Menschen sowie einer alternden Gesellschaft kein Add-on. Wie Sie heute entwickeln, bestimmt wie Sie selber Webinhalte zukünftig vorfinden werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -