WCAG-Checkliste (AA): Alle Anforderungen nach WCAG 2.2 – mit PDF

Aktualisiert im Oktober 2026: jetzt mit allen neuen Kriterien aus WCAG 2.2, der neuen EU-Norm EN 301 549 und einer ehrlichen Antwort auf die Frage, ob das BFSG für deine Software gilt.

Stell dir vor, du lässt deine Startseite automatisch auf Barrierefreiheit prüfen. Die Chance, dass sie durchfällt, liegt bei fast 96 %. Genau so viele von einer Million untersuchten Startseiten hatten erkennbare WCAG-Fehler, im Schnitt 56 pro Seite (WebAIM Million 2026).

Seit September gibt es einen zweiten Grund, genauer hinzuschauen: Die europäische Norm EN 301 549 stellt auf WCAG 2.2 um.

Die Kurzfassung: WCAG AA ist die Stufe, die Gesetze und Normen in Europa verlangen. WCAG 2.2 schließt WCAG 2.1 ein. Wer 2.2 AA erfüllt, erfüllt also auch 2.1 AA. Neu sind sechs Kriterien auf Stufe A und AA, ein altes ist weggefallen. Diese WCAG-Checkliste zeigt dir alle Punkte in fünf Schritten, wer im Team zuständig ist und wie du sie selbst testest.

Lade dir die WCAG-2.2-Checkliste als PDF herunter – kostenlos und druckbar.

Was ist neu in WCAG 2.2?

