**server axe MCP**

Vue d'ensemble

Le serveur axe MCP est un serveur de protocole de contexte de modèle (MCP) qui intègre des tests d'accessibilité de niveau entreprise directement dans votre flux de travail de développement. Construit sur la plateforme axe de confiance, il permet aux développeurs de réaliser des analyses d'accessibilité complètes et de recevoir des conseils de remédiation experts sans quitter leur IDE.

Le serveur offre trois fonctionnalités - analyze, remediate, et igt.

Ces outils s'intègrent parfaitement avec les clients compatibles MCP (comme Claude Desktop, VS Code avec Copilot, ou Cursor) et respectent les paramètres de configuration axe de votre organisation.

Obtenir l'accès

Le serveur Axe MCP est inclus dans le pack pack Axe DevTools pour Web. Un abonnement permettant l'accès au serveur Axe MCP est établi en discutant avec un représentant commercial de Deque.

Outils et capacités

L'outil analyze

L'outil analyze effectue une analyse d'accessibilité complète des pages web en exécutant un scan via l'extension axe DevTools Browser dans un environnement de navigateur réel. Il fonctionne parfaitement avec les URL de développement local (par exemple, localhost:3000) et les URL de production à distance.

Fonctionnalités

1. Authentification - Valide les identifiants de l'utilisateur (soit une clé API, soit un jeton d'accès OAuth 2.0) pour garantir un accès autorisé
2. Récupération de la configuration - Récupère les paramètres configuration axe spécifiques à l'organisation de l'utilisateur, y compris :
   • Standard de test d'accessibilité (par ex. WCAG 2.2 AA)
   • Version de axe-core
   • Besoins de révision / meilleures pratiques
3. Analyse basée sur le navigateur - Lance une instance de navigateur en arrière-plan avec l'extension axe DevTools montée
4. Navigation de page - Accède à l'URL fournie par l'utilisateur dans leur invitation à l'agent AI
5. Balayage d'accessibilité - Exécute une analyse d'accessibilité complète sur la page rendue en utilisant l'extension axe DevTools Browser, garantissant que l'expérience utilisateur réelle est testée (et pas seulement le HTML statique)
6. Livraison des résultats - Renvoie les résultats d'analyse complets à l'agent dans un format structuré

**Tests réactifs**

L'outil analyze prend en charge des paramètres optionnels viewportWidth et viewportHeight, vous permettant de tester des pages à des dimensions spécifiques de fenêtre. Cela est utile pour identifier les problèmes d'accessibilité qui n'apparaissent qu'à certaines tailles d'écran, comme les points de rupture pour mobiles ou tablettes.

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

Lorsque ces paramètres sont omis, le navigateur utilise la taille de fenêtre d'affichage par défaut.

Analyses de page partielle

Par défaut, l'outil analyze scanne l'ensemble de la page. Pour limiter le scan à une région spécifique, passez le paramètre optionnel selector — utile pour se concentrer sur un seul composant ou exclure des parties bruyantes et non pertinentes de la page des résultats.

• Une seule chaîne sélecteur CSS cible un élément dans la trame supérieure :

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

• Un tableau de sélecteurs CSS traverse les frontières d'iframe ou de shadow-DOM — chaque segment sélectionne l'hôte pour le suivant. Utilisez un tableau uniquement lorsque la cible se trouve à l'intérieur d'une iframe ou d'une racine d'ombre :

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

Un tableau prend en charge jusqu'à 10 segments. Si le sélecteur ne correspond à aucun élément sur la page, le scan retourne une erreur. Lorsque selector est omis, la page entière est scannée.

Demandez à votre agent IA en langage naturel — l'agent traduit votre intention en appel d'outil :

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

Interactions du navigateur avant le balayage

L'outil analyze prend en charge un tableau before optionnel d'étapes d'interaction qui après le chargement de la page mais avant le balayage d'accessibilité. Cela ouvre plusieurs scénarios de test réels :

• Pages protégées par connexion — remplir les identifiants et soumettre avant de scanner la page après connexion
• Bannières de cookies/de consentement — masquer les bannières qui pourraient autrement superposer ou obscurcir le contenu de la page
• Contenu dynamique — attendre que le contenu rendu par le client (changements de route, DOM injecté tardivement) apparaisse avant le scan

Les étapes s'exécutent dans l'ordre du tableau, dans le même contexte de navigateur que le scan, donc les cookies, localStorage, et tout changement de route déclenché par click ou fill persistent durant le scan.

Le tableau before prend en charge jusqu'à 20 étapes. Chaque étape a son propre délai d'attente de BROWSER_TIMEOUT_MS (par défaut 30000 ms) ; il n'y a pas de remplacement par étape.

Actions supportées

