Web-Barrierefreiheit in 2 Stunden prüfen: Open-Source-Stack und EAA-Checkliste

Vom Kiwop-Team · Digitale Agentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz · Veröffentlicht am 7. Mai 2026 · Letzte Aktualisierung: 7. Mai 2026

TL;DR — Die Deadline des European Accessibility Act war der 28. Juni 2025. Die meisten Websites sind immer noch nicht konform. Dieser Post gibt Dir das praktische Framework: 5 Open-Source-Tools, die ~70% der automatisch erkennbaren Fehler abdecken, ein vollständiges Audit in 2 Stunden und eine nach rechtlichem Impact priorisierte EAA-Checkliste. Ohne Berater, ohne Sonderbudget. Nur bewährter Stack und kopierbare Befehle.

Als der European Accessibility Act am 28. Juni 2025 in Kraft trat, war die häufigste Reaktion in technischen Teams: „Das schauen wir uns nächste Woche an." Zehn Monate später sind die meisten dieser Websites unverändert. Der WebAIM Million Report 2024 bestätigte das sogar noch vor der Deadline: 94,8% der analysierten Startseiten hatten automatisch erkennbare WCAG-Fehler.

Das Problem ist nicht mangelnder Wille. Es fehlt ein klarer Einstiegspunkt. Du weißt, dass Du WCAG 2.2 AA erfüllen musst, Du weißt, dass es Tools gibt, aber Du hast keinen klaren Plan, wo Du anfangen sollst, wie viel Zeit es erfordert und wie Du priorisieren sollst, was Du findest.

Dieser Artikel ist dieser Einstiegspunkt. Wenn Du bereits unseren Guide über die EAA-Normung, Fristen und Sanktionen gelesen hast, ist das der nächste Schritt: das konkrete technische Verfahren. Wenn nicht, lies ihn zuerst — hier setzen wir voraus, dass Dir klar ist, was das Gesetz von Dir verlangt, und wir konzentrieren uns darauf, wie Du es umsetzt.

Warum JETZT auditieren (und nicht nächste Woche)

Der reale Stand der EAA-Konformität im Jahr 2026

Die Deadline ist vorbei. Es ist keine zukünftige Drohung: Die EAA ist bereits anwendbares Recht in allen EU-Mitgliedstaaten, die die Richtlinie vor dem 28. Juni 2025 umgesetzt haben. Und die Konformitätszahlen sind alarmierend.

Der WebAIM Million 2024 analysierte die 1.000.000 meistbesuchten Startseiten. Ergebnis: 94,8% hatten mindestens einen automatisch erkennbaren WCAG 2.1 AA-Fehler — und das noch vor den Fehlern, die nur bei manueller Überprüfung auftauchen. Die häufigsten Fehler: geringer Farbkontrast (81% der Seiten), fehlender Alternativtext (54,5%), fehlende Formular-Labels (48,6%), leere Links (44,6%) und Schaltflächen ohne zugänglichen Namen (28,2%).

Anders gesagt: Fast sicher hat Deine Website all diese Probleme. Die Frage ist nicht, ob Du konform bist, sondern wie viele Kriterien Du nicht erfüllst und wie schwerwiegend.

Das konkrete rechtliche Risiko

Das offizielle Portal der Europäischen Kommission zur EAA ist klar: Die Normen gelten für jedes Unternehmen, das digitale Produkte oder Dienstleistungen an Verbraucher in der EU anbietet, unabhängig von seinem Sitz. Die Sanktionen legt jeder Mitgliedstaat fest, aber die Richtlinie verlangt, dass sie „wirksam, verhältnismäßig und abschreckend" sind. In mehreren Ländern werden bereits Bußgelder von bis zu 100.000 Euro pro Verstoß vorgesehen.

Über Bußgelder hinaus: Jede Person mit einer Behinderung, die Deinen Dienst nicht nutzen kann, kann eine formelle Beschwerde beim Aufsichtsorgan ihres Landes einreichen. Die Beweislast liegt beim Unternehmen — Du musst nachweisen, dass Du konform bist, nicht sie, dass Du es nicht bist.

Was der Regulierer verlangt (und was nicht)

Was verlangt wird, ist Konformität mit WCAG 2.2 Stufe AA und eine öffentliche Erklärung zur Barrierefreiheit. Was nicht verlangt wird, ist absolute Perfektion oder ein jährliches Audit, das von einer Zertifizierungsstelle unterzeichnet wurde. Es verlangt ein angemessenes Niveau an dokumentierter Sorgfalt.

