Cyberknecht

Wissen / Checklisten / Webentwicklung

Barrierefreiheit prüfen: WCAG-Checkliste

Schnellcheck für besser bedienbare Websites und Webanwendungen.

Stand: 27.10.2026 · Redaktion: Carl Thorns · Kostenlos und ohne Anmeldung

PDF herunterladenAlle Ressourcen

Dieser Leitfaden führt dich vom konkreten Ausgangsproblem über die praktische Umsetzung bis zur überprüfbaren Abnahme. Jeder Abschnitt nennt eine Methode, ein Beispiel, ein Erfolgskriterium und eine typische Fehlerquelle.

Arbeitsablauf auf einen Blick

1. Tastaturbedienung

Navigiere ohne Maus mit Tab, Shift+Tab, Enter, Leertaste und Escape. Achte auf sichtbaren Fokus und sinnvolle Reihenfolge.

Praxisbeispiel
Ein Dropdown öffnet per Tastatur und lässt sich mit Escape schließen.
So erkennst du, dass es funktioniert: Alle wichtigen Aktionen sind ohne Maus erreichbar.
Typischer Fehler: Klickbare div-Elemente ohne Tastaturunterstützung.

2. Kontraste und Skalierung

Prüfe Textkontraste nach WCAG; für normalen Text typischerweise mindestens 4,5:1, für großen Text 3:1 bei AA. Teste Zoom und Textvergrößerung.

Praxisbeispiel
Kontrast-Checker mit Vorder- und Hintergrundfarbe.
So erkennst du, dass es funktioniert: Text bleibt bei 200 % Zoom lesbar und bedienbar.
Typischer Fehler: Nur Desktop-Screenshots in Originalgröße prüfen.

3. Formulare und Fehler

Verbinde Eingaben mit Labels, erkläre Pflichtfelder und zeige Fehler als Text an. Setze aria-invalid nur bei tatsächlichem Fehlerzustand.

Praxisbeispiel
<label for="email">E-Mail</label><input id="email" type="email">
So erkennst du, dass es funktioniert: Fehler lassen sich verstehen und korrigieren, auch mit Screenreader.
Typischer Fehler: Fehler ausschließlich durch rote Rahmen signalisieren.

4. Semantik und Bilder

Nutze echte Überschriften, Listen, Buttons und Links. Beschreibe informative Bilder; dekorative Grafiken erhalten leeren Alt-Text.

Praxisbeispiel
<button type="button">Menü öffnen</button> statt <div onclick="…">.
So erkennst du, dass es funktioniert: Struktur ist in der Screenreader-Überschriftennavigation nachvollziehbar.
Typischer Fehler: ARIA verwenden, um fehlende HTML-Semantik zu kaschieren.

5. Automatisch und manuell testen

Nutze axe oder Lighthouse als Ergänzung, prüfe zusätzlich Tastatur, Zoom, Screenreader und echte Nutzungsszenarien.

Praxisbeispiel
Prüfprotokoll je Template: Befund, WCAG-Kriterium, Schwere, Fix, Retest.
So erkennst du, dass es funktioniert: Kritische Nutzungswege sind manuell getestet.
Typischer Fehler: Automatischen 100-Punkte-Score als vollständige Konformität ausgeben.

Abnahmeprotokoll für die Praxis

Nutze die folgenden Punkte als dokumentierbare Abnahme. Trage bei jedem Punkt Datum, getestete URL beziehungsweise System, Ergebnis und gegebenenfalls einen offenen Befund ein.

  1. Abnahmekriterium: Alle wichtigen Aktionen sind ohne Maus erreichbar.

  2. Abnahmekriterium: Text bleibt bei 200 % Zoom lesbar und bedienbar.

  3. Abnahmekriterium: Fehler lassen sich verstehen und korrigieren, auch mit Screenreader.

  4. Abnahmekriterium: Struktur ist in der Screenreader-Überschriftennavigation nachvollziehbar.

  5. Abnahmekriterium: Kritische Nutzungswege sind manuell getestet.

Fachquellen und weiterführende Dokumentation

Diese Primärquellen dienen zur Vertiefung und zur Prüfung versionsabhängiger Details. Bei rechtlichen Themen ersetzt der Leitfaden keine individuelle Rechtsberatung.

Praxisvertiefung: Tastatur und Formulare zuerst

Navigiere die komplette Seite ausschließlich mit Tab, Shift+Tab, Enter und Escape. Achte auf sichtbaren Fokus, logische Reihenfolge, verständliche Fehlermeldungen und bedienbare Dialoge.

Technische Umsetzung

Prüfe Labels, semantische Buttons, Alt-Texte, Kontraste und Zoom auf 200 %. WCAG 2.2 AA ist eine sinnvolle technische Orientierung; gesetzliche Anforderungen hängen vom Angebot ab.

So überprüfst du das Ergebnis

Automatische Scanner finden nur einen Teil der Probleme. Dokumentiere zusätzlich manuelle Tastatur- und Screenreader-Stichproben.