Konfigurationsreferenz

Diese Seite dokumentiert die Umgebungsvariablen, die der axe MCP Server liest, und die empfohlenen maßgeschneiderten Anweisungen für Ihren KI-Agenten. Diese gelten sowohl für die Docker- und npm-Distributionen. Um herauszufinden, wo Sie diese Werte platzieren, siehe Ihr Client-Setup-Leitfaden.

Konfigurationsoptionen

Der axe MCP Server unterstützt mehrere Umgebungsvariablen zur Anpassung:

AXE_SERVER_URL

Der Standardwert (https://axe.deque.com) ist für die meisten Benutzer korrekt — diejenigen, die die gemeinsame US-SaaS-Instanz von Deque nutzen. Wenn Ihre Organisation eine der folgenden Optionen nutzt, müssen Sie AXE_SERVER_URL auf die Basis-URL Ihrer Instanz setzen:

• Eine regionale SaaS-Instanz (EU, Australien, Frankfurt usw.)
• Ein privates Cloud -Deployment
• Eine lokale Installation

Wenn Sie nicht sicher sind, welche Instanz Ihre Organisation verwendet, überprüfen Sie die URL, die Sie verwenden, um sich im Kontenportal von axe anzumelden, oder fragen Sie Ihren Administrator.

Setzen Sie AXE_SERVER_URL explizit im env Block Ihrer MCP-Serverkonfiguration. Die Einrichtungsanleitungen für den Client enthalten Beispiele, die genau zeigen, wo es hinzuzufügen ist.

AXE_CHROME_PATH

nur npm-Verteilung. Dies wird in Docker nicht unterstützt, das immer seinen gebündelten Browser verwendet — der Server schlägt fehl, wenn AXE_CHROME_PATH in der Docker-Verteilung eingestellt ist.

Standardmäßig verwendet die npm-Verteilung den Chromium-Build, den Sie über Playwrightinstallieren. Setzen Sie AXE_CHROME_PATH auf den vollständigen Pfad einer bestehenden Chrome-/Chromium-Binärdatei, um diese stattdessen zu verwenden und die Playwright-Installation zu überspringen.

• Der Wert muss eine ausführbare Binärdateisein, kein .app Paket oder Verzeichnis. Auf macOS zeigen Sie beispielsweise auf die Binärdatei im Paket: /Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing.
• Die Binärdatei muss gestartet werden und auf --versionantworten. Der Server überprüft dies beim Start und schlägt schnell mit Unable to find specified chrome instance fehl, wenn er es nicht kann.
• Branding von Google Chrome stable 137 und später wird nicht unterstützt. Verwenden Sie Chrome für Tests oder eine andere chromkompatible Binärdatei.

Die analyze und igt Tools akzeptieren auch ein pro-Aufruf- chromePath Argument, das Vorrang vor AXE_CHROME_PATH für diesen Aufruf hat.

Konfiguration Ihres KI-Agenten (Empfohlen)

Um sicherzustellen, dass Ihr KI-Coding-Agent die axe MCP Server-Tools korrekt verwendet und bewährte Praktiken zur Barrierefreiheit befolgt, können Sie ihm benutzerdefinierte Anweisungen geben. Diese Anweisungen helfen dem Agenten, den richtigen Workflow zur Analyse und Behebung von Barrierefreiheitsproblemen zu verstehen.

Wo Anweisungen Hinzufügen

Die Methode variiert je nach Client:

• VS Code mit GitHub Copilot - Hinzufügen zu .github/copilot-instructions.md in Ihrem Projektstammverzeichnis
• Cursor - Hinzufügen zu „Cursor-Regeln“ in den Einstellungen
• Claude-Code - Hinzufügen zu einer CLAUDE.md Datei in Ihrem Projektstammverzeichnis
• Claude Desktop - Hinzufügen zu benutzerdefinierten Anweisungen in den Einstellungen
• Andere MCP-Clients - Konsultieren Sie die Dokumentation Ihres Clients zur Konfiguration benutzerdefinierter Anweisungen

Beispiel-Workflow-Anweisungen

Unten ist eine empfohlene Vorlage, die Sie für Ihren Agenten anpassen können:

# Accessibility Testing and Remediation Workflow

## MANDATORY WORKFLOW - DO NOT DEVIATE

When working with accessibility issues, you MUST follow this exact workflow:

### 1. Analysis Phase

When asked to analyze pages for accessibility issues, you MUST:

- Use the `analyze` tool to scan the page
- Do NOT manually identify accessibility issues
- Always provide the complete URL being analyzed

### 2. Authentication & Pre-Scan Setup

When the user's request involves credentials, form input, dismissing
overlays, or waiting for content before the scan, you MUST:

- Pass an ordered `before` array to the `analyze` tool using the
  `click`, `fill`, and `waitFor` actions
- Resolve any references to env vars, `.env*` files, or local
  configuration into literal strings BEFORE calling the tool — the
  server treats `value` as a literal and will not expand `${VAR}`,
  `$VAR`, or `{{VAR}}` syntax
- Use `fill` for secret values so the server's redaction protections
  apply; never embed secrets in a `selector`, which appears in logs
  and error messages
- ASK the user when the source of a credential or value is ambiguous;
  do NOT guess or fabricate values
- Use ONLY selectors the user provided; if a step needs a selector
  the user did not name, ASK rather than guess
- Use `waitFor` after any `click`/`fill` that triggers async UI
  (route changes, late-rendered content) to deterministically gate
  the next step or the scan — pick a selector that exists ONLY in
  the post-interaction state (e.g., a logout button or dashboard
  heading), never a generic one like `body` or `#app` that already
  exists beforehand

### 3. Remediation Phase

When asked to remediate or fix accessibility issues, you MUST:

- Collect ALL violations from the analysis and pass them to the
  `remediate` tool in a SINGLE batched call — do NOT call `remediate`
  once per issue
- Give each issue a unique `id` so each result can be correlated
  back to its input
- Provide the exact HTML element, rule ID, and issue description for
  every issue in the batch
- Review the remediation guidance before making any code changes
- Apply fixes based on the remediate tool's recommendations
- Do NOT manually fix accessibility issues without first using the remediate tool

### 4. Verification Phase

After applying fixes, you MUST:

- Re-run `analyze` to verify all issues are resolved
- Confirm zero violations before considering the task complete

## Required Workflow Example:

1. analyze → Find violations
2. remediate → Pass ALL violations in one batched call to get fix guidance
3. Apply recommended fixes to code
4. analyze → Verify fixes

## Enforcement

- NEVER skip the remediate tool when fixing accessibility issues
- ALWAYS use both analyze and remediate tools as specified
- This workflow ensures proper accessibility best practices and compliance

Warum das Wichtig ist

Diese Anweisungen stellen sicher, dass Ihr Agent:

• Verwendet das Fachwissen von Deque - Nutzt KI-Modelle, die auf jahrzehntelangen Daten zur Barrierefreiheitsbewertung trainiert sind, anstatt auf allgemeinem LLM-Wissen
• Befolgt bewährte Praktiken - Wendet konsistente, WCAG-konforme Korrekturen an, statt generische Lösungen
• Überprüft Änderungen - Bestätigt immer, dass die Korrekturen die Probleme tatsächlich gelöst haben
• Vermeidet falsches Vertrauen - Geht nicht davon aus, dass es weiß, wie man Zugänglichkeitsprobleme ohne Expertenrat löst

Obwohl optional, verbessern diese Anweisungen erheblich die Qualität und Zuverlässigkeit der Zugänglichkeitskorrekturen in Ihrem Codebestand.