Belegt ein fehlerfreier Scan die Erfüllung aller Anforderungen?

Web-Barrierefreiheit mit KI automatisieren

Automatisierte Barrierefreiheitstests lassen sich direkt im Entwicklungsprozess ausführen. navable verbindet axe-core-Scans mit Fix-Plänen, die ein KI-Coding-Agent im Editor bearbeiten kann.

Vertiefe die Kriterien im WCAG-Hub, den Ablauf unter Developer Workflows oder starte mit dem Accessibility Audit.

Scan, Plan, Fix und erneute Prüfung

Der MCP-Server liefert technische Befunde. Die Agent Skills strukturieren die nächsten Schritte: Plan erstellen, Code ändern und erneut scannen. Prüfe die vorgeschlagenen Änderungen im Code-Review und mit manuellen Tests; ein KI-Agent kann dabei Fehler machen.

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 Deinen 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. Dein Team kann den Bearbeitungsstand in der Plan-Datei verfolgen.

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. Kopiere sie aus dem GitHub-Repository in Dein Projekt. Unsere decken vier Szenarien ab:

Skill	Was er tut
scan-accessibility	Kompletter Workflow: URL scannen → Fix-Plan erstellen → Fixes anwenden → Erneut scannen zur Verifizierung
fix-accessibility	Bestehende `.navable-plan.json` fortsetzen und ausstehende Items abarbeiten
review-component	Source-Code einer Komponente auf Barrierefreiheitsprobleme prüfen — kein Browser nötig
audit-page-structure	Landmarks, Überschriftenhierarchie, Skip-Links und Dokument-Metadaten prüfen

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

Beispiel: Tastaturzugang für scrollbare Codeblöcke

Auf unserer MCP-Toolseite waren zwei horizontal scrollbare Codeblöcke nicht per Tastatur erreichbar. Ein lokaler Scan mit @navable/mcp 0.2.0, axe-core 4.13.0 und Playwright 1.64.0 meldete dafür die Regel scrollable-region-focusable. Geprüft wurde die Sektion #how-it-works.

run_accessibility_scan({
  url: "http://localhost:3002/de/tools/accessibility-mcp-fuer-ai-agents",
  include: ["#how-it-works"]
})

Übergib die zurückgegebene scanId an generate_fix_plan. In unserem Durchlauf entstand fix-1 für diese Regel. Der Fix änderte die vorhandenen Codeblöcke:

// Vorher
<pre className="bg-muted p-3 rounded-lg text-xs overflow-x-auto">
  <code>{step.code}</code>
</pre>

// Nachher
<pre tabIndex={0} className="bg-muted p-3 rounded-lg text-sm overflow-x-auto">
  <code>{step.code}</code>
</pre>

Mit tabIndex={0} erreichst Du den Block per Tab und kannst den überbreiten Inhalt mit den Pfeiltasten lesen. Die Schrift wurde zugleich auf die Mindestgröße des Projekts angehoben. Prüfe Tastaturbedienung und sichtbaren Fokus zusätzlich im Browser.

Der erneute Scan derselben Sektion meldete keinen Verstoß mehr gegen scrollable-region-focusable. Das bestätigt diesen Fix im geprüften Zustand, keine vollständige Barrierefreiheit der Seite. Markiere das geprüfte Plan-Item anschließend über update_fix_status als erledigt.

Wenn der Plan nicht geschrieben wird

Prüfe zuerst NAVABLE_PROJECT_ROOT: Der Server muss wissen, in welchem Projekt .navable-plan.json liegt. Beim Test von Version 0.2.0 scheiterte außerdem die Plan-Erstellung für den Vollseiten-Scan an verschachtelten Selektoren des Video-Players. Der Scan der betroffenen Sektion ließ sich dagegen in einen Plan umwandeln. Begrenze den Scan nur zur Untersuchung des Fehlers; die übrigen Inhalte benötigen weiterhin eine eigene Prüfung.

