Web Accessibility Audit: Barrierefreiheit einer Website testen

Ein Accessibility Audit deckt systematisch Barrieren einer Website auf und liefert einen konkreten Maßnahmenplan. Ob gesetzliche Anforderungen durch das BFSG ab 2025 oder bessere Nutzererfahrung — barrierefreie Websites sind kein optionales Extra mehr. Dieser Leitfaden zeigt, wie ein umfassender Accessibility Audit durchgeführt wird: von automatisierten Tools über manuelle Tests bis zur strukturierten Auswertung.

Was ist ein Accessibility Audit?

Ein Accessibility Audit ist eine systematische Überprüfung einer Website auf Barrierefreiheit nach den Web Content Accessibility Guidelines (WCAG). Ziel ist es, Barrieren zu identifizieren, die Menschen mit Behinderungen den Zugang zu Inhalten oder Funktionen erschweren oder unmöglich machen.

Warum ist ein Audit notwendig?

Ein Accessibility Audit geht weit über eine reine Checklisten-Prüfung hinaus. Er kombiniert automatisierte Scans mit manuellen Tests und realen Nutzungsszenarien.

Die wichtigsten Gründe für einen Audit:

1. Gesetzliche Pflicht: Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet seit Juni 2025 viele Unternehmen zur digitalen Barrierefreiheit
2. Größere Zielgruppe: Rund 13 % der deutschen Bevölkerung lebt mit einer Behinderung
3. Bessere Nutzererfahrung: Barrierefreie Websites sind für alle Nutzer einfacher bedienbar
4. SEO-Vorteile: Semantisches HTML, Alt-Texte und klare Struktur verbessern auch das Ranking

Wichtige Statistiken:

• 96 % aller Websites haben mindestens einen automatisch erkennbaren WCAG-Fehler (Quelle: WebAIM Million)
• 71 % der Nutzer mit Behinderung verlassen unzugängliche Websites sofort wieder (Quelle: Click-Away Pound)
• 30 % der Barrierefreiheitsprobleme lassen sich durch automatisierte Tests erkennen (Quelle: Deque Systems)

Automatisierte Tests

Automatisierte Tools bilden die Grundlage jedes Accessibility Audits. Sie scannen eine Website schnell auf bekannte Verstöße gegen WCAG-Richtlinien und liefern einen ersten Überblick.

Lighthouse Accessibility Score

Google Lighthouse ist in den Chrome DevTools integriert und prüft rund 40 Accessibility-Regeln. Über die DevTools (F12), Tab “Lighthouse” mit aktivierter Kategorie “Accessibility” wird ein Audit gestartet. Der Score von 0 bis 100 gibt eine erste Einschätzung.

Stärken: Kostenlos, schnell, direkt im Browser verfügbar. Grenzen: Erkennt nur grundlegende Fehler wie fehlende Alt-Texte oder mangelnden Kontrast.

axe DevTools

axe von Deque Systems ist der De-facto-Standard für automatisiertes Accessibility-Testing. Es prüft über 80 Regeln und liefert detaillierte Fehlerbeschreibungen mit konkreten Lösungsvorschlägen.

# axe CLI global installieren
npm install -g @axe-core/cli

# Einzelne Seite testen
axe https://beispiel.de

# Mehrere Seiten testen
axe https://beispiel.de https://beispiel.de/kontakt/

# Ergebnisse als JSON speichern
axe https://beispiel.de --save results.json

WAVE (Web Accessibility Evaluation Tool)

WAVE von WebAIM visualisiert Barrierefreiheitsprobleme direkt auf der Seite. Fehler, Warnungen und strukturelle Elemente werden farblich markiert. Besonders hilfreich ist die Kontrastanalyse und die Darstellung der Dokumentstruktur.

Pa11y CLI

Pa11y eignet sich hervorragend für die Integration in CI/CD-Pipelines und automatisierte Workflows:

# Pa11y installieren
npm install -g pa11y

# Einzelne Seite testen (WCAG 2.1 AA)
pa11y https://beispiel.de --standard WCAG2AA

# HTML-Bericht erstellen
pa11y https://beispiel.de --reporter html > report.html

Automatisierte Tests als Ausgangspunkt — Automatisierte Tools sind unverzichtbar, decken aber nur etwa 30 % aller Barrierefreiheitsprobleme auf. Fehler im Kontext, unlogische Tab-Reihenfolgen oder unzureichende Screenreader-Beschreibungen erkennen sie nicht.

Manuelle Tests

Manuelle Tests decken die Probleme auf, die automatisierte Tools nicht erkennen.

Tastaturnavigation testen

Die gesamte Website wird ausschließlich mit der Tastatur navigiert. Zu prüfen ist:

• Tab-Taste: Springt der Fokus logisch von Element zu Element?
• Shift + Tab: Funktioniert die Rückwärts-Navigation?
• Enter/Leertaste: Lassen sich alle interaktiven Elemente aktivieren?
• Escape: Schließen sich Modals und Dropdowns?
• Pfeiltasten: Funktionieren Menüs, Tabs und Slider?
• Fokus-Indikator: Ist immer erkennbar, welches Element gerade fokussiert ist?
• Tastaturfallen: Kann der Fokus irgendwo “steckenbleiben”?

Screenreader-Tests

Getestet wird mit mindestens einem Screenreader. Die drei wichtigsten sind:

• VoiceOver (macOS/iOS): Cmd + F5 zum Aktivieren
• NVDA (Windows): Kostenlos, weit verbreitet
• JAWS (Windows): Professioneller Standard, kostenpflichtig

Geprüft wird: Werden Bilder korrekt beschrieben? Sind Formularfelder verständlich gelabelt? Wird der Seitenzustand bei dynamischen Änderungen kommuniziert? Sind ARIA-Live-Regions korrekt eingesetzt?

Zoom-Test (200 % und 400 %)

Die Website wird auf 200 % und 400 % im Browser vergrößert. Laut WCAG 1.4.4 müssen Inhalte bei 200 % Zoom ohne Informationsverlust nutzbar bleiben. Bei 400 % (WCAG 1.4.10) darf kein horizontales Scrollen für einspaltigen Text erforderlich sein.

Farbkontrast prüfen

Geprüft werden die Kontrastverhältnisse aller Text-Hintergrund-Kombinationen:

• Normaler Text: Mindestens 4,5:1 (WCAG AA)
• Großer Text (ab 18px bold oder 24px): Mindestens 3:1
• Grafische Elemente und UI-Komponenten: Mindestens 3:1

Motion und Animation prüfen

Sichergestellt wird, dass Animationen respektvoll eingesetzt werden:

• Lassen sich alle Animationen per prefers-reduced-motion deaktivieren?
• Gibt es automatisch abspielende Videos oder Karussells ohne Pause-Funktion?
• Blinken oder flackern Inhalte mit mehr als drei Wiederholungen pro Sekunde?

Werkzeug-Übersicht

Tool	Typ	Abdeckung	Kosten
Lighthouse	Automatisch	~40 Regeln, Basis-Checks	Kostenlos
axe DevTools	Automatisch	~80 Regeln, detaillierte Reports	Kostenlos / Pro
WAVE	Automatisch	Visuelle Analyse, Kontrastprüfung	Kostenlos
Pa11y CLI	Automatisch	CI/CD-Integration, WCAG-Standards	Kostenlos
Tastatur-Test	Manuell	Fokus, Navigation, Interaktion	Zeitaufwand
Screenreader	Manuell	Semantik, ARIA, Kontext	Zeitaufwand
Zoom-Test	Manuell	Responsive, Reflow, Lesbarkeit	Zeitaufwand
Kontrastprüfung	Manuell/Tool	Farbverhältnisse, Lesbarkeit	Kostenlos

WCAG-Checkliste für den Audit

Die WCAG 2.1 organisiert Barrierefreiheitsanforderungen in vier Prinzipien.

Wahrnehmbar (Perceivable)

• Alle Bilder haben aussagekräftige Alt-Texte oder sind als dekorativ markiert (alt="")
• Videos haben Untertitel und Audiodeskription
• Inhalte sind in einer logischen Lesereihenfolge strukturiert
• Farbkontraste erfüllen die Mindestanforderungen (4,5:1 für Text)
• Farbe wird nicht als einziges Unterscheidungsmerkmal verwendet
• Text kann auf 200 % vergrößert werden, ohne dass Inhalte verloren gehen
• Bei 400 % Zoom ist kein horizontales Scrollen für Fließtext nötig
• Audio-Inhalte haben eine Texttranskription

Bedienbar (Operable)

• Alle Funktionen sind per Tastatur erreichbar
• Es gibt keine Tastaturfallen
• Skip-Links ermöglichen das Überspringen wiederholender Inhalte
• Seitentitel sind aussagekräftig und einzigartig
• Die Fokus-Reihenfolge ist logisch und vorhersehbar
• Der Fokus-Indikator ist deutlich sichtbar
• Zeitlimits können verlängert oder deaktiviert werden
• Bewegte Inhalte haben eine Pause-Funktion
• Keine Inhalte blinken mehr als dreimal pro Sekunde

Verständlich (Understandable)

• Die Seitensprache ist im HTML-Element definiert (lang="de")
• Fremdsprachige Passagen sind mit lang-Attribut gekennzeichnet
• Formulare haben verständliche Labels und Fehlermeldungen
• Fehlermeldungen beschreiben das Problem und bieten Lösungsvorschläge
• Die Navigation ist konsistent über alle Seiten hinweg
• Eingabefelder haben Autofill-Hinweise (autocomplete)

Robust

• HTML ist valide und fehlerfrei
• ARIA-Attribute werden korrekt eingesetzt
• Benutzerdefinierte Komponenten haben korrekte Rollen, Zustände und Eigenschaften
• Die Website funktioniert mit verschiedenen Browsern und assistiven Technologien

Die 30-%-Regel — Automatisierte Tools erkennen nur etwa 30 % aller WCAG-Verstöße. Die übrigen 70 % erfordern manuelles Testing, Screenreader-Prüfungen und kontextbezogene Bewertungen.

Ergebnisse priorisieren

Nach dem Audit liegt eine Liste von Problemen vor. Priorisiert wird nach Schweregrad.

Kritisch — Inhalte nicht erreichbar

Probleme, die den Zugang zu wesentlichen Inhalten oder Funktionen komplett verhindern:

• Formulare ohne Labels, die nicht ausgefüllt werden können
• Tastaturfallen, aus denen Nutzer nicht entkommen
• Fehlende Alternativtexte für inhaltlich relevante Bilder
• Videos ohne jegliche Untertitel

Maßnahme: Sofort beheben.

Hoch — Funktionalität eingeschränkt

• Unzureichende Farbkontraste bei wichtigen Texten
• Fehlende oder fehlerhafte ARIA-Attribute bei interaktiven Elementen
• Unlogische Fokus-Reihenfolge in Formularen
• Fehlende Seitensprache im HTML-Dokument

Maßnahme: Innerhalb von zwei Wochen beheben.

Mittel — Erschwerter Zugang

• Fehlende Skip-Links
• Suboptimale Überschriftenhierarchie
• Dekorative Bilder mit unnötigen Alt-Texten
• Unzureichende Fehlermeldungen in Formularen

Maßnahme: Im nächsten Sprint oder Release einplanen.

Niedrig — Komfort-Verbesserung

• Fehlende autocomplete-Attribute bei Formularfeldern
• Optimierung der ARIA-Beschreibungen
• Verbesserung der Fokus-Indikatoren über das Mindestmaß hinaus
• Zusätzliche Orientierungshilfen wie Breadcrumbs

Maßnahme: In den fortlaufenden Verbesserungsprozess aufnehmen.

Audit-Bericht erstellen

Ein strukturierter Audit-Bericht enthält:

1. Zusammenfassung: Gesamtbewertung, getestete Seiten, verwendete Tools und Methoden
2. Methodik: Beschreibung der durchgeführten automatisierten und manuellen Tests
3. Ergebnisübersicht: Anzahl der Probleme nach Schweregrad, aufgeteilt nach WCAG-Prinzip
4. Detaillierte Befunde: Für jedes Problem die betroffene Seite, das WCAG-Kriterium, eine Beschreibung, einen Screenshot und eine konkrete Lösungsempfehlung
5. Priorisierte Maßnahmenliste: Sortiert nach Schweregrad mit geschätztem Aufwand
6. Empfehlungen: Vorschläge für Prozesse, Schulungen und regelmäßige Folge-Audits

Regelmäßiges Testing

Ein einmaliger Audit reicht nicht aus. Barrierefreiheit muss kontinuierlich sichergestellt werden.

Testing in den Entwicklungsprozess integrieren

• Pre-Commit: Linting-Tools wie eslint-plugin-jsx-a11y prüfen Accessibility-Regeln im Code
• CI/CD-Pipeline: Pa11y oder axe in die Build-Pipeline integrieren
• Code Reviews: Accessibility als festen Prüfpunkt in Reviews aufnehmen
• Design-Phase: Barrierefreiheit bereits im Designprozess berücksichtigen

Audit-Rhythmus festlegen

• Vollständiger Audit: Mindestens einmal jährlich
• Automatisierte Scans: Wöchentlich oder bei jedem Deployment
• Manuelle Spot-Checks: Bei jeder größeren Änderung an Templates oder Komponenten

Fazit

Ein Web Accessibility Audit ist der erste Schritt zu einer wirklich barrierefreien Website. Die Kombination aus automatisierten Tools und manuellen Tests liefert ein vollständiges Bild. Ergebnisse priorisieren, einen strukturierten Maßnahmenplan erstellen und Accessibility-Testing dauerhaft in den Entwicklungsprozess integrieren.

Verwandte Themen

• BFSG 2025: Was das Barrierefreiheitsstärkungsgesetz bedeutet
• ARIA Landmarks: Seitenstruktur für Screenreader optimieren
• BFSG technisch umsetzen mit Astro

Häufige Fragen

Wie oft sollte ein Accessibility Audit durchgeführt werden?

Ein vollständiger Audit sollte mindestens einmal jährlich durchgeführt werden. Zusätzlich empfehlen sich automatisierte Scans bei jedem Deployment und manuelle Spot-Checks bei größeren Änderungen an Design oder Funktionalität.

Reicht ein automatisierter Test aus?

Nein. Automatisierte Tools erkennen nur etwa 30 % aller Barrierefreiheitsprobleme. Sie finden fehlende Alt-Texte, unzureichende Kontraste und invalides HTML, aber keine kontextbezogenen Fehler.

Welches WCAG-Level sollte angestrebt werden?

Für die meisten Websites ist WCAG 2.1 Level AA der richtige Standard. Er wird vom BFSG als Mindestanforderung referenziert und deckt die wesentlichen Barrierefreiheitsanforderungen ab.