Opens in a new tab

WCAG 2.2: Was bedeuten die neuen Anforderungen?

Was ändert WCAG 2.2 für deine Website? Die sechs neuen Anforderungen verständlich erklärt – mit Beispielen, Prüfhinweisen und einer Checkliste für die Umsetzung.

Philipp Bremer, 9. Oktober 2026

Collage die darstellt wie man durch Untersuchungen eine Webseite den WCAG Regeln konfrom machen kann.

Eine Website lässt sich mit der Tastatur bedienen – doch der nächste Link verschwindet hinter dem Cookie-Banner. Ein Formular ist verständlich beschriftet – verlangt aber dieselbe Adresse dreimal. Das Kundenkonto funktioniert – solange man ein Passwort auswendig weiss und einen Sicherheitscode abtippen kann. Genau solche Hürden nimmt WCAG 2.2 stärker in den Blick.

Für dich als Website-Verantwortliche:r stellt sich deshalb nicht nur die Frage, was in der neuen Version steht. Wichtiger ist: Welche Funktionen solltest du prüfen? Was muss dein Entwicklungsteam anpassen? Und reicht eine Website, die bereits nach WCAG 2.1 geprüft wurde?

Dieser Artikel erklärt die Neuerungen anhand typischer Alltagssituationen. Du erfährst, welche zusätzlichen Anforderungen für WCAG 2.2 AA relevant sind und wie du daraus konkrete Aufgaben für dein Projekt ableitest.

Du möchtest wissen, welche Anpassungen deine Website braucht?

Mit unserem Webseiten-Check erhältst du eine erste Orientierung oder ein individuell vereinbartes Audit.

Website prüfen lassen.

Was ist WCAG 2.2 und was unterscheidet sie von WCAG 2.1?

WCAG steht für «Web Content Accessibility Guidelines»: die Richtlinien des World Wide Web Consortium (W3C) für zugängliche Web-Inhalte. Version 2.2 wurde am 5. Oktober 2023 als W3C-Empfehlung veröffentlicht. Sie baut auf WCAG 2.1 auf und ergänzt Anforderungen, unter anderem für Menschen mit kognitiven Einschränkungen, eingeschränktem Sehvermögen und bei der Nutzung mobiler Geräte.

WCAG unterscheidet drei aufeinander aufbauende Stufen: A umfasst grundlegende Anforderungen, AA ergänzt weitere und AAA geht darüber hinaus. In diesem Artikel konzentrieren wir uns auf WCAG 2.2 AA. Dazu gehören auch die grundlegenden Anforderungen der Stufe A.

Für dieses Ziel kommen gegenüber WCAG 2.1 AA sechs neue Anforderungen hinzu. Sie betreffen unter anderem die Bedienung mit Tastatur und Maus, Formulare und die Anmeldung in ein Benutzerkonto. Diese sechs Neuerungen schauen wir uns im Folgenden an; die zusätzlichen Anforderungen der Stufe AAA lassen wir hier bewusst weg.

Für die Grundlagen, die vier Prinzipien und die Konformitätsstufen findest du mehr in unserem Überblick zu WCAG und WCAG 2.1. Hier konzentrieren wir uns auf die Änderungen und ihre Umsetzung.

Wichtig: Die sechs Neuerungen sind keine vollständige Prüfliste.

Die bisherigen Anforderungen gelten weiterhin. Gute Kontraste, verständliche Beschriftungen oder Tastaturbedienbarkeit bleiben genauso wichtig wie zuvor. Wer nur die Neuerungen prüft, hat damit noch nicht die gesamte Website geprüft.

Welche neuen Anforderungen gelten für WCAG 2.2 AA?

1. Bleibt das fokussierte Element sichtbar?

Wer mit der Tab-Taste durch eine Seite navigiert, muss erkennen können, welches Element gerade ausgewählt ist. Eine feststehende Navigation, ein Cookie-Banner oder eine schwebende Leiste darf dieses Element nicht vollständig verdecken.

Ein Beispiel: Eine Person navigiert zum Button «Anmeldung abschliessen». Der Button erhält den Tastaturfokus, liegt aber komplett unter einer dauerhaft eingeblendeten Kontaktleiste. Die Funktion ist technisch erreichbar – visuell lässt sie sich trotzdem nicht finden.

Was du prüfen solltest: Gehe wichtige Seiten mit der Tastatur durch, auch solange Banner und andere eingeblendete Elemente sichtbar sind. Dein Entwicklungsteam kann beispielsweise den Scrollbereich so berücksichtigen, dass fokussierte Elemente nicht hinter festen Leisten verschwinden.

2. Funktionieren Ziehbewegungen auch ohne Ziehen?

