Barrierefreiheitsprüfung und Behebung von Mängeln in Web-Anwendungen

Seit dem 28. Juni 2025 verlangt der European Accessibility Act (EAA) von vielen digitalen Diensten für Verbraucher in der EU (E-Commerce, Bankwesen, Ticketverkauf, E-Books, Verkehr) Barrierefreiheit; öffentliche Stellen sind bereits seit Jahren an die Web-Zugänglichkeitsrichtlinie gebunden. Die meisten Teams finden Mängel dennoch spät, nämlich im Audit. Regelwerke erfassen den mechanischen Teil in der CI; KI ergänzt die Beurteilung für den Rest: Ist dieser Alternativtext aussagekräftig, ergibt die Fokusreihenfolge Sinn, und wie sieht die richtige Korrektur in dieser Komponente aus? Ergebnis: frühere Erkennung, Korrekturen als Pull Requests und Expertenzeit für das, was nur Menschen prüfen können.

Problem & Nutzen

• Heute: Barrierefreiheit wird durch ein jährliches externes Audit oder durch Overlay-Widgets geprüft. Die Befunde kommen als PDF, Backlogs wachsen, Entwicklern fehlt das Wissen, um „fehlenden Namen für Schaltfläche“ oder Fokusfallen zu beheben, und mit jedem Release treten Rückschritte auf.
• Was Automatisierung leisten kann und was nicht: Regelwerke wie axe-core erkennen zuverlässig nur einen Teil der WCAG-Probleme; Hersteller- und Praxisquellen nennen grob ein Drittel bis die Hälfte der Mängel nach Häufigkeit, und nur eine Minderheit der Erfolgskriterien ist vollständig maschinell prüfbar. Manuelle Tests mit Tastatur, Screenreader und Nutzern bleiben erforderlich [1][3].
• KI-Nutzen: (1) Befunde sortieren und in Entwicklersprache erklären, (2) Patches im Code erzeugen, (3) semantische Kriterien beurteilen, die Regeln nicht abdecken (Qualität von Alternativtexten, Logik von Überschriften, Verständlichkeit von Beschriftungen, Fehlermeldungen, Lesereihenfolge anhand von Screenshots), (4) die Seite wie ein Nutzer bedienen (reine Tastatur- Agenten), (5) Regressionstests schreiben.
• Rechtlicher Treiber: Der EAA (Richtlinie (EU) 2019/882) gilt ab dem 28. Juni 2025; die harmonisierte Norm EN 301 549 verweist auf die WCAG. Version 4.1.1 (Stand 2026-09) richtet sich an WCAG 2.2 AA aus; prüfen Sie, ob sie für Ihren Fall bereits im Amtsblatt zitiert ist, da Version 3.2.1 (WCAG 2.1 AA) möglicherweise noch die formale Referenz ist [2][4].

Varianten

• KMU-Webshop / Agentur: CI-Scan bei jedem Build plus ein KI-Assistent, der Probleme auf Template-Ebene einmal für alle Seiten behebt.
• Produktteam im Großunternehmen: Behebung auf Ebene des Designsystems (Komponentenbibliothek), Barrierefreiheits-Prüfschritte in Pull Requests, Dashboards über Hunderte Anwendungen.
• Öffentlicher Sektor: Überwachung vieler Websites für die Web-Zugänglichkeitsrichtlinie, Barrierefreiheitserklärungen, Feedback-Mechanismus.
• Mobile Apps: gleiche Logik mit nativen Accessibility-Trees (iOS/Android); der EAA erfasst auch Apps.
• Dokumente (PDF/Office) auf der Website: siehe DOC-026. Videountertitel/Audiodeskription: siehe SPEECH-004.
• Private Seiten / Hobbyseiten: kostenlose Browser-Werkzeuge (Lighthouse, axe-Erweiterung) plus ein LLM, das die Befunde erklärt.

So funktioniert es

