© Originalquelle unbekannt, gefunden in diversen Blogs, bearbeitet.
(Originaltext: „What’s on my to-do list today? Oh right. Everything.“)

WCAG 2.2 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. Die WCAG Kriterien sind nach diesen 4 Prinzipien gereiht. A-Kriterien sind absolute Muss-Kriterien. 2 Level A Kriterien sind in WCAG 2.2 neu dazugekommen.

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

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 landmark roles, 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 Tabellen, Vorsicht bei CSS position:absolute und Positionierung von JavaScript generierten Inhalten, keine fixen Leerzeichen ( ) zur Formatierung, Vorsicht bei grid Layouts, damit die korrekte Reihenfolge in verschiedenen Bildschirmgrößen gewahrt bleibt.

• 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, Fehlermarkierung bei Formularen nicht nur durch Farbe (wichtig für Menschen mit Farbfehlsichtigkeiten)

• 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

  Alle interaktiven Elemente sind mit Tabtaste erreichbar und Entertaste bedienbar, bzw. mit Leertaste bei Radiobuttons oder Pfeiltasten bei Tabreitern oder Bildergalerien. Lightboxen und Dialogfelder lassen sich auch mit Escapetaste schließen. Keine rein mausabhängigen JavaScript Eventhandler, kein Wegnehmen des Fokus durch JavaScript (z.B. onfocus=“blur()).

• 2.1.2 Keine Tastaturfallen

  Overlays müssen sich (auch mit Tastatur) schließen lassen, aus eingebetteten Anwendungen muss man mit Pfeil-, Tab- oder Escapetaste wieder hinauskommen,  kein endlos Scrollen, keine Tastaturkürzel, die bereits im Browsermenü oder Screen Reader in Verwendung sind.

• 2.1.4 Tastatur Shortcuts

  Relevant, wenn selbstdefinierte Tastatur Shortcuts nur aus Buchstaben, Punktuation, Zahlen, Symbolen bestehen, sie müssen sich abschalten oder umdefinieren lassen oder dürfen nur bei Fokus aktivierbar sein.

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 landmark roles (ohne diese ev. visuell versteckte Strukturüberschriften vor Menüs), Hauptüberschrift H1 am Contentbeginn und idealerweise auch Ü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 (z.B. „Mehr“, „Download“…) unterhalb von unterscheidenden Überschriften, Tableheadern oder innerhalb von untergeordneten Listen, im gleichen Satz oder Absatz.

2.5 Machen Sie es einfach für User, Funktionalitäten mit verschiedenen Inputmethoden zu bedienen, abgesehen von der Tastatur

• 2.5.1 Pointer Gesten

  Relevant bei Mobilen Applikationen, Gesten auf Touchscreens, Mauszeiger, Stift, Laser-Pointer. Für komplexe Pointer-Gesten (Maus oder Touch) gibt es einfache (tastaturbedienbare) Alternativen.

• 2.5.2 Pointer Cancellation

  Pointer-Eingaben können widerrufen werden bzw. lösen den Event erst beim Abheben des Pointers aus, (up-Event) nicht beim down-Event.

• 2.5.3 Label im Namen

  Sichtbare Label sind im programmatisch ermittelbaren Namen von Bedienelementen enthalten (es ist nicht das html name Attribut gemeint)

• 2.5.4 Motion Actuation – Funktionen durch Bewegung

  Für Eingaben über Geräte-Sensoren stehen alternative Eingabemodi bereit. Funktionen, die über die Bewegung eines Gerätes (zB. schütteln, drehen) ausgelöst werden, oder bei Gesten hin zu einem Gerät (so dass Sensoren wie eine Kamera die Gesten interpretieren können) , können auch mit konventionelleren User Face Komponenten bedient werden.

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.2.6 Konsistente Hilfe (neu WCAG 2.2)

  Kontakt und Hilfe Optionen befinden sich immer an derselben Stelle.

3.3 Hilfen, um Fehler zu vermeiden und zu korrigieren

• 3.3.1 Inputfehler werden in Textform erklärt

  z.b. wird auf ein nicht ausgefülltes Pflichtfeld in einem Formular hingewiesen, 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, wenn label nicht möglich ist. Beispiele für erwartetes Datenformat (z.B. tt.mm.jjjj)

• 3.3.7 Redundante Einträge (neu WCAG 2.2)

  Bereits eingetragene Userdaten in Formularen müssen nicht nochmals eingetragen werden (z.B. wenn Lieferadresse Rechnungsadresse entspricht)

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, in WCAG 2.2 gestrichen)

  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, in WCAG 2.1 wird der Punkt als erfüllt eingestuft.

• 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)