Was Dich nicht rettet: Ein JavaScript-Overlay, das über Deine Website gelegt wird und automatische Barrierefreiheit verspricht. Die FTC hat accessiBe mit einer Million Dollar wegen irreführender Werbung genau in diesem Punkt bestraft. Keine Aufsichtsbehörde akzeptiert ein Overlay als Konformitätsnachweis.

Der erste echte Schritt zu dieser Sorgfalt ist das Audit. Und Du kannst es in 2 Stunden mit den richtigen Tools durchführen.

Der Stack: 5 Open-Source-Tools, die ~70% von WCAG 2.2 AA abdecken

Bevor Du den Prozess siehst, verstehe die grundlegende Einschränkung jedes automatischen Tools: Sie erkennen ungefähr 30-40% der tatsächlichen Barrierefreiheitsprobleme. Das sagt der W3C-Leitfaden zu Barrierefreiheitsaudits. Der Rest erfordert manuelle Überprüfung — Tastaturnavigation, Screenreader, menschliches Urteil.

Warum dann mit automatischen Tools beginnen? Weil sie es Dir ermöglichen, die gröbste Fehlerschicht systematisch in Minuten zu eliminieren, was Zeit für die manuelle Überprüfung freisetzt, wo der eigentliche Wert liegt.

axe-core (Deque) — der Industriestandard-Motor

axe-core ist die Open-Source-Bibliothek von Deque Systems, die heute praktisch alle Barrierefreiheits-Testing-Tools der Industrie antreibt. Chrome DevTools, Storybook, Playwright, Cypress und Dutzende von CI-Frameworks verwenden es. Es ist keine Option unter vielen: Es ist der Motor.

Sein Hauptvorteil ist nicht die Abdeckung — es ist die praktisch null Falsch-Positiv-Rate. Wenn axe einen Fehler meldet, ist es ein echter Fehler. Wenn es nichts meldet, bedeutet das nicht, dass Du sauber bist; es bedeutet, dass die Fehler, die es nicht erkennt, in den 60-70% liegen, die manuelle Überprüfung brauchen.

Du kannst axe auf drei Arten verwenden:

Als Browser-Erweiterung (axe DevTools Free): Installiere die Erweiterung in Chrome oder Firefox, öffne Deine Seite, führe die Analyse aus. Ergebnis in Sekunden. Null Konfiguration. Ideal für den ersten Kontakt.

Als Bibliothek in Tests: Integriere axe-core direkt in Deine Test-Suite mit Playwright oder Cypress:

Via CLI mit @axe-core/cli:

Lighthouse — die kostenlose Chrome-Ergänzung

Lighthouse enthält ein Barrierefreiheits-Audit in seinem Standardbericht, ebenfalls auf axe-core basierend, aber mit zusätzlicher Abdeckung von Performance-Metriken und einigen eigenen Prüfungen.

Sein Barrierefreiheits-Score (0-100) entspricht nicht einem WCAG-Konformitätsprozentwert. Er ist ein relatives Maß, das als Referenz dient. Was wirklich nützlich ist, ist die kategorisierte Issue-Liste, die generiert wird.

Du kannst es ausführen aus:

• Chrome DevTools → Lighthouse → Kategorie „Barrierefreiheit"
• CLI: npx lighthouse https://deine-website.de --only-categories=accessibility --output json
• PageSpeed Insights: https://pagespeed.web.dev/ (kostenlos, ohne Installation)

Die offizielle Lighthouse-Barrierefreiheitsdokumentation von Google dokumentiert genau, was jedes Kriterium prüft und wie der Score berechnet wird. Lies es einmal, um die Ergebnisse nicht falsch zu interpretieren.

Pa11y — Audit von CLI/CI aus

Pa11y ist das Befehlszeilen-Tool, das für die Integration in CI/CD-Pipelines entwickelt wurde. Es kann eine einzelne URL, einen vollständigen Sitemap oder eine Liste von Seiten auditieren und Ergebnisse in mehreren Formaten exportieren.

Pa11y verwendet standardmäßig htmlcs, kann aber für axe-core als Motor konfiguriert werden:

Der Vorteil von Pa11y gegenüber dem manuellen Ausführen von axe ist, dass es gut mit Seiten mit asynchronem JavaScript, Basic Authentication und Multi-Page-Sites umgeht, ohne eigene Skripte schreiben zu müssen.

NVDA + VoiceOver — die echten Screenreader

Kein automatisches Tool kann 20 Minuten Navigation Deiner Website mit einem Screenreader ersetzen. Die Ergebnisse sind immer aufschlussreich — und immer anders als erwartet.