Eine Funktion, die per Drag-and-drop bedient wird, braucht grundsätzlich auch einen Weg mit einzelnen Klicks oder Berührungen ohne Ziehbewegung. Ausnahmen gibt es, wenn das Ziehen wesentlich für die Funktion ist oder die unveränderte Funktion vom Browser bereitgestellt wird.

Ein Beispiel: In einer Liste lassen sich Einträge nur durch Festhalten und Verschieben neu anordnen. Wer die Maus nicht präzise bewegen oder den Finger nicht durchgehend auf dem Bildschirm halten kann, kommt nicht weiter. Schaltflächen wie «Nach oben» und «Nach unten» ermöglichen denselben Vorgang ohne Ziehen.

Was du prüfen solltest: Suche nach verschiebbaren Listen, Schiebereglern, Karten und Karussells. Gibt es eine gleichwertige Möglichkeit per Klick oder Tippen?

Eine reine Tastaturalternative genügt für dieses neue Kriterium nicht. Die Alternative muss auch mit einem Zeigegerät ohne Ziehen funktionieren. Tastaturbedienbarkeit bleibt zusätzlich erforderlich.

3. Sind Buttons und andere Klickziele ausreichend gross?

Kleine, eng aneinanderliegende Bedienelemente sind schwer zu treffen. Das betrifft beispielsweise Menschen mit einem Tremor, aber auch die Bedienung auf einem Touchscreen. WCAG 2.2 verlangt grundsätzlich eine aktive Zielfläche von mindestens 24 × 24 CSS-Pixeln.

Gemeint ist die Fläche, die auf Klicks oder Berührungen reagiert – nicht nur das sichtbare Symbol. Ein kleines Icon kann deshalb innerhalb einer grösseren Schaltfläche liegen.

Die Anforderung enthält Ausnahmen: unter anderem für ausreichend voneinander entfernte kleinere Ziele, eine gleichwertige ausreichend grosse Bedienmöglichkeit auf derselben Seite, Links im Fliesstext, unveränderte Browser-Steuerelemente und eine wesentliche Darstellung. Die Abstandsausnahme hat eine definierte Messregel; «etwas Platz dazwischen» genügt nicht als Nachweis.

Was du prüfen solltest: Kontrolliere besonders Icon-Buttons, Kalenderauswahl, Filter, Schliessen-Schaltflächen und die Navigation. Plane ausreichend grosse aktive Flächen, statt im fertigen Design jedes kleine Element über eine Ausnahme zu begründen. Weitere praktische Hinweise findest du in unserem Artikel zu barrierefreien Buttons.

4. Finden Besucher:innen Hilfe an einer verlässlichen Stelle?

Wenn Hilfeangebote auf mehreren zusammengehörenden Seiten vorkommen, müssen sie in derselben relativen Reihenfolge zum übrigen Inhalt stehen. Dazu gehören beispielsweise Kontaktdaten, Kontaktformulare, Selbsthilfeangebote und Chatfunktionen.

Ein Beispiel: Ein Support-Link steht während einer Buchung einmal oben in der Navigation, im nächsten Schritt versteckt im Inhalt und danach an einer anderen Stelle. Wer Unterstützung braucht, muss sich immer wieder neu orientieren.

Was du prüfen solltest: Betrachte deine Kontakt- und Hilfeangebote über zusammengehörende Seiten hinweg. Eine konsistente, gut auffindbare Position hilft bei der Orientierung – sowohl visuell als auch in der Reihenfolge, in der assistive Technologien die Inhalte erfassen.

Das Kriterium verlangt keinen neuen Chatbot und keinen rund um die Uhr verfügbaren Support. Es regelt die Konsistenz von Hilfeangeboten, die auf mehreren Seiten bereits vorhanden sind.

5. Müssen Menschen dieselben Angaben mehrfach eingeben?

Informationen, die im selben Vorgang erneut benötigt werden, sollen automatisch übernommen werden oder zur Auswahl bereitstehen. Ausnahmen bestehen unter anderem bei wesentlichen erneuten Eingaben, Sicherheitsanforderungen oder nicht mehr gültigen Angaben.

Ein Beispiel: Eine Person gibt bei einer Bestellung die Lieferadresse ein. Wenn dieselbe Adresse für die Rechnung gelten soll, genügt eine Auswahl wie «Rechnungsadresse entspricht der Lieferadresse». Die vollständige Adresse muss nicht nochmals abgetippt werden.

Was du prüfen solltest: Gehe mehrstufige Formulare, Anmeldungen und Bestellungen vom Anfang bis zum Abschluss durch. Wo wird bereits bekannte Information erneut verlangt? Kann das System sie übernehmen oder eine Auswahl anbieten?

