Was ist WCAG 2.2.

WCAG 2.2 ist die vom W3C am 5. Oktober 2023 veröffentlichte Richtlinie für Web-Barrierefreiheit und heute die in den meisten Ländern, die Türkei eingeschlossen, maßgebliche Version.

Der Name trägt mehr Bedeutung als seine Auflösung: Web Content Accessibility Guidelines. Das Wort „Guidelines“ kann täuschen — das Dokument ist keine Liste von Empfehlungen, sondern ein Standard aus testbaren Erfolgskriterien. Jedes Kriterium ist so geschrieben, dass es sich prüfen lässt: „Trifft dies zu, bestanden; wenn nicht, durchgefallen.“ Das ist der Grund, warum Barrierefreiheit messbar ist.

2.2 ersetzt 2.1 nicht — es baut darauf auf. Eine zu WCAG 2.1 konforme Website erfüllt den Großteil von 2.2 bereits; es fehlen nur die neu ergänzten Kriterien. Diese Rückwärtskompatibilität ist eine bewusste Entwurfsentscheidung und hält Versionswechsel günstig.

Was sich von 2.1 zu 2.2 geändert hat

Die Änderung lief in zwei Richtungen: Neun neue Erfolgskriterien kamen hinzu, eines wurde entfernt. Entfernt wurde 4.1.1 „Parsing“, und die Begründung ist lehrreich — moderne Browser reparieren kaputtes HTML ohnehin konsistent, das Kriterium stand also für kein echtes Barrierefreiheitsproblem mehr. Der Standard hat seine eigene tote Klausel beschnitten.

Die neun ergänzten Kriterien sammeln sich in drei Gruppen: Sichtbarkeit des Fokus, Alternativen zu Zeigergesten und Verringerung der kognitiven Last. Alle drei blicken in dieselbe Richtung — die Oberfläche für Tastatur- und Touch-Nutzer vorhersehbar zu machen.

1. 2.4.11 Fokus nicht verdeckt (Minimum) — AA. Das fokussierte Element darf von einem klebenden Header oder Cookie-Banner nicht vollständig verdeckt werden.
2. 2.4.12 Fokus nicht verdeckt (Erweitert) — AAA. Dieselbe Regel, verschärft bis zur teilweisen Verdeckung.
3. 2.4.13 Fokusdarstellung — AAA. Eine numerische Basis für Dicke und Kontrast des Fokusindikators.
4. 2.5.7 Ziehbewegungen — AA. Jede per Ziehen ausgeführte Operation braucht eine Ein-Zeiger-Alternative.
5. 2.5.8 Zielgröße (Minimum) — AA. Touch-Ziele mindestens 24×24 CSS-Pixel.
6. 3.2.6 Konsistente Hilfe — A. Der Hilfekanal muss auf jeder Seite an derselben Stelle stehen.
7. 3.3.7 Wiederholte Eingabe — A. Dieselbe Information darf im selben Ablauf nicht zweimal verlangt werden.
8. 3.3.8 Barrierefreie Authentifizierung (Minimum) — AA. Die Anmeldung darf nicht an ein kognitives Rätsel (CAPTCHA, Gedächtnistest) gebunden sein.
9. 3.3.9 Barrierefreie Authentifizierung (Erweitert) — AAA. Dieselbe Regel, ohne die Ausnahme der Objekterkennung.

Auffällig an dieser Liste ist, dass die meisten neuen Kriterien auf Stufe AA liegen. Der Wechsel zu 2.2 ist für eine Einrichtung mit AA-Ziel also ein echter Arbeitsposten — für eine mit A-Ziel bedeutet er nur zwei neue Klauseln (3.2.6 und 3.3.7).

Das praktische Gewicht der neun Kriterien

Drei der neuen Kriterien sind die auf echten Websites am häufigsten gebrochenen. Wer eine Oberfläche auf 2.2 hebt, spart Zeit, wenn er zuerst auf diese schaut.

2.4.11 macht den Preis klebender Header sichtbar. Ein Header, der beim Scrollen oben stehen bleibt, verdeckt leicht das Element, das ein mit Tab navigierender Nutzer fokussiert hat — der Nutzer hat irgendwo den Fokus, kann aber nicht sehen, wo. Die Lösung liegt meist im CSS bei scroll-margin.

