WCAG 2.2 verständlich erklärt

Die WCAG sind der weltweite Maßstab für barrierefreie Websites – und die Grundlage dessen, was BFSG und EAA von dir verlangen. Hier erfährst du, wie der Standard aufgebaut ist und was in Version 2.2 neu dazugekommen ist.

Aktualisiert am 17. Juli 2026 · Wave Tools Redaktion · 9 Min. Lesezeit

Was sind die WCAG – und wer gibt sie heraus?

Die Web Content Accessibility Guidelines (WCAG) sind der international anerkannte Standard für barrierefreie Webinhalte. Herausgegeben werden sie vom World Wide Web Consortium (W3C), genauer von dessen Web Accessibility Initiative (WAI) – der Organisation, die auch HTML und CSS standardisiert. Die aktuelle Version WCAG 2.2 erschien im Oktober 2023 und baut auf WCAG 2.1 auf: Alles, was vorher galt, gilt weiter, es kamen lediglich neue Anforderungen hinzu (und eine entfiel, dazu später mehr).

Wichtig zu verstehen: Die WCAG selbst sind kein Gesetz, sondern eine technische Richtlinie. Ihre rechtliche Bedeutung bekommen sie, weil Gesetze weltweit auf sie verweisen – in Europa über die Norm EN 301 549, auf der die Anforderungen des European Accessibility Act (EAA) und des deutschen Barrierefreiheitsstärkungsgesetzes (BFSG) beruhen.

Die vier Prinzipien: POUR

Alle Anforderungen der WCAG hängen an vier Prinzipien, die im Englischen mit POUR abgekürzt werden: Perceivable, Operable, Understandable, Robust. Wer diese vier Ideen verstanden hat, versteht die Logik des gesamten Standards.

1. Wahrnehmbar

Alle Inhalte müssen für alle Sinne zugänglich sein – notfalls über einen Ersatzweg. Beispiele:

  • Bilder brauchen Alternativtexte, damit Screenreader sie beschreiben können (mehr dazu im Artikel Alt-Texte richtig schreiben).
  • Videos brauchen Untertitel für Menschen, die nicht (gut) hören.
  • Text braucht ausreichenden Kontrast zum Hintergrund – hellgrau auf weiß ist für viele schlicht unlesbar.

2. Bedienbar

Jede Funktion muss ohne Maus erreichbar sein und darf niemanden unter Zeitdruck setzen. Beispiele:

  • Die komplette Website lässt sich mit der Tastatur bedienen – per Tab, Enter und Pfeiltasten.
  • Das gerade fokussierte Element ist sichtbar hervorgehoben, damit man weiß, wo man sich befindet.
  • Buttons und Links sind groß genug, um sie auch mit zitternden Händen oder auf dem Smartphone zu treffen.

3. Verständlich

Inhalte und Bedienung müssen nachvollziehbar sein. Beispiele:

  • Formulare erklären Fehler konkret: „Bitte gib dein Geburtsdatum im Format TT.MM.JJJJ ein" statt „Ungültige Eingabe".
  • Die Navigation funktioniert auf jeder Seite gleich und Elemente verhalten sich vorhersehbar.
  • Texte sind klar formuliert – Fachjargon wird erklärt oder vermieden.

4. Robust

