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

WCAG 2.2 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. In WCAG 2.2 wurden 4 Kriterien hinzugefügt.

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.3 Anpassbar

• 1.3.4 Display Orientierung (Landscape / Portrait)

  keine Display Fixierung auf Touchscreens, Wechsel zwischen Landscape oder Portraitmodus ist möglich.

• 1.3.5 Input Zweck ist programmiertechnisch identifizierbar

  Benutzen standardisierter vordefinierter Taxonomie bei Inputfeldern, damit Browser bereits gespeicherte Daten wiederverwenden können (für z.B. die E-Mail Adresse), HTML autocomplete funktioniert.

1.4 Unterscheidbar

• 1.4.3 Text (auch in Grafikform) hat eine Kontrastverhältnis zum Hintergrund 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, bei Browserbreite von 1280px, ausgenommen sind Captions und Text in Grafikform; Browserzoom ist ausreichend, mögliche Nur-Textvergrößerung ideal, Zoom muss auch auf mobilen Geräten möglich (d.h. darf nicht deaktiviert) sein.

• 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. Webfonts statt grafischer Text, Textwiedergabe im alt-Attribut bei Textgrafiken, Hintergrundbilder im CSS mit visuell versteckter Textinformation sind nicht geeignet für Accessibility Anpassungen im Betriebssystem (Kontrastmodus) oder Verwendung eigener User Stylesheets; PDFs müssen extrahierbaren Text enthalten.

• 1.4.10 Reflow

  responsives Design, damit Inhalte auch bei 320px Auflösung (iPhone) ohne Querscrollen lesbar sind, das entspricht 400% Zoom bei 1280px.

• 1.4.11 Nicht-Text Inhalte Kontrast

  Icons, Grafiken, Diagramme benötigen Kontrastwert 3:1

• 1.4.12 Text Abstände

  Vorgegebene Abstände sind vorhanden oder anpassbar. Text ist noch gut lesbar bzw. ohne Überlagerungen bei Anpassung von Abständen durch eigene Stylesheets: Zeilenhöhe 1,5 x Schriftgröße, Abstand nach Absätzen 2 x Schriftgröße, Abstand zwischen Wörtern ( 0,16 x Schriftgröße) und Buchstaben (0,12x Schriftgröße).

• 1.4.13 Bei Hover /Fokus eingeblendete Inhalte

  Gilt z.b. für Custom Tooltips, Submenüs und andere nichtmodale Popups. Wenn sie Inhalte überlagern, müssen sie deaktivierbar sein, ohne dass der Pointerzeiger oder Fokus verschoben werden muss, sie müssen hoverbar sein und stehenbleiben, bis der User sie daktiviert oder die Information nicht mehr valide ist.

2 Bedienbar

2.4 Navigierbar

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

  Navigation, Content-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

• 2.4.11 Fokus nicht verdeckt (neu in WCAG 2.2)
  

  Der Tastaturfokus wird nicht von fix positioniertem Inhalt überlagert, z.B. darf ein Aufklappmenü nicht gerade fokussierten Inhalt im Hintergrund überlagern, wenn man den Tastaturfokus verändern muss, um es zu schließen, also z.B. rückwärts tabben müsste, um das Menü zu schließen.

2.5 Input Modalitäten

• 2.5.7 Dragging – Ziehbewegungen (neu WCAG 2.2)

  Neben Dragging ist auch eine Single-Pointer Funktion gegeben (z.B. Pfeiltaste zum Verschieben von Elementen, die man auch verziehen könnte)
  

• 2.5.8 Target Größe
  

  Klickflächen wie Buttons haben eine Mindestklickfläche von 24 x 24 px, Links innerhalb von Text sind davon nicht betroffen.

3 Verständlich

3.1 Lesbar und verständlich

• 3.1.2 Sprachauszeichnung für anderssprachige Textpassagen oder Phrasen

  Anderssprachige längere Textpassagen, Absätze mit lang Attribut, kein lang-Attribut bei richtigen Namen, technischen Fachbegriffen, Wörtern oder Wendungen, die Teil des allgemeinen Sprachgebrauchs sind (z.B. Website, Download…). 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 des Formulars nicht gefährdet wird, semantische Zuordnung der Fehlerhinweise, damit sie im Formularmodus des Screenreaders lesbar sind

• 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.
  den Vorschriften des eCommerce Gesetzes entsprechend bei Webshops, beim eBanking…

• 3.3.8 Zugängliche Authentifizierung (neu in WCAG 2.2)

  Authentifizierung ist ohne koginitiven Funktionstest (wie Passwort merken oder Rätsel lösen) möglich, Beispiele sind Passwort Manager, Bestätigung via E-Mail Link, Captchas mit visueller Objekterkennung sind erlaubt, wenn es eine Mehr Sinne Alternative gibt (wie Audio Captcha).

4 Robust

4.1 kompatibel

• 4.1.3 Status Meldungen

  Statusmeldungen können programmtechnisch bestimmt werden (durch ARIA roles oder attributes, z.b. alert, status, aria-live), so dass assistive Technologien sie interpretieren können, ohne dass der Fokus dort sein muss. Wenn Inhalte zu einer Seite hinzugefügt werden, ohne dass sich der Kontext ändert.