**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. analyze exécute également Tests Guidés Intelligent Automatisés sur la page qu'il scanne, ce qui remplace l'outil igt autonome désormais obsolète.

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
   • Règles Avancées prédéfini
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 - Navigue vers l'URL fournie par l'utilisateur dans son invitation à l'agent IA
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 les deux paramètres sont omis, le scan s'exécute à 1000×1080. Passer viewportWidth seul définit par défaut la hauteur à 1080 ; viewportHeight nécessite d'avoir défini viewportWidth. Chaque dimension peut atteindre jusqu'à 7680 pixels.

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 before actions, 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"
    }
  ]
}

Captures d'écran

L'outil analyze peut renvoyer une capture d'écran de la page avec le rapport de violation, pour que vous puissiez voir ce qui a été scanné. Passez le paramètre facultatif screenshot pour participer — un objet vide suffit :

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

PNG est le format par défaut. Réglez format sur "jpeg" pour une image plus petite sur les pages riches en photos :

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

L'image revient sous forme de bloc de contenu d'image MCP standard, après le rapport de violation.

Ce que montre la capture d'écran

• Le viewport visible, pas la page complète. Le contenu en dessous de la ligne de flottaison n'est pas inclus. Pour capturer plus de la page, passez une viewportHeight grande (par exemple, 4096) afin que la zone visible couvre ce que vous voulez voir.
• La page telle qu'elle était juste avant le début du scan. La capture se fait juste avant axe.run(), donc les changements de DOM qui se produisent pendant le scan — réaffichages de SPA, mises à jour useEffect, animations, requêtes en cours — ne sont pas reflétés. Dans les applications à page unique, ce décalage est fréquent.

Coût et support client

Que l'image s'affiche en ligne dépend de votre client MCP. Le serveur renvoie toujours un bloc d'image conforme aux spécifications, mais certains clients masquent les résultats des outils ou omettent les aperçus d'image — VS Code avec Copilot l'affiche, tandis que Cursor et Claude Desktop peuvent ne pas le faire. Un aperçu manquant est une limitation d'affichage côté client, pas une capture échouée.

Enregistrer les captures d'écran sur disque

La capture d'écran peut également être écrite dans un fichier, ce qui est le moyen fiable de voir une capture dans un client qui ne rend pas les images en ligne. Réglez saveTo sur un chemin absolu :

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

Ou réglez save: true pour laisser le serveur choisir le nom du fichier :

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

Le chemin absolu qui a été écrit revient dans le tableau messages de la réponse, afin que votre agent puisse vous indiquer où trouver le fichier.

La sauvegarde s'applique à scans réussis uniquement. Si le scan échoue après que la capture d'écran ait été réalisée, l'image est retournée en ligne avec l'erreur indépendamment de inline, et n'est jamais écrite sur disque.

Quand la capture échoue

La capture d'écran est faite au mieux et n'échoue jamais un scan. Si la capture dépasse le délai, le scan renvoie quand même ses résultats avec une note dans le tableau messages de la réponse :

Screenshot capture failed: <reason>

Si le scan lui-même échoue après que la capture d'écran ait été prise, l'image est quand même retournée avec la réponse d'erreur — l'état visuel de la page au moment où il y a eu un problème est généralement la preuve de débogage la plus utile que vous ayez.

Règles Avancées

Au-delà du jeu de règles standard axe-core, l'outil analyze peut exécuter Règles Avancées — des tests automatisés qui utilisent des captures d'écran, la vision par ordinateur et des modèles de langage étendus pour détecter des problèmes que axe-core seul ne peut pas, comme des en-têtes qui ressemblent à des en-têtes ou des images informatives avec un texte alternatif peu utile.

Le préréglage exécuté est régi par le configuration axe de votre organisation et — là où votre administrateur le permet — peut être remplacé par serveur avec AXE_ADVANCED_RULES ou par scan avec l'argument advancedRules :

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

Chaque réponse indique le préréglage qui a réellement été exécuté et d'où il provient :

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

