WCAG 2.2 Checkliste: Vollständiger Leitfaden für Prüfung und Umsetzung

Diese Seite liefert eine vollständige, deutschsprachige WCAG 2.2 Checkliste mit prüfbaren Umsetzungsanweisungen und einem Audit-Workflow. Sie deckt alle Erfolgskriterien nach den vier Prinzipien Wahrnehmbar, Bedienbar, Verständlich und Robust ab, inklusive der neun neuen Kriterien aus WCAG 2.2. Der empfohlene Prüfprozess kombiniert automatisierte Scans mit manuellen Screenreader- und Tastaturtests und stützt sich auf die offizielle WCAG 2.2 Spezifikation des W3C sowie den Schweizer Standard eCH-0059.

Kurz gesagt:

• Die Priorität liegt auf der automatisierten Vorprüfung kritischer Fehler in den automatisierten Tests, gefolgt von manuellen Screenreader- und Tastatur-Tests.
• Wichtige Erfolgskriterien wie gut sichtbarer Fokus, Kontrastwerte und Tastaturzugänglichkeit sollten als erstes im Designsystem umgesetzt werden.
• Das Erreichen von AA-Konformität dauert in der Regel vier bis acht Wochen, inklusive manueller Tests und Dokumentation.
• Automatisierte Tools erkennen nur etwa 30 bis 40 % der tatsächlichen Barrierefreiheitsprobleme, die manuelle Tests erfordern.
• Frühzeitiges Einbinden von WCAG 2.2 in den Entwicklungsprozess erleichtert die spätere rechtliche Umsetzung und reduziert Nachrüstkosten.

Inhaltsverzeichnis

• Wie ist die WCAG 2.2 Checkliste aufgebaut und wie nutzen Sie sie?
• Vollständige WCAG 2.2 Checkliste: Alle Erfolgskriterien im Detail
• Was ist neu in WCAG 2.2 gegenüber Version 2.1?
• Wie testen Sie WCAG 2.2 richtig: Tools, Screenreader und Nachweisführung
• Wie priorisieren Sie die Umsetzung und wie viel Aufwand ist realistisch?
• Welche rechtlichen Vorgaben gelten für WCAG 2.2 in der Schweiz?
• Praxis-Perspektive: Wie unterstützt Outwork Unternehmen bei WCAG 2.2
• Was die Praxis über WCAG 2.2 wirklich zeigt
• Quellen

Wie ist die WCAG 2.2 Checkliste aufgebaut und wie nutzen Sie sie?

Eine Barrierefreiheitscheckliste ist nur so gut wie der Prozess dahinter. Wer WCAG 2.2 nur als PDF abhakt, verpasst den eigentlichen Punkt: Barrierefreiheit ist kein einmaliges Audit, sondern ein wiederkehrender Prüfzyklus im Entwicklungsalltag.

Die Checkliste in diesem Artikel folgt der Struktur des W3C und gliedert sich nach den vier Prinzipien der WCAG: Wahrnehmbar, Bedienbar, Verständlich und Robust. Innerhalb dieser Prinzipien sind die Erfolgskriterien nach Konformitätsstufe sortiert, also A, AA und AAA. Für die meisten Organisationen ist AA das relevante Zielniveau, auch weil sich EN 301 549 und viele nationale Vorgaben genau daran orientieren.

Der Prüfworkflow, der sich in der Praxis bewährt hat, läuft in drei Schritten ab:

1. Automatisierte Vorprüfung: Ein Scanner wie axe oder Lighthouse identifiziert strukturelle Fehler, etwa fehlende Alt-Texte oder ungültige ARIA-Attribute.
2. Manuelle Verifizierung: Ein Tester geht die kritischen Nutzerpfade mit Tastatur und Screenreader durch, da automatisierte Tools semantische und kontextuelle Fehler kaum erkennen.
3. Nutzertest und Dokumentation: Reale Anwender mit unterschiedlichen Beeinträchtigungen prüfen kritische Journeys, während Ergebnisse in einem Issue-Tracker mit Referenz auf das jeweilige Erfolgskriterium festgehalten werden.

