Was ist ein Accessibility Audit? Definition 2026

Ein Accessibility Audit ist eine systematische Überprüfung einer Website, App oder digitalen Anwendung daraufhin, ob sie von allen Menschen genutzt werden kann, einschließlich Personen mit visuellen, motorischen, auditiven oder kognitiven Einschränkungen. Grundlage ist in der Regel der internationale Standard WCAG 2.1 Level AA (Web Content Accessibility Guidelines), der auch im deutschen Barrierefreiheitsstärkungsgesetz (BFSG) referenziert wird.

Seit dem 28. Juni 2025 ist das BFSG in Kraft und verpflichtet privatwirtschaftliche Unternehmen erstmals zur digitalen Barrierefreiheit. Ein Accessibility Audit ist damit nicht mehr nur eine Best Practice, sondern der erste Schritt zur rechtskonformen Dokumentation. Wer keinen Audit vorweisen kann, hat im Streitfall gegenüber Marktüberwachungsbehörden eine schwache Position.

Es gibt zwei grundlegende Audit-Typen: Automatisierte Audits mit Tools wie axe DevTools oder Lighthouse decken ca. 30 bis 40 Prozent der WCAG-Kriterien ab. Manuelle Audits durch Experten und Tests mit echten Screenreadern wie NVDA oder VoiceOver sind für die restlichen Kriterien unverzichtbar. Ein professioneller BFSG-konformer Audit kombiniert immer beide Ansätze.

Ein strukturierter Accessibility Audit folgt einem klaren Prozess, der sicherstellt, dass keine relevanten WCAG-Kriterien übersehen werden:

• 1. Scope definieren: Welche Seiten, Flows und Interaktionselemente werden geprüft? Bei großen Websites empfiehlt sich eine repräsentative Stichprobe nach WCAG-Konformitätsmethodik.
• 2. Automatisierter Scan: axe DevTools, Lighthouse oder Silktide Accessibility Checker scannen die gesamte Seite und liefern eine priorisierte Liste der gefundenen Verstöße inkl. WCAG-Kriteriums-Referenz.
• 3. Manueller Test: Tastaturnavigation (nur Tab/Enter/Pfeil), Screenreader-Test mit NVDA + Firefox und VoiceOver + Safari, 200%-Zoom-Test, Farbblindheits-Simulation und Prüfung komplexer Widgets (Modals, Dropdowns, Akkordeons).
• 4. Bericht erstellen: Dokumentation aller Befunde mit WCAG-Kriterium, Schweregrad (kritisch/ernst/moderat/gering), Screenshot und konkreter Handlungsempfehlung.
• 5. Barrierefreiheitserklärung: Auf Basis des Audits wird die gesetzlich vorgeschriebene Erklärung erstellt, die Konformitätsstatus, bekannte Barrieren und einen Feedback-Mechanismus enthält.

Die Toollandschaft für Accessibility Audits ist 2026 gut aufgestellt. Kein einzelnes Tool deckt alle WCAG-Kriterien ab, aber die Kombination aus automatisierten und manuellen Werkzeugen liefert ein vollständiges Bild:

• axe DevTools – Browser-Extension (Chrome/Firefox) und axe-core als Node.js-Paket für CI/CD. Branchen-Standard, sehr geringe Falsch-Positiv-Rate.
• Google Lighthouse – In Chrome DevTools integriert, liefert Accessibility-Score und priorisierte Fehlerliste. Gut als erster Schnellcheck.
• WAVE (WebAIM) – Visualisiert Barrierefreiheitsprobleme direkt auf der Seite, besonders hilfreich für Alt-Text und Strukturprobleme.
• Silktide Accessibility Checker – Crawlt ganze Websites automatisiert, ideal für große Projekte mit vielen Unterseiten.
• NVDA + Firefox (Windows, kostenlos) – Screenreader-Referenz für manuelle Tests unter Windows.
• VoiceOver + Safari (macOS/iOS) – Pflicht für Apple-Plattformen und mobile Tests.
• Stark (Figma-Plugin) – Prüft Kontraste und Farbblindheits-Simulationen direkt im Design-Prozess.

Für Teams mit CI/CD-Pipelines empfiehlt NCA die Integration von axe-core in Cypress-Tests als eigene Stage. So werden A11Y-Regressions automatisch erkannt, bevor sie in Produktion gelangen. eslint-plugin-jsx-a11y ergänzt den Stack auf Ebene der statischen Code-Analyse.

Die WCAG unterscheiden drei Konformitätsstufen, die im Audit als Bewertungsmaßstab dienen:

• Level A (Minimum): Grundlegende Anforderungen, ohne die bestimmte Nutzergruppen gar keinen Zugang haben. Beispiel: Alt-Texte für informative Bilder, Videos mit Untertiteln.
• Level AA (Standard, BFSG-Pflicht): Deckt die Mehrheit der Barrieren ab. Beinhaltet Farbkontrasträte (4,5:1), sichtbare Fokus-Indikatoren, Vermeidung von reiner Farbbedeutung. Das BFSG verlangt Konformität auf Level AA.
• Level AAA (Optimal): Höchste Anforderungen, nicht immer für alle Inhalte erreichbar. Beispiel: Gebärdensprache für alle Audioinhalte, Kontrastverhältnis 7:1.

Ein BFSG-konformer Audit prüft systematisch alle Kriterien der Stufen A und AA. WCAG 2.2 fügt gegenüber 2.1 sechs neue Level-A/AA-Kriterien hinzu, darunter sichtbare Fokus-Indikatoren (2.4.11) und Mindestgröße für Klickziele (2.5.8). Die für das BFSG aktualisierte EN 301 549 wird künftig auf WCAG 2.2 verweisen – wer jetzt auf 2.2 prüft, ist langfristig auf der sicheren Seite.

Bei PHP- und Symfony-basierten Webanwendungen gibt es spezifische Stolpersteine, die ein Accessibility Audit regelmäßig aufdeckt. NCA sieht in seiner Projektpraxis vor allem folgende Muster:

• Twig-Templates mit nicht-semantischem HTML: Häufig werden <div>-basierte Strukturen ohne ARIA-Rollen eingesetzt, wo natives HTML wie <nav>, <main> oder <button> ausreicht.
• Formulare ohne korrekte Labels: Symfony Form Builder generiert oft IDs, die nicht automatisch mit <label for> verknüpft werden. Muss im Template manuell geprüft werden.
• Dynamische Inhalte ohne ARIA-Live-Regionen: Ajax-Updates, Flash-Messages und Validierungsfeedback sind für Screenreader unsichtbar, wenn kein aria-live gesetzt ist.
• Sulu CMS Editierbereich: Rich-Text-Eingaben im Backend können HTML produzieren, das im Frontend Barrierefreiheitsprobleme verursacht (z. B. leere Links, fehlende Alt-Texte in Redakteur-uploads).

NCA führt Accessibility Audits direkt im Projektkontext durch und kennt die typischen Schwachstellen von Symfony, Sulu CMS und PHP-Frontends. Nach dem Audit übernehmen wir bei Bedarf die technische Umsetzung aller Korrekturen, inklusive Barrierefreiheitserklärung und CI/CD-Integration.

Die wichtigsten Fragen zum Accessibility Audit 2026, kompakt beantwortet.