WCAG 2.2 Anforderungen verstehen und umsetzen

Die Web Content Accessibility Guidelines (WCAG) 2.2 sind der aktuelle internationale Standard für digitale Barrierefreiheit. Diese Seite bietet einen technischen Überblick für Produktteams, Entwickler, UX- und QA-Teams – mit Fokus auf praxisnahe Umsetzung, typische Fehlerquellen und einen strukturierten Remediation-Ablauf.

Hinweis: Diese Informationen dienen der allgemeinen Orientierung und ersetzen keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten, hängt vom konkreten Angebot, vom Adressatenkreis und von der tatsächlichen Ausgestaltung der Dienstleistung ab.

Kurzantwort (TL;DR)

WCAG 2.2 erweitert WCAG 2.1 um neun neue Erfolgskriterien, die vor allem motorische Einschränkungen, kognitive Belastung und mobile Nutzung adressieren. Für Websites und Shops in Deutschland sind diese Kriterien je nach Angebot über das Barrierefreiheitsstärkungsgesetz (BFSG) und die harmonisierte Norm EN 301 549 relevant. Eine seriöse Konformitätsbewertung erfordert immer eine Einzelfallprüfung – kein automatisches Tool kann eine vollständige WCAG-Konformität abbilden.

Die vier WCAG-Prinzipien (POUR) im Überblick

Alle Erfolgskriterien der WCAG basieren auf vier übergeordneten Prinzipien, die unter dem Akronym POUR zusammengefasst werden:

• Perceivable (Wahrnehmbar): Informationen und UI-Komponenten müssen für die Sinne der Nutzer:innen wahrnehmbar sein – etwa durch Textalternativen, ausreichende Kontraste und anpassbare Darstellung.
• Operable (Bedienbar): Bedienelemente und Navigation müssen mit unterschiedlichen Eingabemethoden (Tastatur, Sprache, Touch, Assistenztechnologie) nutzbar sein.
• Understandable (Verständlich): Inhalte und Bedienkonzepte müssen klar, vorhersehbar und nachvollziehbar sein.
• Robust (Robust): Inhalte müssen so umgesetzt sein, dass sie von aktuellen und zukünftigen User-Agents – einschließlich assistiver Technologien – zuverlässig interpretiert werden können.

Vertiefung: WCAG-Grundlagen und POUR-Prinzipien sowie POUR in der Barrierefreiheit.

Neu in WCAG 2.2 gegenüber WCAG 2.1

WCAG 2.2 ergänzt neun neue Erfolgskriterien. Praxisrelevant sind insbesondere:

Bedienbarkeit und Eingabe

• 2.4.11 / 2.4.12 Focus Not Obscured (AA / AAA): Der Tastatur-Fokus darf nicht vollständig von anderen UI-Elementen (z. B. Cookie-Bannern, Sticky-Headern) verdeckt werden.
• 2.4.13 Focus Appearance (AAA): Strengere Vorgaben an Größe und Kontrast der Fokusanzeige.
• 2.5.7 Dragging Movements (AA): Funktionen, die Drag-Gesten nutzen, müssen auch über einen einfachen Klick oder Tap erreichbar sein.
• 2.5.8 Target Size (Minimum) (AA): Interaktive Ziele sollen mindestens 24 × 24 CSS-Pixel groß sein (mit definierten Ausnahmen).

Verständlichkeit und kognitive Last

• 3.2.6 Consistent Help (A): Hilfsangebote (z. B. Kontakt, Chat, FAQ) müssen an konsistenter Position erscheinen.
• 3.3.7 Redundant Entry (A): Bereits eingegebene Informationen dürfen im selben Prozess nicht erneut manuell abgefragt werden.
• 3.3.8 / 3.3.9 Accessible Authentication (AA / AAA): Login-Prozesse dürfen nicht ausschließlich auf kognitiven Tests (z. B. Erinnern von Zeichen, Lösen von Rätseln) basieren.

Nicht mehr enthalten

• 4.1.1 Parsing wurde aus WCAG 2.2 entfernt, da moderne Browser entsprechende Probleme weitgehend tolerieren.

Bezug zu BFSG und EN 301 549

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt seit dem 28. Juni 2025 die EU-Richtlinie 2019/882 (European Accessibility Act) in Deutschland um und kann je nach Produkt- und Dienstleistungstyp – etwa bei elektronischem Geschäftsverkehr – auch Websites und Online-Shops betreffen. Als technischer Maßstab gilt die harmonisierte Norm EN 301 549, die WCAG (in der jeweils referenzierten Fassung) als Grundlage für Webinhalte übernimmt und um zusätzliche Anforderungen ergänzt. Ob WCAG 2.1 oder 2.2 im konkreten Fall normativ herangezogen wird, hängt vom Stand der Norm-Referenzierung und vom Einzelfall ab. Eine fundierte Bewertung erfordert eine individuelle Prüfung des Angebots, des Adressatenkreises und der Ausnahmetatbestände – mehr dazu unter EN 301 549 in der Praxis.

