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