NVDA (Windows, kostenlos): Der meistgenutzte Screenreader in Windows-Umgebungen. Lade es von nvaccess.org herunter. Die grundlegenden Shortcuts für ein schnelles Audit:

VoiceOver (macOS/iOS, im System enthalten): Aktiviere es mit Cmd + F5. Für ein schnelles Audit auf macOS:

Was Du mit beiden Screenreadern suchst: Kündigt es korrekt den Typ jedes Elements an (Schaltfläche, Link, Feld)? Haben Formulare Labels? Haben Bilder nützliche Alt-Texte? Ergibt die Lesereihenfolge Sinn?

WAVE (Browser-Erweiterung) — schnelle visuelle Checks

Die WAVE-Erweiterung von WebAIM überlagert visuelle Icons direkt auf der Seite und zeigt Fehler, Warnungen und Strukturelemente an. Es ist die schnellste Möglichkeit, einen visuellen Überblick über Probleme zu erhalten, ohne den Browser zu verlassen.

Besonders nützlich für:

• Die Heading-Hierarchie auf einen Blick sehen (Springst Du von H1 zu H4?)
• Bereiche mit geringem Kontrast im visuellen Kontext erkennen
• Formulare ohne Label vor der Ausführung von axe identifizieren
• Sicherstellen, dass ARIA-Landmarks korrekt definiert sind (header, nav, main, footer)

Verwende es nicht als Hauptwerkzeug — es hat mehr Falsch-Positive als axe. Verwende es als ersten visuellen Überblick vor der Ausführung der anderen.

Schritt für Schritt: Dein erstes Audit in 2 Stunden

Dieses Protokoll deckt die kritischsten Seiten Deiner Website ab: Home, eine Listenseite, eine Detailseite und den Haupt-Conversion-Flow (Kontakt, Registrierung oder Kauf). Mit den 2 Stunden so verteilt:

Minute 0-15: Setup → Minute 15-45: Automatisierung → Minute 45-90: Manuelle Überprüfung → Minute 90-120: Priorisierung und Bericht

Minute 0-15: Setup

Bevor Du Tools startest, definiere genau, welche Seiten Du auditieren wirst. Ein Audit, das versucht, die gesamte Website auf einmal abzudecken, deckt am Ende nichts gut ab.

Empfohlene Mindestliste für ein erstes Audit:

1. Startseite (/)
2. Eine repräsentative Listing- oder Kategorieseite
3. Eine repräsentative Detail- oder Serviceseite
4. Kontaktseite oder Hauptformular
5. Eine Checkout- oder Registrierungsseite (falls zutreffend)

Installiere mit dieser Liste die Tools:

Installiere auch die WAVE-Erweiterung in Chrome oder Firefox und lade NVDA herunter, wenn Du unter Windows bist (oder aktiviere VoiceOver auf macOS mit Cmd + F5).

Minute 15-45: Automatisierte Ausführung (axe + Lighthouse + Pa11y)

Führe die drei Tools für jede URL Deiner Liste aus. Die Reihenfolge ist wichtig: Beginne mit axe, weil sein Output am saubersten ist, dann Lighthouse für die kombinierte Performance- + Barrierefreiheits-Ansicht und Pa11y zur Validierung mit einem zweiten Motor.

Öffne während der Ausführung jede URL in Chrome mit der aktiven WAVE-Erweiterung. Notiere visuell die Muster, die Du siehst, bevor Du die Berichte liest.

Wenn die Skripte fertig sind, öffne die JSON mit einem Viewer oder zähle einfach die Verletzungen:

Minute 45-90: Manuelle Tests mit Screenreadern

Das ist der Teil, der am meisten bringt und den die meisten überspringen. Überspringe ihn nicht.

Protokoll für 20 Minuten mit NVDA oder VoiceOver (wiederhole für jede kritische Seite):

1. Navigiere nur mit Tab vom Anfang der Seite. Ist das erste Element „Zum Hauptinhalt springen" (Skip-Link)? Ist der Fokus jederzeit sichtbar? Ergibt die Reihenfolge logischen Sinn?

1. Öffne die Heading-Liste (Insert + F7 in NVDA, Rotor in VoiceOver). Gibt es ein H1? Ist die Hierarchie kohärent? Gibt es Headings bei Elementen, die visuell keine Headings sind?

