Die Web Content Accessibility Guidelines WCAG 2.0 sind seit 11. Dezember 2008 eine W3C Recommendation, also ein offizieller Standard des World Wide Web Consortiums (W3C) für die Erstellung barrierefreier Websites. Sie enthalten Empfehlungen, wie Websites auch für Menschen mit Behinderungen gut zugänglich gemacht werden können. Das W3C ist ein internationales Konsortium, das Internetstandards entwickelt (u.a. auch HTML, XML, CSS…). Die WCAG 2.0 ersetzen die bisher gültigen WCAG 1.0.

Akualisierung November 2009: Seit Oktober 2009 gibt es eine offizielle deutsche Übersetzung, die Richtlinien für barrierefreie Webinhalte (WCAG) 2.0.

Aufbau der WCAG 2.0

Die 12 Richtlinien (Guidelines) mit den zugehörigen 61 testbaren Erfolgskriterien (Success Criteria) sind normativ und technikunabhängig formuliert. Sie gelten also für W3C Spezifikationen wie HTML und CSS ebenso wie für patentgebundene, proprietäre Formate wie PDF, Flash, Silverlight, Video- und Audioformate, Java usw…

Die sehr ausführlichen Zusatzdokumente mit technischen Vorgaben (Sufficient Techniques), zusätzlichen Empfehlungen (Advisory Techniques) und Verständnis Hilfen (Understanding WCAG 2.0) sind nicht normativ, sondern können verändert und erweitert werden, um der technischen Entwicklung im Internet gerecht zu werden.

Die Reihung der Guidelines und zugehörigen Erfolgskriterien erfolgt bewußt nicht nach Konformitätslevels, sondern nach den 4 Prinzipien Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. D.h. alle Erfolgskriterien sind wichtig und sollten nach Möglichkeit eingehalten werden, nicht nur die der Konformitätsstufe A. Manche Erfolgskriterien der Konformitätsstufe AAA sind nicht für jedes Webangebot umsetzbar.

Eine Konformitätserklärung kann auf der Website stehen, ist aber nicht verpflichtend. Wenn sie angeführt wird, muss sie allerdings genaue Vorgaben erfüllen: Conformance to WCAG 2.0.

Gesetzliche Vorgaben in Österreich

Die WCAG 2.0 definieren sich als international gültige Empfehlung, sie sind keine Norm. In einzelnen Staaten gibt es landesspezifische Vorgaben (z.B. BITV in Deutschland), die aber grundsätzlich auf den WCAG beruhen. Im österreichischen E-Government Gesetz wird für Websites der öffentlichen Hand die Einhaltung der WCAG Stufe A zwingend vorgeschrieben, die Erfüllung weiterer Stufen soweit möglich wird angestrebt. Das österreichische Bundesbehindertengleichstellungsgesetz (BBGStG) impliziert die Einhaltung der WCAG Stufe AA. Websites, die in Österreich mit Hilfe öffentlicher Fördermittel erstellt werden, unterliegen dem BBGStG, sollten also möglichst WCAG 2.0 AA konform gestaltet werden.

Zusammenfassung

Dieses Dokument ist eine Einführung in die WCAG 2.0 für AuftraggeberInnen, WebentwicklerInnen, WebdesignerInnen und Contentzuständige.

Es ist eine frei übersetzte, stichwortartige Kurzfassung der Richtlinien und dazugehörigen Erfolgskriterien, gereiht nach Konformitätsstufen (A, AA, AAA), da in der Praxis doch ein Bedürfnis nach einer Übersicht laut den gesetzlich vorgegebenen Levels besteht.
Zusätzlich gibt es technische Hinweise für den Weballtag, um einen schnellen Überblick zu den gängigsten Anforderungen bekommen. Dies kann nützlich sein, weil die technischen Erläuterungen zu den WCAG noch nicht auf deutsch vorliegen.

Die Vorgaben betreffen nicht nur Design und Programmierung einer Website, sondern müssen auch bei der Erstellung von Inhalten in Content Management Systemen beachtet werden.

Diese Zusammenfassung beruht auf der Schnell Referenz (Quick Reference) How to Meet WCAG 2.0 vom Dezember 2008.

Übersetzung, Beispiele und Erläuterungen sind subjektiv und nicht vollständig. Exakte Referenz sind nur die Originaldokumente der WCAG 2.0 (englisch), akkordierte deutsche Übersetzung: Richtlinien für barrierefreie Webinhalte (WCAG) 2.0

Die Zusammenstellung wurde mit Mitteln des BMGFJ, Abt. II/5-Jugendpolitik unterstützt und österreichischen Jugendorganisationen zur Verfügung gestellt.