WCAG 2.2 ist seit dem 5. Oktober 2023 eine offizielle Empfehlung des W3C. Gegenüber WCAG 2.1 kamen neun Erfolgskriterien dazu. Sechs davon betreffen die Stufen A und AA und sind damit für dich relevant (W3C: What's New in WCAG 2.2).

Ein Kriterium ist weggefallen: 4.1.1 Parsing. Es prüfte fehlerfreien HTML-Code und gilt heute als überholt.

2.4.11 Fokus nicht verdeckt (Minimum)

Wer per Tastatur navigiert, muss sehen, wo der Fokus gerade ist. Das klassische Problem in Web-Apps: Ein Header, der beim Scrollen stehen bleibt, oder ein Cookie-Banner liegt genau über dem Feld, das gerade den Fokus hat. Auf Stufe AA darf das fokussierte Element nicht vollständig verdeckt sein. Teilweise ist erlaubt, aber kein schönes Ziel. Eine einfache Lösung ist scroll-padding-top in der Höhe des Headers.

2.5.7 Ziehbewegungen

Drag & Drop ist für viele Menschen mit motorischen Einschränkungen schwer oder gar nicht machbar. Deshalb muss jede Funktion, die Ziehen nutzt, auch mit einem einfachen Klick oder Tipp funktionieren. Beispiel Kanban-Board: Neben dem Ziehen gibt es ein Menü „Verschieben nach …". Beim Slider gibt es zusätzlich Plus- und Minus-Buttons oder ein Eingabefeld. Mehr dazu in meinem Artikel zur motorischen Barrierefreiheit.

2.5.8 Zielgröße (Minimum)

Klickziele müssen mindestens 24 × 24 CSS-Pixel groß sein. Kleinere Ziele sind erlaubt, wenn genug Abstand drumherum ist: Ein Kreis mit 24 px Durchmesser um jedes kleine Ziel darf kein anderes Ziel berühren. Ausgenommen sind außerdem Links im Fließtext und Elemente, deren Größe der Browser bestimmt.

Typischer Fall in SaaS: Die kleinen Icons in einer Tabellenzeile (Bearbeiten, Duplizieren, Löschen), dicht nebeneinander. Das ist nicht nur ein Barrierefreiheitsproblem. Hier löscht auch der gesunde Nutzer mit Maus mal aus Versehen den falschen Datensatz.

3.2.6 Konsistente Hilfe

Wenn dein Produkt Hilfe anbietet, also Kontaktdaten, ein Kontaktformular, eine FAQ oder einen Chatbot, dann muss sie auf allen Seiten an derselben Stelle in derselben Reihenfolge stehen. Wer Hilfe braucht, sucht sie nicht jedes Mal neu. Die gute Nachricht: Das Kriterium verlangt nicht, dass du Hilfe anbietest. Es verlangt nur, dass sie konsistent ist, wenn es sie gibt.

3.3.7 Redundante Eingabe

Informationen, die jemand im selben Prozess schon eingegeben hat, dürfen nicht noch einmal abgefragt werden. Sie müssen automatisch ausgefüllt oder zur Auswahl angeboten werden. Klassiker: Im Checkout die Lieferadresse und dann noch mal die Rechnungsadresse, ohne Häkchen „Gleich wie Lieferadresse". Oder im Onboarding den Firmennamen in Schritt 1 und dann noch mal in Schritt 4. Ausnahmen gibt es für Sicherheit (Passwort bestätigen) und wenn die alten Daten nicht mehr gültig sind.

3.3.8 Barrierefreie Authentifizierung (Minimum)

Ein Login darf keinen „kognitiven Funktionstest" voraussetzen, also kein Merken, Abtippen oder Rätsellösen, außer es gibt eine Alternative oder eine Hilfe. Als Hilfe zählen laut W3C ausdrücklich Passwort-Manager und Kopieren & Einfügen. Heißt in der Praxis:

• Einfügen in Passwort- und Code-Felder nicht blockieren

• autocomplete-Attribute setzen, damit Passwort-Manager funktionieren

• Rätsel-CAPTCHAs nur mit Alternative. Bilderkennung („Klicke alle Ampeln an") ist auf Stufe AA erlaubt.

• Login per E-Mail-Link oder Passkey ist eine gute Alternative

Wie große Organisationen das umsetzen

Ein gutes, öffentliches Beispiel ist das Designsystem des britischen Gesundheitsdienstes NHS. Das Team hat für jedes neue Kriterium dokumentiert, welche Komponenten betroffen sind: Header und Fokus-Stil für 2.4.11, Buttons und Icons für 2.5.8, Auswahlfelder und Aufgabenlisten für 2.5.7, Zurück-Link und Fehlermeldungen für 3.3.7, Header und Footer für 3.2.6 (NHS Service Manual).

Die Lehre für SaaS-Teams: WCAG 2.2 setzt du am effizientesten im Designsystem um, nicht Screen für Screen. Einmal den Button richtig, und er ist es überall.

Muss ich WCAG 2.1 oder 2.2 erfüllen?

Kurz: Rechtlich reicht in der EU gerade noch WCAG 2.1 AA. Planen solltest du aber mit 2.2.

Der Hintergrund: Gesetze wie das BFSG schreiben nicht direkt die WCAG vor. Sie verweisen auf die europäische Norm EN 301 549. Die gültige Fassung V3.2.1 von 2021 basiert auf WCAG 2.1 AA. Am 2. September 2026 wurde die neue Fassung V4.1.1 veröffentlicht, sie übernimmt alle A- und AA-Anforderungen aus WCAG 2.2 (AccessibleEU, EU-Kommission).

Rechtlich maßgeblich wird die neue Fassung erst, wenn die EU-Kommission sie im Amtsblatt veröffentlicht. Laut Fachbeiträgen ist das vorläufig für den 30. November 2026 geplant (Pivotal Accessibility).

Meine Empfehlung: Wenn du jetzt ein Feature planst, einen Audit machst oder dein Designsystem anfasst, nimm direkt 2.2 als Maßstab. Alles andere ist doppelte Arbeit in ein paar Monaten.

Und WCAG 3? Ist ein unvollständiger Entwurf. Laut W3C wird WCAG 3 erst in einigen Jahren fertig, und WCAG 2 bleibt danach noch lange gültig (W3C). Kein Grund zu warten.

WCAG, BITV 2.0, EN 301 549, BFSG: Was gilt für wen?

Die Abkürzungen gehen schnell durcheinander. Hier die Übersicht:

Du suchst eine BITV-2.0-Checkliste? Die BITV verweist auf die EN 301 549 und damit auf die WCAG. Diese Checkliste deckt die technischen Anforderungen also ab. Zusätzlich verlangt die BITV eine Erklärung zur Barrierefreiheit und einen Feedback-Mechanismus.

Gilt das BFSG für meine Software?

Ehrliche Antwort: kommt drauf an, wer deine Kunden sind. Die Bundesfachstelle Barrierefreiheit schreibt dazu: „Das Gesetz gilt daher grundsätzlich nur im B2C-Bereich". B2B-Geschäfte fallen nicht darunter (Bundesfachstelle Barrierefreiheit, FAQ).

Außerdem gilt eine Ausnahme für kleine Dienstleister: Wer weniger als zehn Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz hat, ist bei Dienstleistungen ausgenommen.

Also:

• Deine SaaS richtet sich an Verbraucher (z. B. Banking-App, Online-Shop, Buchungsplattform)? Dann gilt das BFSG.

• Du verkaufst an Behörden? Dann wird deine Kundin die BITV 2.0 bzw. die Landesregelungen ins Lastenheft schreiben.

• Reines B2B? Dann bist du gesetzlich nicht verpflichtet.

Warum sich WCAG für B2B trotzdem lohnt

„Nicht verpflichtet" heißt nicht „egal". Aus meiner Sicht gibt es drei gute Gründe:

1. Deine Kunden fragen danach. Spätestens wenn ein großer Konzern oder eine öffentliche Stelle einkauft, steht Barrierefreiheit im Anforderungskatalog.

2. Deine Nutzer sind Menschen. Auch in Unternehmen arbeiten Menschen mit Sehbeeinträchtigung, Farbsehschwäche oder motorischen Einschränkungen. Wer dein Tool täglich acht Stunden nutzt, merkt jede Barriere.

3. Es ist gute UX. Größere Klickziele, klare Fehlermeldungen, kein doppeltes Ausfüllen: Davon profitieren alle Nutzer, nicht nur die mit Einschränkungen.

Hinweis: Das ist keine Rechtsberatung. Ob und wie das BFSG für dein Produkt gilt, klärst du im Zweifel mit einer Anwältin oder einem Anwalt.

Die WCAG-Checkliste in 5 Schritten

Alle Kriterien der WCAG folgen vier Prinzipien. Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein, also mit verschiedenen Geräten, Browsern und Screenreadern funktionieren. Wenn du die vier verstanden hast, verstehst du die WCAG.

Statt dich durch alle Kriterien einzeln zu arbeiten, gehst du in fünf Schritten vor. Bei jedem Punkt steht, wer im Team zuständig ist. Die neuen Punkte aus WCAG 2.2 sind markiert.

Schritt 1: Visuelle Zugänglichkeit

Hier können Design und Redaktion die ersten Haken setzen.

• Kontrast prüfen (AA 1.4.3 & 1.4.11) · Zuständig: Design
  Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1, Bedienelemente und Grafiken (z. B. Icon-Buttons, Formularrahmen) mindestens 3:1. Wie du das schnell prüfst, zeige ich in meinem Guide zu barrierefreien Farben und Farbkontrasten.

• Nicht nur Farbe (A 1.4.1) · Zuständig: Design
  Informationen dürfen nicht allein über Farbe transportiert werden. Ein Link im Fließtext braucht zusätzlich eine Unterstreichung, ein Fehlerfeld zusätzlich ein Icon oder einen Text.

• Skalierung (AA 1.4.4 & 1.4.10) · Zuständig: Dev
  Zoome auf 200 %. Wird etwas abgeschnitten oder entsteht ein horizontaler Scrollbalken? Dann fehlt der Reflow. Relative Einheiten wie rem helfen. Mehr dazu im Artikel zu lesbaren, barrierefreien Schriftarten.

• NEU: Fokus nicht verdeckt (AA 2.4.11) · Zuständig: Design + Dev
  Sticky Header, Banner und Chat-Widgets dürfen das fokussierte Element nicht komplett verdecken.

Schritt 2: Tastatur und Bedienung

Die Pflichtübung. Wenn dein Produkt nicht per Tastatur bedienbar ist, ist es nicht barrierefrei.

• Tab-Test (A 2.1.1) · Zuständig: Dev
  Geh deine Seite nur mit der Tab-Taste durch. Erreichst du jede Funktion und kannst sie mit Enter auslösen? Besonders anfällig sind selbst gebaute Elemente wie Dropdowns oder Menüs.

• Sichtbarer Fokus (AA 2.4.7) · Zuständig: Design
  Du musst jederzeit sehen, wo du gerade bist. Wer den Fokus-Rahmen per CSS entfernt, muss ihn gut sichtbar ersetzen. Ziel: mindestens 3:1 Kontrast.

• Logische Reihenfolge (A 2.4.3) · Zuständig: Dev
  Die Tab-Reihenfolge folgt dem visuellen Aufbau. Fehler entstehen oft durch falsches tabindex oder per CSS verschobene Elemente.

• Skip-Link (A 2.4.1) · Zuständig: Dev
  Ein „Zum Inhalt springen"-Link als erstes Element erspart Tastatur- und Screenreader-Nutzern die komplette Navigation auf jeder Seite.

• NEU: Ziehbewegungen (AA 2.5.7) · Zuständig: Design + Dev
  Alles, was per Drag & Drop geht, geht auch per Klick.

• NEU: Zielgröße (AA 2.5.8) · Zuständig: Design
  Klickziele mindestens 24 × 24 px oder mit genug Abstand.

  
  

Schritt 3: Semantik und Alternativtexte

Saubere Struktur ist die Grundlage dafür, dass Screenreader und andere Hilfsmittel dein Produkt verstehen.

• Überschriften-Hierarchie (A 1.3.1) · Zuständig: Dev + Content
  Eine <h1> pro Seite, danach logisch <h2> bis <h6> ohne Sprünge.

• Alternativtexte (A 1.1.1) · Zuständig: Content
  Jedes informative Bild braucht einen Alt-Text, der die Information beschreibt, nicht nur das Motiv. Reine Deko bekommt alt="".

• Name und Rolle (A 4.1.2) · Zuständig: Dev
  Jedes Bedienelement braucht einen Namen und eine Rolle, die Hilfstechnologien auslesen können. Ein Icon-Button ohne Text braucht ein aria-label.

• Klarer Linkzweck (A 2.4.4) · Zuständig: Content
  „Hier klicken" sagt nichts. Besser: „WCAG-Checkliste als PDF herunterladen".

• Sprache (A 3.1.1 & AA 3.1.2) · Zuständig: Dev
  <html lang="de"> setzen und fremdsprachige Abschnitte auszeichnen, damit der Screenreader richtig ausspricht.

Schritt 4: Formulare und Interaktion

Formulare sind oft die größte Barriere, gerade in SaaS. Ausführlich dazu: Barrierefreie Formulare erstellen.

• Labels (A 1.3.1 & 3.3.2) · Zuständig: Design + Dev
  Jedes Feld hat ein sichtbares, technisch verknüpftes Label. Ein Platzhalter ist kein Label, er verschwindet beim Tippen.

• Fehlermeldungen (A 3.3.1) · Zuständig: Design + Dev
  Fehler werden sichtbar und als Text benannt, am besten mit Lösungsvorschlag: „Bitte gib das Datum im Format TT.MM.JJJJ ein."

• Keine Überraschungen (A 3.2.2) · Zuständig: Dev
  Eine Auswahl im Dropdown darf nicht ungefragt die Seite wechseln oder ein Formular abschicken.

• NEU: Redundante Eingabe (A 3.3.7) · Zuständig: Design + Dev
  Daten nicht doppelt abfragen, sondern vorausfüllen oder zur Auswahl anbieten.

• NEU: Barrierefreie Authentifizierung (AA 3.3.8) · Zuständig: Dev
  Einfügen erlauben, Passwort-Manager unterstützen, keine Rätsel ohne Alternative.

• NEU: Konsistente Hilfe (A 3.2.6) · Zuständig: Design
  Kontakt und Hilfe immer an derselben Stelle.

Schritt 5: Multimedia und Bewegung

• Untertitel (A 1.2.2) · Zuständig: Content
  Aufgezeichnete Videos mit Ton brauchen Untertitel.

• Audiodeskription (A 1.2.3 / AA 1.2.5) · Zuständig: Content
  Wenn ein Video wichtige Informationen nur zeigt und nicht sagt, braucht es eine Audiodeskription.

• Bewegung stoppen (A 2.2.2) · Zuständig: Design + Dev
  Karussells, Animationen und alles, was sich automatisch bewegt, muss sich pausieren lassen.

• Kein Blinken (A 2.3.1) · Zuständig: Design
  Nichts darf öfter als dreimal pro Sekunde blinken, das kann epileptische Anfälle auslösen.

Mehr zu Audio und Video findest du im Artikel zur auditiven Barrierefreiheit.

Die häufigsten WCAG-Fehler und wie du sie in 10 Minuten findest

Die WebAIM-Studie zeigt, welche Fehler am häufigsten vorkommen. Gemessen wurden Startseiten von Websites. In Web-Apps sieht es nach meiner Erfahrung nicht besser aus. Wer Oberflächen mit KI-Tools baut, hat genau diese Fehler oft gleich mehrfach im Produkt. Wie du das prüfst, steht im Artikel Vibe Coding & Barrierefreiheit.

1. Zu wenig Kontrast (83,9 % der Seiten) → Schnelltest: Kontrast-Plugin in Figma oder die Chrome DevTools. Anleitung im Farbkontrast-Guide.

2. Fehlende Alt-Texte (53,1 %) → Schnelltest: Browser-Erweiterung wie WAVE oder die Bilder im Barrierefreiheitsbaum der DevTools prüfen.

3. Fehlende Formular-Labels (51 %) → Schnelltest: Auf das Label klicken. Springt der Cursor ins Feld? Dann ist es verknüpft.

4. Leere Links (46,3 %) → Schnelltest: Mit dem Screenreader (VoiceOver: Cmd + F5) durch die Seite gehen und hören, was vorgelesen wird.

5. Leere Buttons (30,6 %) → Schnelltest: Wie bei Links. Typisch sind Icon-Buttons ohne Beschriftung.

6. Fehlende Dokumentsprache (13,5 %) → Schnelltest: Im Quellcode nach <html lang= suchen.

Quelle: WebAIM Million 2026

Selbsttest: Ich habe meine eigene Website geprüft
Bevor ich diese Checkliste aktualisiert habe, habe ich pixelstress.com selbst durch die neuen Kriterien geschickt. Ergebnis: Mein Menü-Button im Header hatte keinen Namen und keine Rolle. Ein Screenreader hätte dort nichts Sinnvolles vorgelesen, also genau Fehler Nummer 5 aus der Liste oben. Mit genau 24 × 24 Pixeln war er außerdem knapp an der Mindestgröße.
Inzwischen ist es ein echter Button mit der Beschriftung „Menü öffnen" bzw. „Menü schließen", die Klickfläche ist auf 40 × 40 Pixel gewachsen, und er lässt sich per Tastatur mit Enter öffnen und schließen.
Und damit beim Tabben nichts unter meinem fixierten Header verschwindet, hält der Browser jetzt per scroll-padding-top oben Abstand. Eine Zeile CSS.
Die Moral: Auch wer sich täglich mit Barrierefreiheit beschäftigt, rutscht durch. Deshalb ist eine Checkliste kein Misstrauensvotum, sondern ein Werkzeug.

Fazit & nächste Schritte

Barrierefreiheit ist ein Prozess, kein Projekt. Mit WCAG 2.2 kommen sechs neue Punkte dazu, die in Web-Apps oft brechen, und die neue EN 301 549 macht sie bald zum europäischen Maßstab. Wer jetzt plant, plant mit 2.2. Ob das BFSG für dich gilt, hängt von deinen Kunden ab. Gute UX ist es in jedem Fall.

Wie du Barrierefreiheit in jeder Projektphase verankerst, vom Briefing bis nach dem Launch, zeigt der Leitfaden Barrierefreiheit im UX-Prozess.

So startest du:

1. PDF-Checkliste herunterladen und mit deinem Team durchgehen.

2. Den 10-Minuten-Test machen: die sechs häufigsten Fehler auf deinen wichtigsten Screens prüfen.

3. Die sechs neuen Kriterien priorisieren, am besten direkt im Designsystem.

Lade dir die WCAG-2.2-Checkliste als PDF herunter

Häufig gestellte Fragen zur WCAG-Checkliste

Was muss ich für WCAG 2.2 AA erfüllen?

Alle Erfolgskriterien der Stufen A und AA aus WCAG 2.2. Das sind die Kriterien aus WCAG 2.1 AA (ohne das gestrichene 4.1.1) plus sechs neue: Fokus nicht verdeckt, Ziehbewegungen, Zielgröße, konsistente Hilfe, redundante Eingabe und barrierefreie Authentifizierung.

Was ist neu in WCAG 2.2 im Vergleich zu 2.1?

WCAG 2.2 bringt neun neue Erfolgskriterien, davon sechs auf Stufe A und AA. Sie betreffen vor allem die Bedienung mit Tastatur und Touch, Formulare und Logins. Das Kriterium 4.1.1 Parsing ist weggefallen.

Reicht WCAG 2.1 noch?

Rechtlich in der EU aktuell noch, weil die gültige Norm EN 301 549 V3.2.1 auf WCAG 2.1 AA verweist. Die neue Fassung V4.1.1 mit WCAG 2.2 ist seit September 2026 veröffentlicht und soll voraussichtlich Ende 2026 im EU-Amtsblatt erscheinen. Für neue Projekte solltest du deshalb direkt mit 2.2 planen.

Gilt das BFSG für meine Software, auch im B2B?

Das BFSG gilt für Produkte und Dienstleistungen für Verbraucher. Laut Bundesfachstelle Barrierefreiheit fallen reine B2B-Geschäfte nicht darunter. Dienstleister mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz sind ebenfalls ausgenommen. Im Zweifel solltest du das rechtlich prüfen lassen.

Was ist der Unterschied zwischen WCAG, BITV 2.0, EN 301 549 und BFSG?

Die WCAG sind der technische Standard des W3C. Die EN 301 549 ist die europäische Norm, die auf die WCAG verweist. Das BFSG (für Produkte und Dienstleistungen an Verbraucher) und die BITV 2.0 (für öffentliche Stellen des Bundes) sind deutsche Rechtsvorschriften, die sich auf diese Norm stützen.

Welches WCAG-Level ist Pflicht?

Gesetze und Normen in Europa verlangen Stufe AA. Das schließt alle Kriterien der Stufe A ein. Stufe AAA ist nicht verpflichtend und für ganze Produkte meist auch nicht realistisch.

Wie teste ich meine Website oder App selbst?

Starte mit drei Handgriffen: Bedien deine Seite nur mit der Tab-Taste, zoome auf 200 % und prüfe die Kontraste mit einem Tool. Danach hilft ein automatischer Test (z. B. WAVE oder Lighthouse). Automatische Tests finden aber nur einen Teil der Probleme. Für eine verlässliche Aussage brauchst du zusätzlich manuelle Tests und idealerweise Tests mit Betroffenen.

Was sind die häufigsten WCAG-Fehler?

Laut WebAIM Million 2026: zu geringer Kontrast (83,9 % der Startseiten), fehlende Alt-Texte (53,1 %), fehlende Formular-Labels (51 %), leere Links (46,3 %), leere Buttons (30,6 %) und fehlende Angabe der Dokumentsprache (13,5 %).