Für die Organisation empfiehlt es sich, klare Verantwortlichkeiten festzulegen: Wer prüft welche Komponente, wer verifiziert Fixes, wer dokumentiert den Fortschritt für Audits? Ein einfacher CSV-Export mit den Spalten Kriterium, Status, Verantwortlicher und Nachweis reicht oft schon aus, um Compliance nachvollziehbar zu machen.

Profi-Tipp: Verknüpfen Sie jedes gefundene Problem in Ihrem Issue-Tracker direkt mit der Nummer des Erfolgskriteriums, etwa „2.4.7 Sichtbarer Fokus“. Das spart bei einem externen Audit enorm viel Zeit, weil die Nachvollziehbarkeit sofort gegeben ist.

Vollständige WCAG 2.2 Checkliste: Alle Erfolgskriterien im Detail

Die folgende Checkliste deckt sämtliche Erfolgskriterien der WCAG 2.2 ab und liefert zu jedem Punkt eine kurze Definition sowie eine konkrete Prüfaufgabe. Die offizielle Definition jedes Kriteriums samt Techniken findet sich in den Understanding-Seiten des W3C.

Prinzip 1: Wahrnehmbar

• 1.1.1 Textalternativen (A): Jedes Bild mit Informationsgehalt braucht einen Alt-Text, der die Funktion beschreibt, nicht nur das Motiv. Beispiel: Statt „Bild1.jpg“ schreiben Sie „Diagramm: Umsatzentwicklung 2023 bis 2026“. Automatisiert prüfbar, ob ein alt-Attribut existiert, aber nicht, ob es sinnvoll ist.
• 1.2.1 bis 1.2.9 Zeitbasierte Medien (A/AA/AAA): Videos brauchen Untertitel, Transkripte und bei AA-Anspruch Audiodeskription. Manuelle Prüfung notwendig, da Scanner Videoinhalte nicht bewerten können.
• 1.3.1 Info und Beziehungen (A): Überschriften, Listen und Tabellen müssen semantisch korrekt ausgezeichnet sein, nicht nur optisch wie eine Überschrift aussehen. Prüfen Sie mit dem Accessibility-Tree im Browser, ob <h2> tatsächlich als Überschrift interpretiert wird.
• 1.3.4 Ausrichtung (AA): Inhalte dürfen nicht auf eine Bildschirmausrichtung beschränkt sein, außer die Ausrichtung ist essenziell (etwa bei einer Klavier-App). Testen Sie durch Drehen des Geräts im Portrait- und Landscape-Modus.
• 1.3.5 Eingabezweck erkennen (AA): Formularfelder wie Name oder E-Mail sollten mit autocomplete-Attributen versehen sein, damit Passwortmanager und Assistenzsysteme sie korrekt zuordnen. Diese Verbindung zu Formularen wird auch bei den neuen Authentifizierungs-Kriterien in WCAG 2.2 relevant, dazu später mehr.
• 1.4.1 Farbe allein (A): Fehlermeldungen dürfen nicht nur durch rote Farbe markiert sein, es braucht zusätzlich ein Symbol oder einen Text.
• 1.4.3 Kontrast Minimum (AA): Text braucht ein Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund, große Schrift ab 24px mindestens 3:1. Tools wie der Chrome DevTools Kontrastprüfer oder Colour Contrast Analyser liefern hier exakte Werte, das Farbkontrast prüfen lässt sich also vollständig automatisieren.
• 1.4.4 Textgrösse anpassbar (AA): Text muss sich bis 200 % vergrössern lassen, ohne dass Inhalte verloren gehen oder horizontales Scrollen nötig wird. Prüfen Sie das mit der Browser-Zoomfunktion.
• 1.4.10 Reflow (AA): Bei einer Fensterbreite von 320px darf kein horizontales Scrollen für den Haupttext nötig sein. Kritisch für mobile Layouts.
• 1.4.11 Kontrast von Nicht-Text-Inhalten (AA): Buttons, Icons und Formularrahmen brauchen ebenfalls 3:1 Kontrast zur Umgebung, nicht nur Fliesstext.
• 1.4.13 Inhalt bei Hover oder Fokus (AA): Tooltips, die bei Hover erscheinen, müssen sich wegklicken lassen, dürfen den Mauszeiger nicht sofort verlieren und müssen bestehen bleiben, solange der Nutzer sie braucht.

Prinzip 2: Bedienbar