1. Aktiviere den Formularmodus, wenn Formulare vorhanden sind. Fülle das Formular nur mit der Tastatur aus. Kündigt jedes Feld sein Label an? Werden Validierungsfehler korrekt angekündigt? Kannst Du das Formular absenden?

1. Navigiere durch Links (Taste K in NVDA). Haben alle Links einen beschreibenden Text außerhalb des Kontexts? Sagt keiner „Hier klicken", „Mehr sehen" oder „Lesen"?

1. Höre auf die Bilder. Wenn der Fokus auf ein Bild trifft, beschreibt der Alternativtext seinen Inhalt oder seine Funktion? Werden dekorative Bilder ignoriert (alt="")?

Dokumentiere jedes gefundene Problem mit: URL, betroffenes Element, verletztes WCAG-Kriterium und Priorität (wir sehen sie im nächsten Schritt).

Minute 90-120: Priorisierung und Bericht

Du hast zwei Quellen von Issues: automatische Berichte und Deine manuellen Notizen. Die Aufgabe jetzt ist, sie zusammenzuführen und nach rechtlichem und Nutzer-Impact zu priorisieren.

Versuche noch nichts zu lösen. Das Ziel der 2 Stunden ist Diagnose, nicht Behebung.

Für den Bericht erstelle ein Dokument mit dieser Mindeststruktur:

Wie man die Ergebnisse interpretiert: Priorisierung nach rechtlichem Impact

Der häufigste Fehler bei der Interpretation eines Barrierefreiheitsaudits ist, alle Issues gleich zu behandeln. Ein geringer Kontrast in einem Footer-Text hat sehr andere Konsequenzen als ein Registrierungsformular, das nicht per Tastatur bedienbar ist.

Die Priorisierungsmatrix kombiniert zwei Achsen: Schweregrad für den Nutzer (Blockiert es die Nutzung?) und rechtliche Exposition (Betrifft es kritische Flows, die der Regulierer zuerst prüfen würde?).

Kritische Issues (blockieren Konformität)

Ein Issue ist kritisch, wenn es verhindert, eine Aufgabe zu erledigen für einen Nutzer mit einer Behinderung oder wenn es einen Flow betrifft, den der Regulierer vorrangig prüfen würde (Registrierung, Kauf, Kontakt, Zugang zum Dienst).

Die üblichen Kandidaten:

• Formulare nicht per Tastatur zugänglich: Das WCAG-Kriterium 2.1.1 (Tastatur) ist Level A — das Mindestlevel. Es beim Kontaktformular nicht zu erfüllen ist eine direkte Konformitätssperre.
• Funktionale Bilder ohne Alt-Text: Ein Bild, das ein Link oder eine Schaltfläche ohne Alternativtext ist, lässt den Screenreader-Nutzer ohne Informationen, um zu handeln. Kriterium 1.1.1.
• Schaltflächen ohne zugänglichen Namen: <button><svg>...</svg></button> ohne aria-label. Die Schaltfläche existiert, der Nutzer weiß, dass sie da ist, aber nicht, was sie tut. Kriterium 4.1.2.
• Video mit Audio ohne Untertitel: Wenn Du Videos mit Audioinformationen hast, verlangt Kriterium 1.2.2 synchronisierte Untertitel. Das Fehlen ist blockierend und hoch sichtbar.

Wichtige Issues (hohes Beschwerderisiko)

Ein Issue ist wichtig, wenn es die Nutzung erheblich erschwert, aber nicht vollständig blockiert, oder wenn es Seiten mit hoher Sichtbarkeit betrifft, obwohl der individuelle Einfluss partiell ist.

• Geringer Kontrast im Haupttext: Kriterium 1.4.3. Ein Verhältnis unter 4,5:1 bei Fließtext betrifft Nutzer mit Sehschwäche und Nutzer in schwierigen Lichtverhältnissen (das sind nicht nur Menschen mit deklarierter Behinderung).
• Unterbrochene Heading-Hierarchie: Von H1 zu H4 springen, Headings nur für visuelles Styling verwenden oder kein H1 haben. Betrifft Screenreader und kognitive Nutzer, die nach Struktur navigieren. Kriterium 1.3.1.
• Fehlender sichtbarer Fokus: Wenn das Fokus-outline global mit *:focus { outline: none; } entfernt wurde, wird Tastaturnavigation undurchsichtig. Kriterium 2.4.7 (AA) und 2.4.11 (AA in WCAG 2.2).
• Fehlermeldungen ohne ARIA Live Regions: Wenn ein Formular validiert und Fehler anzeigt, kündigt der Screenreader sie automatisch an? Wenn nicht, weiß der Nutzer nicht, dass etwas schiefgelaufen ist. Kriterium 3.3.1.