2.5.8 brachte erstmals auf AA eine numerische Basis für Touch-Ziele: 24×24 CSS-Pixel. Das liegt unter der bekannten 44-Pixel-Empfehlung für mobile Oberflächen — 44 ist weiterhin AAA (2.5.5). 24 genügt also, um AA zu bestehen; aber 44 anzustreben sammelt AAA ein und funktioniert mit echten Fingern besser.

3.3.8 berührt CAPTCHA direkt. Ein kognitives Rätsel zur Anmeldebedingung zu machen ist jetzt ein AA-Verstoß; ein Rätsel darf nur verwendet werden, wenn es eine Alternative hat. Die Ausnahmen für Objekterkennung und persönliche Inhalte gelten auf AA, nicht auf AAA.

Warum die Versionsnummer nicht 3.0 ist

Das W3C arbeitet parallel an WCAG 3.0, und das wird sich von der 2.x-Familie grundlegend unterscheiden: ein Punktemodell statt des binären Bestanden/Durchgefallen, und ein breiterer Geltungsbereich. Aber 3.0 wird viele Jahre im Entwurfsstadium bleiben, und selbst veröffentlicht wird es 2.2 nicht sofort entwerten.

Für alle, die heute entscheiden, ist das beruhigend: Eine Investition in WCAG 2.2 ist in naher Zukunft nicht verloren. Sowohl das Rundschreiben in der Türkei als auch der European Accessibility Act beziehen sich auf die 2.x-Familie.

Wo man liest

Der Standard selbst ist ein dichtes Dokument und wurde nicht geschrieben, um von vorn bis hinten gelesen zu werden. Das W3C weiß das und bietet eine dreischichtige Struktur; am richtigen Punkt einzusteigen spart Zeit.

1. Die Richtlinie selbst — der normative Text. Um zu erfahren, was ein Kriterium genau sagt.
2. Die Understanding-Dokumente — Absicht, Nutzen und Beispiele je Kriterium. Um zu verstehen, WARUM es ein Kriterium gibt.
3. Die Techniques-Dokumente — konkrete Wege, das Kriterium zu erfüllen, mit Codebeispielen. Für die Umsetzungsphase.
4. Die Quick Reference (How to Meet WCAG) — eine nach Stufe und Technologie filterbare Arbeitsliste. Der nützlichste Einstieg für die tägliche Arbeit.

In der Praxis ist der richtige Ablauf für die meisten Teams: In der Quick Reference den AA-Filter öffnen, die eigene Technologie wählen, die Liste als Checkliste verwenden; bei der Klausel, an der man hängt, in Understanding hinabsteigen. Den Standard von vorn bis hinten zu lesen ist fast nie nötig.

Wer in der Türkei arbeitet, hat einen Schritt mehr: Die vom Ministerium für Familie und Soziale Dienste veröffentlichte Checkliste entfaltet die 31 Kriterien der Stufe A in 126 Bewertungsfragen. Da die Prüfung in öffentlichen Projekten nach dieser Liste erfolgt, muss sie neben dem WCAG-Text offen bleiben.

Für wen: Arten der Beeinträchtigung und ihre Gegenstücke

WCAG Klausel für Klausel zu lesen kann vergessen lassen, was man warum tut. Hinter den Kriterien stehen konkrete Nutzungssituationen, und sie zu kennen macht den Unterschied zwischen dem „Bestehen“ einer Klausel und ihrer wirklichen Lösung.

1. Sehen — bei vollständigem Sehverlust der Screenreader; bei Sehschwäche Vergrößerung und hoher Kontrast; bei Farbenblindheit ein zweites Merkmal neben der Farbe. Alternativtext, Kontrast und semantische Struktur betreffen diese Gruppe.
2. Hören — Untertitel und Transkript für Audioinhalte. Auf jeder Website mit Video unmittelbar relevant.
3. Motorik — wer keine Maus benutzen kann, navigiert per Tastatur, Schalterzugang oder Blicksteuerung. Tastaturzugang, Fokussichtbarkeit und Touch-Ziele entstehen hier.
4. Kognition — Unterschiede in Aufmerksamkeit, Gedächtnis und Lesen. Die Kriterien konsistente Hilfe, wiederholte Eingabe und barrierefreie Authentifizierung kamen in 2.2 genau für diese Gruppe hinzu.
5. Vorübergehend und situativ — der gebrochene Arm, der Bildschirm in der Sonne, der laute Raum, das Telefon in einer Hand. Erfasst zeitweise jeden ohne dauerhafte Beeinträchtigung.