• 2.1.1 Tastatur (A): Jede Funktion muss ohne Maus erreichbar sein. Das ist der schnellste manuelle Test überhaupt: Maus weglegen, nur mit Tab, Enter und Pfeiltasten navigieren.
• 2.1.2 Keine Tastaturfalle (A): Der Fokus darf sich nicht in einem Modal oder Widget festsetzen, ohne dass ein Ausweg existiert. Häufiger Fehler bei selbstgebauten Dropdown-Menüs.
• 2.2.1 Zeitlimits anpassbar (A): Sitzungs-Timeouts müssen sich verlängern, deaktivieren oder anpassen lassen. Betrifft vor allem Login-Bereiche und Formulare mit Countdown.
• 2.4.3 Fokus-Reihenfolge (A): Die Tab-Reihenfolge muss der visuellen und logischen Struktur entsprechen. Ein falsches tabindex sorgt hier oft für Chaos.
• 2.4.6 Überschriften und Beschriftungen (AA): Überschriften müssen den nachfolgenden Inhalt präzise beschreiben, Formularlabels dürfen nicht generisch wie „Feld 1“ heissen.
• 2.4.7 Sichtbarer Fokus (AA): Der fokussierte Rahmen muss deutlich sichtbar sein, mit gutem Kontrast zur Umgebung. Ein outline: none ohne Ersatzlösung ist einer der häufigsten Fehler überhaupt.
• 2.5.1 Zeigergesten (A): Funktionen, die per Wischgeste oder Mehrfingergeste ausgelöst werden, brauchen eine Alternative mit einfachem Klick oder Tap.
• 2.5.3 Beschriftung im Namen (A): Der sichtbare Text eines Buttons muss im zugänglichen Namen enthalten sein, damit Spracheingabe-Nutzer den Button per Sprachbefehl treffen können.

Prinzip 3: Verständlich

• 3.1.1 Sprache der Seite (A): Das lang-Attribut im HTML-Tag muss korrekt gesetzt sein, sonst liest ein Screenreader deutschen Text mit falscher Aussprache vor.
• 3.2.1 Bei Fokus (A): Ein Element darf beim Erhalt des Fokus keinen unerwarteten Kontextwechsel auslösen, etwa ein automatisches Absenden eines Formulars.
• 3.3.1 Fehlererkennung (A): Formularfehler müssen textlich benannt werden, inklusive Angabe, welches Feld betroffen ist.
• 3.3.2 Beschriftungen oder Anweisungen (A): Pflichtfelder und Formatanforderungen, etwa „TT.MM.JJJJ“, müssen vor dem Absenden sichtbar sein.
• 3.3.3 Fehlervorschlag (AA): Wo möglich, sollte das System einen Korrekturvorschlag anbieten, etwa bei einer falsch formatierten Postleitzahl.

Prinzip 4: Robust

• 4.1.2 Name, Rolle, Wert (A): Custom-Widgets wie ein selbstgebautes Dropdown brauchen korrekte ARIA-Rollen und -Zustände, etwa role="listbox" und aria-expanded. Dies ist einer der häufigsten Stolpersteine bei modernen JavaScript-Frameworks.
• 4.1.3 Statusmeldungen (AA): Erfolgs- oder Fehlermeldungen, die dynamisch erscheinen, müssen per aria-live="polite" oder role="status" angekündigt werden, ohne dass der Fokus springt.

Bei den meisten dieser Kriterien lässt sich ein Grundgerüst automatisiert prüfen, doch die eigentliche Aussagekraft entsteht erst durch den manuellen Test. Ein Scanner erkennt, ob ein alt-Attribut vorhanden ist, aber nicht, ob „Foto“ als Alt-Text irgendeinen Nutzen hat. Genau diese Lücke zwischen technischer Prüfung und tatsächlicher Zugänglichkeit ist der Kern jeder seriösen Barrierefreiheitscheckliste.

Was ist neu in WCAG 2.2 gegenüber Version 2.1?

WCAG 2.2 ist keine Revolution, sondern eine gezielte Erweiterung. Neun neue Erfolgskriterien kommen hinzu, alle sind laut W3C abwärtskompatibel zu WCAG 2.1, sodass eine bestehende AA-Konformität nicht bricht, sondern ergänzt wird.