Geringfügige Issues (Verbesserungen)

Ein Issue ist geringfügig, wenn es begrenzten Einfluss hat, sekundäre Elemente betrifft oder Kontexturteil erfordert, um festzustellen, ob es wirklich ein Problem ist.

• Beschreibender, aber ungenauer Alt-Text bei dekorativen oder unterstützenden Bildern.
• Kontrast leicht unter dem Minimum bei Footer-Texten oder Disclaimern.
• Redundante ARIA-Rollen, die keinen Schaden anrichten, aber keinen Wert hinzufügen.
• Kontextuelle Link-Texte (die mit dem umgebenden Text Sinn ergeben, aber nicht alleine).

Ignoriere geringfügige Issues nicht auf unbestimmte Zeit — sie häufen sich an. Aber blockiere die Behebung kritischer Issues nicht durch das Lösen geringfügiger zuerst.

Was Tools NICHT erkennen (und manuell gemacht werden muss)

Hier sind die 60-70%, die axe, Pa11y und Lighthouse nicht sehen. Dieser Block unterscheidet ein echtes Audit von einem automatischen Check und einem Klick auf „Teilen". Die W3C-Dokumentation zur Konformitätsbewertung beschreibt das rigorös; hier ist die praktische Version.

Falscher Einsatz von „dekorativem" Alternativtext: axe überprüft, ob Bilder Alt-Texte haben, kann aber nicht wissen, ob der Alternativtext den Inhalt korrekt beschreibt. „Bild 1" oder der Dateiname bestehen den automatischen Check und sind ein echter Fehler.

Logische Tab-Reihenfolge: Tab navigiert durch interaktive Elemente in der DOM-Reihenfolge. Wenn Dein CSS Elemente visuell neu anordnet, kann die Tab-Reihenfolge chaotisch sein. Kein Tool erkennt das — nur durch Navigation mit Tab.

Korrekt verknüpfte Formular-Labels: axe erkennt fehlende Labels, aber erkennt keine Labels, die im HTML vorhanden, aber nicht korrekt mit dem richtigen Feld verknüpft sind (entweder durch falsche for/id-Verknüpfung oder falsch implementierte Proximity Association).