Der Erstaufruf kann Paket und Chromium herunterladen. Eine feste Einrichtungszeit versprechen wir deshalb nicht. Falls der automatische Browser-Download fehlschlägt, nutze die Installationshinweise in der MCP-Dokumentation.

Der lokale Loop prüft Änderungen während der Entwicklung. Ein CI-Test läuft dagegen bei Push oder Pull Request; er braucht einen gestarteten Testserver und einen definierten Prüfpfad. Hosted MCP fragt vorhandene navable-Audit-Daten ab. Die MCP-Toolseite erklärt Einrichtung und Regelauswahl, Developer Workflows ordnet diese Wege ein.

So funktioniert es in der Praxis

Die Skills geben die Schritte vor, der MCP-Server liefert Scan-Daten. Prüfe bei jedem Schritt, ob die Befunde und vorgeschlagenen Änderungen zur getesteten Seite passen.

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 — Zuordnung zur technischen Norm

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)

Das Mapping ordnet technische Befunde WCAG-Erfolgskriterien und EN-301-549-Klauseln zu. Das hilft beim Sortieren und Dokumentieren von Fixes. Es bewertet weder alle Anforderungen der Norm noch die rechtlichen Pflichten einer Dienstleistung.

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 Paket installiert sich via npx. Chromium wird beim ersten Scan automatisch heruntergeladen (~150 MB einmalig). Für diese Einrichtung brauchst Du weder einen API-Key noch ein Konto.

Um die Agent Skills hinzuzufügen, kopiere den Skills-Ordner in Dein 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 maschinell auswertbare axe-core-Regeln in diesen Kategorien:

Kategorie	Beispiel-Regeln
Bilder & Medien	`image-alt`, `svg-img-alt`, `video-caption`
Formulare & Labels	`label`, `select-name`, `autocomplete-valid`
Farbe & Kontrast	`color-contrast`, `link-in-text-block`
Navigation & Links	`link-name`, `bypass`, `button-name`
Überschriften & Struktur	`heading-order`, `document-title`, `page-has-heading-one`
Landmarks & Regionen	`region`, `landmark-one-main`
ARIA	`aria-required-attr`, `aria-valid-attr-value`, `aria-roles`
Tastatur	`tabindex`, Fokus-Management-Muster
Sprache	`html-has-lang`, `html-lang-valid`
Tabellen	Header-Zuordnungen, Caption-Verwendung

Die Fix-Guides enthalten Vorher/Nachher-Code für 55 dokumentierte Muster. Prüfe, ob der vorgeschlagene Fix zu Deinem Element passt.

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

axe-core erkennt maschinell prüfbare Struktur-, Attribut-, Kontrast- und ARIA-Probleme. Manuell prüfen musst Du unter anderem:

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 Dein 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

Der Local MCP startet Chromium und den Scan auf Deinem Rechner. Dein KI-Client verarbeitet Prompts und Tool-Ergebnisse nach seinen eigenen Einstellungen; je nach Anbieter können diese an einen KI-Dienst gehen. Prüfe diese Einstellungen, bevor Du vertrauliche Inhalte testest. Das MCP-Paket ist Open Source und MIT-lizenziert.

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 technische Barrieren in Kundenprojekten früh erkennen

Mitmachen

Der Local MCP wird als Open-Source-Paket weiterentwickelt. Wenn Du auf Probleme stößt, Feature-Wünsche hast oder Fix-Patterns beitragen möchtest:

Issue auf GitHub eröffnen
Repos mit einem Stern markieren, wenn Du sie nützlich findest
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

Grenzen der automatisierten Prüfung

Nein. Der Scan prüft maschinell auswertbare Regeln auf den untersuchten Seiten. Ergänze manuelle Tests und eine fachliche Bewertung. Rechtliche Fragen zur Dienstleistung benötigen eine eigene Prüfung.

Mehr zum Entwicklungsablauf und zum Audit.

Unsere Top Beiträge:

Lege mit der Website-Test-Checkliste fest, welche Nutzerwege Du nach dem Code-Fix erneut prüfst.

Updates erhalten

Erhalte Tipps und Updates rund um Barrierefreiheit.