• 2.4.11 Fokus nicht verdeckt (Minimum, AA): Ein fokussiertes Element darf nicht vollständig von einem Sticky-Header oder Cookie-Banner überdeckt werden. Prüfen Sie speziell Formulare mit vielen Feldern, bei denen ein fixierter Header den unteren Bereich verdeckt.
• 2.4.12 Fokus nicht verdeckt (Erweitert, AAA): Die strengere Variante verlangt, dass der Fokus überhaupt nicht verdeckt wird, auch nicht teilweise.
• 2.4.13 Fokuserscheinungsbild (AAA): Definiert Mindestgrössen und Kontrastanforderungen für den Fokusindikator selbst.
• 2.5.7 Zieh-Bewegungen (AA): Jede Funktion, die per Drag-and-drop funktioniert, etwa das Neuanordnen einer Liste, braucht eine Alternative per einfachem Klick, zum Beispiel Pfeiltasten zum Verschieben.
• 2.5.8 Zielgrösse (Minimum, AA): Klickbare Elemente müssen mindestens 24×24 CSS-Pixel gross sein, ausser es gibt ausreichend Abstand zu Nachbarelementen. Betrifft vor allem mobile Buttons und Icon-Leisten.
• 3.2.6 Konsistente Hilfe (A): Wenn eine Website Hilfefunktionen wie einen Chat oder eine Kontaktseite anbietet, müssen diese auf jeder Seite an derselben Position im Seitenablauf erscheinen.
• 3.3.7 Redundante Eingabe (A): Informationen, die der Nutzer bereits in einem früheren Schritt eingegeben hat, dürfen im selben Prozess nicht nochmals abgefragt werden, ausser aus Sicherheitsgründen.
• 3.3.8 Barrierefreie Authentifizierung (Minimum, AA): Login-Prozesse dürfen keine kognitive Testfunktion wie das Merken eines Passworts ohne Alternative erzwingen. Passkeys, Magic Links oder Kompatibilität mit Passwortmanagern erfüllen dieses Kriterium.
• 3.3.9 Barrierefreie Authentifizierung (Erweitert, AAA): Strengere Variante, die zusätzlich Objekterkennungs-Captchas ausschliesst.

Für ein bestehendes Produkt mit sauberer WCAG 2.1 AA-Basis bedeutet das in der Praxis vor allem eines: Fokus-Styling überprüfen, Touch-Ziele nachmessen und den Login-Flow auf Alternativen zu reinem Passwort-Zwang durchsehen. Die neuen Kriterien rund um Drag-and-drop und Authentifizierung lassen sich kaum automatisiert testen, hier braucht es echte Klicktests.

Ein Blick auf die betroffenen Bereiche zeigt, wo der Aufwand am ehesten anfällt: Formulare (3.3.7, 3.3.8), mobile Interfaces (2.5.7, 2.5.8) und komplexe Layouts mit fixierten Elementen (2.4.11). Genau diese drei Bereiche sind auch die häufigste Fehlerquelle in bestehenden Webanwendungen.

Wie testen Sie WCAG 2.2 richtig: Tools, Screenreader und Nachweisführung

Automatisierte Tools sind der Einstieg, nicht das Ziel. Praktische Untersuchungen zeigen, dass automatisierte Tests nur rund 30 bis 40 % der tatsächlichen Barrierefreiheitsmängel abdecken. Der Rest verlangt einen Menschen, der mit Tastatur oder Screenreader arbeitet.

Für die Werkzeugwahl gilt eine einfache Faustregel: Lighthouse eignet sich für schnelle Checks während der Entwicklung, weil es direkt in Chrome DevTools integriert ist. axe DevTools liefert präzisere Ergebnisse und lässt sich in CI/CD-Pipelines einbinden, etwa über axe-core als npm-Paket. Pa11y wiederum eignet sich für automatisierte Batch-Scans über mehrere URLs hinweg, etwa bei einem Relaunch mit hunderten Seiten. Keines dieser Tools erkennt jedoch, ob ein Alt-Text inhaltlich sinnvoll ist oder ob eine ARIA-Live-Region tatsächlich sinnvoll vorgelesen wird.

Der manuelle Prüfablauf, der sich bewährt hat, sieht so aus:

