**axe MCP Server**

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard
Not for use with personal data

Überblick

Der axe MCP Server ist ein Model Context Protocol (MCP) Server, der die barrierefreie Prüfung auf Unternehmensniveau direkt in Ihren Entwicklungsworkflow integriert. Basierend auf der bewährten axe-Plattform ermöglicht er Entwicklern, umfassende Barrierefreiheits-Scans durchzuführen und fundierte Unterstützung zur Behebung von Problemen direkt in ihrer IDE zu erhalten.

Der Server bietet drei Funktionen – analyze, remediateund igt.

Diese Tools integrieren sich nahtlos mit MCP-kompatiblen Clients (wie Claude Desktop, VS Code mit Copilot oder Cursor) und berücksichtigen die axe-Konfigurationseinstellungen Ihrer Organisation.

Zugang erhalten

Der axe MCP Server ist im Axe DevTools für Web Paket. Ein Abonnement, das den Zugriff auf den axe MCP-Server ermöglicht, wird durch ein Gespräch mit einem Deque-Vertriebsmitarbeiter eingerichtet.

Tools & Funktionen

Das analyze Tool

Das analyze Tool führt eine umfassende Barrierefreiheitsanalyse von Webseiten durch, indem es einen Scan über die axe DevTools Browser-Erweiterung in einer realen Browserumgebung durchführt. Es funktioniert nahtlos mit sowohl lokalen Entwicklungs-URLs (z. B. localhost:3000) als auch mit Remote-Produktions-URLs.

Was es macht

  1. Authentifizierung - Validiert die Benutzerdaten (entweder einen API-Schlüssel oder ein OAuth 2.0-Zugriffstoken), um autorisierten Zugang sicherzustellen
  2. Konfigurationsabfrage - Ruft die organisationsspezifische axe-Konfiguration Einstellungen des Benutzers ab, einschließlich:
    • Barrierefreiheits-Standard (z. B. WCAG 2.2 AA)
    • axe-core Version
    • Bedarf an Überprüfung / bewährte Praktiken
  3. Browserbasierte Analyse - Startet eine Browser-Instanz im Hintergrund mit der montierten axe DevTools-Erweiterung
  4. Seitennavigation - Navigiert zur vom Benutzer im Prompt an den KI-Agenten bereitgestellten URL
  5. Barrierefreiheits-Scan - Führt eine vollständige Barrierefreiheitsanalyse auf der gerenderten Seite durch, indem die axe DevTools Browser-Erweiterung verwendet wird und sichergestellt wird, dass die tatsächliche Benutzererfahrung getestet wird (nicht nur statisches HTML)
  6. Ergebnisauslieferung - Gibt umfassende Analyseergebnisse in einem strukturierten Format an den Agenten zurück

Reaktionsfähiges Testen

Das analyze Tool unterstützt optionale viewportWidth und viewportHeight Parameter, die es Ihnen ermöglichen, Seiten bei spezifischen Viewport-Dimensionen zu testen. Dies ist nützlich, um Barrierefreiheitsprobleme zu erkennen, die nur bei bestimmten Bildschirmgrößen wie mobilen oder Tablet-Auflösungen auftreten.

Analyze http://localhost:3000 for accessibility issues at a mobile viewport of 375x812

Wenn diese Parameter weggelassen werden, verwendet der Browser seine Standard-Viewport-Größe.

Teilschrittscans

Standardmäßig scannt das analyze Tool die gesamte Seite. Um den Scan auf einen bestimmten Bereich zu beschränken, geben Sie den optionalen selector Parameter — nützlich, um sich auf eine einzelne Komponente zu konzentrieren oder störende, nicht zugehörige Teile der Seite aus den Ergebnissen auszuschließen.

  • Ein einzelner CSS-Selektor-String richtet sich auf ein Element im oberen Rahmen:

    {
      "url": "http://localhost:3000",
      "selector": "#main"
    }
  • Ein Array von CSS-Selektoren durchläuft iframe- oder Shadow-DOM-Grenzen — jeder Abschnitt wählt den Host für den nächsten. Verwenden Sie ein Array nur, wenn das Ziel innerhalb eines iframes oder Shadow-Root liegt:

    {
      "url": "http://localhost:3000",
      "selector": ["iframe#checkout", "#payment-form"]
    }

Ein Array unterstützt bis zu 10 Segmente. Wenn der Selektor kein Element auf der Seite trifft, gibt der Scan einen Fehler zurück. Wenn selector weggelassen wird, wird die gesamte Seite gescannt.

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:

Scan only the #main region of http://localhost:3000 for accessibility issues

Browser-Interaktionen vor dem Scannen

Das analyze Tool unterstützt ein optionales before Array von Interaktionsschritten, die nach dem Laden der Seite aber vor dem Barrierefreiheits-Scan. Dies öffnet mehrere reale Testszenarien:

  • Anmeldeseiten — füllen Sie Anmeldedaten aus und senden Sie sie ab, bevor Sie die Seite nach der Anmeldung scannen
  • Cookie/Einwilligungsbanner — schließen Sie Banner, die sonst den Seiteninhalt überlagern oder verdecken würden
  • Dynamische Inhalte — warten Sie, bis vom Client gerenderte Inhalte (Routenänderungen, spät injizierter DOM) erscheinen, bevor Sie scannen

Schritte werden in Array-Reihenfolge im gleichen Browserkontext wie der Scan ausgeführt, sodass Cookies, localStorageund alle durch click oder fill im Scan erhalten bleiben.

Das before Array unterstützt bis zu 20 Schritte. Jeder Schritt erhält seine eigene Timeout-Zeit von BROWSER_TIMEOUT_MS (Standard 30000 ms); es gibt keine individuellen Überschreibungen für Schritte.

Unterstützte Aktionen
Aktion Erforderliche Felder Optionale Felder Zweck
click selector Klicken Sie auf das Element, das dem CSS entspricht selector (z. B. eine Senden-Schaltfläche, eine „Schließen“-Schaltfläche auf einem Banner).
fill selector, value Ein Eingabefeld ausfüllen, das selector entspricht, mit value. Verwenden Sie dies für Anmeldedaten, Suchanfragen oder Formularfelder. Ein leerer String löscht die Eingabe.
waitFor selector state — eines von "visible" (Standard), "attached", "hidden", "detached" Warten auf das Element, das zu selector passt, um statezu erreichen. Verwenden Sie dies, um den nächsten Schritt oder den Scan selbst zu ermöglichen. Wählen Sie einen Selector, der nur im Zustand nach der Interaktion existiert (z. B. eine Abmelde-Schaltfläche oder eine Dashboard-Überschrift) — generische Selektoren wie body oder #app existieren bereits vor der Interaktion und lösen sich sofort auf, sodass sie nichts steuern.
Beispiel: Anmeldung vor dem Scannen

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:

Analyze http://localhost:3000 for accessibility issues. Before running
the analysis, fill in the #username and #password fields with USERNAME
and PASSWORD from ./.env.local, click the button[type=submit] button,
and wait for #main-content to appear.

Der Agent löst die Eingabeaufforderung auf und ruft das analyze Werkzeug mit einer Nutzlast auf, die ungefähr wie folgt aussieht:

{
  "url": "http://localhost:3000",
  "before": [
    {
      "action": "fill",
      "selector": "#username",
      "value": "<resolved-from-.env.local>"
    },
    {
      "action": "fill",
      "selector": "#password",
      "value": "<resolved-from-.env.local>"
    },
    { "action": "click", "selector": "button[type=submit]" },
    { "action": "waitFor", "selector": "#main-content" }
  ]
}
important

fill.value wird als sensibel behandelt. Der axe MCP Server protokolliert niemals fill.value, gibt es nie in Fehlermeldungen aus und sendet es niemals an Telemetrie. Verwenden Sie fill für alle vom Benutzer bereitgestellten oder geheimen Eingaben (Passwörter, API-Token usw.), damit Geheimnisse im gesamten Prozess verborgen bleiben — und betten Sie niemals sensible Werte in ein selectorein, was erscheint in Protokollen und Fehlermeldungen.

note

Der Agent löst value, nicht der Server. Der axe MCP Server behandelt value als einen literalen String — er liest nicht Dateien, erweitert keine Umgebungsvariablen und interpretiert keine Platzhaltersyntax wie ${VAR}, $VARoder {{VAR}}. Ihr KI-Agent (Claude, Copilot, Cursor usw.) ist dafür verantwortlich, die Absicht des Nutzers in einen konkreten String umzusetzen, bevor das Tool aufgerufen wird.

In der Praxis bedeutet das:

  • Formulieren Sie Aufforderungen natürlich — „verwende BENUTZERNAME/PASSWORT aus .env.local“ funktioniert. Der Agent liest die Datei mit seinen eigenen Dateisystemtools und ersetzt die Werte.
  • Platzhaltersyntax nicht einfügen — das Schreiben von value: "${USERNAME}" in einer Aufforderung bewirkt, dass der literale String ${USERNAME} in das Eingabefeld eingegeben wird.
  • Seien Sie explizit bei mehrdeutigen Quellen — wenn Sie sagen „verwende meine gespeicherten Anmeldedaten“ ohne den Agenten auf eine Datei oder Umgebungsvariable hinzuweisen, wird ein gut funktionierender Agent nachfragen, anstatt zu raten. Sagen Sie ihm, wo er suchen soll.
caution

Einige Authentifizierungsprozesse werden nicht unterstützt. before Aktionen steuern die Seite durch Playwright-ähnliche Interaktionen in einer Dockerisierten Chromium-Instanz. Folgende Punkte liegen absichtlich außerhalb des Geltungsbereichs:

  • Captcha -Herausforderungen (reCAPTCHA, hCaptcha usw.)
  • 2FA / TOTP / SMS Bestätigungscodes
  • Drittanbieter-SSO Umleitungslisten (z. B. „Mit Google anmelden“, von Okta gehostete Anmeldeseiten)

Wenn Ihr eigentlicher Anmeldevorgang ein oben genanntes Element benötigt, prüfen Sie einen alternativen Einstiegspunkt:

  • Eine vorab authentifiziertes Sitzungscookie in einer Staging-Umgebung integriert
  • Eine Sitzungstoken oder Umgehungs-URL , die Ihr Team für automatisierte Tests verwendet
  • Eine Staging-URL mit deaktivierter Authentifizierung für Barrierefreiheitstests

Wichtige Vorteile

  • Echtbrowser-Tests - Testet die tatsächlich gerenderte Seite, nicht nur den Quellcode, um genaue Ergebnisse zu gewährleisten
  • Organisationsstandards - Respektiert die axe-Konfigurationseinstellungen Ihres Teams für konsistentes Testen über alle Benutzer hinweg
  • Umfassende Abdeckung - Nutzt die branchenführende axe-Plattform
  • Reaktionsfähiges Testen - Testen bei bestimmten Ansichtsgrößen, um aufbruchsspezifische Barrierefreiheitsprobleme zu erkennen
  • Gezielte Scans - Beschränken Sie einen Scan auf einen bestimmten Bereich, ein iframe oder eine Shadow-Root mit dem selector Parameter
  • Authentifizierte & Interaktive Seiten - Scannen Sie Seiten hinter einem Login, schließen Sie Cookie-Banner oder warten Sie auf dynamische Inhalte mithilfe von before Aktionen

Ausgabe

Das Tool gibt eine strukturierte JSON-Antwort zurück, die Folgendes enthält:

  • Alle festgestellten Barrierefreiheitsverletzungen
  • Schweregrad der Verstöße (kritisch, ernst, moderat, geringfügig)
  • Spezifische Elementselektoren und Quellcode
  • Regel-IDs und Beschreibungen

Das remediate Tool

Das remediate Tool nimmt eines oder mehrere Barrierefreiheitsprobleme, die vom analyze oder igt Tool identifiziert wurden, und generiert kontextbezogene, KI-gestützte Lösungsempfehlungen, die von Codierungsagenten in tatsächliche Code-Fixes übersetzt werden können. Probleme werden als Batch übermittelt, sodass ein einziger Aufruf Korrekturen für alle auf einer Seite gefundenen Verstöße zurückgeben kann.

Was es macht

  1. Authentifizierung - Validiert die Anmeldeinformationen des Benutzers – entweder einen API-Schlüssel oder ein OAuth 2.0-Access-Token –, um autorisierten Zugriff sicherzustellen
  2. AI-Guthaben Verbrauch - Jedes Problem im Batch verbraucht KI-Credits aus der Zuteilung Ihrer Organisation, was den Einsatz fortschrittlicher KI-Modelle ermöglicht, die auf Deques umfangreichem Barrierefreiheitswissen trainiert sind
  3. KI-erzeugte Behebung - Erstellen qualitativ hochwertige, umsetzbare Barrierefreiheitskorrekturen, die von Codierungsagenten interpretiert und im Quellcode umgesetzt werden können
note

Wenn die AI-Credits aufgebraucht sind, funktioniert das remediate Tool nicht mehr, bis Ihre Credits wieder aufgeladen sind (entweder durch Zukauf oder durch Rücksetzung Ihres monatlichen Zyklus). Jedoch wird das analyze Tool weiterhin funktionieren.

Batch-Behebung

Das Tool akzeptiert ein issues Array. Übermitteln Sie alle Probleme eines einzigen analyze oder igt Durchlaufs gemeinsam in einem Aufruf, anstatt das Tool einmal pro Problem aufzurufen – ein Batch unterstützt zwischen 1 und 25 Probleme.

Jedes Problem hat die folgenden Felder:

Feld Erforderlich Beschreibung
id Ja Eine vom Anrufer gewählte Kennung, die innerhalb des Batchs einzigartig ist (z. B. die Regel-ID plus ein Zähler: color-contrast-0). Dient nur dazu, jedes Ergebnis mit seinem Eingang zu korrelieren.
rule Ja Die axe Regel-ID aus dem analyze/igt Ausgabe (z. B. color-contrast, image-alt).
elementHtml Ja Das HTML-Snippet des verletzenden Elements.
remediation Ja Eine Beschreibung dessen, was falsch ist und was behoben werden muss, aus der Zusammenfassung des Problems (wahlweise angereichert mit dessen Beschreibung, Hilfetext oder KI-Begründung).
pageUrl Nein Die URL der Seite, die behoben wird, aus dem analyze Antwort.

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf – er erstellt das Batch aus den Analyseergebnissen:

Analyze http://localhost:3000 and remediate every issue found

Der Agent löst die Eingabeaufforderung auf und ruft das remediate Werkzeug mit einer Nutzlast auf, die ungefähr wie folgt aussieht:

{
  "issues": [
    {
      "id": "color-contrast-0",
      "rule": "color-contrast",
      "elementHtml": "<span style=\"color: #aaa\">Sign up</span>",
      "remediation": "Increase the contrast ratio to at least 4.5:1",
      "pageUrl": "http://localhost:3000"
    },
    {
      "id": "image-alt-1",
      "rule": "image-alt",
      "elementHtml": "<img src=\"logo.png\">",
      "remediation": "Add alt text describing the image"
    }
  ]
}

Ausgabe

Das Tool gibt ein Array von ergebnisspezifischen Resultaten zurück, die jeweils über idmit ihrem Input verknüpft sind. Ein Resultat hat eine von zwei Formen:

  • Erfolgstatus: "ok", mit einem remediation Objekt, das eine allgemeine Beschreibung, die Behebungsschritte und einen konkreten Code-Fix enthält
  • Fehlerstatus: "error", mit einem error Objekt (code und message) für ein Problem, das nicht behoben werden konnte
{
  "data": [
    {
      "id": "color-contrast-0",
      "status": "ok",
      "remediation": {
        "general_description": "...",
        "remediation": "...",
        "code_fix": "<span style=\"color: #595959\">Sign up</span>"
      }
    },
    {
      "id": "image-alt-1",
      "status": "error",
      "error": { "code": "LLM_ERROR", "message": "..." }
    }
  ]
}

Ergebnisse sind unabhängig: Ein Fehler bei einem Problem blockiert keine Hinweise für die anderen.

Credit-Nutzung

Das remediate Tool ist Teil des AI-Credit-Management-Systems. Jedes Problem in einem Batch verbraucht Credits aus dem monatlichen Kontingent Ihrer Organisation. Administratoren können den Credit-Verbrauch über das axe-Konto-Portal überwachen.

Das igt Tool

Das igt Tool führt Deques Automatisierte Intelligente Geführte Tests (IGTs) gegen eine Webseite aus Ihrer IDE aus. Während die axe DevTools Browser-Erweiterung einen Entwickler normalerweise mit manuellen Eingabeaufforderungen durch ein IGT führt, igt führt das Tool den Test automatisch aus und liefert strukturierte Ergebnisse, auf die ein Coding-Agent reagieren kann.

Derzeit unterstützt das Tool das Tastatur-IGT, das bewertet, ob die interaktiven Elemente auf einer Seite ausschließlich mit der Tastatur erreicht und bedient werden können.

Was es macht

  1. Authentifizierung - Validiert die Benutzeranmeldedaten—entweder einen API-Schlüssel oder ein OAuth 2.0 Zugriffstoken—, um autorisierten Zugang sicherzustellen
  2. Browser-basierter Lauf - Tests im selben Chromium-Instanz mit der eingebauten axe DevTools-Erweiterung, die das analyze Tool verwendet
  3. Seitennavigation - Navigiert zur vom Benutzer im Prompt an den KI-Agenten bereitgestellten URL
  4. Automatisiertes Tastatur-IGT - Durchgeht die Seite per Tabulator, während KI jeden Tabstopp analysiert, um die Fokusreihenfolge und Tastaturoperabilität zu bewerten—kein manuelles Eingreifen erforderlich
  5. Ergebnisauslieferung - Gibt strukturierte Befunde an den Agenten zurück

Verbrauch

Das Tool akzeptiert ein url und ein igtTools Array, das angibt, welche IGTs ausgeführt werden sollen. Derzeit ist das Tastatur-IGT der einzige unterstützte Wert:

{
  "url": "http://localhost:3000",
  "igtTools": ["keyboard"]
}

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf—der Agent übersetzt Ihre Absicht in den Tool-Aufruf:

Run the keyboard IGT on http://localhost:3000

Browser-Interaktionen vor dem Testen

Wie das analyze Tool, igt akzeptiert ein optionales before Array von Interaktionsschritten, die nach dem Laden der Seite aber bevor der geführte Test ausgelöst wird. Dies erlaubt es Ihnen, einen geführten Test gegen seiten mit Login-Schranken durchzuführen, Cookie-Banner zu entfernen oder zu warten, bis dynamische Inhalte zuerst erscheinen.

Die Schritte laufen in derselben gleichen Browserkontext wie der Test (sodass Cookies, localStorageund Routenänderungen bestehen bleiben), verwenden die gleichen click, fillund waitFor Aktionen und sind gleichzeitig auf das gleiche Limitiert 20 Schritte. Siehe Unterstützte Aktionen unter dem analyze Tool für die vollständige Referenz, einschließlich der Behandlung sensibler Werte von fill.value und der Selektor-Regeln.

{
  "url": "http://localhost:3000",
  "igtTools": ["keyboard"],
  "before": [
    { "action": "fill", "selector": "#username", "value": "<resolved-from-.env.local>" },
    { "action": "click", "selector": "button[type=submit]" },
    { "action": "waitFor", "selector": "#main-content" }
  ]
}

Ausgabe

Das Tool gibt eine strukturierte JSON-Antwort zurück:

{
  "pageUrl": "http://localhost:3000",
  "data": {
    "keyboard": {
      "issues": [],
      "unanalyzedElements": [],
      "terminatedReason": "keyboard-trap"
    }
  }
}
  • issues - Während des Laufs gefundene Verstöße gegen die Tastaturzugänglichkeit
  • unanalyzedElements - Tabstopps, die die KI nicht analysieren konnte. Diese werden separat von issues gemeldet, sodass sie manuell überprüft werden können, anstatt fälschlicherweise als bestanden oder durchgefallen eingestuft zu werden.
  • terminatedReason - Präsentieren nur wenn der Lauf abgebrochen wurde, bevor jeder Tabstopp analysiert wurde. Der aktuelle Wert ist "keyboard-trap", was bedeutet, dass der Test auf eine Keyboard-Falle gestoßen ist, aus der er nicht entkommen konnte; die verbleibenden Schritte werden abgebrochen und die bis zu diesem Zeitpunkt analysierten Tabstopps werden in issues.

Credit-Nutzung

Das igt Tool ist ein KI-gestütztes Feature und Teil der AI-Credit-Management-Systems. Jeder Lauf verbraucht KI-Guthaben aus dem monatlichen Kontingent Ihrer Organisation. Administratoren können die Kreditnutzung über das axe-Konto-Portal überwachen.

note

Wenn die AI-Credits aufgebraucht sind, funktioniert das igt Tool nicht mehr, bis Ihre Credits wieder aufgeladen sind (entweder durch Zukauf oder durch Rücksetzung Ihres monatlichen Zyklus). Jedoch wird das analyze Tool weiterhin funktionieren.

Erste Schritte

Die Einrichtung des axe MCP Servers umfasst drei unabhängige Entscheidungen:

  1. Wählen Sie eine Distribution — Docker oder npm
  2. Richten Sie die Authentifizierung ein — einen API-Schlüssel oder OAuth 2.0
  3. Konfigurieren Sie Ihren ClientVS Code mit Copilot, Cursoroder **Claude Code**

Für Umgebungsvariablen und empfohlene Anweisungen für den KI-Agenten siehe die Konfigurationsreferenz. Wenn etwas schiefgeht, siehe Fehlerbehebung.

Beispielaufforderungen

Sicherstellen, dass die erwarteten Werkzeuge aufgerufen werden

In vielen IDEs wird durch die Verwendung der folgenden Syntax (Präfix „#“) sichergestellt, dass die Werkzeuge des axe MCP Servers wie erwartet aufgerufen werden:

#analyze the http://localhost:3033/ web page for accessibility issues and #remediate any violations found

Eine localhost-URL auf Barrierefreiheitsprobleme analysieren:

Analyze http://localhost:3000 for accessibility issues

Analyse mit Behebung:

Analyze https://example.com for accessibility issues and fix any issues found

Eine Seite hinter einer Login-Schranke analysieren:

Analyze http://localhost:3000 for accessibility issues. Before running the
analysis, fill in the #username and #password fields with USERNAME and
PASSWORD from ./.env.local, click the button[type=submit] button, and
wait for #main-content to appear.
Analyze https://example.com for accessibility issues, but first click the
#cookie-dismiss button to dismiss the cookie consent banner.

Support

Für Fragen, Probleme oder Feedback bezüglich des axe MCP Servers:

Sicherheit & Datenschutz FAQ

Erfasst oder speichert axe MCP Server unseren Quellcode?

Nein. Der MCP-Server von Axe erfasst oder speichert Ihren Quellcode in keiner Datenbank oder permanentem Speicher.

Wenn das analyze Tool ausgeführt wird, enthält die Antwort den HTML-Quellcode der Elemente mit Barrierefreiheitsproblemen zu Kontext- und Debugging-Zwecken. Diese Daten jedoch:

  • Werden nur in der unmittelbaren API-Antwort an Ihr KI-Agent zurückgegeben
  • Werden nie in von Deque verwalteten Datenbanken gespeichert
  • Bleiben innerhalb Ihrer lokalen Entwicklungsumgebung
  • Werden nach Abschluss der Analyse verworfen

Wie lange bleiben MCP-Testergebnisse in der von Deque verwalteten Infrastruktur?

Tun sie nicht. MCP-Testergebnisse werden in keiner von Deque verwalteten Datenbank oder Speichersystem gespeichert.

Das analyze Tools:

  • Läuft vollständig auf Ihrem Rechner — in einem Docker-Container oder als lokaler Node.js-Prozess mit der npm-Distribution
  • Gibt die Ergebnisse direkt an Ihr KI-Agent zurück
  • Sendet keine Analyseergebnisse an Deque-Server

Die einzige Ausnahme ist, wenn Sie das remediate Tool aufrufen, das minimale Metadaten von Verstößen (siehe unten) umfassen kann, um KI-gestützte Korrekturanleitungen zu erstellen.

Welche Daten werden an Deque-Server gesendet?

Nur bei Verwendung des remediate Tools:

Die folgenden Daten werden an den KI-Remediation-Endpunkt von Deque gesendet, um Korrekturanleitungen zu erstellen:

  • Regel-ID - Die spezifische Barrierefreiheitsregel, die verletzt wurde
  • Element-HTML - Das HTML-Markup des oder der betroffenen Elemente
  • Metadaten zu Problemen - Beschreibung der Verstöße und Leitfaden zur Abhilfe von axe-core

Diese Daten werden ausschließlich zur Erstellung von Korrekturanleitungen verwendet und nicht langfristig in Deque-Datenbanken gespeichert.

Das analyze Tool sendet keine Daten an Deque-Server über Authentifizierungsanforderungen hinaus (Gültigkeitsprüfung Ihres API-Schlüssels oder OAuth 2.0-Zugriffstokens).

Welches Zugriffslevel benötigt das KI-Agent, um zu funktionieren?

Das KI-Agent (Claude, Copilot, Cursor usw.) benötigt Zugriff auf:

  1. MCP-Server-Kommunikation - Das Agent muss in der Lage sein, die Tools des MCP-Servers über das Model Context Protocol aufzurufen

  2. Tool-Antwortdaten - Das Agent erhält:

    • Daten zu Barrierefreiheitsverstößen von analyze Aufrufen
    • Leitlinien zur Abhilfe von remediate Aufrufen
    • Diese Daten sind für das Agent erforderlich, um Probleme zu verstehen und Codekorrekturen zu generieren
  3. Ihr Codebase (optional) - Wenn Sie möchten, dass das Agent automatisch Codekorrekturen vornimmt, benötigt es Zugriff auf Ihre Quellcodedateien

  • Dies ist Standard für KI-Coding-Assistenten in IDEs (VS Code, Cursor usw.)
  • Nicht erforderlich, wenn Sie die Tools nur zur Analyse und Anleitung verwenden (z.B. über die Claude Desktop-App)

Der MCP-Server selbst benötigt Zugriff auf:

  • Von Ihnen zum Testen angegebene URLs (unterstützt sowohl lokal als auch remote)
  • Ihre axe-Anmeldedaten: entweder ein API-Schlüssel (generiert im axe-Kontoportal) oder ein OAuth 2.0-Zugriffstoken (erhalten über @deque/axe-auth); bereitgestellt über Umgebungsvariable

Wichtig: Der MCP-Server läuft lokal auf Ihrem Rechner — in einem Docker-Container oder als Node.js-Prozess mit der npm-Distribution. Er erfordert keinen umfassenden Dateisystemzugriff oder erhöhte Privilegien.

Best Practices

  • Anmeldedatensicherheit - Speichern Sie Ihren AXE_API_KEY oder AXE_ACCESS_TOKEN als Umgebungsvariable, nicht im Code. Mit OAuth 2.0 @deque/axe-auth speichert es Tokens in Ihrem OS-Schlüsselbund und injiziert bei jedem Start ein neues Zugriffstoken, sodass kein langzeitiger Geheimcode in Ihrer Konfiguration vorhanden sein muss
  • Lokale Tests - Testen Sie lokale Entwicklungs-URLs (localhost) oder Staging, um sensiblen Vorproduktion-Code isoliert zu halten
  • Netzwerkisolation - Der MCP-Server kommuniziert nur mit:
    • URLs, die Sie ausdrücklich zur Analyse anfordern
    • Deque-Server für Authentifizierung (API-Schlüssel- oder OAuth 2.0-Token-Validierung) und Behebung (bei Aufruf)
    • Ihrem lokalen AI-Agenten über das MCP-Protokoll
  • Überprüfen vor der Anwendung - Überprüfen Sie immer von KI-generierte Codeänderungen, bevor Sie sie in Ihr Code-Repository übernehmen