WCAG Checkliste (AA-Standard): Ein 5-Schritte-Fahrplan für mehr Barrierefreiheit

Die Umsetzung von Barrierefreiheit ist seit 2025 nicht mehr optional, sondern gesetzlich verpflichtend.

Das Barrierefreiheitsstärkungsgesetz (BFSG) schreibt vor, dass digitale Produkte – insbesondere barrierefreie Websites, Apps und Software die Erfolgskriterien der Stufen A und AA der WCAG (Web Content Accessibility Guidelines) erfüllen müssen.

Komplexität als Projekt-Stopper

Die Anforderungen an digitale Barrierefreiheit durch die die WCAG (Web Content Accessibility Guidelines) sind komplex und verwirrend. Hunderte von Kriterien und technischen Spezifikationen können selbst erfahrene Teams lähmen.

Der Fehler liegt oft im Ansatz: Man versucht, den gesamten Standard zu verinnerlichen, statt ihn in umsetzbare Schritte zu zerlegen. Genau das möchte ich in diesem Artikel zeigen.

Diese 5-Schritte-Checkliste zeigt dir, wie du dein SaaS-Produkt, deine Website oder dein digitales Tool schnell und rechtssicher barrierefrei machst und das Ganze im Einklang mit dem BFSG, BITV 2.0 und dem European Accessibility Act (EAA).

Lade jetzt die vollständige, druckbare PDF-Checkliste herunter und starte dein WCAG-Audit sofort!
WCAG-Checkliste-Download

Das Fundament der WCAG: Die 4 Säulen der Barrierefreiheit 

Die Logik hinter allen Barrierefreiheitsanforderungen lässt sich auf vier einfache Prinzipien reduzieren. Wenn Sie diese verstanden haben, verstehen Sie die WCAG:

Wahrnehmbar (Perceptible) 

Nutzer müssen visuelle Inhalte, Audioinhalte und Texte erfassen können.

Verwende Textalternativen für alle Nicht-Text-Inhalte, z. B. einen Alt-Text oder detaillierte Textalternativen, wenn Bilder oder Videos Informationen transportieren.

Bedienbar (Operable)

Alle interaktiven Elemente und Schaltflächen müssen per Tastatur oder Eingabehilfe erreichbar sein.

Verständlich (Understandable)

Verwende einfache Sprache, klare Navigation und konsistente Strukturen.

Robust (Robust)

Dein Produkt sollte mit verschiedenen Geräten, Browsern, Hilfstechnologien und Screenreadern zuverlässig funktionieren.

Dein 5-Schritte-Fahrplan für barrierefreie Websites und Apps: So nutzt du die Checkliste im Alltag

Im Folgenden findest du den praxisorientierten Fahrplan, mit dem du dein Projekt systematisch auf WCAG-Konformität prüfen kannst.

Schritt 1: Visuelle Zugänglichkeit 

Designer und Redakteure können hier die ersten und wichtigsten Haken setzen. Es geht um die reine Wahrnehmbarkeit der Inhalte.

Kontrast-Quick-Check (AA 1.4.3 & 1.4.11)

Überprüfe alle Textelemente und Bedienelemente (z. B. Icon-Buttons, Formularrahmen) auf das korrekte Kontrastverhältnis. Der Standard ist 4.5:1 für normalen Text und 3:1 für Nicht-Text-Elemente. Praxis-Tipp: Nutze Browser-Erweiterungen, um Kontraste direkt im Browser zu prüfen. Achte darauf, dass du nicht nur Farbe zur Informationsvermittlung nutzt. Ein farbiger Textlink muss zusätzlich unterstrichen sein (A 1.4.1)

Du weißt nicht, wie du den Kontrast 4.5:1 exakt überprüfst? Lerne in meinem speziellen Guide zum Farbkontrast, wie du die WCAG-Vorgaben schnell und präzise erfüllst.

Skalierungs-Probe (AA 1.4.4 & 1.4.10)

Zoome deine Seite auf 200 %. Werden Inhalte abgeschnitten oder entsteht eine horizontale Scroll-Leiste? Dann fehlt der Reflow. Dies ist für User mit Sehbeeinträchtigung essentiell. Stelle sicher, dass du relative Einheiten wie rem oder % für Schriftgrößen nutzt, damit der Browser die Skalierung sauber umsetzen kann.

Schritt 2: Tastatur-Bedienbarkeit sicherstellen 

Dieser Schritt ist die absolute Pflichtübung. Wenn dein Produkt nicht per Tastatur bedienbar ist, ist es nicht barrierefrei (PO-RU: Operable).

Tab-Test (A 2.1.1)