Typische Fehler in Websites und Shops

Aus unseren Audits wiederkehrende technische Mängel:

• Bilder ohne sinnvolle Alternativtexte oder dekorative Bilder, die fälschlich vorgelesen werden.
• Unzureichende Farbkontraste bei Text, Icons und Fokusindikatoren.
• Tastaturfallen in Modals, Karussells und Custom-Komponenten.
• Fokus wird von Cookie-Bannern, Headern oder Chat-Widgets verdeckt (Verstoß gegen 2.4.11).
• Fehlende oder falsche ARIA-Rollen – z. B. role="button" auf einem <div>, das nicht per Tastatur bedienbar ist.
• Formulare ohne programmatisch verknüpfte Labels oder ohne klare Fehlermeldungen.
• Drag-only-Interaktionen in Filtern, Slidern oder Sortierfunktionen (Verstoß gegen 2.5.7).
• Zu kleine Touch-Targets in mobilen Navigationen und Checkout-Buttons.
• Login-Prozesse mit kognitiven Hürden (z. B. Captchas ohne Alternative).
• Dynamische Inhaltsänderungen ohne aria-live, die Screenreader-Nutzende nicht mitbekommen.
• PDF-Dokumente und eingebettete Inhalte (Karten, Videos, iFrames), die nicht barrierefrei aufbereitet sind.
• Strukturelle Probleme: Überschriftenhierarchien werden übersprungen, Landmarks fehlen.

Remediation in der Praxis: So gehen wir vor

Unser Remediation-Ablauf ist auf Produkt- und Entwicklungsteams zugeschnitten und integriert sich in bestehende Sprints und CI/CD-Prozesse.

1. Scoping & Inventory

Definition des Prüfumfangs (Templates, kritische User-Journeys, Checkout, Login), Festlegung der relevanten Konformitätsstufe (in der Regel AA) und Klärung der Norm-Referenzen.

2. Technisches Audit

Kombination aus automatisiertem Scanning (axe-core, Lighthouse, Pa11y), manuellen Tests (Tastatur, Screenreader-Tests mit NVDA/JAWS/VoiceOver) und Code-Review. Ergebnis: priorisiertes Findings-Backlog mit Severity, betroffenen Erfolgskriterien und Codestellen.

3. Priorisierung & Roadmap

Gruppierung nach Impact (Blocker, kritisch, moderat, kosmetisch) und Aufwand. Quick Wins werden separat ausgewiesen, strukturelle Themen (Design-System, Komponentenbibliothek) als mittelfristige Workstreams geplant.

4. Umsetzung & Pairing

Direkte Unterstützung der Entwickler:innen via Pull-Request-Reviews, Pairing-Sessions und konkrete Code-Beispiele – inklusive Komponentenrefactorings (z. B. Modals, Tabs, Custom-Selects).

5. Verifikation

Re-Test der behobenen Findings, Regressionstests und Aufbau automatisierter Accessibility-Checks in der Pipeline (z. B. axe-linter, Storybook-a11y-Addon).

6. Dokumentation & Monitoring

Erstellung einer technischen Dokumentation zum erreichten Stand, Empfehlungen für die Erklärung zur Barrierefreiheit und Setup für laufendes Monitoring.

Mehr dazu: Accessibility-Remediation für Websites und Shops.

Wichtig: Was Tools leisten – und was nicht

Automatisierte Testwerkzeuge sind ein wertvoller Bestandteil jedes Audits, decken aber typischerweise nur 20–40 % der Erfolgskriterien zuverlässig ab. Kontextuelle Aspekte – z. B. sinnvolle Alternativtexte, logische Lesereihenfolge, Verständlichkeit von Formulardialogen oder die Bedienbarkeit komplexer Widgets – erfordern manuelle Prüfung und Expertise.

Kein Tool kann eine vollständige WCAG-Konformität sicherstellen. Eine belastbare Konformitätsbewertung setzt eine Einzelfallprüfung durch erfahrene Prüfer:innen voraus, die technische, gestalterische und inhaltliche Dimensionen zusammenführt.

Konkrete nächste Schritte

1. Bestandsaufnahme: Definieren Sie kritische Templates und User-Journeys (Startseite, Produktdetailseite, Suche, Warenkorb, Checkout, Login).
2. Quick-Scan: Führen Sie einen automatisierten Scan auf den wichtigsten Seiten durch, um grobe Defizite sichtbar zu machen.
3. Manuelle Stichproben: Testen Sie zentrale Flows ausschließlich per