Les règles avancées sont incluses avec votre abonnement aux outils axe DevTools pour le Web — le même qui vous offre le serveur axe MCP. Elles ajoutent environ 15 à 20 secondes à une analyse, consomment Crédits IA, et constituent le seul cas où analyze envoie des données de page (une capture d'écran complète et la structure de la page) à Deque pour évaluation. Voir Règles avancées pour les préréglages, la priorité, les messages de dégradation, et les détails sur la confidentialité.

Tests guidés intelligents

L'outil analyze peut également exécuter les Tests Guidés Intelligents Automatisés (IGTs) de Deque de Deque sur la même page lors du même appel. Passez le tableau optionnel igtTools nommant quels TGI exécuter — IGT Clavier est actuellement la valeur prise en charge :

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

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

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

Chaque TGI demandé s'exécute en séquence après l'analyse axe, sur la même page, dans le même navigateur, à la même largeur de fenêtre. Tout ce qui prépare la page s'exécute une fois et se prolonge dans les deux : before actions, injection de cookies, et paramètres de la fenêtre.

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

Structure de la réponse

Définir igtTools change la structure de data. Sans cela, data est le tableau des problèmes axe. Avec cela, data contient axe et igt en tant que clés égales, avec une entrée igt par outil demandé :

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

• status — "complete" ou "error". Vérifiez cela avant de lire quoi que ce soit d'autre : issues et igtElements sont présents uniquement sur "complete", et error uniquement sur "error".
• issues — les problèmes d'accessibilité trouvés par le TGI. Le nombre de problèmes est la longueur de ce tableau.
• igtElements — l'élément chaque traité par le TGI, pas une liste de problèmes. Les entrées avec analysisFailed: true n'ont pas pu être analysées par l'IA et devraient être examinées manuellement. Chaque entrée est réduite aux seuls champs d'identification : vnodeId, selector, tagName, role, accessibleName, states et analysisFailed, présents uniquement lorsque l'élément les contient.
• terminatedReason — présent uniquement lorsque l'exécution s'est arrêtée prématurément, ce qui signifie que les résultats sont partiels. "keyboard-trap" signifie que le test a rencontré un piège de focus d'où il ne pouvait pas s'échapper ; "insufficient-credits" signifie que le compte a épuisé ses crédits IA en cours d'exécution.

Les échecs sont isolés

Un TGI qui échoue ne fait **pas** échouer l'appel et n'affecte jamais les résultats axe. L'échec est signalé comme celui de cet outil avec un message en status: "error", tandis que les résultats axe reviennent normalement — y compris lorsque le paramètre d'apprentissage automatique de votre organisation est désactivé, auquel cas la partie TGI explique que l'apprentissage automatique est requis.

Utilisation des crédits

Les TGI sont alimentés par l'IA et font partie du Système de gestion des crédits d'IA. Chaque exécution consomme des crédits IA de l'allocation mensuelle de votre organisation ; l'analyse axe elle-même ne le fait pas. Demandez des TGI délibérément plutôt que de les ajouter à chaque analyse.

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
• Contexte visuel - Retourner une capture d'écran de la page en plus du rapport avec le paramètre screenshot, y compris lorsqu'une analyse échoue
• Règles avancées - Détecter les problèmes nécessitant un raisonnement visuel ou contextuel, à un seuil de confiance que votre organisation contrôle
• Tests guidés intelligents - Exécuter un TGI sur la même page avec le même appel et le paramètre igtTools

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
• Un bloc advancedRules rapportant le préréglage Règles avancées exécuté et d'où il provient
• Un tableau messages contenant des notes sur l'exécution (par exemple, une capture d'écran échouée, une exécution des règles avancées dégradée, ou le chemin où une capture d'écran a été enregistrée)

Lorsque screenshot est défini, un bloc de contenu d'image suit le rapport. Lorsque igtTools est défini, les résultats TGI sont retournés avec les résultats axe, indexés par nom d'outil.

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 ou 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 de Deque sur une page web en tant qu'appel autonome. Tout ce qu'il fait, analyze le fait désormais dans le même appel que l'analyse d'accessibilité — voir Tests guidés intelligents pour l'utilisation et la consommation de crédits, qui sont les mêmes pour les deux.

L'objet de résultat par test est également le même pour les deux — status, issues, igtElements, et un terminatedReason optionnel, comme décrit dans Structure de la réponse. Seule l'enveloppe diffère : igt retourne ses résultats directement sous data, indexés par nom de test (data.keyboard), tandis que analyze les imbrique sous data.igt aux côtés de data.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**

Les utilisateurs de Claude Code peuvent sauter ces étapes avec le plugin d'accessibilité axe, qui enregistre le serveur et ajoute des commandes slash pour la configuration, les instructions d'agent et l'exécution complète du cycle de remédiation.

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.

Capturer une capture d'écran de la page :

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

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

Il y a deux exceptions :

• L'outil remediate, qui peut inclure des métadonnées de violation minimales (voir ci-dessous) pour générer des conseils de correction basés sur l'IA.
• Règles avancées, lorsqu'un préréglage actif est en vigueur. Les règles avancées sont évaluées côté serveur, donc analyze télécharge une capture d'écran complète de la page et la structure de la page dont les règles ont besoin. Voir Ce qui est envoyé à Deque.

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.

Lorsque vous utilisez Règles avancées :

Les règles avancées sont évaluées par les services ML et LLM de Deque plutôt que dans le navigateur local, donc une analyse avec un préréglage actif envoie :

• Une capture d'écran complète de la page en cours d'analyse
• Structure de la page et styles calculés — la charge utile d'évaluation dont les règles avancées ont besoin pour raisonner sur la mise en page, le contraste et les en-têtes

Cette capture est indépendante du paramètre optionnel screenshot de l'outil analyze : omettre ce paramètre ne l'empêche pas. Définissez le préréglage des règles avancées sur disabled — par analyse, par serveur ou à l'échelle de l'organisation dans configuration axe — pour les pages dont le contenu ne doit pas quitter votre environnement.

Sinon, l'outil analyze n'envoie aucune donnée aux serveurs Deque au-delà des demandes d'authentification (validation de votre clé API ou jeton d'accès OAuth 2.0) et de la récupération de la configuration axe de votre organisation.

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