Der letzte Punkt ist die am meisten missverstandene Seite der Barrierefreiheit. Hoher Kontrast ist nicht nur für Sehschwache, sondern für alle, die in der Sonne aufs Telefon schauen. Untertitel sind nicht nur für Gehörlose, sondern für alle, die im Meeting ein stummes Video ansehen. Ein großes Touch-Ziel ist nicht nur für zitternde Hände, sondern für alle, die im ruckelnden Bus das Telefon benutzen.

Barrierefreies Design ist kein Design für weniger Menschen — es ist Design für mehr Situationen.

Drei häufige Missverständnisse

In Teams, die neu auf WCAG blicken, wiederholen sich einige Missverständnisse. Alle drei kehren als unnötige Kosten oder falsches Vertrauen zurück.

Erstens: „Barrierefreiheit macht die Website hässlich.“ Ein Mythos, geboren aus Designgewohnheiten, die den Fokusring entfernen und den Kontrast senken. WCAG schreibt nirgends eine bestimmte visuelle Sprache vor; es setzt numerische Basen für das Kontrastverhältnis, die Fokussichtbarkeit und die Zielgröße. Innerhalb dieser Basen lassen sich unendlich viele visuelle Sprachen bauen. Die Schwierigkeit ist nicht Ästhetik, sondern Disziplin.

Zweitens: „Wir machen es mit ARIA barrierefrei.“ ARIA ist eine Ergänzung für die Stellen, an denen semantisches HTML nicht reicht — kein Ersatz. Falsch verwendetes ARIA ist schlimmer als keines: Eine nicht existierende Rolle zu deklarieren heißt den Screenreader anzulügen. Die Regel ist klar: Gibt es das richtige HTML-Element, verwenden Sie es — und denken Sie erst danach an ARIA.

Drittens: „Unser Prüfwerkzeug ist grün, wir sind konform.“ Automatische Werkzeuge können nur einen Teil der WCAG-Kriterien testen; der Rest verlangt menschliches Urteil. Ob ein Bild einen Alternativtext HAT, fragt das Werkzeug; ob dieser Text das Bild RICHTIG beschreibt, kann es nicht fragen. Ein hoher Score ist die Antwort auf die gestellten Fragen.

Der Wechsel zu 2.2: ein realistischer Plan

Eine zu WCAG 2.1 konforme Website auf 2.2 zu heben ist meist eine kleinere Arbeit als gedacht, denn die meisten neuen Kriterien haben zur Regel gemacht, was ohnehin als gute Praxis galt.

1. Zuerst die Bestandsaufnahme — welche Stufe streben Sie an? Bei A gibt es nur zwei neue Klauseln (3.2.6 und 3.3.7). Bei AA sind fünf zu prüfen.
2. Messen Sie die klebenden Header — 2.4.11 ist die am häufigsten gebrochene neue Klausel. Gehen Sie die Seite mit Tab durch und prüfen Sie, ob das fokussierte Element unter dem Header verschwindet.
3. Scannen Sie die Touch-Ziele — listen Sie die klickbaren Elemente unter 24×24 CSS-Pixeln. Inline-Links fallen unter die Ausnahme.
4. Prüfen Sie den Anmeldefluss — gibt es ein CAPTCHA oder einen Gedächtnisschritt, greift 3.3.8 und eine Alternative wird Pflicht.
5. Lesen Sie die Formulare erneut — verlangt ein Ablauf dieselbe Information zweimal, verstößt er gegen 3.3.7. Autofill oder das Weiterreichen des früheren Wertes löst es.

Diese fünf Schritte sind in der Praxis der gesamte Übergang von 2.1 zu 2.2. Für ein bei null beginnendes Projekt gibt es gar keinen Übergangsposten — es wird direkt nach 2.2 gebaut, und der Kostenunterschied ist null. Das ist der konkreteste Nutzen davon, Barrierefreiheit von Anfang an statt nachträglich zu behandeln.