Inhalte müssen mit möglichst vielen Browsern und Hilfstechnologien funktionieren. Beispiele:

  • Sauberes, semantisches HTML: Ein Button ist ein button, keine anklickbare div-Box.
  • Statusmeldungen (etwa „Produkt wurde in den Warenkorb gelegt") werden so ausgezeichnet, dass auch Screenreader sie mitbekommen.

Konformitätsstufen: A, AA und AAA

Jedes Erfolgskriterium der WCAG ist einer von drei Stufen zugeordnet:

  • A – das absolute Minimum. Wird es verfehlt, sind Inhalte für manche Gruppen komplett unzugänglich.
  • AA – der etablierte Standard. Diese Stufe verlangen praktisch alle Gesetze weltweit, auch EAA und BFSG über die EN 301 549.
  • AAA – die höchste Stufe, etwa Gebärdensprachvideos für alle Audioinhalte. Sie ist als Gesamtziel für komplette Websites meist nicht realistisch und wird auch rechtlich nicht gefordert.

Merksatz für die Praxis: Wenn jemand „WCAG-konform" sagt, ist fast immer Stufe AA gemeint. Konformität mit AA schließt automatisch alle A-Kriterien mit ein.

Neu in WCAG 2.2: neun Erfolgskriterien

WCAG 2.2 ergänzt neun neue Erfolgskriterien. Sie zielen vor allem auf Menschen mit motorischen Einschränkungen, mit kognitiven Beeinträchtigungen und auf die mobile Nutzung:

KriteriumStufeWas es verlangt
2.4.11 Fokus nicht verdeckt (Minimum)AADas fokussierte Element darf nicht komplett von Cookie-Bannern, Sticky-Headern oder Chat-Widgets verdeckt werden.
2.4.12 Fokus nicht verdeckt (Erweitert)AAADas fokussierte Element darf gar nicht verdeckt werden, auch nicht teilweise.
2.4.13 Fokus-ErscheinungsbildAAADer Fokusindikator muss eine Mindestgröße und einen Mindestkontrast haben.
2.5.7 ZiehbewegungenAAAlles, was per Drag-and-drop funktioniert (Slider, Sortieren), braucht eine Alternative mit einfachen Klicks oder Taps.
2.5.8 Zielgröße (Minimum)AAKlick- und Touch-Ziele müssen mindestens 24×24 CSS-Pixel groß sein oder genug Abstand zueinander haben.
3.2.6 Konsistente HilfeAHilfeangebote wie Kontaktlink, Telefonnummer oder Chat stehen auf jeder Seite an derselben Stelle.
3.3.7 Redundante EingabeABereits eingegebene Daten (etwa die Lieferadresse) müssen nicht im selben Prozess erneut eingetippt werden.
3.3.8 Barrierefreie Authentifizierung (Minimum)AALogins dürfen keine Merk- oder Transkriptionsleistung erzwingen: Passwort-Manager und Einfügen müssen funktionieren, kognitive Rätsel-Captchas brauchen Alternativen.
3.3.9 Barrierefreie Authentifizierung (Erweitert)AAAAuch Objekterkennung („Wähle alle Bilder mit Ampeln") ist als einziger Weg nicht erlaubt.

Gleichzeitig wurde ein altes Kriterium gestrichen: 4.1.1 Parsing (fehlerfreie Syntax) entfällt in WCAG 2.2, weil moderne Browser und Hilfstechnologien fehlertolerant genug geworden sind und das Kriterium keinen eigenen Nutzen mehr hatte.

WCAG, EN 301 549 und BFSG/EAA: Wie hängt das zusammen?

Die Kette ist einfacher, als sie klingt: Der EAA ist die EU-Richtlinie, das BFSG ihre deutsche Umsetzung. Beide verlangen Barrierefreiheit nach der harmonisierten Europäischen Norm EN 301 549 – und die übernimmt für Webinhalte im Kern die WCAG auf Stufe AA. Aktuell verweist die EN 301 549 noch auf WCAG 2.1; die Aktualisierung auf 2.2 ist in Arbeit. Wer heute direkt auf WCAG 2.2 AA hinarbeitet, ist also auf der sicheren Seite: Damit sind alle 2.1-Anforderungen abgedeckt, und die kommenden dazu.

Wer vom BFSG betroffen ist, welche Fristen gelten und welche Bußgelder drohen, liest du im Artikel BFSG und EAA: Wer muss bis wann barrierefrei sein?

Typische Missverständnisse

  • „Ein Overlay-Widget macht meine Seite konform." Nein. Bedienhilfen wie Kontrast-Umschalter oder Vorlesefunktionen sind eine sinnvolle Ergänzung, können aber Grundprobleme im Code – fehlende Alternativtexte, kaputte Tastaturbedienung, unbeschriftete Formulare – nicht beheben. Barrierefreiheit entsteht im Fundament, nicht als aufgesetzte Schicht.
  • „Barrierefreiheit betrifft nur Blinde." Die WCAG decken auch motorische, auditive und kognitive Einschränkungen ab – und helfen ganz nebenbei allen: bessere Kontraste in der Sonne, größere Buttons am Smartphone, klarere Formulare für jeden.
  • „Ein automatischer Test genügt." Automatische Tools finden erfahrungsgemäß nur einen Teil der Probleme. Ob ein Alternativtext sinnvoll ist oder eine Tastaturfalle existiert, zeigt erst manuelles Testen.

Pragmatisch starten

Du musst nicht alle Kriterien auf einmal angehen. Ein realistischer Einstieg:

  1. Bestandsaufnahme: Prüfe die wichtigsten Seiten und Prozesse (Startseite, Kontakt, Checkout) mit einem automatischen Tool und per Tastatur. Eine Anleitung findest du unter Website auf Barrierefreiheit testen.
  2. Schnelle Erfolge zuerst: Kontraste, Alternativtexte, Formular-Beschriftungen und sichtbarer Fokus lassen sich oft mit wenig Aufwand beheben – und decken viele AA-Kriterien ab.
  3. Neue 2.2-Kriterien einplanen: Prüfe Zielgrößen, Drag-and-drop-Alternativen und deinen Login-Prozess.
  4. Dranbleiben: Verankere Barrierefreiheit in Redaktions- und Entwicklungsprozessen, damit neue Inhalte nicht neue Barrieren schaffen.

Gut zu wissen: WCAG-Konformität ist kein einmaliges Projekt, sondern ein Zustand, den du halten musst. Jedes neue Bild, jedes neue Formular kann neue Barrieren einführen – regelmäßige kurze Checks sind wirksamer als eine einmalige Großaktion.

Ein solides WCAG-Fundament kannst du sinnvoll ergänzen: Wave Access gibt deinen Besucherinnen und Besuchern sofort nutzbare Bedienhilfen an die Hand – von Kontrast- und Schriftanpassung bis zur Vorlesefunktion.

Wave Access entdecken →