Exemple : Se connecter avant de scanner

Demandez à votre agent IA en langage naturel — l'agent traduit votre intention en appel d'outil :

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.

L'agent résout l'invite et appelle l'outil analyze avec une charge utile similaire à :

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

Injection de cookies

L'outil analyze prend en charge un tableau cookies optionnel qui définit les cookies sur le contexte du navigateur avant la navigation — afin qu'ils soient transmis dès la première requête vers la page. Ceci est distinct de actions before, qui s'exécutent après la navigation et ne peuvent donc pas influencer comment la requête initiale est routée. Deux utilisations courantes :

• Routage d'environnement — définissez un cookie de sélecteur de branche de mise en scène ou de fonctionnalité qu'une couche de périphérie ou de CDN lit pour décider quelle version du site servir.
• Sessions pré-authentifiées — injecter un cookie de session valide pour que le scan commence déjà connecté, sans avoir à passer par un formulaire de connexion via before.

Le tableau cookies supporte jusqu'à 20 cookies.

Champs de cookie

Exemple : arriver sur une page pré-authentifiée

Demandez à votre agent IA en langage naturel — l'agent traduit votre intention en appel d'outil :

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.

L'agent résout la valeur du cookie et appelle l'outil analyze avec une charge utile similaire à :

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

Principaux avantages

• **Tests dans un véritable navigateur** - Teste la page réellement rendue, pas seulement le code source, garantissant des résultats précis
• **Normes de l'organisation** - Respecte les paramètres de configuration axe de votre équipe pour un test cohérent chez tous les utilisateurs
• **Couverture complète** - S'appuie sur la plateforme axe, leader du secteur
• **Tests réactifs** - Teste à des dimensions de viewport spécifiques pour détecter des problèmes d'accessibilité liés aux points d'arrêt
• Analyses ciblées - Restreint un scan à une région spécifique, iframe ou shadow root avec le paramètre selector
• **Pages authentifiées et interactives** - Scanne les pages derrière une connexion, rejette les bannières de cookies, ou attend du contenu dynamique en utilisant les actions before
• Cookies de session et d'environnement - Atteignez déjà authentifié, ou dirigez vers un environnement spécifique, en injectant des cookies avant la navigation avec le paramètre cookies

Sortie

L'outil renvoie une réponse JSON structurée contenant :

• Toutes les violations d'accessibilité trouvées
• Niveaux de gravité des violations (critique, grave, modéré, mineur)
• Sélecteurs d'éléments spécifiques et code source
• Identifiants et descriptions des règles

L'outil remediate

L'outil remediate prend un ou plusieurs problèmes d'accessibilité identifiés par l'outil analyze ou igt et génère des conseils de remédiation contextuels et alimentés par l'IA que les agents de codage peuvent traduire en corrections de code réelles. Les problèmes sont soumis en lot, donc un seul appel peut retourner des corrections pour chaque violation trouvée sur une page.

Fonctionnalités

1. Authentification - Valide les identifiants de l'utilisateur — soit une clé API, soit un jeton d'accès OAuth 2.0 — pour garantir un accès autorisé
2. Utilisation de Crédit IA - Chaque problème du lot consomme des crédits AI de l'allocation de votre organisation, permettant l'utilisation de modèles AI avancés formés sur l'expertise approfondie en accessibilité de Deque
3. **Remédiation générée par l'IA** - Conçoit des correctifs d'accessibilité de haute qualité et exploitables que les agents de codage peuvent interpréter et mettre en œuvre dans le code source

Remédiation par lot

L'outil accepte un tableau issues. Soumettez tous les problèmes d'un seul analyze ou exécution de igt ensemble en un seul appel plutôt que d'appeler l'outil une fois par problème — un lot supporte entre 1 et 25 problèmes.

Chaque problème possède les champs suivants :

Invitez votre agent AI en langage naturel — il assemble le lot à partir des résultats de l'analyse :

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

L'agent résout l'invite et appelle l'outil remediate avec une charge utile similaire à :

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

Sortie

L'outil retourne un tableau de résultats par problème, chacun étant référencé à son entrée par id. Un résultat a l'une des deux formes :

• Succès — status: "ok", avec un objet remediation contenant une description générale, les étapes de remédiation, et une correction de code concrète
• Erreur — status: "error", avec un objet error (code et message) pour un problème qui n'a pas pu être remédié

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

Les résultats sont indépendants : un échec sur un problème ne bloque pas les recommandations pour les autres.

Utilisation de crédits

L'outil remediate fait partie de Système de gestion des crédits d'IA. Chaque problème dans un lot consomme des crédits de l'allocation mensuelle de votre organisation. Les administrateurs peuvent suivre l'utilisation des crédits via le portail de compte axe.

L'outil igt

L'outil igt exécute les Tests Guidés Intelligents Automatisés (IGTs) de Deque de Deque contre une page web depuis votre IDE. Là où l'extension de navigateur axe DevTools guide normalement un développeur à travers un IGT avec des invites manuelles, l'outil igt exécute le test automatiquement et renvoie des résultats structurés sur lesquels un agent de codage peut agir.

Aujourd'hui, l'outil supporte les IGT Clavier, qui évaluent si les éléments interactifs sur une page peuvent être atteints et opérés uniquement à l'aide du clavier.

Fonctionnalités

1. Authentification - Valide les identifiants de l'utilisateur — soit une clé API ou un jeton d'accès OAuth 2.0 — pour garantir un accès autorisé
2. Exécution Basée sur le Navigateur - Teste dans la même instance Chromium avec l'extension axe DevTools montée que l'outil analyze utilise
3. Navigation de page - Navigue vers l'URL fournie par l'utilisateur dans son invitation à l'agent IA
4. IGT Clavier Automatisé - Parcourt les onglets de la page pendant que l'IA analyse chaque arrêt d'onglet, évaluant l'ordre de mise au point et l'opérabilité du clavier—aucune saisie manuelle requise
5. Livraison des résultats - Renvoie les résultats structurés à l'agent

Utilisation

L'outil accepte un url et un tableau igtTools indiquant quels IGT exécuter. Le seul IGT actuellement pris en charge est celui du clavier :

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

Incitez votre agent AI avec un langage naturel—l'agent traduit votre intention en appel de l'outil :

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

Interactions du Navigateur Avant Test

Comme l'outil analyze, igt accepte un tableau optionnel before d'étapes d'interaction qui s'exécutent après le chargement de la page mais avant que le test guidé ne soit déclenché. Cela vous permet de mener un test guidé sur des pages nécessitant une connexion, de fermer des bannières de cookies ou d'attendre l'apparition de contenu dynamique.

Les étapes s'exécutent dans le même contexte de navigateur du test (les cookies, localStorage et les changements de route persistent), utilisent les mêmes actions click, fill et waitFor, et sont limitées au même 20 étapes. Voir Actions supportées sous l'outil analyze pour la référence complète, y compris le traitement des valeurs sensibles de fill.value et les règles de sélecteur.

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

Sortie

L'outil retourne une réponse JSON structurée :

{
  "pageUrl": "http://localhost:3000",
  "data": {
    "keyboard": {
      "issues": [],
      "unanalyzedElements": [],
      "terminatedReason": "keyboard-trap"
    }
  }
}

• issues - Violations de l'accessibilité clavier trouvées pendant l'exécution
• unanalyzedElements - Arrêts d'onglet que l'IA n'a pas pu analyser. Ceux-ci sont rapportés séparément de issues afin qu'ils puissent être examinés manuellement, plutôt que d'être mal signalés comme réussis ou échoués.
• terminatedReason - Présente uniquement lorsque l'exécution a été interrompue avant que tous les arrêts d'onglet ne soient analysés. La valeur actuelle est "keyboard-trap", ce qui signifie que le test a rencontré un piège à clavier qu'il ne pouvait pas échapper ; les étapes restantes sont arrêtées et les arrêts d'onglet analysés jusqu'à ce point sont renvoyés dans issues.

Utilisation de crédits

L'outil igt est une fonctionnalité alimentée par l'IA et fait partie de Système de gestion des crédits d'IA. Chaque exécution consomme des crédits IA de l'allocation mensuelle de votre organisation. Les administrateurs peuvent suivre l'utilisation des crédits via le portail de compte axe.

Premiers Pas

La configuration du serveur axe MCP implique trois choix indépendants :

1. Choisir une distribution — Docker ou npm
2. Configurer l'authentification — une clé API ou OAuth 2.0
3. Configurer votre client — VS Code avec Copilot, Cursor ou **Claude Code**

Pour les variables d'environnement et les instructions recommandées pour l'agent AI, voir Référence de Configuration. Si quelque chose ne va pas, voir Dépannage.

Exemples d'invites

Assurer l'appel des outils attendus

Dans de nombreux IDE, utiliser la syntaxe suivante (préfixe "#") garantira que les outils du server axe MCP sont appelés comme prévu :

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

Analyser une URL localhost pour les problèmes d'accessibilité :

Analyze http://localhost:3000 for accessibility issues

Analyse avec remédiation :

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

Analyser une page derrière une connexion :

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.

Ignorer une bannière de cookies avant de scanner :

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

Scanner une page avec un cookie de session injecté :

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

Pour des questions, problèmes, ou retours concernant le serveur axe MCP :

• Support technique: helpdesk@deque.com
• Demandes générales: helpdesk@deque.com
• Questions de vente: sales@deque.com

FAQ Sécurité et confidentialité

Le serveur axe MCP capture-t-il ou stocke-t-il notre code source ?

Non. Le serveur MCP axe ne capture ni ne stocke votre code source dans aucune base de données ou stockage persistant.

Lorsque l'outil analyze est exécuté, la réponse inclut le code source HTML des éléments présentant un problème d'accessibilité à des fins de contexte et de débogage. Cependant, ces données :

• Ne sont renvoyées que dans la réponse immédiate de l'API à votre agent IA
• Ne sont jamais conservées dans les bases de données gérées par Deque
• Restent dans votre environnement de développement local
• Sont supprimées après la fin de l'analyse

Combien de temps les résultats des tests MCP résident-ils sur l'infrastructure gérée par Deque ?

Les résultats des tests Ils ne résident pas. MCP ne sont pas stockés dans une base de données ou un système de stockage géré par Deque.

L'outil analyze :

• Fonctionne entièrement sur votre machine — dans un conteneur Docker, ou en tant que processus local Node.js avec la distribution npm
• Retourne les résultats directement à votre agent IA
• N'envoie pas les résultats d'analyse aux serveurs Deque

La seule exception est lorsque vous appelez l'outil remediate, qui peut inclure des métadonnées minimales de violation (voir ci-dessous) pour générer des conseils de correction alimentés par l'IA.

Quelles données sont envoyées aux serveurs Deque ?

Uniquement lors de l'utilisation de l'outil remediate :

Les données suivantes sont envoyées au point de terminaison de remédiation IA de Deque pour générer des conseils de correction :

• Identifiant de règle - La règle d'accessibilité spécifique qui a été violée
• HTML de l'élément - Le balisage HTML de (des) élément(s) concerné(s)
• Métadonnées des problèmes - Description de la violation et conseils de remédiation de axe-core

Ces données sont utilisées exclusivement pour générer des conseils de correction et ne sont pas stockées à long terme dans les bases de données de Deque.

L'outil analyze n'envoie aucune donnée aux serveurs Deque au-delà des demandes d'authentification (validation de votre clé API ou jeton OAuth 2.0).

Quel niveau d'accès l'agent IA doit-il avoir pour fonctionner ?

L'agent IA (Claude, Copilot, Cursor, etc.) doit avoir accès à :

1. Communication du serveur MCP - L'agent doit pouvoir appeler les outils du serveur MCP via le Model Context Protocol

2. Données de réponse de l'outil - L'agent reçoit :

   • Données de violation d'accessibilité provenant des appels analyze
   • Conseils de remédiation provenant des appels remediate
   • Ces données sont nécessaires à l'agent pour comprendre les problèmes et générer des corrections de code

3. Votre code source (optionnel) - Si vous souhaitez que l'agent applique automatiquement des correctifs de code, il a besoin d'accéder à vos fichiers de code source

• Ceci est standard pour les assistants de codage IA dans les IDE (VS Code, Cursor, etc.)
• Pas nécessaire si vous utilisez uniquement les outils pour l'analyse et les conseils (par exemple, via l'application Claude pour ordinateur)

Le serveur MCP lui-même doit avoir accès à :

• Les URL que vous spécifiez pour le test (prend en charge à la fois local et distant)
• Vos identifiants axe : soit une clé API (générée dans le portail de compte axe) ou un jeton d'accès OAuth 2.0 (obtenu via @deque/axe-auth) ; fournis via une variable d'environnement

Important : Le serveur MCP fonctionne localement sur votre machine — dans un conteneur Docker, ou comme un processus Node.js avec la distribution npm. Il ne nécessite pas un accès large au système de fichiers ni de privilèges élevés.

Meilleures pratiques

• Sécurité des identifiants - Stockez vos AXE_API_KEY ou AXE_ACCESS_TOKEN comme une variable d'environnement, pas dans le code. Avec OAuth 2.0, @deque/axe-auth garde les jetons dans votre trousseau de clés de l'OS et injecte un nouveau jeton d'accès au démarrage, de sorte qu'aucun secret de longue durée n'a besoin de résider dans votre configuration
• Tests locaux - Testez des URLs de développement local (localhost) ou de pré-production pour garder du code sensible isolé
• Isolement du réseau - Le serveur MCP ne communique qu'avec :
  • les URLs que vous demandez explicitement d'analyser
  • Serveurs Deque pour l'authentification (validation de la clé API ou du jeton OAuth 2.0) et la remédiation (lorsqu'elle est appelée)
  • votre agent IA local via le protocole MCP
• Revoir avant d'appliquer - Revisitez toujours les modifications de code générées par l'IA avant de les intégrer dans votre base de code