putzhuber.net > WCAG > WCAG 2.0 – A

50er Jahre Anzeige, Hausfrau beim Abwasch mit Prilpaket, mit Slogan: wenig Stil hilft viel
Inserat für "Pril", aus "Frau und Mutter", 47. Jahrgang, zweites Juniheft 1958, Seite 32, bearbeitet. (Originaltext: "Pril so sparsam - wenig Pril hilft viel", "Pril ohne Soda schont die Hände")

Accessibility Know-how

Für die BerufskollegInnen, die sich einen schnellen Überblick verschaffen wollen...

Die Inhalte sind nicht neu, aber weitgehend aktuell.

WCAG 2.0 – A

22. Dezember 2008

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.

Aktualisierung Feber 2017: Einige Textergänzungen

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 inhaltswichtige Bilder und Bedienelemente, leeres alt Attribut (alt=““) für unwichtige Bilder wie z.B. Teaserbilder mit dabeistehender Textinformation oder Dekografiken, eine Ersatzlösung für grafische Captchas, Beschreibung für Diagramme oder Charts, title Attribut bei zeitbasierten Medien (Audio, Video, Animationen…),  title Attribut für (i)frames, visuell versteckter Text bei informationstragenden Hintergrundbildern, Überprüfung der Screenreaderausgabe bei Font-Icons (ev. Verstecken mit aria-hidden Attribut und zusätzliche Textinformation)

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 ohne Sprache wäre statt der Beschreibung in Textform auch eine Beschreibung des visuellen Inhalts im Audiotrack für blinde User möglich

  • 1.2.2 Captions für voraufgezeichnete, synchronisierte Medien (Video mit Sprache)

    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, semantische Seitenstruktur mit HTML5 Strukturelementen oder WAI ARIA landmarkroles, Semantisches Markup – für Überschriften, Absätze, Listen, Datentabellen, Formulare…, korrektes DOM Scripting, um Inhalte per JavaScript dazuzufügen…, getaggte PDFs…

  • 1.3.2 Sinnvolle Reihenfolge

    Auch ohne grafische Ansicht, korrekte Lesereihenfolge (bei Navigation mit Pfeiltasten mit Screenreader), lineare Lesbarkeit bei Layouttabellen, Vorsicht bei CSS position:absolute und Positionierung von 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, keine Hinweise wie „Finden Sie in der rechten Spalte“, „Klicken Sie auf den roten Button“

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 im Fließtext zusätzliche visuelle Markierung (wie Unterstreichen), zusätzliches Muster bei Diagrammen mit verschiedenfarbigen Teilen, mehrfache Fehlermarkierung bei Formularen (nicht nur roter Rahmen bei fehlerhaften Inputfeldern)

  • 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()), alle interaktiven Elemente sind mit Tabtaste, Leertaste, Pfeiltasten und Entertaste bedienbar, Lightboxen und Dialogfelder lassen sich auch mit Escapetaste schließen

  • 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), Sessions sind lang genug, damit man auch bei motorischen Einschränkungen genug Zeit für die Fertigstellung einer Aktion hat.

  • 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 aktualisiert 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. Werbung lässt sich schließen, Ticker und Carousels haben einen Stoppbutton oder lassen sich mit Tastatur und Maus anhalten.

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, Skiplink (Zum Inhalt), HTML5 Strukturelemente oder landmarkroles (ohne diese ev. visuell versteckte Strukturüberschriften vor Menüs), Hauptüberschrift H1 und Überschriften bei Sections

  • 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; Fokushandling – Fokus wird in Lightboxen und Modale Dialoge gesetzt, Darüberhinaustabben wird unterbunden; tabindex nur setzen, wenn absolut notwendig, tabindex=“0″ bei Verwendung von nicht nativen interaktiven Elementen, Links mit href

  • 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 unklaren Linkbezeichnungen wie „Klicken Sie hier“; erlaubt sind sich wiederholende, gleichlautende, nicht selbsterklärende Links unterhalb von unterscheidenden Überschriften, Tableheadern oder innerhalb von untergeordneten Listen, im gleichen Satz oder Absatz (z.B. „Mehr“, „Download“…)

3 Verständlich

3.1 Textinhalt ist lesbar und verständlich

  • 3.1.1 Sprachangabe der Seite

    Richtiges Sprachattribut im HTML Element – z.B. lang=“de“

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

    Kein onchange Eventhandler in Selectboxen, keine automatische von Screenreadern nicht nachvollziehbare Änderung  von Formularen beim Anklicken eines Radio Buttons oder einer Checkbox, keine automatische Formularversendung ohne Klick auf Submitbutton oder Enter

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, auf semantische Zuordnung von Fehlermeldungen achten (durch ARIA Markup oder innerhalb des Labels)

  • 3.3.2 Labels oder Instruktionen

    Semantische Zuordnung von Formularfeldbeschreibungen durch label Element, title oder  aria-label Attribut, nur wenn label nicht möglich ist, Beispiel für erwartetes Datenformat

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, alt-Attribute…; d.h. weitgehend valider Code, viele Validierungsfehler, z.B. nicht maskierte Sonderzeichen im Pfad, veraltete Attribute…sind tolerierbar

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

    Interaktive Elemente müssen auch mit assistiven Technologien verständlich und bedienbar sein, standardgemäß verwendete HTML Kontrollelemente erfüllen das von vornherein.
    Bei Entwicklung eigener User Interface Controls, Verwendung von Webcomponents,  korrekte DOM Funktionen, um Inhalte hinzuzufügen, WAI-ARIA, um Zusatzinformationen für Screen Reader zu geben für Widgets, für die es keine native HTML Semantik gibt (z.B. Slider, Treenavigation, Tooltip, Carousel….), für Autosuggest bei einem Suchformular, Autoaktualisierung von Inhalt etc…, korrekte Verwendung von Wai-ARIA, keine redundante Semantik (d.h. störend zuviel Information für Screenreader)

Weiter zu WCAG 2.0 AA

Kommentarfunktion ist deaktiviert