Web-Barrierefreiheit mit KI automatisieren: Wie Agenten mit navable MCP deine WCAG-Audits übernehmen

Zwei kostenlose Tools, die automatisierte Barrierefreiheitstests dorthin bringen, wo Code geschrieben wird. Keine Dashboards. Keine Browser-Extensions. Nur die IDE und ein KI-Agent.

Die Lücke in der Entwickler-Toolchain

Entwickler haben Linter für Code-Qualität, Formatter für Konsistenz und Type-Checker für Korrektheit. Diese Tools laufen im Editor, erkennen Probleme früh und sind in CI-Pipelines integriert.

Bei Barrierefreiheit sieht das anders aus. Der typische Workflow:

1. Feature bauen
2. Deployen
3. Wochen später einen PDF-Bericht vom Auditor mit 40+ Befunden erhalten
4. Zurückgehen und Dinge in Code fixen, den man halb vergessen hat

Diese Kluft — an einem Ort bauen, an einem anderen testen, viel später fixen — ist der Grund, warum sich Barrierefreiheitsschulden anhäufen. Es liegt nicht daran, dass Entwicklern das Thema egal ist. Der Feedback-Loop ist zu langsam und das Tooling trifft sie nicht dort, wo sie arbeiten.

Seit das BFSG (Barrierefreiheitsstärkungsgesetz) im Juni 2025 in Kraft getreten ist und WCAG 2.1 Level AA für digitale Dienste in Deutschland vorschreibt — und der European Accessibility Act ähnliche Regeln EU-weit ausweitet — ist diese Lücke nicht mehr nur ein UX-Thema, sondern ein rechtliches Risiko.

Wir haben zwei Open-Source-Tools gebaut, um sie zu schließen.

Was wir veröffentlichen

Jedes Tool ist für sich nützlich — aber sie sind dafür gemacht, zusammenzuarbeiten. Der MCP-Server liefert die Scan-Engine. Die Agent Skills liefern strukturierte, schrittweise Anleitungen. Wenn beides eingerichtet ist, folgt Ihr KI-Agent einem deterministischen, wiederholbaren Workflow — Scan, Plan, Fix, Verifizierung — statt Lösungen zu improvisieren. Gleicher Input, gleicher Prozess, jedes Mal.

1. @navable/mcp — Ein MCP-Server für Barrierefreiheits-Scanning

Das Model Context Protocol (MCP) ist ein offener Standard, der KI-Coding-Agenten den Aufruf externer Tools ermöglicht. Unser MCP-Server verbindet Ihren Agenten mit einem echten Chromium-Browser, der axe-core ausführt — die Industriestandard-Engine für Barrierefreiheitstests.

Er stellt drei Tools bereit:

• run_accessibility_scan — Scannt eine URL gegen WCAG 2.1 Level A + AA Regeln. Liefert strukturierte Verstöße mit Schweregrad, betroffenen Elementen, WCAG-Erfolgskriterien und EN-301-549-Klausel-Mapping.
• generate_fix_plan — Wandelt Scan-Ergebnisse in eine priorisierte .navable-plan.json-Datei um. Kritische Probleme zuerst, geringfügige zuletzt. Jeder Eintrag enthält die verletzte Regel, betroffene Nodes und eine Fix-Beschreibung.
• update_fix_status — Verfolgt den Fortschritt, während Items von „ausstehend" zu „erledigt" wechseln. Die Plan-Datei wird zu einem lebenden Dokument für Ihr Team.

Funktioniert mit Cursor, VS Code (GitHub Copilot) und Claude Code.

npm: @navable/mcp | GitHub: web-DnA/navable-web-accessibility-mcp

2. navable Agent Skills — Workflow-Anleitungen für KI-Coding-Agenten

Agent Skills sind strukturierte Anleitungen, die KI-Agenten bestimmte Workflows beibringen. Kopieren Sie sie aus dem GitHub-Repository in Ihr Projekt. Unsere decken vier Szenarien ab:

Der Scan-Skill enthält 10 Fix-Guides für Bilder, Formulare, Farbkontrast, ARIA, Tastaturnavigation, Überschriften, Landmarks, Sprache, Navigation und Tabellen — mit Vorher/Nachher-Codebeispielen für 55 häufige Verstöße.

GitHub: web-DnA/navable-web-accessibility-skills

So funktioniert es in der Praxis

Wenn beide Tools konfiguriert sind, wird der Workflow deterministisch. Der Agent rät nicht, was als Nächstes zu tun ist — die Skills definieren die exakte Abfolge, und der MCP-Server führt jeden Schritt aus.

Ein Entwickler startet seinen Dev-Server und tippt in die IDE:

Scanne http://localhost:3000 auf Barrierefreiheitsprobleme

So sieht das in der Praxis aus:

Schritt 1: Scan im echten Browser

Der MCP-Server startet Headless-Chromium, navigiert zur URL und führt axe-core aus. Getestet wird die tatsächlich gerenderte Seite — JavaScript-generierte Inhalte, dynamische Komponenten, CSS-gesteuerte Sichtbarkeit — nicht nur statisches HTML.

Schritt 2: Strukturierte Ergebnisse

Jeder Verstoß wird zurückgegeben mit:

• Schweregrad — kritisch, ernst, moderat oder gering
• CSS-Selektoren + HTML-Snippets — zeigen auf die exakt betroffenen Elemente
• WCAG-Erfolgskriterium — z. B. 1.4.3 Kontrast (Minimum)
• EN-301-549-Klausel — z. B. §9.1.4.3 — der europäische Standard, auf den das BFSG verweist

Schritt 3: Fix-Plan-Generierung

Der Agent erstellt .navable-plan.json — einen strukturierten, nach Priorität sortierten Fix-Plan. Jedes Item trackt:

{
  "id": "fix-1",
  "ruleId": "color-contrast",
  "impact": "serious",
  "wcagSc": ["1.4.3"],
  "en301549": "§9.1.4.3",
  "help": "Elemente müssen minimale Farbkontrastverhältnisse einhalten",
  "status": "pending"
}

Schritt 4: Geführte Fixes

Der Agent lädt den passenden Fix-Guide, findet die Quelldatei über CSS-Selektor und HTML-Snippet aus dem Scan, wendet die Code-Änderung an und markiert das Item als erledigt. Er arbeitet den Plan in Prioritätsreihenfolge ab — kritisch zuerst, geringfügig zuletzt.

Schritt 5: Verifizierung

Nach den Fixes scannt der Agent die Seite erneut, um die Behebung der Verstöße zu bestätigen. Die Plan-Datei erhält einen Verifizierungs-Zeitstempel für die Audit-Dokumentation.

Der gesamte Zyklus — Scan, Plan, Fix, Verifizierung — dauert Minuten. Nicht Tage.

Das EN-301-549-Mapping (und warum es wichtig ist)

Die meisten Barrierefreiheitstest-Tools berichten WCAG-Erfolgskriterien. Das ist nützlich, aber für die europäische Compliance unvollständig.

Das BFSG verweist auf EN 301 549 — den harmonisierten europäischen Standard für IKT-Barrierefreiheit. Wenn eine Compliance-Beauftragte oder die Marktüberwachungsbehörde fragt, welche Anforderungen Sie erfüllt haben, spricht sie in EN-301-549-Klauselnummern, nicht in WCAG-Erfolgskriterien.

navable bildet jeden Befund auf beides ab. Wenn der Scan einen Kontrastverstoß meldet, erfahren Sie, dass es WCAG 1.4.3 und EN 301 549 §9.1.4.3 betrifft. Ihre Konformitätsdokumentation entsteht als Nebenprodukt der Entwicklung.

Einrichtung in unter 2 Minuten

Für VS Code (GitHub Copilot)

.vscode/mcp.json erstellen:

{
  "servers": {
    "navable": {
      "command": "npx",
      "args": ["-y", "@navable/mcp"]
    }
  }
}

Für Cursor

.cursor/mcp.json erstellen:

{
  "mcpServers": {
    "navable": {
      "command": "npx",
      "args": ["-y", "@navable/mcp"]
    }
  }
}

Für Claude Code

claude mcp add navable -- npx -y @navable/mcp

Das war's. Das Paket installiert sich via npx. Chromium wird beim ersten Scan automatisch heruntergeladen (~150 MB einmalig). Keine API-Keys, keine Accounts, keine weitere Konfiguration.

Um die Agent Skills hinzuzufügen, kopieren Sie den Skills-Ordner in Ihr Projekt:

# VS Code
cp -r skills/* .github/skills/

# Cursor
cp -r skills/* .agents/skills/

# Claude Code
cp -r skills/* .claude/skills/

Was getestet wird

Der Scanner prüft 50 WCAG 2.1 Erfolgskriterien (Level A + AA) in 10 Kategorien:

Die Fix-Guides liefern Vorher/Nachher-Code für 55 dokumentierte Muster, sodass der Agent nicht rät — er wendet getestete Lösungen an.

Integrierte Referenz-Ressourcen

Der MCP-Server stellt auch Referenzdokumentation als MCP-Ressourcen bereit:

• WCAG ↔ EN 301 549 Mapping — vollständige Querverweistabelle mit Testbarkeits-Bewertungen
• Fix-Patterns nach Regel — spezifische Muster per axe-Rule-ID abrufen (z. B. navable://docs/fix-patterns/color-contrast,label)
• ARIA-Patterns — 25 WAI-ARIA-APG-Widget-Muster mit Tastaturanforderungen
• Semantic-HTML-Referenz — HTML-Elemente auf implizite ARIA-Rollen gemappt

Diese laden on demand und halten den Kontext des Agenten auf das Relevante fokussiert.

Was es nicht ersetzt

Automatisiertes Scanning erkennt schätzungsweise 30–40 % der Barrierefreiheitsbarrieren. Es ist wirksam bei strukturellen Problemen, fehlenden Attributen, Kontrastverhältnissen und ARIA-Fehlverwendung. Es kann nicht bewerten:

• Qualität von Tastaturnavigations-Flows
• Reihenfolge und Klarheit von Screenreader-Ansagen
• Kognitive Belastung und Lesbarkeit von Inhalten
• Ob Alternativtexte tatsächlich aussagekräftig sind
• Komplexe Interaktionsmuster im Kontext

navable erledigt den automatisierbaren Teil, damit Ihr Team die manuelle Testzeit dort investieren kann, wo nur Menschen urteilen können. Es ist das Barrierefreiheits-Äquivalent eines Linters — es fängt mechanische Probleme schnell ab, ersetzt aber nicht das Expert-Review.

Datenschutz und Sicherheit

Alles läuft lokal. Der MCP-Server startet eine lokale Chromium-Instanz, die sich mit Ihrem Localhost-Dev-Server verbindet. Es werden keine Daten an externe Dienste gesendet. Keine Telemetrie. Keine Analytics. Der Quellcode ist Open Source und MIT-lizenziert — Sie können ihn selbst prüfen.

Für wen ist das?

• Entwickler, die Barrierefreiheits-Feedback im Editor wollen, während sie bauen — nicht Wochen später in einem PDF
• Teamleiter, die Barrierefreiheit zu einem kontinuierlichen Teil der Entwicklung machen wollen statt zu einem periodischen Audit
• Compliance-Teams, die EN-301-549-Mapping für die BFSG-Dokumentation brauchen
• Agenturen, die BFSG-konforme Websites für EU-Kunden liefern

Mitmachen

Das ist Version 0.1 — aktiv in Entwicklung und offen für Feedback. Wenn Sie auf Probleme stoßen, Feature-Wünsche haben oder Fix-Patterns beitragen möchten:

• Issue auf GitHub eröffnen
• Repos mit einem Stern markieren, wenn Sie sie nützlich finden
• Pull Requests willkommen — besonders für zusätzliche Fix-Patterns und ARIA-Guides

Barrierefreie Produkte zu bauen sollte kein Spezial-Tooling-Budget erfordern. Mit diesen Tools ist es Teil des Workflows.

Links:

• MCP-Server: github.com/web-DnA/navable-web-accessibility-mcp
• Agent Skills: github.com/web-DnA/navable-web-accessibility-skills
• npm: @navable/mcp