Eine Checkliste fuer Barrierefreiheits-Audits ist ein strukturiertes Dokument, das Sie durch jeden Verifizierungsschritt fuehrt, um sicherzustellen, dass Ihre Website fuer Menschen mit Behinderungen funktioniert. Statt eines vagen Versprechens, Dinge barrierefrei zu machen, verwandelt eine Checkliste die Konformitaet in konkrete Ja-oder-Nein-Fragen. Hat dieses Bild einen Alternativtext? Kann ein Tastaturnutzer jedes interaktive Element erreichen? Erfuellt der Farbkontrast das 4,5:1-Verhaeltnis? Dieser Leitfaden bietet ueber 50 Pruefpunkte, die nach den vier WCAG-Prinzipien gegliedert sind. Ob Sie sich auf das BFSG (Barrierefreiheitsstaerkungsgesetz) vorbereiten, das seit Juni 2025 in Kraft ist, die ADA-Title-II-Anforderungen fuer US-Behoerden ab April 2026, oder einfach ein besseres Produkt bauen moechten, diese Checkliste gibt Ihnen die Struktur dafuer.
Warum Sie eine strukturierte Audit-Checkliste brauchen
Ein Barrierefreiheits-Audit ohne Checkliste durchzufuehren ist wie eine Gebaeudepruefung aus dem Gedaechtnis. Sie finden die offensichtlichen Probleme und uebersehen die subtilen, die tatsaechlich Nutzer blockieren.
Automatisierte Scanning-Tools sind ein guter Ausgangspunkt, erkennen aber nur etwa 30 bis 40 Prozent der WCAG-Probleme. Der Rest erfordert menschliches Urteilsvermoegen.
Die rechtliche Dimension hat sich erheblich verschaerft. Das BFSG (Barrierefreiheitsstaerkungsgesetz) ist seit dem 28. Juni 2025 durchsetzbar und sieht Bussgelder von bis zu 100.000 Euro vor. Die europaeische Richtlinie zur Barrierefreiheit (EAA) gilt EU-weit, mit Strafen von bis zu 300.000 Euro in Spanien und 250.000 Euro in Frankreich. Eine Checkliste ist Ihr Nachweis, dass Sie die Konformitaet ernst genommen und einen methodischen Prozess befolgt haben.
Jenseits der gesetzlichen Anforderungen gibt es ein Geschaeftsargument. Barrierefreie Websites performen tendenziell besser in Suchmaschinen, konvertieren mehr Nutzer und erzeugen weniger Support-Tickets.
Vor dem Start: Ihr Audit einrichten
Ein gutes Audit beginnt mit der Definition des Umfangs. Jede Seite einer grossen Website zu testen ist unpraktisch und unnoetig. Konzentrieren Sie sich auf diese Kategorien:
Seiten mit hohem Traffic: Ihre Startseite, wichtigste Landing Pages und die Top-10-Seiten nach Besucherzahl.
Wichtige Nutzerflows: Registrierung, Login, Checkout, Suche und mehrstufige Formulare. Testen Sie die komplette Reise, nicht einzelne Seiten isoliert.
Einzigartige Templates: Wenn Ihre Website 8 verschiedene Seitenlayouts verwendet, testen Sie mindestens eine repraesentative Seite pro Template.
Inhaltsreiche Seiten: Blog-Beitraege, Dokumentation und Wissensdatenbank-Artikel.
Fuer eine typische Unternehmenswebsite mit 50 bis 200 Seiten deckt die Pruefung von 10 bis 15 repraesentativen Seiten die grosse Mehrheit der Template- und Komponentenvariationen ab.
Benoetigte Werkzeuge
Sie brauchen keine teure Enterprise-Software fuer ein gruendliches Audit. Hier ist ein praktisches Toolkit:
Automatisierter Scanner: Nutzen Sie unseren kostenlosen Barrierefreiheits-Checker auf web-accessibility-checker.com fuer einen sofortigen WCAG 2.2 Konformitaetsbericht.
Browser DevTools: Chrome und Firefox bieten beide Barrierefreiheits-Inspektionspanels.
Screenreader: NVDA ist kostenlos fuer Windows. VoiceOver ist in macOS und iOS integriert. TalkBack ist in Android integriert.
Tastatur: Ihre physische Tastatur. Trennen Sie Ihre Maus und versuchen Sie, Ihre wichtigsten Nutzerflows nur mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten zu absolvieren.
Kontrastanalysator: Der Colour Contrast Analyser von TPGi ist kostenlos.
PDF-Pruefer: Verwenden Sie PAC 2024 fuer die Pruefung der Barrierefreiheit von PDF-Dokumenten.
Prinzip 1: Wahrnehmbar
Das erste WCAG-Prinzip fragt: Koennen Nutzer den Inhalt wahrnehmen? Informationen duerfen nicht fuer alle Sinne eines Nutzers unsichtbar sein.
Bilder und Nicht-Text-Inhalte
Jedes informative Bild muss einen Alternativtext haben, der dieselbe Information wie das Bild vermittelt. Dekorative Bilder, die keine Information tragen, sollten leere alt-Attribute haben, damit Screenreader sie ueberspringen.
Pruefen Sie, dass komplexe Bilder wie Diagramme und Infografiken erweiterte Beschreibungen haben.
Stellen Sie sicher, dass alle Bild-Buttons und verlinkte Bilder Alternativtext haben, der die Aktion beschreibt, nicht das Bild.
CAPTCHAs muessen Alternativen bieten. Ein bildbasiertes CAPTCHA braucht mindestens eine Audio-Alternative.
Video- und Audio-Inhalte
Voraufgezeichnete Videos benoetigen synchronisierte Untertitel. Automatisch generierte Untertitel sind ein Anfang, enthalten aber typischerweise Fehler, die manuell korrigiert werden muessen.
Voraufgezeichnete Audio-Inhalte benoetigen eine Texttranskription.
Voraufgezeichneter Video-Inhalt braucht Audiodeskriptionen fuer visuelle Informationen, die nicht durch die bestehende Audiospur vermittelt werden.
Live-Video mit Audio braucht Echtzeit-Untertitel.
Text und Lesbarkeit
Normaler Text unter 18pt oder 14pt fett braucht ein Kontrastverhaeltnis von mindestens 4,5:1 zum Hintergrund. Grosser Text ab 18pt oder 14pt fett braucht mindestens 3:1.
Die Seite muss funktional und lesbar bleiben, wenn der Text auf 200 Prozent vergroessert wird. Der Inhalt sollte sich ohne horizontales Scrollen bei 320 CSS-Pixeln Breite neu anordnen.
Verwenden Sie keine Textbilder, wenn echter Text denselben visuellen Effekt erzielen kann. Logos sind die einzige Ausnahme.
Pruefen Sie, dass Inhalte sich nicht allein auf Farbe stuetzen, um Informationen zu vermitteln.
Prinzip 2: Bedienbar
Koennen Nutzer die Oberflaeche bedienen? Jede Funktion muss fuer Menschen funktionieren, die Tastaturen, Screenreader, Sprachbefehle oder Schalter verwenden.
Tastaturzugaenglichkeit
Jedes interaktive Element muss mit der Tastatur allein erreichbar und bedienbar sein. Navigieren Sie mit Tab durch Ihre gesamte Seite.
Pruefen Sie auf Tastaturfallen. Eine Tastaturfalle tritt auf, wenn man in ein Element navigieren kann, aber nicht wieder heraus. Modale Dialoge sind die haeufigsten Verursacher.
Stellen Sie sicher, dass die Tab-Reihenfolge einer logischen Lesefolge folgt.
Benutzerdefinierte Komponenten, die mit div- oder span-Elementen statt nativem HTML gebaut sind, benoetigen eine explizite Tastaturbehandlung.
Fokus-Sichtbarkeit
Jedes interaktive Element muss einen sichtbaren Fokusindikator haben, wenn es den Tastaturfokus erhaelt.
Nach WCAG 2.2 Kriterium 2.4.11 darf das fokussierte Element nicht vollstaendig hinter Sticky-Headern, schwebenden Buttons, Cookie-Bannern oder Chat-Widgets verborgen sein.
Entfernen Sie niemals Fokus-Umrisse, ohne einen ebenso sichtbaren Ersatz bereitzustellen.
Zielgroesse und Touch
WCAG 2.2 Kriterium 2.5.8 verlangt, dass interaktive Ziele mindestens 24 mal 24 CSS-Pixel gross sind oder genuegend Abstand haben.
Fuer Drag-and-Drop-Funktionalitaet verlangt WCAG 2.2 Kriterium 2.5.7 eine Einzelzeiger-Alternative.
Zeitbegrenzung und Bewegung
Wenn Inhalte sich automatisch bewegen, blinken oder scrollen, muessen Nutzer sie pausieren, stoppen oder ausblenden koennen.
Nichts auf der Seite sollte mehr als dreimal pro Sekunde blinken.
Bei Zeitbegrenzungen muessen Nutzer diese deaktivieren, anpassen oder verlaengern koennen.
Prinzip 3: Verstaendlich
Koennen Nutzer den Inhalt und die Funktionsweise der Oberflaeche verstehen?
Sprache und Lesbarkeit
Die Seite muss ihre Sprache im HTML-lang-Attribut deklarieren. Fuer deutsche Seiten verwenden Sie lang de.
Navigationsmenues und wiederkehrende Komponenten sollten auf allen Seiten an derselben relativen Position erscheinen.
Pruefen Sie, dass Anweisungen sich nicht ausschliesslich auf sensorische Merkmale stuetzen.
Formulare und Fehlerbehandlung
Jedes Formulareingabefeld braucht ein sichtbares, programmatisch zugeordnetes Label. Placeholder-Text allein ist kein Label.
Bei Fehlern muessen die spezifischen Felder identifiziert und die Probleme beschrieben werden.
WCAG 2.2 Kriterium 3.3.7 verlangt, dass bereits eingegebene Informationen in mehrstufigen Prozessen vorausgefuellt werden.
Fuer die Authentifizierung verlangt WCAG 2.2 Kriterium 3.3.8, dass Passwort-Manager nicht blockiert werden.
Prinzip 4: Robust
Koennen assistive Technologien den Inhalt korrekt interpretieren?
Semantisches HTML und ARIA
Verwenden Sie semantische HTML-Elemente: header, nav, main, footer, article, section, aside.
Ueberschriften muessen einer logischen Hierarchie folgen. Ein H1 pro Seite, gefolgt von H2 fuer Hauptabschnitte und H3 fuer Unterabschnitte.
Alle interaktiven Elemente muessen barrierefreie Namen haben.
Verwenden Sie ARIA-Rollen und -Eigenschaften nur, wenn natives HTML die benoetigte Semantik nicht bietet.
Pruefen Sie, dass dynamische Inhaltsaktualisierungen ueber aria-live-Regionen an Screenreader gemeldet werden.
Die vollstaendige Checkliste: Kurzreferenz
Hier ist die vollstaendige Checkliste in einem scanbaren Format.
Wahrnehmbar: - Alle informativen Bilder haben beschreibenden Alt-Text - Dekorative Bilder haben leere alt-Attribute - Videos haben synchronisierte Untertitel - Audio-Inhalte haben Texttranskriptionen - Textkontrast betraegt mindestens 4,5:1 - Seite ist bei 200% Zoom ohne horizontales Scrollen nutzbar - Inhalte stuetzen sich nicht allein auf Farbe
Bedienbar: - Alle interaktiven Elemente sind per Tastatur erreichbar - Keine Tastaturfallen vorhanden - Tab-Reihenfolge folgt logischer Lesefolge - Sichtbare Fokusindikatoren vorhanden - Interaktive Ziele mindestens 24x24 CSS-Pixel - Drag-and-Drop hat Einzelzeiger-Alternativen - Auto-animierte Inhalte haben Pause-Steuerung - Skip-Navigation-Link vorhanden
Verstaendlich: - Seitensprache im HTML-lang-Attribut deklariert - Navigation konsistent auf allen Seiten - Alle Formularfelder haben sichtbare Labels - Fehlermeldungen sind spezifisch und beschreibend - Authentifizierung blockiert keine Passwort-Manager
Robust: - Semantische HTML-Landmarks werden verwendet - Ueberschriften-Hierarchie ist logisch - Alle interaktiven Elemente haben barrierefreie Namen - ARIA wird korrekt und nur bei Bedarf verwendet
Probleme nach dem Audit priorisieren
Kritische Probleme blockieren Nutzer vollstaendig bei der Erledigung von Kernaufgaben. Beheben Sie diese zuerst.
Hohe Probleme verursachen erhebliche Schwierigkeiten, haben aber Workarounds. Zweite Prioritaet.
Mittlere Probleme beeintraechtigen die Benutzerfreundlichkeit, verhindern aber nicht die Aufgabenerfuellung.
Niedrige Probleme sind Best-Practice-Verbesserungen jenseits der strikten WCAG-Anforderungen.
Dokumentieren Sie jeden Fund mit Schweregrad, betroffener Seiten-URL, relevantem WCAG-Kriterium und empfohlener Korrektur.
Laufende Ueberwachung automatisieren
Ein Audit ist eine Momentaufnahme. Websites aendern sich staendig. Ohne laufende Ueberwachung schleichen sich Barrierefreiheits-Regressionen innerhalb von Wochen ein.
Richten Sie automatisiertes Scanning nach einem Zeitplan ein. Unser Barrierefreiheits-Checker ermoeglicht regelmaessige Scans.
Integrieren Sie Barrierefreiheitspruefungen in Ihren Entwicklungs-Workflow mit Bibliotheken wie axe-core in Ihrer CI/CD-Pipeline.
Planen Sie vierteljaehrliche manuelle Reviews. Schulen Sie Ihr Content-Team.
Gesetzliche Anforderungen 2026
Die rechtliche Landschaft fuer Web-Barrierefreiheit hat sich deutlich verschaerft.
Das BFSG (Barrierefreiheitsstaerkungsgesetz) ist seit dem 28. Juni 2025 in Kraft und die deutsche Umsetzung der europaeischen Barrierefreiheitsrichtlinie (EAA). Es gilt fuer digitale Produkte und Dienstleistungen, die in Deutschland verkauft werden. Bussgelder koennen bis zu 100.000 Euro betragen.
Die EAA gilt EU-weit mit laenderspezifischen Sanktionen: bis zu 300.000 Euro in Spanien und 250.000 Euro in Frankreich mit zusaetzlichen taeglichen Strafen.
ADA Title II verlangt jetzt explizit Web-Barrierefreiheit fuer US-Behoerden nach WCAG 2.1 Level AA. Die Frist fuer groessere Einrichtungen ist der 26. April 2026.
WCAG 2.2 AA als Audit-Ziel deckt die Anforderungen aller dieser Rahmenwerke ab.