Gehe deine gesamte Seite einmal nur mit der Tab-Taste durch. Kannst du jede einzelne Funktion (Schaltfläche, Navigation, Dropdowns) erreichen und mit ENTER aktivieren? Wenn nicht, muss optimiert werden. Achte besonders auf Custom-Elemente, denen oft der native Fokus fehlt.

Fokus-Indikator (AA 2.4.7)

Beim Tab-Test musst du jederzeit sehen, wo du gerade bist. Ist der Fokus-Indikator (ein Rahmen um das aktive Element) kontrastreich und gut sichtbar? Wenn du ihn per CSS entfernt hast, musst du ihn durch eine andere Lösung ersetzen. Der Indikator sollte den Kontrast 3:1 erfüllen.

Fokus-Reihenfolge (A 2.4.3)

Die Tab-Reihenfolge muss logisch und intuitiv dem visuellen Fluss der Seite folgen (von oben nach unten und von links nach rechts). Fehlerhafte Reihenfolgen entstehen oft durch falsche tabindex-Nutzung oder das Verschieben von Elementen per CSS, ohne die Quellcode-Ordnung zu beachten.

Abkürzungen schaffen (A 2.4.1)

Implementiere einen "Zum Inhalt springen"-Link (Skip Link) als erstes fokussierbares Element. Das erspart Screenreader-Nutzern das mühsame Durchhören der Hauptnavigation auf jeder Seite.

Schritt 3: Semantische Struktur und Alternativtexte

Korrekte Semantik ist der Schlüssel zur Robustheit (PO-RU: Understandable & Robust).

Überschriften-Hierarchie (A 1.3.1)

Prüfe die logische Reihenfolge deiner Überschriften (<h1> bis <h6>). Vermeide Sprünge (z. B. von <h2> direkt auf <h4>). Sie dienen Screenreadern als Navigationsstruktur. Denk daran: Es sollte nur eine <h1> pro Seite geben, die den Hauptinhalt beschreibt.

Alternativtexte (A 1.1.1)

Jedes informative Bild braucht einen präzisen alt-Text. Reine Zierbilder erhalten alt="". Sei prägnant und beschreibe die Funktion oder Information, nicht nur das Motiv. Wichtig: Karten und komplexe Grafiken benötigen eine detaillierte, textuelle Beschreibung neben dem Bild (oder über aria-describedby).

Linkzweck klar machen (A 2.4.4)

Die Linktexte müssen ohne Kontext verständlich sein. Linktexte wie „Hier klicken“ oder „Mehr erfahren“ sind nicht ideal. Bessere Linktexte enthalten, das Ziel (z. B. „Lade unser WCAG-E-Book herunter). Wenn du Links im Fließtext einbetten musst, nutze aria-label="[Zweck des Links]" für Screenreader.

Sprachdeklaration (A 3.1.1/3.1.2)

Stelle sicher, dass die Hauptsprache der Seite (<html lang="de">) und abweichende Sprachen in Textabschnitten (<span lang="en">SaaS</span>) korrekt deklariert sind. Das stellt die korrekte Aussprache durch den Screenreader sicher.

Schritt 4: Formulare und Interaktionen wasserdicht machen 

Formulare sind oft die größte Barriere. Hier müssen Eingaben, Anweisungen und Fehlermeldungen für alle transparent sein. Noch mehr Informationen zum Thema findest du in meinem Artikel zum Thema barrierefreie Formulare.

Labels korrekt verknüpfen (A 1.3.1)

Dies ist der häufigste Formularfehler: Jedes Eingabefeld (Input, Textarea) benötigt ein fest damit verknüpftes <label>-Element. Stelle die Verbindung technisch über die for- und id-Attribute sicher. Achtung: Placeholder sind kein Ersatz für Labels, da sie beim Tippen verschwinden.

Anweisungen und Format (A 3.3.2)

Wenn das Eingabeformat komplex ist (z. B. Passwortanforderungen, Datumsformat), gib klare Anweisungen vor dem Feld. Der User muss wissen, was erwartet wird, bevor er den Fehler macht.

Fehlerkommunikation (A 3.3.1)

Eingabefehler müssen nach der Validierung visuell (rote Markierung, Icon) und textuell (klare Fehlermeldung, die den Fehler benennt) kommuniziert werden. Screenreader-Nutzern muss der Fehler über aria-live dynamisch mitgeteilt werden. Gib, wenn möglich, Fehlervorschläge (z. B. "Das Datum muss im Format TT.MM.JJJJ eingegeben werden").

Keine Überraschungen (A 3.2.2)

Eine Aktion, die durch eine Eingabe ausgelöst wird (z. B. das Ändern eines Dropdowns), darf niemals überraschend einen Submit oder einen Seitenwechsel auslösen. Solche Änderungen müssen vom User explizit ausgelöst werden (z. B. per Klick auf einen "Weiter"-Button).

Schritt 5: Multimedia- und Zeitmanagement prüfen

Dieser Schritt betrifft alle Inhalte, die sich bewegen, automatisch ablaufen oder Audiospuren enthalten.

Untertitel und Transkripte (A 1.2.2 )

Alle aufgezeichneten Videos mit Ton benötigen synchrone Untertitel (Level A). Live-Übertragungen benötigen diese auf Stufe AA. Wenn Videos keine visuellen Inhalte enthalten, die für das Verständnis essenziell sind, reicht ein Transkript aus (A 1.2.1).

Audiodeskription 

Enthält dein Video visuelle Informationen, die nicht aus dem Ton hervorgehen (z. B. eine Handlungsanweisung, die nur gezeigt wird), ist eine Audiodeskription (zusätzliche Tonspur) erforderlich.

Automatische Bewegung stoppen (A 2.2.4)

Inhalte, die automatisch starten und sich bewegen oder blinken (z. B. Karussells, Werbebanner, zeitgesteuerte Animationen), müssen vom User pausiert, gestoppt oder ausgeblendet werden können. Das gibt Usern mit kognitiven Einschränkungen oder Leseproblemen die nötige Zeit, den Inhalt zu erfassen.                                                                                                                                                                                                                     

Kein Blinken >3x/Sek. (A 2.3.1)

Das Blinken oder Flackern von Inhalten darf die Frequenz von 3 Mal pro Sekunde nicht überschreiten, da dies epileptische Anfälle auslösen kann.

Rechtliche Konformität mit BITV & European Accessibility Act (EAA)

Durch die Umsetzung dieser Checkliste trägst du zur Erfüllung deiner rechtlichen Pflichten bei. Die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) in Deutschland und der European Accessibility Act (EAA) bauen direkt auf dem technischen Standard WCAG 2.1 AA (bzw. zukünftig 2.2 AA) auf.

Wenn du die technischen Kriterien unserer Checkliste erfolgreich umsetzt, hast du die technische Basis für die Barrierefreiheit-Erklärung und den Feedback-Mechanismus geschaffen, welche die BITV zusätzlich fordert. Kurz gesagt: Die Checkliste ist dein Fundament, das Gesetz ist das Dach.

Fazit: Barrierefreiheit ist ein Prozess, kein Projekt

Barrierefreiheit ist kein einmaliges Mammutprojekt, sondern ein umsetzbarer Prozess. Mit diesem 5-Schritte-Fahrplan und der strukturierten Abarbeitung der AA-Kriterien in unseren fünf Kernbereichen minimierst du das Projektrisiko und maximierst die Inklusion.

Lade jetzt die vollständige, druckbare PDF-Checkliste herunter und starte dein WCAG-Audit sofort!
WCAG-Checkliste-Download

Häufig gestellte Fragen (FAQ)

Was ist eine WCAG-Checkliste?

Eine WCAG-Checkliste ist ein strukturierter Leitfaden, um Websites und digitale Produkte Schritt für Schritt auf Barrierefreiheit nach WCAG 2.1 AA zu prüfen.

Welche 5 Schritte braucht man für WCAG 2.1 AA-Konformität?

1. Kontrast & Skalierung prüfen

2. Tastatur-Bedienbarkeit sicherstellen

3. Semantische Struktur optimieren

4. Formulare barrierefrei gestalten

5. Multimedia & Zeitmanagement testen

Wie mache ich mein SaaS-Produkt barrierefrei?

Indem du die WCAG-Kriterien (Stufe AA) umsetzt – vom Kontrast über Bedienbarkeit bis zu Transkripten. Mit unserer Checkliste kannst du dein Audit systematisch durchführen.

Welchen strategischen Wert bietet Barrierefreiheit für mein SaaS-Produkt?

Barrierefreiheit (WCAG AA) ist seit 2025 durch das Barrierefreiheitsstärkungsgesetz (BFSG) gesetzlich verpflichtend. Strategisch gesehen ist sie ein Wettbewerbsvorteil und keine reine Pflichtübung.

Durch die Umsetzung der Kriterien:

• Erhöhst du die Kundenreichweite und den potenziellen Markt (Inklusion).

• Reduzierst du die Support-Kosten durch selbsterklärende, verständliche Interfaces.

• Minimierst du das rechtliche Risiko und stärkst die Produktmarke.

• Steigerst du die Nutzerbindung und somit den Customer Lifetime Value.

Nutze unsere Checkliste, um Barrierefreiheit nicht als Kostenfaktor, sondern als nachhaltige strategische Investition zu betrachten.

Quellen & Referenzen

• W3C – Web Content Accessibility Guidelines (WCAG)

• BITV 2.0 – Barrierefreie Informationstechnik-Verordnung

• European Accessibility Act (EAA)