1. Code-Repository + Staging-URL
2. regelbasierter Scan (axe-core / Lighthouse / Pa11y in Playwright, je Seite und Zustand)
3. agentische Erkundung (reine Tastaturbedienung, Formulare, Dialoge, Fehlerzustände; DOM + a11y-Baum + Screenshots)
4. LLM/VLM-Beurteilung semantischer Kriterien (Alternativtexte, Beschriftungen, Überschriften, Kontrast in Bildern, Lesereihenfolge)
5. Zuordnung zu WCAG 2.2 / EN 301 549 + Schweregrad + Deduplizierung nach Komponente
6. Korrekturvorschlag (Patch gegen die Quellkomponente, mit Repo-Kontext)
7. erneuter Scan des gepatchten Builds
8. Pull Request mit Vorher-/Nachher-Nachweis
9. menschliche Prüfung (Entwickler + Barrierefreiheits-Fachperson)
10. Merge
11. CI-Regressionstests
12. regelmäßiges manuelles Audit mit Screenreadern und Nutzenden mit Behinderungen

• Erkennung: Deterministische Regeln liefern die Grundwahrheit; das LLM darf Konformität nicht „erklären“.
• Korrektur-Agent: Coding-Agent (siehe CODE-002) mit einem Barrierefreiheits-Werkzeug über MCP, damit Korrekturen durch erneutes Ausführen der Regeln überprüft werden.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ein Entwickler prüft jeden Patch; die Barrierefreiheits-Fachperson gibt Konformitätsaussagen und die Barrierefreiheitserklärung frei; KI-generierte Alternativtexte werden geprüft, wo der Kontext zählt (informative Bilder, Diagramme).

Datenaufbereitung

Die Daten sind hier überwiegend Code und gerenderte Seiten, daher ist die Aufbereitung gering (grob 10 bis 15 Prozent des Aufwands). Quellen sind das Git-Repository, das Designsystem oder die Komponentenbibliothek, Staging-URLs, das Ticketsystem und vorhandene Audit-PDFs. Typische Lücken: keine stabile Staging-Umgebung, Testzustände (angemeldet, Checkout, Fehlerdialoge), die sich nicht automatisch erreichen lassen, keine synthetischen Testkonten und Barrierefreiheitsbefunde, die nur als gescannte oder PDF-Auditberichte vorliegen.

Schritte zur Aufbereitung: - Legen Sie die 5 bis 10 wichtigsten Nutzerwege fest und skripten Sie sie in Playwright, damit der Scanner jeden Zustand erreicht und nicht nur die Startseite. - Erstellen Sie synthetische Testkonten und Demodaten, damit keine echten Kundendaten in Screenshots oder DOM-Dumps auftauchen. - Wandeln Sie alte Auditberichte in einen Ticket-Backlog mit WCAG-Kriterium, Komponente und Schweregrad um; ein Modell kann die Extraktion übernehmen (zur Dokumentenextraktion siehe DOC-014 und DOC-018). - Dokumentieren Sie Komponentenkonventionen (Design Tokens, Fokusstile, Namensregeln) als kurze Markdown-Dateien, die der Agent lesen kann; das ist eine kleine Wissensbasis im Sinne von PREP-013. - Prüfen Sie, welche PDFs und Videos auf der Website gesondert behandelt werden müssen (DOC-026, SPEECH-004).

Die Grundlagen der Datenreife behandelt GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: Weg B — die Korrekturen müssen in Ihrem eigenen Repository und Ihren Templates landen, und eine axe-Prüfung in der CI plus ein Coding-Agent kosten wenig; Overlay- oder SaaS-Produkte beheben selten den Quellcode.
• enterprise: Weg A — bei Hunderten Anwendungen bieten Plattformen wie Deque axe oder Siteimprove Dashboards, Berichtswesen und Audit-Unterstützung, deren Eigenbau sich nicht lohnt.
• developer: Weg B — fügen Sie axe-core zur vorhandenen Playwright-Suite hinzu und lassen Sie einen Coding-Agenten Patches vorschlagen, die er durch erneutes Scannen überprüft.
• public: Weg C — Open-Source-Engines (axe-core, Pa11y) und Open-Weight-Code-Modelle halten Code und Testkonten auf der eigenen Infrastruktur und vermeiden Beschaffungshürden.