Die automatische Vervollständigung des Browsers allein reicht dafür nicht: Die Website muss die bereits vorhandene Information innerhalb des Vorgangs verfügbar machen. Eine Speicherung über spätere, neue Sitzungen hinweg verlangt dieses Kriterium nicht. Mehr zur Gestaltung solcher Abläufe findest du in unserem Leitfaden zu barrierefreien Formularen.

6. Kann man sich anmelden, ohne alles auswendig zu wissen?

Wer sich in ein bestehendes Konto anmeldet, soll nicht allein darauf angewiesen sein, ein Passwort auswendig zu wissen oder ein Rätsel zu lösen. Die Website muss dafür eine Unterstützung oder einen anderen Anmeldeweg anbieten, sofern keine der vorgesehenen Ausnahmen greift. Eine solche Unterstützung kann beispielsweise ein funktionierender Passwortmanager sein.

Ein Beispiel: Ein Kundenportal verhindert das Einfügen von Passwörtern und lässt keine Passwortmanager zu. Wer ein langes Passwort nicht auswendig weiss oder zuverlässig abtippen kann, wird ausgeschlossen. Ein korrekt aufgebautes Anmeldeformular kann Passwortmanager und das Einfügen aus der Zwischenablage unterstützen.

Was du prüfen solltest: Funktionieren Passwortmanager, Kopieren und Einfügen sowie die Eingabe von Bestätigungscodes? Prüfe den gesamten Anmeldeweg einschliesslich zusätzlicher Faktoren und der Kontowiederherstellung, wenn dabei eine Authentifizierung verlangt wird.

Das bedeutet nicht, dass Passwörter oder alle CAPTCHAs pauschal verboten wären. Die Anforderung enthält Ausnahmen, etwa für bestimmte Tests, bei denen man Objekte auf Bildern erkennen muss. Solche Verfahren können dennoch Menschen ausschliessen; sie müssen ausserdem die anderen Anforderungen erfüllen. Unsere Empfehlung ist deshalb, Anmeldungen möglichst ohne Rätsel oder Abschreiben zu ermöglichen, statt nur nach einer Ausnahme zu suchen.

Was bedeutet der Wechsel auf WCAG 2.2 für deine bestehende Website?

Du musst nicht allein wegen einer neuen Versionsnummer alles neu entwickeln. Sinnvoll ist zuerst eine Bestandsaufnahme.

Dann lässt sich untersuchen, wo die sechs neuen Anforderungen greifen und welche Anpassungen nötig sind. Vorhandene Prüfergebnisse bleiben eine hilfreiche Grundlage. Änderungen seit dem letzten Audit müssen jedoch mitbetrachtet werden.

Dann fehlt die belastbare Grundlage für einen reinen Versionsvergleich. In diesem Fall ist eine breitere Prüfung sinnvoll – nicht nur ein Check der neuen Kriterien.

Eine frühere Anforderung an die Verarbeitung des Quellcodes («Parsing») ist in WCAG 2.2 entfallen. Das bedeutet aber nicht, dass fehlerhafter Code keine Rolle mehr spielt: Wenn dadurch Beschriftungen oder Bedienelemente nicht richtig funktionieren, bleiben das Barrieren, die geprüft und behoben werden müssen.

Für neue oder grundlegend überarbeitete Websites empfehlen wir WCAG 2.2 AA als klar vereinbartes Prüfziel. Das W3C rät zur Verwendung der aktuellen Version. Halte dabei nicht nur «barrierefrei» fest, sondern auch Version, Stufe, Prüfumfang und die wichtigen Nutzungsvorgänge.

Ist WCAG 2.2 automatisch gesetzlich vorgeschrieben?

WCAG 2.2 ist ein technischer Standard, nicht selbst ein Gesetz. Ob und welche rechtlichen Anforderungen für dein Angebot gelten, muss getrennt von der technischen Versionsfrage geklärt werden. Das W3C erlässt keine gesetzlichen Vorschriften und verweist für rechtliche Fragen auf die zuständigen Stellen. Quelle: W3C – Web Accessibility Laws & Policies.

Dieser Artikel erklärt deshalb die technische Umsetzung, nicht die Rechtslage für jeden Einzelfall. Für die gesonderte Einordnung findest du unsere Artikel zum European Accessibility Act für Schweizer Unternehmen und zur BehiG-Revision.

Checkliste: So planst du die nächsten Schritte zu WCAG 2.2 AA

Die folgenden Schritte sind eine praktische Vorgehensweise für dein Projekt, kein Ersatz für eine vollständige Konformitätsprüfung:

  1. Prüfgrundlage klären: Gibt es einen aktuellen Bericht? Welche Version, Stufe, Seiten und Abläufe wurden geprüft?
  2. Wichtige Vorgänge auswählen: Betrachte Kontaktaufnahme, Anmeldung, Buchung oder Bestellung vollständig – einschliesslich eingebundener Dienste.
  3. Die sechs Neuerungen prüfen: Verdeckte Elemente, Ziehbewegungen, Zielflächen, Hilfeangebote, wiederholte Eingaben und Anmeldung.
  4. Konkrete Aufgaben festhalten: Nicht «Fokus verbessern», sondern beispielsweise «Kontaktleiste verdeckt den Absenden-Button bei Tastaturnavigation».
  5. Beheben und erneut testen: Automatische Tools unterstützen die Arbeit. Ob die Abläufe tatsächlich funktionieren, braucht zusätzlich fachkundige manuelle Bewertung und gegebenenfalls Tests mit Nutzer:innen.
  6. Die Prüfung in die Pflege aufnehmen: Neue Plugins, Formulare und Inhaltsbausteine dürfen die erreichte Zugänglichkeit nicht unbemerkt verschlechtern.

Unser Tipp: Prüfe nicht nur die Startseite.

Die entscheidende Frage ist, ob jemand eine Aufgabe abschliessen kann. Ein zugänglicher Einstieg hilft wenig, wenn Login, Zahlungsdienst oder Bestätigung später eine Barriere bilden.

Häufige Fragen zu WCAG 2.2

Nicht automatisch. Für das hier beschriebene Ziel kommen sechs neue Anforderungen hinzu. Prüfe, welche davon für die Funktionen deiner Website relevant sind und ob sie erfüllt werden. Ein vorhandener WCAG-2.1-Bericht kann die Ausgangsbasis sein, ersetzt aber nicht die Bewertung der zusätzlichen Anforderungen und zwischenzeitlicher Änderungen.

Nein. Auch die bisherigen Anforderungen müssen erfüllt sein – beispielsweise an Kontraste, Tastaturbedienung und verständliche Beschriftungen. Die sechs Neuerungen ergänzen diese Grundlage. Eine vollständige Prüfung berücksichtigt die gesamte Website im vereinbarten Prüfumfang und die wichtigen Abläufe.

Nein. Das Kriterium zur Zielgrösse enthält Ausnahmen, beispielsweise für Links im Fliesstext und ausreichend voneinander entfernte kleinere Ziele. Die konkrete Zielfläche und gegebenenfalls die Abstandsmessung müssen geprüft werden. Für einzelne Buttons und Icon-Schaltflächen sind ausreichend grosse aktive Flächen meist die sinnvollere Gestaltung.

Nein. Ein Tool kann bestimmte Fehler finden, aber nicht allein feststellen, ob eine Website die Standards erfüllt. Dafür braucht es fachkundige menschliche Bewertung. Besonders wichtige Abläufe wie Login oder Buchung sollten nicht nur technisch gescannt, sondern tatsächlich durchlaufen werden.

Nicht allein wegen des Versionswechsels. Prüfe zuerst den aktuellen Zustand und die zusätzlichen Anforderungen. Daraus lässt sich ableiten, ob einzelne Komponenten angepasst werden können oder grundlegende Probleme bestehen. Eine neue Versionsnummer ersetzt diese Bestandsaufnahme nicht.

Welche Anpassungen braucht deine Website wirklich?

WCAG 2.2 wird dann hilfreich, wenn aus den Kriterien verständliche Aufgaben werden: ein Button bleibt sichtbar, ein Formular übernimmt bekannte Angaben, eine Anmeldung lässt sich ohne Abschreiben erledigen. Statt möglichst viele Regeln aufzuzählen, lohnt sich der Blick auf die Menschen und die Vorgänge, die deine Website ermöglichen soll.

Wir helfen dir, den aktuellen Stand einzuordnen und passende nächste Schritte festzulegen – von einer ersten Orientierung bis zu einem individuell vereinbarten Audit.

Webseiten-Check und Audit kennenlernen

Quellen und weiterführende Informationen

Über den Autor

Profilbild von Philipp Bremer

Philipp Bremer ist ein Barrierefreiheits-Enthusiast in Zürich. Mit seiner Leidenschaft für inklusive Webentwicklung hilft er Unternehmen, NGOs und Einzelpersonen dabei, Websites zu schaffen, die wirklich für alle Menschen zugänglich sind.

Mehr über Philipp Bremer erfahren

Schon diese Artikel gelesen?

Wir glauben, dass da für jede:n was dabei ist: