**axe MCP Server**

Ü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, remediate und igt. analyze führt zudem Automatisierte Intelligente Geführte Tests gegen die Seite aus, die er scannt, und ersetzt das mittlerweile veraltete eigenständige igt-Tool.

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 enthalten. Ein Abonnement zur Freischaltung des Zugriffs auf den Axe-MCP-Server wird durch Gespräche mit einem Deque-Vertriebsmitarbeiter eingerichtet.

Tools & Funktionen

Das analyze-Tool

Das analyze-Tool führt eine umfassende Barrierefreiheitsanalyse von Webseiten durch, indem es mithilfe der Axe DevTools Browser Extension in einer realen Browserumgebung scannt. Es funktioniert nahtlos sowohl mit lokalen Entwicklungs-URLs (z. B. localhost:3000) als auch mit Remote-Produktions-URLs.

Was es macht

1. Authentifizierung — Validiert die Benutzeranmeldedaten (entweder einen API-Schlüssel oder ein OAuth 2.0 Access Token), um autorisierten Zugriff zu gewährleisten
2. Konfigurationsabfrage — Ruft die benutzerspezifischen axe-Konfiguration-Einstellungen der Organisation ab, einschließlich:
   • Barrierefreiheits-Standard (z. B. WCAG 2.2 AA)
   • axe-core Version
   • Bedarf an Überprüfung / bewährte Praktiken
   • Erweiterte Regeln Voreinstellung
3. Browserbasierte Analyse — Startet eine Browserinstanz im Hintergrund mit installierter Axe DevTools Extension
4. Seitennavigation - Navigiert zur URL, die vom Benutzer in seiner Eingabeaufforderung an den KI-Agent gesendet wurde
5. Barrierefreiheits-Scan — Führt eine vollständige Barrierefreiheitsanalyse auf der gerenderten-Seite mit der Axe DevTools Browsererweiterung durch, um sicherzustellen, 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 ermöglichen, Seiten in bestimmten Ansichtsfensterabmessungen zu testen. Dies ist nützlich, um Barrierefreiheitsprobleme zu erkennen, die nur bei bestimmten Bildschirmgrößen auftreten, wie z. B. bei Mobilgeräten oder Tablet-Breakpoints.

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

Wenn beide Parameter weggelassen werden, läuft der Scan mit 1000×1080. Wird nur viewportWidth übergeben, wird die Höhe auf 1080 gesetzt; viewportHeight benötigt die Voreinstellung von viewportWidth. Jede Dimension kann bis zu 7680 Pixel betragen.

Teilschrittscans

Standardmäßig scannt das analyze-Tool die gesamte Seite. Um den Scan auf einen bestimmten Bereich zu beschränken, übergeben Sie den optionalen selector-Parameter — nützlich, um sich auf eine einzelne Komponente zu konzentrieren oder laute, unzusammenhängende Teile der Seite aus den Ergebnissen auszuschließen.

• Ein einzelner CSS-Selektor-String zielt auf ein Element im obersten Frame ab:

  {
    "url": "http://localhost:3000",
    "selector": "#main"
  }

• Ein Array von CSS-Selektoren durchläuft iframe- oder Shadow-DOM-Grenzen — jedes Segment wählt den Host für das nächste aus. Verwenden Sie ein Array nur, wenn das Ziel in einem iframe oder Shadow-Root lebt:

  {
    "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 ausführen. Dies eröffnet verschiedene reale Testszenarien:

• Anmeldeseiten — Füllen Sie Anmeldedaten aus und senden Sie diese ab, bevor Sie die Seite nach dem Login 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 eingefügte DOM-Elemente) angezeigt werden, bevor Sie scannen

Schritte werden in Array-Reihenfolge ausgeführt, im gleichen Browserkontext wie der Scan, sodass Cookies, localStorage und alle durch click oder fill ausgelösten Routenänderungen in den Scan übergehen.

Das before-Array unterstützt bis zu 20 Schritte. Jeder Schritt erhält ein eigenes Timeout von BROWSER_TIMEOUT_MS (Standardmäßig 30000 ms); es gibt keinen überschreibenden Timeout pro Schritt.

Unterstützte Aktionen

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 und ruft das analyze-Tool mit einer Nutzlast ähnlich wie folgt auf:

{
  "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" }
  ]
}

Cookie-Injektion

Das analyze-Tool unterstützt ein optionales cookies-Array, das Cookies im Browserkontext vor der Navigation setzt — sodass sie bei der allerersten Anfrage an die Seite übermittelt werden. Dies unterscheidet sich von before Aktionen, die nach der Navigation laufen und daher keinen Einfluss darauf haben, wie die anfängliche Anfrage geroutet wird. Zwei häufige Anwendungsfälle:

• Umgebungsrouting — setzen Sie ein Staging- oder Feature-Branch-Selektorkookie, das von einer Edge- oder CDN-Schicht gelesen wird, um zu entscheiden, welche Version der Seite bereitgestellt wird.
• Vorausgefüllte Sitzungen — einen gültigen Sitzungscookie injizieren, damit der Scan bereits eingeloggt startet, ohne ein Anmeldeformular über before durchlaufen zu müssen.

Das cookies-Array unterstützt bis zu 20 Cookies.

Cookie-Felder

Beispiel: Auf einer vorab authentifizierten Seite landen

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

Analyze https://app.example.com for accessibility issues. Set the session
cookie for app.example.com from ./.env.local so the scan starts already
logged in.

Der Agent löst den Cookie-Wert auf und ruft das analyze-Tool mit einer Nutzlast ähnlich wie folgt auf:

{
  "url": "https://app.example.com",
  "cookies": [
    {
      "name": "session",
      "value": "<resolved-from-.env.local>",
      "domain": "app.example.com"
    }
  ]
}

Screenshots

Das analyze-Tool kann einen Screenshot der Seite zusammen mit dem Verletzungsbericht zurückgeben, sodass Sie sehen können, was gescannt wurde. Übergeben Sie den optionalen screenshot-Parameter, um einzuwilligen — ein leeres Objekt ist ausreichend:

{
  "url": "http://localhost:3000",
  "screenshot": {}
}

PNG ist die Standardeinstellung. Setzen Sie format auf "jpeg", um ein kleineres Bild auf seitenlastigen Seiten zu erhalten:

{
  "url": "http://localhost:3000",
  "screenshot": { "format": "jpeg" }
}

Das Bild wird nach dem Verletzungsbericht als standardmäßiger MCP-Image-Content-Block zurückgegeben.

Was der Screenshot zeigt

• Das sichtbare Viewport, nicht die vollständige Seite. Inhalte unterhalb des Falzes sind nicht enthalten. Um mehr von der Seite zu erfassen, stellen Sie viewportHeight ein (z. B. 4096), damit der sichtbare Bereich das abdeckt, was Sie sehen möchten.
• Die Seite, wie sie unmittelbar war, bevor der Scan begann. Die Aufnahme erfolgt direkt vor axe.run(), sodass DOM-Änderungen, die während des Scans auftreten — SPA-Neurenderungen, useEffect-Aktualisierungen, Animationen, laufende Anfragen — nicht reflektiert werden. Bei Single-Page-Apps ist diese Verschiebung häufig.

Kosten und Kundensupport

Ob das Bild inline gerendert wird, hängt von Ihrem MCP-Client ab. Der Server gibt immer einen spezifikationskonformen Bildblock zurück, aber einige Clients klappen Tool-Ergebnisse zusammen oder weglassen Bildvorschauen — VS Code mit Copilot zeigt es an, während Cursor und Claude Desktop möglicherweise nicht. Eine fehlende Vorschau ist eine clientseitige Anzeigeeinschränkung, kein fehlgeschlagener Capture.

Screenshots auf Festplatte speichern

Der Screenshot kann auch in eine Datei geschrieben werden, was der zuverlässige Weg ist, um eine Aufnahme in einem Client zu sehen, der keine Inline-Bilder rendert. Setzen Sie saveTo auf einen absoluten Pfad:

{
  "url": "http://localhost:3000",
  "screenshot": { "saveTo": "/Users/me/Desktop/home.png" }
}

Oder setzen Sie save: true, um dem Server die Wahl des Dateinamens zu überlassen:

{
  "url": "http://localhost:3000",
  "screenshot": { "save": true }
}

Der geschriebene absolute Pfad wird im messages-Array der Antwort zurückgegeben, sodass Ihr Agent Ihnen sagen kann, wo Sie die Datei finden.

Das Speichern gilt für nur erfolgreiche Scans. Wenn der Scan fehlschlägt, nachdem der Screenshot aufgenommen wurde, wird das Bild dennoch inline zusammen mit dem Fehler zurückgegeben, unabhängig von inline, und wird niemals auf die Festplatte geschrieben.

Wenn das Erfassen fehlschlägt

Der Screenshot wird nach bestem Bemühen aufgenommen und schlägt einen Scan niemals fehl. Wenn das Erfassen abläuft, gibt der Scan dennoch seine Ergebnisse mit einer Notiz im messages-Array der Antwort zurück:

Screenshot capture failed: <reason>

Wenn der der Scan selbst fehlschlägt, nachdem der Screenshot aufgenommen wurde, wird das Bild dennoch mit der Fehlerantwort zurückgegeben — der visuelle Zustand der Seite im Moment des Fehlers ist in der Regel das nützlichste Debugging-Mittel, das Sie haben.

Erweiterte Regeln

Jenseits des standardmäßigen axe-core-Regelwerks kann das analyze-Tool Erweiterte Regeln ausführen — automatisierte Tests, die Screenshots, Computer Vision und große Sprachmodelle nutzen, um Probleme zu erkennen, die axe-core allein nicht erfassen kann, wie Überschriften, die nur wie Überschriften aussehen, oder informative Bilder mit unzureichendem Alternativtext.

Welches Preset ausgeführt wird, wird durch die axe-Konfiguration Ihrer Organisation geregelt und kann – soweit Ihr Administrator dies erlaubt – pro Server mit AXE_ADVANCED_RULES oder pro Scan mit dem advancedRules-Argument überschrieben werden:

{
  "url": "http://localhost:3000",
  "advancedRules": "thorough"
}

Jede Antwort meldet das tatsächlich ausgeführte Preset und seine Herkunft:

{
  "advancedRules": {
    "value": "thorough",
    "source": "tool_arg"
  }
}

Erweiterte Regeln kommen mit Ihrem axe DevTools for Web-Abonnement — demselben, das Ihnen den axe MCP Server zur Verfügung stellt. Sie fügen einem Scan etwa 15–20 Sekunden hinzu, verbrauchen AI-Credits und sind der einzige Fall, bei dem analyze Seiteninformationen (ein vollständiger Screenshot plus Seitenstruktur) an Deque zur Auswertung sendet. Siehe Erweiterte Regeln für Voreinstellungen, Prioritäten, Degradationsmeldungen und Datenschutzeinzelheiten.

Intelligente Geführte Tests

Das analyze-Tool kann auch Deques Automatisierte Intelligente Geführte Tests (IGTs) auf dieselbe Seite im selben Aufruf ausführen. Übergeben Sie das optionale igtTools-Array, das benennt, welche IGTs ausgeführt werden sollen — der Tastatur-IGT ist derzeit der 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 Werkzeugaufruf:

Scan http://localhost:3000 for accessibility issues and run the keyboard IGT on it

Jeder angeforderte IGT läuft in Folge nach dem axe-Scan, auf derselben Seite, im selben Browser, bei derselben Viewport-Breite. Alles, was die Seite vorbereitet, läuft einmal und wird in beide übernommen: before Aktionen, Cookie-Injektion und das Viewport-Parameter.

{
  "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" }
  ]
}

Antwortform

Das Setzen von igtTools ändert die Form von data. Ohne es ist data das axe-Fehlerarray. Mit ihm führt data axe und igt als gleichwertige Schlüssel, mit jeweils einem igt-Eintrag pro angefordertes Tool:

{
  "pageUrl": "http://localhost:3000",
  "data": {
    "axe": [],
    "igt": {
      "keyboard": {
        "status": "complete",
        "issues": [],
        "igtElements": [],
        "terminatedReason": "keyboard-trap"
      }
    }
  }
}

• status — "complete" oder "error". Überprüfen Sie es, bevor Sie etwas anderes lesen: issues und igtElements sind nur bei "complete" vorhanden, und error nur bei "error".
• issues — die Zugänglichkeitsprobleme, die der IGT gefunden hat. Die Anzahl der Probleme entspricht der Länge dieses Arrays.
• igtElements — jede-Element, das der IGT bearbeitet hat, keine Liste von Problemen. Einträge mit analysisFailed: true konnten von der KI nicht analysiert werden und sollten manuell überprüft werden. Jeder Eintrag ist auf nur identifizierende Felder reduziert: vnodeId, selector, tagName, role, accessibleName, states und analysisFailed, die jeweils nur dann vorhanden sind, wenn das Element sie enthält.
• terminatedReason — vorhanden nur, wenn der Lauf frühzeitig gestoppt wurde, was bedeutet, dass die Ergebnisse teilweise sind. "keyboard-trap" bedeutet, dass der Test auf eine Fokussperre stieß, aus der er nicht entkommen konnte; "insufficient-credits" bedeutet, dass das Konto während des Laufs die KI-Kredite aufgebraucht hat.

Fehler sind isoliert

Ein IGT, das fehlschlägt, lässt nicht den Aufruf nicht fehlschlagen und beeinflusst nie die axe-Ergebnisse. Der Fehler wird als eigenes status: "error" dieses Tools mit einer Nachricht gemeldet, während die axe-Ergebnisse normal zurückkommen — einschließlich wenn die maschinelle Lernsetzung Ihrer Organisation deaktiviert ist, in welchem Fall der IGT-Teil erklärt, dass maschinelles Lernen erforderlich ist.

Kreditnutzung

IGTs sind KI-gesteuert und Teil des AI-Credit-Management-Systems. Jeder Lauf verbraucht KI-Kredite aus dem monatlichen Kontingent Ihrer Organisation; der axe-Scan selbst nicht. Fordern Sie IGTs bewusst an, anstatt sie zu jedem Scan hinzuzufügen.

Wichtige Vorteile

• Echtbrowser-Tests - Testet die tatsächlich gerenderte Seite, nicht nur Quellcode, um genaue Ergebnisse sicherzustellen
• 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 Viewport-Abmessungen, um breakpointspezifische Zugänglichkeitsprobleme zu erfassen
• Gezielte Scans - Begrenzen Sie einen Scan auf eine bestimmte Region, ein Iframe oder eine Shadow-Root mit dem selector-Parameter
• Authentifizierte & Interaktive Seiten - Scannen Sie Seiten hinter einem Login, blenden Sie Cookie-Banner aus oder warten Sie auf dynamische Inhalte mithilfe von before-Aktionen
• Sitzungs- und Umgebungscookies - Landen Sie bereits authentifiziert oder routen Sie zu einer spezifischen Umgebung, indem Sie Cookies vor der Navigation mit dem cookies-Parameter injizieren
• Visueller Kontext - Geben Sie einen Screenshot der Seite zusammen mit dem Bericht mit dem screenshot-Parameter zurück, auch wenn ein Scan fehlschlägt
• Erweiterte Regeln - Erkennen Sie Probleme, die visuelles oder kontextuelles Denken erfordern, bei einem Konfidenzgrad, den Ihre Organisation steuert
• Intelligente Geführte Tests - Führen Sie einen IGT gegen dieselbe Seite im selben Aufruf mit dem igtTools-Parameter aus

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
• Ein advancedRules-Block, der das ausgeführte Erweiterte Regeln-Voreinstellung und dessen Herkunft meldet
• Ein messages-Array, das Anmerkungen über den Lauf enthält (zum Beispiel eine fehlgeschlagene Screenshot-Aufnahme, einen verschlechterten erweiterten Regel-Lauf oder den Pfad, in den ein Screenshot gespeichert wurde)

Wenn screenshot gesetzt ist, folgt ein Bildinhaltsblock dem Bericht. Wenn igtTools gesetzt ist, werden IGT-Ergebnisse zusammen mit den axe-Ergebnissen zurückgegeben, geordnet nach Tool-Name.

Das remediate-Tool

Das remediate-Tool nimmt eines oder mehrere von den analyze- oder igt-Tool identifizierte Zugänglichkeitsprobleme entgegen und generiert kontextbezogene, KI-gesteuerte Behebungsanleitungen, die Codierungsagenten in tatsächliche Codekorrekturen übersetzen können. Probleme werden als Batch übermittelt, sodass ein einziger Aufruf Korrekturen für jede auf einer Seite gefundene Verletzung zurückgeben kann.

Was es macht

1. Authentifizierung - Validiert die Anmeldeinformationen des Benutzers - entweder einen API-Schlüssel oder ein OAuth 2.0-Zugangstoken - um autorisierten Zugriff sicherzustellen
2. AI-Guthaben Nutzung - Jedes Problem im Batch verbraucht KI-Guthaben aus dem Budget Ihrer Organisation, was die Verwendung fortschrittlicher KI-Modelle ermöglicht, die auf umfangreichem Zugänglichkeitswissen von Deque trainiert wurden
3. KI-erzeugte Behebung - Erarbeitet hochwertige, umsetzbare Zugänglichkeitskorrekturen, die Codierungsagenten interpretieren und im Quellcode implementieren können

Batch-Behebung

Das Tool akzeptiert ein issues-Array. Reichen Sie alle die Probleme von einem einzelnen analyze- oder igt-Lauf gesammelt in einem Aufruf ein, anstatt das Tool für jedes Problem einzeln aufzurufen - ein Batch unterstützt zwischen 1 und 25 Problemen.

Jedes Problem hat die folgenden Felder:

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 und ruft das remediate-Tool mit einer Nutzlast ähnlich wie folgt auf:

{
  "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 Ergebnissen pro Problem zurück, das jeweils durch id mit seiner Eingabe verknüpft ist. Ein Ergebnis hat eine von zwei Formen:

• Erfolg — status: "ok", mit einem remediation-Objekt, das eine allgemeine Beschreibung, die Behebungsschritte und eine konkrete Codekorrektur enthält
• Fehler — status: "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 Guthaben aus dem monatlichen Budget Ihrer Organisation. Administratoren können die Nutzung der Guthaben über das axe Account Portal überwachen.

Das igt-Tool

Das igt-Tool führt Deques Automatisierte Intelligente Geführte Tests gegen eine Webseite als eigenständigen Aufruf aus. Alles, was es tut, erledigt analyze jetzt im selben Aufruf wie der Accessibility-Scan — siehe Intelligente Geführte Tests für Verwendung und Kreditverbrauch, die für beide gleich sind.

Das Ergebnisobjekt pro Test ist ebenfalls für beide gleich — status, issues, igtElements und ein optionales terminatedReason, wie in Antwortform beschrieben. Nur das Kuvert unterscheidet sich: igt gibt seine Ergebnisse direkt unter data zurück, geordnet nach Testname (data.keyboard), wohingegen analyze sie unter data.igt neben data.axe einbettet.

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 — ein API-Schlüssel oder OAuth 2.0
3. Konfigurieren Sie Ihren Client — VS Code mit Copilot, Cursor oder **Claude Code**

Claude-Code-Nutzer können diese Schritte mit dem axe Accessibility Plugin überspringen, das den Server registriert und Slash-Befehle für Einrichtung, Agentenanweisungen und den vollständigen Behebungslauf hinzufügt.

Für Umgebungsvariablen und empfohlene Anweisungen für den KI-Agenten siehe 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.

Ein Cookie-Banner vor dem Scannen schließen:

Analyze https://example.com for accessibility issues, but first click the
#cookie-dismiss button to dismiss the cookie consent banner.

Einen Screenshot der Seite aufnehmen:

Analyze http://localhost:3000 for accessibility issues and capture a screenshot of the page

Scannen einer Seite mit einem eingesetzten Sitzungscookie:

Analyze https://app.example.com for accessibility issues. Set the session
cookie for app.example.com from ./.env.local so the scan starts already
logged in.

Support

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

• Technischer Support: helpdesk@deque.com
• Allgemeine Anfragen: helpdesk@deque.com
• Vertriebsfragen: sales@deque.com

Sicherheit & Datenschutz FAQ

Erfasst oder speichert axe MCP Server unseren Quellcode?

Nein. Der axe MCP Server erfasst oder speichert Ihren Quellcode nicht in einer Datenbank oder einem persistenten Speicher.

Wenn das analyze-Tool läuft, enthält die Antwort den HTML-Quellcode der Elemente mit Zugänglichkeitsproblemen zu Kontext- und Debugging-Zwecken. Diese Daten:

• 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-Tool:

• 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

Es gibt zwei Ausnahmen:

• Das remediate-Tool, das minimale Verletzungsmetadaten (siehe unten) enthalten kann, um KI-gesteuerte Reparaturanleitungen zu generieren.
• Erweiterte Regeln, wenn ein aktives Preset wirksam ist. Erweiterte Regeln werden serverseitig ausgewertet, daher lädt analyze einen Screenshot der gesamten Seite und die für die Regeln erforderliche Seitenstruktur hoch. Siehe Was an Deque gesendet wird.

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 Zugänglichkeitsregel, die verletzt wurde
• Element-HTML - Das HTML-Markup des betroffenen Elements/der betroffenen Elemente
• Metadaten zu Problemen - Beschreibung des Verstoßes und Behebungsanleitung von axe-core

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

Bei Verwendung von Erweiterte Regeln:

Erweiterte Regeln werden von den ML- und LLM-Diensten von Deque statt im lokalen Browser ausgewertet, daher wird bei einem Scan mit einem aktiven Preset gesendet:

• Ein Screenshot der gesamten Seite der gescannten Seite
• Seitenstruktur und berechnete Stile — der Bewertungspayload, den die erweiterten Regeln benötigen, um über Layout, Kontrast und Überschriften zu entscheiden

Diese Erfassung ist unabhängig vom optionalen screenshot Parameter des analyze Tools: Das Weglassen dieses Parameters verhindert sie nicht. Setzen Sie das Preset für die erweiterten Regeln auf disabled — pro Scan, pro Server oder organisationsweit in axe-Konfiguration — für Seiten, deren Inhalt Ihre Umgebung nicht verlassen darf.

Andernfalls sendet das analyze Tool keine Daten an die Deque-Server außer Authentifizierungsanfragen (Validierung Ihres API-Schlüssels oder OAuth 2.0-Zugriffstokens) und dem Abrufen der Axe-Konfiguration Ihrer Organisation.

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 - Der Agent muss in der Lage sein, die Werkzeuge des MCP-Servers über das Model Context Protocol aufzurufen

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

   • Daten zu Zugänglichkeitsverstößen aus analyze-Aufrufen
   • Behebungsanleitungen aus 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 der Agent Codekorrekturen automatisch anwendet, benötigt er 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 Account Portal) 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. Es erfordert keinen umfassenden Zugriff auf das Dateisystem oder erhöhte Berechtigungen.

Best Practices

• Anmeldedatensicherheit - Speichern Sie Ihr AXE_API_KEY oder AXE_ACCESS_TOKEN als Umgebungsvariable, nicht im Code. Bei OAuth 2.0 speichert @deque/axe-auth Token in Ihrem Betriebssystemschlüsselbund und injiziert ein neues Zugriffstoken beim Start, sodass kein langfristiges Geheimnis in Ihrer Konfiguration verbleiben muss.
• Lokale Tests - Testen Sie lokale Entwicklungs-URLs (localhost) oder Staging, um sensiblen Pre-Production-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 Ihre Codebasis übernehmen