1. Tastatur-Durchlauf: Jede Seite ohne Maus bedienen, dabei auf Fokusreihenfolge, sichtbaren Fokus und erreichbare Funktionen achten.
2. Screenreader-Test mit NVDA oder VoiceOver: Kritische Journeys wie Checkout oder Registrierung mit geschlossenen Augen durchgehen, um zu prüfen, ob Ansagen Sinn ergeben.
3. Kognitive Testfälle: Prüfen, ob Formulare klare Anweisungen geben, Fehlermeldungen verständlich sind und keine unnötige Komplexität entsteht.
4. Nutzertest mit realen Betroffenen: Für kritische Prozesse lohnt sich ein Test mit drei bis fünf Personen, die tatsächlich Screenreader, Schalter oder Vergrösserungssoftware im Alltag nutzen.

Für die Dokumentation reicht ein strukturierter Audit-Report, der pro gefundenem Problem folgende Punkte festhält: betroffenes Erfolgskriterium, Seite oder Komponente, Schweregrad, Screenshot oder Codeausschnitt und empfohlene Lösung. Diese Struktur lässt sich in ein Ticketsystem übernehmen und dient als Nachweis gegenüber Auftraggebern oder Aufsichtsbehörden.

Profi-Tipp: Bauen Sie mindestens einen automatisierten Accessibility-Test in Ihre CI/CD-Pipeline ein, der bei jedem Pull-Request läuft. Das verhindert, dass bereits behobene Fehler durch neue Features unbemerkt zurückkehren. Ein strukturierter Ansatz zur Testautomatisierung für Webapps zeigt, wie sich solche Prüfungen sinnvoll in bestehende Entwicklungsprozesse integrieren lassen.

Wie priorisieren Sie die Umsetzung und wie viel Aufwand ist realistisch?

Nicht jedes Erfolgskriterium verdient dieselbe Priorität am ersten Tag. Eine sinnvolle Priorisierung wägt drei Faktoren gegeneinander ab: das Risiko für Nutzer, den Umsetzungsaufwand und die rechtliche Relevanz für die jeweilige Organisation.

Kritische Blocker wie fehlende Tastaturbedienbarkeit oder unsichtbarer Fokus gehören immer an die Spitze der Liste, weil sie Nutzer komplett aussperren. Kontrastfehler und fehlende Alt-Texte folgen direkt danach, weil sie sich meist mit überschaubarem Aufwand beheben lassen. Komplexere Themen wie eine vollständige ARIA-Überarbeitung von Custom-Komponenten oder die Umstellung der Authentifizierung auf Passkeys brauchen mehr Planung und gehören eher in einen späteren Sprint.

Ein realistischer Zeitplan für ein mittelgrosses Projekt sieht häufig so aus: In der ersten Phase, dem MVP, werden kritische Blocker und die häufigsten automatisiert erkennbaren Fehler behoben, das dauert je nach Seitenumfang zwei bis vier Wochen. Die zweite Phase zielt auf vollständige AA-Konformität, inklusive manueller Screenreader-Tests für alle kritischen Journeys, hierfür sollten vier bis acht Wochen eingeplant werden. Die dritte Phase, der Feinschliff, deckt AAA-Ziele und wiederkehrende Audits ab und läuft meist kontinuierlich weiter.

Budgethinweise hängen stark vom Bestand ab: Ein Projekt, das von Grund auf mit einem durchdachten Designsystem aufgebaut wird, bei dem Fokus-Styling, Kontrastwerte und Touch-Ziel-Grössen als Tokens definiert sind, spart gegenüber nachträglichen Korrekturen erheblich Zeit. Nachträgliche Fixes in einem gewachsenen System sind fast immer teurer, weil sich Muster wiederholen, die einzeln korrigiert werden müssen.

Ein wiederkehrender Audit-Zyklus, etwa quartalsweise, verhindert, dass neue Features unbemerkt neue Barrieren einführen. Das ist günstiger als ein grosses Nachprüfungsprojekt alle paar Jahre.

Welche rechtlichen Vorgaben gelten für WCAG 2.2 in der Schweiz?

Der rechtliche Rahmen für digitale Barrierefreiheit ist in der Schweiz im Wandel. Das Behindertengleichstellungsgesetz (BehiG) verpflichtet aktuell vor allem öffentliche Stellen zu barrierefreien Online-Angeboten, während private Unternehmen bislang nicht flächendeckend gesetzlich dazu verpflichtet sind. Eine Revision des BehiG mit erweiterten Pflichten ist jedoch in Vorbereitung, wie eine rechtliche Analyse zeigt.

• Öffentliche Stellen orientieren sich beim technischen Umsetzungsstandard meist an eCH-0059, dem Schweizer Referenzstandard, der sich eng an WCAG anlehnt.
• Für Unternehmen mit Bezug zum EU-Markt ist der European Accessibility Act (EAA) relevant, dessen Übergangsfristen bereits laufen und der auch Schweizer Anbieter betrifft, die Produkte oder Dienstleistungen in der EU anbieten.
• Die geplante BehiG-Revision deutet auf strengere Pflichten für private Anbieter hin, weshalb ein frühzeitiges Umsetzen von WCAG 2.2 das spätere Risiko einer Nachrüstung unter Zeitdruck reduziert.
• EN 301 549, der europäische Beschaffungsstandard für barrierefreie IKT, verweist direkt auf WCAG-Erfolgskriterien und dient vielen Ausschreibungen als Referenz.

Wer heute schon nach WCAG 2.2 AA arbeitet, ist für kommende Verschärfungen bereits vorbereitet, unabhängig davon, wie genau die finale Gesetzesfassung aussieht. Das ist der pragmatischste Grund, warum sich proaktives Handeln lohnt: Normen und Gesetze folgen der technischen Praxis meist mit Verzögerung, nicht umgekehrt.

Praxis-Perspektive: Wie unterstützt Outwork Unternehmen bei WCAG 2.2

Outwork begleitet Unternehmen bei Softwareentwicklung, Webplattformen und digitaler Transformation, und Barrierefreiheit ist dabei kein nachträglicher Prüfschritt, sondern Teil des Entwicklungsprozesses von Anfang an. Automatisierte Accessibility-Checks lassen sich direkt in bestehende CI/CD-Pipelines integrieren, sodass Regressionen auffallen, bevor sie live gehen.

Der wirksamste Hebel liegt nicht im nachträglichen Audit, sondern im Designsystem: Wer Fokus-Styling, Kontrastwerte und Touch-Ziel-Grössen als wiederverwendbare Komponenten definiert, verhindert die meisten WCAG-Verstösse, bevor sie überhaupt entstehen.

Ein UX-Audit-Ablauf, der automatisierte Scans, manuelle Screenreader-Durchläufe und punktuelle Nutzertests kombiniert, deckt Probleme auf, die reine Tool-Scans übersehen. Für Unternehmen, die ihre bestehende Webplattform oder App auf WCAG 2.2 prüfen und umsetzen lassen möchten, bietet die Softwareentwicklung von Outwork eine praxisnahe Anlaufstelle für Umsetzung und laufende Betreuung.

Was die Praxis über WCAG 2.2 wirklich zeigt

Die grösste Fehleinschätzung rund um WCAG 2.2 ist, dass Barrierefreiheit primär ein rechtliches Risiko sei, das man mit einem einmaligen Audit abhakt. Genau das ist der Denkfehler, der Projekte teuer macht. Wer Fokus-Styling, Kontrast und Touch-Ziele erst am Ende einer Entwicklung prüft, zahlt doppelt: einmal für den ursprünglichen Code, einmal für die Korrektur.

Die konventionelle Herangehensweise setzt zu stark auf automatisierte Scanner. Ein grüner Haken bei einem Tool wie Lighthouse fühlt sich nach Erledigung an, sagt aber wenig über die tatsächliche Nutzbarkeit für jemanden mit Screenreader aus.

Was Unternehmen zuerst angehen sollten, ist nicht die vollständige AAA-Konformität, sondern die Verankerung von Barrierefreiheit im Designsystem. Das ist der Hebel mit der besten Wirkung pro investierter Stunde, weil er verhindert, dass dieselben Fehler in jeder neuen Komponente wieder auftauchen.

— Outwork

Empfehlungen

• UX Audit Website: Praxisleitfaden für Entscheider
• Design System aufbauen: Der pragmatische Leitfaden für Teams
• WordPress für Unternehmen: Der ehrliche Praxisguide 2026