2026-04-30•4 min read•navable Team•

MCP ServerPa11yHTMLCSWCAG 2.1Accessibility TestingDual-Engineaxe-coreKI-EntwicklertoolsOpen SourceBFSG

navable MCP v0.2: Dual-Engine-Scanning mit Pa11y und HTMLCS

Eine Scan-Engine ist gut. Zwei Engines, die dasselbe Problem bestätigen? Das ist Konfidenz, die in einen Compliance-Bericht gehört.

Was ist neu in v0.2

Version 0.2 von @navable/mcp führt Pa11y/HTMLCS als optionale zweite Barrierefreiheits-Scan-Engine neben axe-core ein. Wenn aktiviert, laufen beide Engines parallel gegen dieselbe Seite, und ihre Befunde werden serverseitig dedupliziert, bevor sie Ihren KI-Agenten erreichen.

Das Ergebnis: höhere Audit-Konfidenz, kreuzbestätigte Befunde und breitere WCAG-Abdeckung — ohne Token-Kosten oder Scan-Zeit zu verdoppeln.

Warum zwei Engines?

Keine einzelne Barrierefreiheits-Test-Engine findet alles. axe-core und HTMLCS (die Engine hinter Pa11y) haben unterschiedliche Regelsätze, unterschiedliche Erkennungsstrategien und unterschiedliche blinde Flecken. Wenn beide Engines dasselbe Element für dasselbe WCAG-Erfolgskriterium flaggen, ist das ein kreuzbestätigter Befund — hohe Konfidenz, dass es eine echte Barriere ist, kein Fehlalarm. Das ist entscheidend für die Compliance-Abnahme, bei der Auditoren Evidenz erwarten.

So funktioniert es

Pa11y aktivieren

Pro Scan — engines an den Tool-Aufruf übergeben:

run_accessibility_scan({ url: "http://localhost:3000", engines: ["axe", "htmlcs"] })

Immer aktiv — in .navable.json im Projekt-Root eintragen:

{
  "engines": ["axe", "htmlcs"]
}

Standardmäßig läuft nur axe-core. Pa11y ist Opt-in — Sie entscheiden, wann Sie es nutzen.

Keine zusätzlichen Downloads

Pa11y teilt dieselbe Chromium-Binary, die Playwright bereits für das axe-core-Scanning installiert hat. Es gibt keinen zweiten Browser-Download. Die Pakete pa11y und puppeteer-core sind in @navable/mcp enthalten — einfach auf v0.2 updaten und los.

Serverseitige Deduplizierung

Wenn beide Engines laufen, nutzt der MCP-Server eine konservative Dedup-Strategie:

Gleiches WCAG-Erfolgskriterium + identischer normalisierter CSS-Selektor + übereinstimmendes HTML-Snippet → zusammengeführt in einen Eintrag (axe-Version bleibt erhalten, mit Tag alsoFlaggedBy: ["htmlcs"])
Uneindeutige Überlappung → beide Einträge bleiben als separate Befunde

Das bedeutet: Sie verlieren nie einen legitimen Befund durch zu aggressives Merging. Der Sicherheitsbias ist: falsche Zusammenführungen sind weitaus schlimmer als nicht erkannte Duplikate.

Wie die Ergebnisse aussehen

{
  "ruleId": "image-alt",
  "impact": "critical",
  "source": "axe",
  "alsoFlaggedBy": ["htmlcs"],
  "wcagCriteria": [{ "sc": "1.1.1", "en301549": "9.1.1.1" }],
  "selector": "img.hero-banner",
  "html": "<img class=\"hero-banner\" src=\"/hero.jpg\">"
}

Befunde, die nur von HTMLCS stammen, enthalten eine helpUrl (Link zum WCAG-Understanding-Dokument) und eine developerNote (ein Satz Anleitung für den Agenten):

{
  "ruleId": "WCAG2AA.Principle1.Guideline1_3.1_3_1.H49.AlignAttr",
  "impact": "moderate",
  "source": "htmlcs",
  "helpUrl": "https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html",
  "developerNote": "Verwenden Sie semantisches HTML zur Strukturvermittlung: Überschriften für Abschnitte, <table> mit <th> für Daten...",
  "wcagCriteria": [{ "sc": "1.3.1", "en301549": "9.1.3.1" }]
}

Wann welchen Modus verwenden

Szenario	Empfohlene Engines	Warum
Iterative Fix-Loops (Scan → Fix → Re-Scan)	`["axe"]` (Standard)	Schnell (~3 s), geringe Token-Kosten, enger Feedback-Loop
Compliance-Audit / BFSG-Abnahme	`["axe", "htmlcs"]`	Kreuzbestätigung, breitere Abdeckung, Audit-Grade-Konfidenz
Nutzer fragt nach „gründlichem" oder „vollständigem" Scan	`["axe", "htmlcs"]`	Maximale Erkennungsabdeckung
CI-Pipeline Quick-Check	`["axe"]`	Geschwindigkeit zählt, minimaler Output

Der Agent-Skill audit-page-structure aktiviert automatisch Dual-Engine. Der Skill scan-accessibility (für Fix-Workflows) behält den axe-only-Standard für schnellere Iteration.

Token-Kosten mit `htmlcsIgnore` steuern

HTMLCS gibt „Prüfen Sie, ob…"-Warnungen aus, die für menschliche Auditoren gedacht sind. Diese erhöhen die Token-Kosten, ohne dem Agenten umsetzbare Arbeit zu geben. Unterdrücken Sie sie in .navable.json:

{
  "engines": ["axe", "htmlcs"],
  "htmlcsIgnore": [
    "WCAG2AA.Principle1.Guideline1_3.1_3_1.H49.AlignAttr",
    "WCAG2AA.Principle2.Guideline2_4.2_4_1.H64.1",
    "WCAG2AA.Principle1.Guideline1_3.1_3_1.H42.2"
  ]
}

Suchen Sie in Ihren Scan-Ergebnissen nach HTMLCS-Einträgen, deren help-Text mit „Check that…" beginnt — das sind Kandidaten zur Unterdrückung.

Upgrade

npm install @navable/mcp@latest

Oder bei Nutzung von npx:

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

Keine Breaking Changes. Bestehende Workflows, die engines nicht übergeben, laufen weiterhin mit axe-only — gleiches Verhalten wie zuvor.

Aktualisierte Agent Skills

Die navable Agent Skills wurden für v0.2 aktualisiert:

scan-accessibility — dokumentiert jetzt den engines-Parameter mit Anleitung, wann axe-only vs. Dual-Engine sinnvoll ist. Bleibt standardmäßig bei axe-only für schnelle Fix-Loops.
audit-page-structure — aktiviert automatisch ["axe", "htmlcs"] für strukturelle Audits, bei denen Kreuzbestätigung Mehrwert bietet.
Beide Skills verarbeiten die neuen Ergebnisfelder (source, alsoFlaggedBy, helpUrl, developerNote), damit Ihr Agent weiß, wie er mit HTMLCS-only-Befunden umgehen soll.

Wenn Sie die Skills bereits in Ihr Projekt kopiert haben, holen Sie die neueste Version aus dem Repository, um die aktualisierten Beschreibungen und die Dual-Engine-Verarbeitung zu erhalten.

Was kommt als Nächstes

HTMLCS-Advisory-Filter-Presets — community-kuratierte htmlcsIgnore-Listen für gängige Frameworks
Pro-Engine-Timing in Metadaten — sehen Sie exakt, wie lange jede Engine gebraucht hat
Konfigurierbare Dedup-Strenge — lockern oder verschärfen Sie die Merge-Strategie für Ihren Anwendungsfall