Weiter zu WCAG 2.0 A

WCAG 2.0 Erfolgskriterien – Konformitätsstufe A

Um für NutzerInnen mit Behinderung zugänglich zu sein, müssen Webinhalte für alle wahrnehmbar, bedienbar, verständlich und technisch robust sein.

Akualisierung November 2009: Seit Oktober 2009 gibt es eine offizielle deutsche Übersetzung, die Richtlinien für barrierefreie Webinhalte (WCAG) 2.0. Die folgende stichwortartige Auflistung von Erfolgskriterien ist aber nicht obsolet, weil sie für Nicht-Fachleute leichter verständlich ist als die Original-Richtlinien.

1 Wahrnehmbar

1.1 Textalternativen für Nicht-Text-Inhalte

• 1.1.1 gleichwertige Textalternativen für Nicht-Text-Inhalte

  Sinnvolle! alt Attribute für Bilder, Buttons, leeres alt Attribut für Dekografiken, eine Ersatzlösung für grafische Captchas, Kurzbeschreibung bei zeitbasierten Medien (Audio, Video, Flash…) innerhalb des object Elements, Langbeschreibung für Diagramme oder Charts, title für (i)frames, labels bei Formularelementen…

1.2 Alternativen für zeitbasierte Medien

sofern sie nicht nur eine Medienalternative zu Textinhalten sind und klar als solche markiert werden

• 1.2.1 Textalternative für voraufgezeichnete reine Audio- oder Videobeiträge ohne Sprache

  Transkription von Hörbeiträgen für Menschen mit Hörbehinderung, bei Video wäre statt der Textalternative für Blinde auch eine Beschreibung des visuellen Inhalts im Audiotrack möglich

• 1.2.2 Captions für voraufgezeichnete, synchronisierte Medien

  Untertitel mit Dialog, Sprecheridentifikation, wichtigen Geräuschen in vertonten Videos für Menschen mit Hörbehinderung

• 1.2.3 Textalternative oder Audio Beschreibung für voraufgezeichnete synchronisierte Medien

  Transkription oder Beschreibung des Videoinhaltes im Audiotrack für blinde Menschen

1.3 Inhalt kann auf verschiedene Weise dargestellt werden, ohne Inhalt oder Struktur zu verlieren

WebnutzerInnen können Websites individuell anpassen, z.B. ohne Farbe, ohne Bilder, vergrößert, mit Zoomsoftware, mit Braillezeile, am Handy lesen…

• 1.3.1 Information, Struktur und durch die Präsentation vermittelte Beziehungen können programmtechnisch bestimmt werden

  Sie sind maschinenlesbar, auch für blinde Menschen mit Screen Readern, oder sie sind als Text verfügbar

  Trennung von Struktur und Layout, Semantisches Markup – für Überschriften, Absätze, Listen, Datentabellen, Formulare…, korrektes DOM Scripting, um Inhalte per JavaScript dazuzufügen…, getaggte PDFs, Strukturinformationen in Flash…

• 1.3.2 Sinnvolle Reihenfolge

  Auch ohne grafische Ansicht, korrekte Tab Reihenfolge, lineare Lesbarkeit bei Layouttabellen, Vorsicht bei CSS position:absolute und JavaScript generierten Inhalten, keine fixen Leerzeichen ( ) zur Formatierung…

• 1.3.3 Sensorische Unabhängigkeit

  Bedienbarkeit und Verständnis hängen nicht von grafischer Oberfläche (von Form, Größe oder Positionierung von Komponenten) oder Sound ab

1.4 Inhalte sind gut sichtbar und hörbar, Vorder- und Hintergrund Information sind klar unterscheidbar

• 1.4.1 Farbunterschiede sind nicht allein bedeutungstragend

  z.B. bei Links zusätzliche visuelle Markierung, zusätzliches Muster bei Diagrammen, mehrfache Fehlermarkierung bei Formularen

• 1.4.2 Audio Kontrolle

  Automatisch abspielendes Audio (länger als 3 sec.) muss abschaltbar oder unabhängig von Systemlautstärke-Regelung steuerbar sein (damit Vorlesesoftware nicht gestört wird)

2 Bedienbar

2.1 Tastaturbedienbarkeit

• 2.1.1 Tastaturbedienbarkeit

  nicht nur mausabhängige JavaScript Eventhandler, kein Wegnehmen des Fokus durch JavaScript (z.B. onfocus=”blur())

• 2.1.2 Keine Tastaturfallen

  Gängige Exitmethoden bei Plug-Ins, aus eingebetteten Anwendungen muss man mit Pfeil-, Tab- oder Escapetaste wieder hinauskommen, keine Accesskeys, die bereits im Browser oder Screen Reader in Verwendung sind

2.2 Genügend Zeit, um Inhalte zu lesen oder zu hören

• 2.2.1 Zeitlimits können entweder abgeschalten werden oder (nach vorheriger Warnung) innerhalb von 20 sec. um den Faktor 10 verlängert werden

  außer das Zeitlimit ist absolut notwendig (Echtzeit Events wie Auktionen, zeitabhängige Tests)

• 2.2.2 Neben Textinhalten sich bewegende, blinkende, scrollende Inhalte, die automatisch starten und länger als 5 Sec. dauern, können unterbrochen, gestoppt oder versteckt werden.

  Auch Inhalte, die automatisch upgedatet werden (und automatisch starten, länger als 5 Sec. dauern und parallel zu anderen Inhalten präsentiert werden) können unterbrochen, gestoppt oder versteckt werden oder die Update Frequenz ist einstellbar.

2.3 Keine Photoepilepsie auslösend

• 2.3.1 Inhalte dürfen nicht öfter als 3x/sec flashen (sehr schnell, sehr hell aufleuchten)

  oder der Helligkeitsunterschied muss unterhalb definierter Schwellenwerte (general flash and red flash thresholds) bleiben

2.4 Navigierbarkeit (Inhalte sind gut navigierbar, auffindbar, Standort ist klar)

• 2.4.1 Sich wiederholende Inhaltsblöcke (z.B. Menüs) lassen sich überspringen

  Menüs als Liste, Skiplinks, grafisch versteckte Überschriften vor Menüs

• 2.4.2 Eindeutiger Seitentitel für jede Seite

• 2.4.3 Logische, bedienbare Fokus Reihenfolge

  z.B. bei Links, Formularelementen, dynamischer Einbindung oder Änderung von Content; tabindex nur setzen, wenn wirklich notwendig

• 2.4.4 Zweck von Links im Kontext: selbsterklärende oder zumindestens im unmittelbaren Kontext verständliche Links

  Linkziel im alt Attribut bei verlinkten Bildern, Vermeiden von “Klicken Sie hier”, “Mehr”, “Download”…, erlaubt sind sich wiederholende, gleichlautende, nicht selbsterklärende Links unterhalb von unterscheidenden Überschriften, Tableheadern oder innerhalb von untergeordneten Listen, im gleichen Satz oder Absatz.

3 Verständlich

3.1 Textinhalt ist lesbar und verständlich

• 3.1.1 Sprachangabe der Seite

  Richtiges Sprachattribut im HTML Element – lang, xml:lang

3.2 Websites verhalten sich vorhersehbar

• 3.2.1 Seiteninhalt ändert sich nicht, wenn ein Element Fokus erhält

  keine automatischen Popups beim Laden der Seite, eher activate als focus als Formulartrigger

• 3.2.2 Userkontrolle bei Input

  Keine automatische Änderung von Formularen beim Anklicken eines Radio Buttons oder einer Checkbox, keine automatische Formularversendung ohne Klick auf Submitbutton oder vorherige Information, ohne Vorwarnung mit onchange Eventhandler in Selectboxen

3.3 Hilfen, um Fehler zu vermeiden und zu korrigieren

• 3.3.1 Inputfehler werden in Textform erklärt

  z.b. ein nicht ausgefülltes Pflichtfeld in einem Formular

• 3.3.2 Labels oder Instruktionen

  z.B. Formularelement label, title, wenn label nicht möglich ist, Beispiel für erwartetes Datenformat, fieldset, legend…

4 Technisch robust

4.1 Kompatibilität mit derzeitigen und zukünftigen User Agents inklusive Assistive Technologien

• 4.1.1 Parsing: Markup wird korrekt verwendet

  Elemente mit vorgeschriebenen Endtags, richtig verschachtelt, eindeutige IDs, d.h. weitgehend valider Code, manche Validierungsfehler, z.B. nicht maskierte Sonderzeichen, sind tolerierbar

• 4.1.2 Name, Rolle und Wert von Elementen, Änderungen von Zuständen, Eigenschaften, Werten sind maschinenlesbar

  Sie müssen auch mit assistiven Technologien ausgelesen werden können
  Bei Entwicklung eigener User Interface Controls; standardgemäß verwendete HTML Kontrollelemente erfüllen das von vornherein, korrekte DOM Funktionen, um Inhalte hinzuzufügen, WAI-ARIA, um Zusatzinformationen für Screen Reader zu geben für Widgets (Slider, Treenavigation etc…) oder bei Seitenänderungen via Ajax, Flash Accessibility Vorgaben…

Weiter zu WCAG 2.0 AA

WCAG 2.0 Erfolgskriterien – Priorität AA

Um für Menschen mit Behinderung gut zugänglich zu sein, müssen Webinhalte für alle wahrnehmbar, bedienbar, verständlich und technisch robust sein und neben den Empfehlungen der Stufe A die folgenden Kriterien erfüllen.

1 Wahrnehmbar

1.2 Alternativen für zeitbasierte Medien

• 1.2.3 Captions für live Ton in Videos

  Untertitel für UserInnen mit Hörbehinderung – für live Audio Inhalte in synchronisierten Medien

• 1.2.4 Audio Beschreibung für voraufgezeichnete Videos

  im Audiotrack von Videos für blinde UserInnen – für aufgezeichnete Video Inhalte in synchronisierten Medien

1.4 Unterscheidbar

• 1.4.3 Text (auch in Grafikform) hat eine Kontrastverhältnis von 4.5:1

  außer er ist rein dekorativ oder ein Logo, größerer Text (18pt oder 14pt fettgedruckt) hat eine Kontrastverhältnis von 3:1

• 1.4.4 Text ist ohne Zoomsoftware bis auf 200% vergrößerbar

  ohne Verlust von Inhalt oder Funktionalität, ausgenommen sind Captions und Text in Grafikform

• 1.4.5 Text statt Grafik wird verwendet

  soweit mit verwendeter Technik für die visuelle Präsentation möglich, außer Grafik ist notwendig wie z.B bei Logos, oder die Textgrafiken sind visuell anpassbar an Nutzerbedürfnisse. Accessible Image Replacement ist erlaubt – z.B. Hintergrundbilder im CSS, Textinformation außerhalb des Viewports positioniert (für blinde NutzerInnen), zusätzlich sollte auch eine Version ohne Bilder vorhanden sein, bei der die Inhalte auch bei deaktivierten Bildern sichtbar sind (für NutzerInnen mit Sehbhinderung). PDFs müssen extrahierbaren Text enthalten.

2 Bedienbar

2.4 Navigierbar

• 2.4.5 Mehr als eine Möglichkeit, um Seiten innerhalb einer (komplexeren) Webseite zu finden

  Navigation, Links, Suchfunktion, Sitemap…

• 2.4.6 Aussagekräftige Überschriften und Labels

• 2.4.7 Sichtbarer Tastaturfokus

  a:focus, a:active Angaben im CSS, Standard-Fokusanzeige (Rahmen um den Link) nicht wegnehmen

3 Verständlich

3.1 Lesbar und verständlich

• 3.1.2 Sprachauszeichnung für anderssprachige Textpassagen oder Phrasen

  (Ausdrücke oder Wendungen), mit lang, xml:lang Attribut, außer bei richtigen Namen, Technischen Fachbegriffen, Wörtern oder Wendungen, die Teil des allgemeinen Sprachgebrauchs sind. Ein CMS Editor muss Sprachauszeichnung ermöglichen!

3.2 Vorhersehbar

• 3.2.3 Konsistente Navigation auf jeder Seite

• 3.2.4 Konsistente Identifikation von Komponenten mit gleicher Funktionalität

  logische, übereinstimmende names, labels, sinnvolle Alternativtexte z.B. für Icons…

3.3 Eingabe Hilfen

• 3.3.3 Fehlerhandling: Korrekturvorschläge bei Inputfehlern

  wenn sie automatisch prüfbar sind und Sicherheit oder Zweck nicht gefährdet wird

• 3.3.4 Fehlervermeidung: sensible Daten sind überprüfbar und korrigierbar

  bei Formularen, die Verträge oder finanzielle Transaktionen betreffen, Userdaten in Datenbanken ändern oder Testantworten abschicken, sind Transaktionen reversibel oder können vor dem nächsten Schritt auf Fehler überprüft werden oder können vor dem endgültigen Abschicken durchgelesen, bestätigt und korrigiert werden

Weiter zu WCAG 2.0 AAA

WCAG 2.0 Erfolgskriterien – Priorität AAA

Um für Menschen mit Behinderung sehr gut zugänglich zu sein, müssen Webinhalte für alle wahrnehmbar, bedienbar, verständlich und technisch robust sein und neben den Empfehlungen der Stufen A und AA die folgenden Kriterien erfüllen.

1 Wahrnehmbar

1.2 Alternativen für zeitbasierte Medien

• 1.2.6 Gebärdensprachübersetzung für aufgezeichnete Audio Inhalte in synchronisierten Medien

• 1.2.7 Erweiterte Audio Beschreibung für aufgezeichnete Video Inhalte in synchronisierten Medien

  wenn Pausen für Audiobeschreibung zu kurz sind, Video wird dafür unterbrochen

• 1.2.8 Textalternative für aufgezeichnete synchronisierte Medien und nur Video Inhalte

• 1.2.9 Textalternative, die äquivalenten Inhalt bietet, für live Audio Inhalte

1.4 Unterscheidbar

• 1.4.6 Text, auch in Grafikform hat Kontrastverhältnis von 7:1

  größerer Text (18pt, 14pt fett) von 4.5:1(ausgenommen rein dekorativer Text oder Logos)

• 1.4.7 Bei Audioinhalten, die Sprache und Hintergrundgeräusche enthalten, können Hintergrundgeräusche abgeschalten werden

  wenn sie nicht mindestens 20 Dezibel (ca. 4x) leiser sind oder nur fallweise auftreten, Ausnahme Audio Capchas

• 1.4.8 Visuelle Präsentation von Textblöcken

  Vorder- und Hintergrundfarbe sind von NutzerInnen umstellbar, Textblöcke sind nicht breiter als 80 Buchstaben, kein text-align:justified, Zeilenabstand von 1,5 in Absätzen, Absatzabstand 1,5x höher als Zeilenhöhe, Textvergrößerung ohne assistive Technologien ist bis auf 200% möglich, ohne dass quer gescrollt werden muss, um einen Textblock zu lesen (bei der gängigsten Bildschirmauflösung, von derzeit 1024px)

• 1.4.9 Text in Grafikform nur für Dekoration oder bei absoluter Notwendigkeit (z.B. Logo)

2 Bedienbar

2.1 Tastaturbedienbar

• 2.1.3 ausnahmslose Tastaturbedienbarkeit ohne Timing für individuellen Tastendruck

2.2 Genügend Zeit

• 2.2.3 Timing ist bei keiner Aktivität notwendig

  außer bei nicht-interaktiven synchronisierten Medien und Echtzeit Events

• 2.2.4 Unterbrechungen, z.B. Contentupdates, können verschoben oder unterdrückt werden

  außer bei Notfällen wie Datenverlust, z.B. kein meta refresh, kein meta redirect, Einstellmöglichkeit via Formular, wie oft Börsenkurse auf der Seite aktualisiert werden…

• 2.2.5 Wenn authentifizierte Session ausläuft (Logout bei zu langer Inaktivität), kann der/die UserIn nach Wiederanmeldung ohne Datenverlust weitermachen

2.3 Keine epileptischen Anfälle auslösen

• 2.3.2 Kein Inhalt leuchtet (flasht) öfter als 3x/sec auf

2.4 Navigierbar

• 2.4.8 Information über Standort

  Breadcrumb Trail, klare Heraushebung des aktiven Navigationspunktes, Sitemap

• 2.4.9 selbsterklärende, kontextunabhängige Linktexte

• 2.4.10 Headings – Überschriften o.ä., wenn Inhalte in Bereiche aufgeteilt sind

3 Verständlich

3.1 Lesbar und verständlich

• 3.1.3 Unübliche Wörter, Idiome, Jargon werden erklärt

  z.B. in Klammern, mit Links zu Glossar…

• 3.1.4 Abkürzungen werden erklärt

  z.B. in Klammern bei ersten Auftreten, Verlinkung zu Glossar, oder mit abbr oder acronym Element…

• 3.1.5 Leichter verständliche Version für Inhalte, die Lesekenntnisse erfordern, die über lower secondary education level hinausgehen

  (6 – 9 Jahre Schulbildung, 11-14 Jahre) abgesehen von richtigen Namen und Titeln, z.B. leicht lesbare Zusammenfassung
  alternative leicht zu lesende Version, gesprochene Version oder Gebärdensprachübersetzung, zusätzliche Inhalte (Illustrationen…)

• 3.1.6 Aussprachehilfen für Wörter, die bei falscher Aussprache nicht eindeutig sind

3.2 Vorhersehbar

• 3.2.5 Änderungen von Seiteninhalten nur bei User Anfrage, nicht automatisch

3.3 Eingabehilfen

• 3.3.5 Kontextsensitive Hilfe

  z.B. erwartetes Datenformat angeben, Hilfelink, Rechtschreibkorrektur…

• 3.3.6 Fehlervermeidung bei allen Formularen

  Bei allen Formularen, bei denen User Informationen abschicken, sind Transaktionen reversibel oder können vor dem nächsten Schritt auf Fehler überprüft werden oder können vor dem endgültigen Abschicken durchgelesen, bestätigt und korrigiert werden