Weg A — Kaufen (Standardsoftware)

• Barrierefreiheits-Plattformen mit KI-Funktionen: Deque axe DevTools (inkl. Axe MCP Server für KI-Coding-Agenten in der IDE), Level Access, Siteimprove, TPGi, BrowserStack Accessibility, LambdaTest, Evinced; aus der EU: Siteimprove (DK) und nationale BITV-/EAA-Prüfspezialisten.
• Eingebaute Werkzeuge: Lighthouse und Chrome DevTools, Microsoft Accessibility Insights (Open Source), GitHub Copilot oder Cursor mit dem axe-MCP-Server.
• Vorsicht: „Overlay“-Widgets, die Konformität per Einzeiler versprechen, beheben den Quellcode nicht, werden von Barrierefreiheits-Fachleuten vielfach kritisiert und wurden in den USA von Aufsichtsbehörden beanstandet; verlassen Sie sich für die EAA-Konformität nicht darauf.
• Wählen Sie A, wenn: Sie Dashboards, Berichtswesen und Audit-Unterstützung mit wenig Entwicklungsaufwand wünschen.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Fügen Sie @axe-core/playwright (oder Pa11y / Lighthouse CI) zur vorhandenen Playwright-/Cypress-Suite hinzu und lassen Sie Builds bei neuen Verstößen fehlschlagen.
• Senden Sie Verstöße samt dem zugehörigen Komponenten-Quellcode an ein Code-Modell (Claude, GPT, Gemini oder Mistral Codestral/Devstral als EU-Anbieter), das Patches vorschlägt; nutzen Sie ein multimodales Modell für Prüfungen anhand von Screenshots (Kontrast in Bildern, sichtbare Fokusanzeigen, Lesereihenfolge).
• Steuern Sie das Ganze über einen Coding-Agenten (Claude Code, Copilot Coding Agent, Codex, Cursor) mit axe MCP Server oder Playwright MCP, damit der Agent seine Korrektur überprüfen kann.
• Nutzen Sie EU-Regionen oder EU-Anbieter, wenn Seiten personenbezogene Daten enthalten (angemeldete Zustände, Testkonten).

Weg C — Selbst betreiben (Open Source)

• Engines: axe-core (MPL-2.0), Pa11y, Lighthouse, IBM Equal Access Checker, Accessibility Insights, Alternativen zur WAVE API; Playwright für die Automatisierung.
• Modelle: Open-Weight-Code- und Vision-Modelle (z. B. Qwen3-Coder, Devstral, Qwen-VL-Familie) über vLLM oder Ollama; Agent über OpenHands, Aider, Cline oder Continue.
• Hardware: HW2 für quantisierte Code-Modelle der ~30B-Klasse und ein kleines VLM; HW3 für leistungsfähigere agentische Korrekturen.
• Gut geeignet für öffentliche Stellen oder Code, der das Haus nicht verlassen darf.

Weg D — Eigenes Training

Selten nötig. Möglich ist das Feintuning eines kleinen VLM auf eigenen annotierten Screenshots (z. B. eigene Muster des Designsystems) oder das Lernen der Korrekturkonventionen Ihrer Komponentenbibliothek aus früheren Barrierefreiheits-Pull-Requests. Einige hundert geprüfte Vorher-nachher-Patches sind ein brauchbarer Anfang.

Stand der Technik (2026)

• Hybrid aus Regeln und LLM ist das vorherrschende Muster: deterministische Engines für Genauigkeit, LLMs für Erklärung, Korrekturerzeugung und semantische Prüfungen. MCP-Server stellen die Barrierefreiheits-Engine Coding-Agenten zur Verfügung, damit der Agent seine eigenen Änderungen validiert [3].
• WCAG 2.2 (W3C-Empfehlung, ergänzt u. a. Focus Not Obscured, Target Size (Minimum), Dragging Movements, Accessible Authentication) ist die aktuelle Grundlage; mehrere der neuen Kriterien sind nur teilweise maschinell prüfbar [5].
• Agentische Tastatur- und Screenreader-Simulation wird besser, doch das Screenreader-Verhalten unterscheidet sich zwischen NVDA, JAWS, VoiceOver und TalkBack; LLM-Simulationen sind kein Ersatz.
• Grenzen und Fehlerbilder: halluzinierte oder generische Alternativtexte; „Korrekturen“, die ARIA ergänzen, wo natives HTML besser ist (die erste ARIA-Regel lautet, es nicht zu verwenden, wenn ein natives Element genügt); Patches, die eine Regel zum Schweigen bringen, ohne Nutzern zu helfen; fehlende dynamische Zustände (Modals, Toasts, Routenwechsel in SPAs); falsche Konformitätsaussagen. Testen Sie immer erneut mit assistiven Technologien.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: llm-code + agent-framework + Playwright mit CODE-004 (Testerzeugung), CODE-002 (Agenten von Ticket zu Pull Request), CODE-003 (KI-Code-Review als Barrierefreiheits-Reviewer), CODE-014 (Fehlertriage).
• Vision/Design: CODE-008 und CODE-007 erzeugen Oberflächen; ergänzen Sie ein Barrierefreiheits-Gate, damit erzeugte Oberflächen nicht standardmäßig unzugänglich ausgeliefert werden.
• Inhalte: DOC-026 für von der Website verlinkte PDFs/Office-Dateien; SPEECH-004 für Untertitel von Videoinhalten.
• Dokumentation: CODE-006 zur Dokumentation der Barrierefreiheitsverträge von Komponenten.
• Ein GPU-Server (HW2/HW3), der ein Code-Modell bereitstellt, kann all dies bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Lizenzen pro Nutzer oder pro gescannter Seite/Domain.
• Weg B: 2-6 Wochen, um CI-Gates und einen Korrektur-Agenten für ein Produkt einzuführen; Kosten vor allem Modell-Tokens pro Verstoß (gering) und Prüfzeit der Entwickler.
• Weg C: 1-3 Monate inkl. Modellbetrieb und Agenten-Einrichtung.
• Kennzahlen: offene Verstöße nach Schweregrad, neue Verstöße pro Release (Ziel null), Zeit bis zur Behebung, Anteil der Korrekturen, die ohne Nacharbeit akzeptiert werden, durch manuelles Audit abgedeckte WCAG-Kriterien, Beschwerden beim Support und Meldungen über den Feedback-Mechanismus, Auditbefunde pro Jahr.

Menschen & Veränderung

• Früh einbinden: Geschäftsleitung (Budget, gesetzliche Pflicht nach EAA/BFSG), den Produkt- oder Shop-Verantwortlichen als Prozesseigner sowie Entwickler und Designer als Anwender. Ziehen Sie Recht/Compliance für die Barrierefreiheitserklärung und die IT für den CI-Zugang hinzu. Bitten Sie Menschen mit Behinderungen oder einen Verband für Barrierefreiheit, an den Tests mitzuwirken; sie sind die eigentlichen Kunden des Ergebnisses.
• Betriebsrat: abhängig. Das Werkzeug analysiert Code und Seiten, nicht Personen. Die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG wird relevant, wenn Akzeptanzquoten von Pull Requests oder Kennzahlen je Entwickler berichtet werden; halten Sie Dashboards auf Komponenten- oder Teamebene. Informieren Sie den Betriebsrat dennoch nach § 90 Abs. 1 Nr. 3 BetrVG, wenn sich Arbeitsabläufe ändern.
• Datenschutz: Nutzen Sie synthetische Testkonten; eine DSFA ist normalerweise nicht nötig, aber schließen Sie mit den Modellanbietern einen AVV (Art. 28 DSGVO) und fragen Sie den/die Datenschutzbeauftragte(n), wenn angemeldete Seiten gescannt werden.
• KI-Kompetenz: Unterstützen Sie Entwickler mit einer kurzen Schulung (Art. 4 KI-Verordnung in der geänderten Fassung): was der Agent beurteilen kann und was nicht, warum Alternativtext-Vorschläge geprüft werden müssen.
• Pilot und Kommunikation: Beginnen Sie mit einem Team und einem Template; stellen Sie es als Weg dar, mühsame Korrekturen loszuwerden, nicht als Messung von Personen. Typische Sorge: „Die KI erklärt uns für konform“ — antworten Sie, dass Konformitätsaussagen bei einer Fachperson bleiben und manuelle Tests nötig sind.
• Menschen behalten die Kontrolle: Jeder Patch wird geprüft; keine automatischen Merges.

Siehe GUIDE-008, GUIDE-009 und GUIDE-014.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; das Werkzeug ist eine Entwicklerhilfe und keine Anwendung nach Anhang III. KI-Kompetenz (Art. 4) gilt für das Team. Wird eine KI-Funktion als Chatbot an Endnutzer ausgeliefert, gilt Art. 50 (Transparenz) gesondert.
• Barrierefreiheitsrecht: EAA (Richtlinie 2019/882) mit nationaler Umsetzung (z. B. BFSG in Deutschland, anwendbar seit 28. Juni 2025; Kleinstunternehmen, die Dienstleistungen erbringen, sind ausgenommen); Web-Zugänglichkeitsrichtlinie (2016/2102) für öffentliche Stellen; EN 301 549 als harmonisierte Norm. Marktüberwachung und Sanktionen sind national geregelt. Automatisierte Scans allein belegen keine Konformität [2][4].
• DSGVO: Gescannte Staging-Seiten oder angemeldete Seiten und Screenshots können personenbezogene Daten enthalten; nutzen Sie synthetische Testkonten, EU-Hosting oder Selbstbetrieb und einen Auftragsverarbeitungsvertrag mit den Modellanbietern.
• Sicherheit/geistiges Eigentum: Coding-Agenten erhalten Zugriff auf das Repository; verwenden Sie Tokens mit minimalen Rechten und prüfen Sie alle Patches. Fügen Sie keinen proprietären Code in Chat-Werkzeuge für Endverbraucher ein.
• Gegenmaßnahmen: deterministische Überprüfung jeder Korrektur, Freigabe durch Fachleute, Nutzertests mit Menschen mit Behinderungen, Veröffentlichung einer zutreffenden Barrierefreiheitserklärung.

Erste Schritte

1. Führen Sie Lighthouse und axe auf Ihren 5-10 wichtigsten Nutzerwegen aus (Checkout, Login, Formulare) und halten Sie die Ausgangslage fest.
2. Fügen Sie @axe-core/playwright zur CI hinzu, sodass neue Verstöße den Build fehlschlagen lassen; beginnen Sie nur mit kritischen und schwerwiegenden.
3. Beheben Sie zuerst Probleme in Templates und im Designsystem (Farbkontrast, Fokusstile, Formularbeschriftungen, Landmarks) mit einem KI-Coding-Agenten und prüfen Sie jeden Patch.
4. Ergänzen Sie pro Release einen manuellen Durchgang mit Tastatur und Screenreader (NVDA/VoiceOver); beauftragen Sie ein Expertenaudit, bevor Sie Konformität behaupten.
5. Veröffentlichen Sie eine Barrierefreiheitserklärung und einen Feedback-Kanal und verfolgen Sie die Kennzahlen monatlich.

Quellen

1. Deque — axe-core (open-source rules engine) — https://github.com/dequelabs/axe-core
2. Directive (EU) 2019/882 (European Accessibility Act) — https://eur-lex.europa.eu/eli/dir/2019/882/oj
3. Deque — Axe MCP Server — https://www.deque.com/axe/mcp-server/
4. ETSI — EN 301 549 V4.1.1 (2026-09) — https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf
5. W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
6. Deque — axe DevTools Playwright integration — https://www.deque.com/blog/new-axe-devtools-integration-playwright/
7. Microsoft — Accessibility Insights — https://accessibilityinsights.io/
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj