Zuletzt fachlich geprüft und aktualisiert am 3. September 2026.
WCAG 2.2 ist ein technischer Standard mit testbaren Erfolgskriterien. Für Unternehmen ist meist Stufe AA der praktische Zielrahmen. Ein automatischer Scan reicht nicht. Code, Design, Inhalte und reale Bedienwege müssen gemeinsam geprüft werden.
Dieser Leitfaden zeigt, wie Sie WCAG 2.2 für Ihr Unternehmen fundiert planen, umsetzen und prüfen.
Auf einen Blick
- WCAG 2.2 folgt den Prinzipien wahrnehmbar, bedienbar, verständlich und robust.
- Die Erfolgskriterien sind in A, AA und AAA eingeteilt.
- Version 2.2 ergänzt neun Kriterien gegenüber WCAG 2.1.
- Automatische und manuelle Tests gehören zusammen.
Barrierefreiheit wirkt auf den ersten Blick wie eine lange technische Liste. Die WCAG ordnet diese Liste in vier verständliche Prinzipien. Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.
Für Unternehmen ist wichtig, wie diese Kriterien in Design, Entwicklung und Redaktion übersetzt werden. Ein einmaliger Audit findet Probleme. Ein guter Prozess verhindert, dass neue Inhalte dieselben Barrieren zurückbringen.
Vier Prinzipien als gemeinsamer Rahmen
Wahrnehmbar bedeutet, dass Informationen nicht nur über einen Sinn verfügbar sind. Bilder brauchen passende Alternativen. Kontrast und Vergrößerung dürfen Inhalte nicht zerstören.
Bedienbar betrifft Tastatur, Fokus, Zeitlimits und Zielgrößen. Verständlich fordert klare Sprache, konsistente Hilfe und gute Fehlerhinweise. Robust bedeutet, dass assistierende Technik Struktur und Zustände zuverlässig erkennt.
A, AA und AAA richtig einordnen
Stufe A enthält grundlegende Anforderungen. AA ergänzt wichtige Kriterien für breite Nutzbarkeit. AAA umfasst weitergehende Ziele, die nicht immer für sämtliche Inhalte erreichbar sind.
Eine Konformitätsaussage gilt nur, wenn alle anwendbaren Kriterien der gewählten Stufe erfüllt sind. Einzelne grüne Tests ergeben noch keine vollständige Konformität. Scope, Seitenauswahl und Prüfmethodik müssen dokumentiert sein.
Was WCAG 2.2 neu ergänzt
Version 2.2 ergänzt unter anderem sichtbaren Fokus, Mindestzielgrößen, konsistente Hilfe, weniger doppelte Eingaben und zugängliche Authentifizierung. Diese Kriterien richten den Blick stärker auf reale Bedienwege.
Prüfen Sie besonders Formulare, Logins, Menüs, Dialoge und wiederkehrende Hilfen. Viele Probleme entstehen nicht in einem statischen Absatz, sondern in Interaktionen und Zustandswechseln.
- Fokus darf nicht durch andere Inhalte verdeckt werden.
- Ziele brauchen ausreichende Größe oder Abstand.
- Hilfe muss auf wiederkehrenden Seiten konsistent erreichbar sein.
- Authentifizierung darf keine unnötigen kognitiven Hürden erzwingen.
Audit und laufende Verantwortung
Ein Audit kombiniert automatisierte Tests, Codeprüfung, Tastaturbedienung, Screenreader-Stichproben und visuelle Prüfung. Wählen Sie repräsentative Vorlagen und wichtige Nutzerwege statt nur der Startseite.
Danach braucht jeder Befund Eigentümer, Priorität und Abnahmekriterium. Schulen Sie Redaktion und Entwicklung passend zu ihrer Aufgabe. Neue Komponenten werden vor Freigabe geprüft.
WCAG 2.2 in sieben Schritten umsetzen
- Definieren Sie Geltungsbereich und Zielstufe.
- Inventarisieren Sie Vorlagen, Komponenten und wichtige Nutzerwege.
- Kombinieren Sie automatische und manuelle Prüfmethoden.
- Priorisieren Sie Blockaden vor rein formalen Abweichungen.
- Beheben Sie Ursachen in Komponenten statt Einzelfälle.
- Prüfen Sie Änderungen mit dokumentierten Abnahmekriterien.
- Verankern Sie Schulung und regelmäßige Wiederholungsprüfungen.
Typische Fehler und wie Sie diese vermeiden
- Einen automatischen Score mit WCAG-Konformität gleichsetzen.
- Nur die Startseite und keine Formulare oder Dialoge testen.
- Einzelfehler beheben, obwohl die gemeinsame Komponente falsch ist.
- Redaktion und laufende Inhaltspflege aus dem Prozess auslassen.
Rechtliche Anforderungen ergeben sich nicht allein aus WCAG. BFSG, nationale Regeln, Verträge und Beschaffung können zusätzliche Vorgaben schaffen. Lassen Sie den konkreten Geltungsbereich prüfen.
Der Standard ist international. Für deutschsprachige Inhalte kommen klare Sprache, verständliche Fehlermeldungen und gute Übersetzungen hinzu. Dieser Beitrag ersetzt keine Rechtsberatung.
Prüffragen für Ihr Unternehmen
- Welche Zielstufe und welcher Scope sind verbindlich?
- Werden wichtige Abläufe vollständig per Tastatur getestet?
- Gibt es Screenreader- und Zoom-Prüfungen?
- Wie verhindert die Redaktion neue Barrieren?
WCAG 2.2: So verankern Sie das Thema im Betrieb
Ein guter Leitfaden wird erst wertvoll, wenn aus WCAG 2.2 ein wiederholbarer Arbeitsablauf entsteht. Legen Sie deshalb vor dem Start Ausgangslage, Ziel, Verantwortliche und Prüftermin fest. Der folgende Rahmen macht Fortschritt sichtbar und verhindert Aktionismus.
1. Bestand und Ausgangswert sichern
Erfassen Sie Seitentypen, Komponenten, Formulare, Schnittstellen und redaktionelle Sonderfälle. Priorisieren Sie nach Nutzung, Umsatznähe und Fehlerrisiko. Eine Prüfung einzelner Muster ist erst dann aussagekräftig, wenn alle betroffenen Varianten bekannt sind.
Halten Sie den Ausgangswert in einem gemeinsamen Dokument fest. Notieren Sie Datenquelle, Zeitraum und bekannte Lücken. Ein sauberer Ausgangspunkt schützt davor, normale Schwankungen später als Erfolg oder Fehler zu deuten.
2. Wirkung mit einer kleinen Messkette prüfen
Verbinden Sie technische Kennzahlen mit erfolgreichen Nutzeraufgaben. Messen Sie Ladeverhalten, Interaktion, Formularabschlüsse und Fehlermeldungen. Ergänzen Sie manuelle Prüfungen mit Tastatur, Screenreader und unterschiedlichen Darstellungsgrößen. Automatische Werkzeuge allein reichen nicht aus.
Für jede Kennzahl braucht es eine eindeutige Definition. Legen Sie außerdem fest, wer sie prüft und welche Entscheidung daraus folgen kann. Kennzahlen ohne mögliche Handlung erzeugen Berichte, aber keine bessere Steuerung.
3. Verantwortung und Qualität absichern
Produktverantwortung priorisiert Anforderungen und Abnahmekriterien. Design und Entwicklung prüfen Komponenten bereits vor dem Einbau. Redaktion achtet auf Überschriften, Alternativtexte und verständliche Hinweise. Der Betrieb dokumentiert Updates, Tests und bekannte Einschränkungen.
Die Freigabe sollte fachliche Richtigkeit, Markensprache, Datenschutz und technische Funktion abdecken. Je höher das Risiko einer Aussage, desto klarer muss der Nachweis sein. Im DACH-Raum zählen belastbare Belege meist mehr als besonders laute Versprechen.
4. Einen realistischen Prüfrhythmus festlegen
Prüfen Sie kritische Funktionen nach jeder relevanten Änderung. Führen Sie monatlich einen technischen Kurzcheck und quartalsweise eine Prüfung wichtiger Nutzerwege durch. Erkenntnisse fließen in Komponenten und Redaktionsregeln ein, damit derselbe Fehler nicht erneut entsteht.
Beginnen Sie mit einem begrenzten Bereich, der genug Daten und echtes Lernpotenzial bietet. Skalieren Sie erst, wenn Ablauf und Messung funktionieren. So wächst ein tragfähiger Standard, der auch bei neuen Personen oder Kanälen bestehen bleibt.
Häufige Fragen
Was ist der Unterschied zwischen WCAG 2.1 und 2.2?
WCAG 2.2 ergänzt neun Erfolgskriterien. Bestehende Kriterien bleiben weitgehend erhalten. W3C empfiehlt die neueste Version.
Reicht WCAG AA für das BFSG?
Das lässt sich nicht pauschal gleichsetzen. Technische Normen und konkrete Rechtsanforderungen müssen für den jeweiligen Dienst geprüft werden.
Kann ein Tool WCAG-Konformität bestätigen?
Nein. Tools finden bestimmte Muster. Viele Kriterien brauchen manuelle Prüfung, Kontext und reale Bedienung.
Quellen und Vertiefung
Passende nächste Schritte
Vertiefen Sie das Thema mit unserer Barrierefreiheits-Leistung, der Webentwicklung.
Prüfen Sie wichtige Nutzerwege zuerst
Der BFSG-Quick-Check schafft eine erste Übersicht über technische und redaktionelle Barrieren.
Weiterlesen und prüfen
WCAG 2.2 an konkreten Bedienwegen prüfen
Die folgenden Beispiele greifen typische Probleme aus der früheren Einführung auf. Die verbindlichen Anforderungen und Ausnahmen stehen in der W3C-Übersicht zu WCAG 2.2.
| Situation | Prüfung |
|---|---|
| Ein feststehender Banner überlagert Bedienelemente | Mit der Tastatur weitergehen. Bei AA darf das fokussierte Element nicht vollständig durch selbst erstellte Inhalte verdeckt sein. Die weitergehende AAA-Anforderung ist davon zu unterscheiden. |
| Ein Regler funktioniert nur durch Ziehen | Eine Bedienmöglichkeit mit einzelnem Zeiger ohne Ziehbewegung prüfen; notwendige Ausnahmen fachlich bewerten. |
| Ein Formular verlangt dieselben Angaben erneut | Prüfen, ob bereits eingegebene Informationen im selben Prozess übernommen oder auswählbar gemacht werden können. |
| Ein Login blockiert Passwortmanager oder Einfügen | Authentifizierung ohne unnötige Gedächtnisaufgabe ermöglichen und den vollständigen Anmeldeweg testen. |
Notieren Sie jeweils den konkreten Ablauf und die betroffene Komponente. Ein behobener Banner auf einer Seite genügt nicht, wenn dieselbe Komponente auf anderen Seiten weiterhin Inhalte verdeckt.