Kontextuelle Link-Texte: WCAG erlaubt Links, deren Text („Mehr sehen") im Kontext durch den umgebenden Text Sinn ergibt (Kriterium 2.4.4 — Im Kontext). axe kann nicht bewerten, ob dieser Kontext ausreichend ist. Nur ein Mensch kann das beurteilen.

Lesefluss im Screenreader: Die Lesereihenfolge eines Screenreaders folgt dem DOM, nicht der visuellen Präsentation. Layouts mit CSS Grid oder Flexbox, die Elemente visuell neu anordnen, können einen unverständlichen Lesefluss erzeugen, den kein automatisches Tool erkennt.

Video-Untertitel und Transkriptionen: axe erkennt, ob ein <track>-Element in einem <video> existiert, kann aber nicht überprüfen, ob die Untertitel genau, vollständig oder gut synchronisiert sind. Das erfordert menschliche Überprüfung.

Komplexe Gesten ohne Alternative: Wenn Deine Oberfläche Funktionen hat, die durch Mehrfinger-Gesten aktiviert werden (Pinch, Swipe) ohne Tastatur- oder Einfingertipp-Alternative, ist das eine Verletzung des Kriteriums 2.5.1. Desktop-Tools erkennen das nicht.

Falsch verwendetes ARIA: axe erkennt ungültiges ARIA, aber nicht technisch gültiges ARIA, das die Semantik bricht. Ein role="presentation" auf einem interaktiven Element oder ein aria-hidden="true" auf relevanten Inhalten besteht den automatischen Check und sind schwerwiegende Fehler.

Berichterstattung im EAA-Konformitätsformat

Ein Audit, das keine nützliche Dokumentation erzeugt, ist ein halbes Audit. Der Regulierer verlangt keinen axe-Test; er verlangt Sorgfaltsnachweis. Die GOV.UK-Barrierefreiheitsguidelines — Branchenreferenz, obwohl UK-bezogen — dokumentieren den De-facto-Standard für Barrierefreiheitserklärungen, den mehrere europäische Regulierer als Referenz übernommen haben.

Struktur des von der Verwaltung verlangten Berichts

Ein Barrierefreiheitsaudit-Bericht, den Du dem Regulierer vorlegen kannst (oder der Dir als Basis für Deine Erklärung dient), muss enthalten:

1. Umfang: Welche Seiten wurden auditiert, warum wurden diese ausgewählt und welche Assistenztechnologien wurden für die manuelle Überprüfung verwendet.
2. Methodik: Automatisierte Tools (genaue Versionen), manuelle Überprüfungsprozess (Screenreader, Browser-Versionen).
3. Evaluierter Standard: WCAG 2.2 Stufe AA / EN 301 549.
4. Befunde: Liste der nicht erfüllten Kriterien, mit Belegen (Screenshots, HTML-Fragmente), klassifiziert nach Schweregrad.
5. Konformitätsstatus: Vollständige, teilweise oder nicht konforme Konformität — mit Begründung.
6. Dokumentierte Ausnahmen: Wenn es unkontrollierbare Drittinhalte gibt (externes Widget, eingebettete Karte), als vorübergehende Ausnahme mit Lösungsplan dokumentieren.
7. Datum des Audits und Überprüfungsfrequenz.

Vorlage für die Barrierefreiheitserklärung

Die Barrierefreiheitserklärung ist das öffentliche Dokument, das die EAA verlangt, auf Deiner Website zu veröffentlichen (üblicherweise unter einer URL wie /barrierefreiheit oder im Footer). Mindeststruktur:

Wie man vorübergehende Ausnahmen dokumentiert

Wenn Du Inhalte hast, die nicht konform sind, aber nicht sofort behoben werden können (Chat-Widget eines Drittanbieters, eingebettete Karte, veraltete PDF), erlaubt die EAA deren Dokumentation als vorübergehende Ausnahme unter Bedingungen:

• Den betroffenen Inhalt und das verletzte WCAG-Kriterium beschreiben.
• Begründen, warum es eine unverhältnismäßige Last ist, ihn sofort zu beheben.
• Das geplante Lösungsdatum oder die verfügbare zugängliche Alternative angeben.
• Die Erklärung aktualisieren, wenn es behoben ist.

Eine dokumentierte Ausnahme ist rechtlicher Schutz. Eine undokumentierte Ausnahme ist es nicht.

Konformität aufrechterhalten: CI-Integration

Das punktuelle Audit sagt Dir, wo Du heute stehst. Die CI-Integration sagt Dir, ob das, was Du morgen veröffentlichst, das bricht, was Du gestern repariert hast. Ohne Barrierefreiheits-CI ist die Behebung ein Eimer mit Löchern.

axe-core in GitHub Actions / GitLab CI

Der grundlegendste CI-Block mit axe und Playwright:

Und der entsprechende Test:

Wenn Dein Projekt React oder ein anderes SPA-Framework verwendet, stelle sicher, dass der Test wartet, bis der dynamische Inhalt gerendert wurde, bevor axe ausgeführt wird — verwende page.waitForSelector oder page.waitForLoadState('networkidle').

Pa11y Dashboard

Pa11y hat ein Open-Source-Web-Dashboard, das es ermöglicht, die Barrierefreiheit einer gesamten Website über die Zeit zu überwachen und die Entwicklung der Issues pro Seite zu sehen. Besonders nützlich für:

• Websites mit vielen dynamisch generierten Seiten (Blogs, E-Commerce).
• Teams, wo nicht-technische Mitarbeiter die Ergebnisse konsultieren.
• Geplante wöchentliche oder monatliche Audits ohne manuelle Eingriffe.

Für kleinere Projekte ist Pa11y CI mit JSON-Output und einer versionierten Konfigurationsdatei im Repo oft ausreichend:

Der threshold-Parameter erlaubt es, eine maximale Anzahl akzeptabler Verletzungen festzulegen, bevor der Build fehlschlägt — nützlich, wenn Du im Behebungsprozess bist und Regressionen vermeiden möchtest, ohne jeden PR zu blockieren.

Pull-Request-Gating

Die effektivste Art, Konformität aufrechtzuerhalten, ist das Blockieren von PR-Merges, die neue Verletzungen einführen. Der empfohlene Flow:

1. Der CI-Workflow führt axe auf den vom PR betroffenen Seiten aus.
2. Wenn es neue Verletzungen gibt (verglichen mit dem Basis-Branch), schlägt der Check fehl.
3. Der PR kann nicht gemergt werden, bis die neuen Verletzungen behoben oder die Ausnahme dokumentiert ist.

Der Schlüssel ist, nur betroffene Seiten zu auditieren — die gesamte Website bei jedem PR zu auditieren ist zu langsam. Eine praktische Strategie: Welche Komponenten jeder PR betrifft abbilden und die Seiten auditieren, die diese Komponenten verwenden.

Dieses in den Entwicklungszyklus integrierte QA-Automation-Modell ist dasselbe, das wir auf andere Qualitätsbereiche anwenden: Performance, Sicherheit, Test-Abdeckung.

Zu überwachende Metriken

Die Metriken, die für die zeitliche Verfolgung von Barrierefreiheit wirklich zählen:

Häufige Fehler bei der Behebung

Das Audit ist die Hälfte der Arbeit. Bei der Behebung machen die meisten Teams Fehler, die neue Probleme schaffen oder ein falsches Konformitätsgefühl erzeugen.

Fehler 1: Nur reparieren, was axe erkennt

Wenn Du nur automatische Issues behebst, deckst Du 30-40% des Problems ab und lässt 60-70% unberührt. Der Regulierer akzeptiert nicht „wir haben axe ohne Fehler bestanden" als WCAG-Konformitätsnachweis. Bestehe den automatischen Check UND die manuelle Überprüfung.

Fehler 2: Automatischer Alt-Text mit KI ohne Überprüfung

Mehrere Barrierefreiheitstools und CMSs bieten automatische Alt-Text-Generierung mit KI an. Das Ergebnis kann technisch vorhanden sein (was axe zufriedenstellt), aber semantisch nutzlos oder falsch. Ein von KI generierter Alt-Text, der „eine Person mit einem Laptop in einem Büro" beschreibt, wenn das Bild ein technisches Architekturdiagramm zeigt, besteht den automatischen Check und scheitert am echten Kriterium. Überprüfe immer generierte Alt-Texte.

Fehler 3: Unnötige ARIA-Rollen, die den Baum brechen

Das häufigste Antimuster beim Versuch, Barrierefreiheit zu „verbessern": ARIA-Rollen zu Elementen hinzufügen, die bereits korrekte native Semantik haben. <button role="button"> ist redundant. <nav role="navigation"> ist redundant. Aber <div role="button"> statt <button> bricht den Barrierefreiheitsbaum, weil das Div nicht das Tastaturverhalten der nativen Schaltfläche hat. Die allgemeine Regel: Verwende natives semantisches HTML, bevor Du ARIA hinzufügst. ARIA ist für Fälle, die HTML nicht abdeckt, nicht zum Dekorieren von vorhandenem HTML.

Fehler 4: Markup ändern ohne erneutes Testen mit NVDA

Jede HTML-Änderung, die Struktur, Rollen, Landmarks oder Elementreihenfolge betrifft, kann die Screenreader-Erfahrung auf nicht offensichtliche Weise ändern. Eine Änderung, die den axe-Score verbessert, kann die tatsächliche Navigation verschlechtern. Teste erneut mit NVDA oder VoiceOver jedes Mal, wenn Du die semantische Struktur einer Seite änderst, nicht nur bei spezifischen Barrierefreiheitsänderungen.

Fehler 5: Ohne das Kriterium zu verstehen beheben

„Füge aria-label zu Schaltflächen hinzu" ist eine Anweisung, die wörtlich interpretiert und im Übermaß angewendet werden kann. Wenn eine Schaltfläche bereits sichtbaren beschreibenden Text hat, kann das Hinzufügen von aria-label ihm widersprechen und den Screenreader verwirren (Kriterium 2.5.3 — Label in Name — verlangt, dass aria-label den sichtbaren Text enthält). Bevor Du eine Korrektur anwendest, lies das WCAG-Kriterium, das die Änderung rechtfertigt, in der offiziellen W3C-Spec.

Häufig gestellte Fragen

Reicht WCAG AA oder brauche ich AAA?

Die EAA verlangt WCAG 2.2 Stufe AA. Stufe AAA ist nicht gesetzlich obligatorisch. Dennoch sind einige AAA-Kriterien sehr einfach zu implementieren und bieten signifikante Verbesserungen für bestimmte Nutzergruppen (wie Kriterium 2.4.12 — Fokusdarstellung — das eine größere Fokussichtbarkeit verlangt). Wenn Du AA ohne zusätzlichen Aufwand erreichst, prüfe, ob bestimmte AAA-Kriterien für Deine Zielgruppe relevant sind. Aber mach AAA nicht zu einem normativen Konformitätsziel — das ist es nicht.

Was ist, wenn ich ein Drittanbieter-Widget habe, das nicht konform ist?

Das ist eines der häufigsten und unbequemsten Szenarien. Wenn das Widget in einem kritischen Flow ist (Support-Chat, Zahlungsgateway, Registrierungsformular), hast Du drei Möglichkeiten: Es durch ein zugängliches ersetzen, eine gleichwertige zugängliche Alternative bereitstellen oder es als vorübergehende Ausnahme mit Lösungsdatum dokumentieren. Was Du nicht kannst, ist es ignorieren — das Gesetz macht Dich verantwortlich für die vollständige Nutzererfahrung, die Du anbietest, einschließlich Komponenten, die Du nicht direkt kontrollierst. Wenn der Widget-Anbieter keine Barrierefreiheits-Roadmap hat, ist das ein Anbieterauswahlkriterium.

Was kostet ein professionelles Barrierefreiheitsaudit?

Ein unabhängiges professionelles Audit — das einen formellen Bericht mit rechtlichem Wert für die Vorlage beim Regulierer generiert — kostet für eine mittelgroße Website im Allgemeinen zwischen 3.000 und 15.000 Euro, abhängig von der Seitenanzahl, der Komplexität der Interaktionen und ob es echte Nutzertests mit Menschen mit Behinderungen umfasst.

Das 2-Stunden-Audit in diesem Post ist kein Äquivalent zu einem professionellen Audit. Es ist eine Hochebene-Diagnose, die Dir zeigt, wo Du stehst und hilft zu priorisieren. Es dient als Basis für die interne Behebung. Wenn Du den formellen Bericht für den Regulierer oder einen rechtlichen Prozess brauchst, benötigst Du ein professionelles Audit. Bei Kiwop führen wir formelle Barrierefreiheitsaudits durch — wenn Du an diesem Punkt bist, sprechen wir.

Muss das Audit wiederholt werden?

Ja, und auf zwei Ebenen. Die automatische Ebene (axe in CI) sollte bei jedem PR ausgeführt werden, der UI-Komponenten ändert. Die vollständige Ebene (Automatisierung + manuelle Überprüfung mit Screenreadern + Flow-Überprüfung) sollte mindestens einmal jährlich wiederholt werden und immer dann, wenn es signifikante Design-Änderungen, neue Hauptfunktionalitäten oder einen Wechsel der Rendering-Technologie gibt.

Barrierefreiheit ist kein Zustand, der einmal erreicht wird und sich selbst erhält. Es ist ein kontinuierlicher Prozess — genau wie Performance oder Sicherheit.

Müssen PDFs oder Dokumente auch konform sein?

Ja. Die EAA gilt nicht nur für HTML. Herunterladbare Dokumente (PDF, Word, Excel), die Teil eines digitalen Dienstes sind, müssen ebenfalls zugänglich sein, wenn sie für den Nutzer relevante Informationen enthalten. Zugängliche PDFs erfordern Heading-Struktur, korrekte Lesereihenfolge, Alt-Text bei Bildern und echten Text (kein gescanntes Bild). Tools: PAC 2024 (PDF Accessibility Checker, kostenlos) und der eingebaute Barrierefreiheitsprüfer in Adobe Acrobat. Wenn Deine Website Dokumentation, Verträge, Rechnungen oder Formulare als PDF anbietet, schließe sie in das Audit ein.

Fazit: Konformität ist ein Prozess, kein Ereignis

Wenn es eine Lektion gibt, die alles oben Gesagte zusammenfasst, dann diese: Barrierefreiheit wird genauso wie Software gewartet — mit automatisierten Tests, die Regressionen erkennen, periodischen Überprüfungen, die validieren, was die Automatisierung nicht sieht, und Dokumentation, die Sorgfalt demonstriert.

Die EAA-Deadline ist vorbei. Du kannst das nicht rückgängig machen. Was Du tun kannst, ist heute zu beginnen, mit dem Stack, den Du hast, in 2 Stunden und von dort aus aufzubauen. Ein unvollkommenes Audit, das heute gemacht wird, ist unendlich wertvoller als ein perfektes Audit, das nie durchgeführt wird.

Der Weg ist: Diagnose (dieser Post) → priorisierte Behebung → CI-Integration → formelles Audit, wenn Deine rechtliche Exposition es erfordert.

Wenn Du an einem Punkt des Weges externe Unterstützung brauchst — ein formelles Audit, eine komplexe Behebung oder die Integration von Barrierefreiheit in den Softwareentwicklungs-Prozess Deines Teams von Anfang an — macht Kiwop genau das. Erzähl uns, wo Du stehst und wir sagen Dir, wo Du anfangen sollst.