**server axe MCP**

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

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 Axe DevTools pour Web forfait. Un abonnement permettant l'accès au serveur axe MCP est mis en place en discutant avec un représentant commercial de Deque.

Outils et capacités

L'outil analyze outil

L'outil analyze réalise une analyse d'accessibilité complète des pages Web en effectuant un balayage grâce à l'extension du navigateur axe DevTools dans un environnement de navigateur réel. Il fonctionne sans problème avec les URL de développement local (par exemple, localhost:3000) et les URL de production distantes.

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 la configuration axe spécifique à 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 - Navigue vers l'URL fournie par l'utilisateur dans leur invite à l'agent IA
  5. Balayage d'accessibilité - Exécute une analyse complète de l'accessibilité sur la page rendue en utilisant l'extension du navigateur axe DevTools, garantissant que l'expérience utilisateur réelle est testée (pas seulement le HTML statique)
  6. Livraison des résultats - Retourne des résultats d'analyse complète à 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 les pages à des dimensions spécifiques de la fenêtre d'affichage. Ceci est utile pour détecter les problèmes d'accessibilité qui n'apparaissent qu'à certaines tailles d'écran, comme les points d'arrêt pour mobile ou tablette.

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 toute la page. Pour limiter l'analyse à 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 le cadre supérieur :

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

  • Un tableau de sélecteurs CSS traverse les frontières iframe ou 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 shadow :

    {
  "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, l'analyse retourne une erreur. Quand 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 s'exécutent après le chargement de la page mais avant le balayage d'accessibilité. Cela débloque plusieurs scénarios de test réels :

  • Pages protégées par connexion — renseigner les identifiants et soumettre avant de scanner la page post-connexion
  • Bannières de cookies/de consentement — ignorer les bannières qui couvriraient ou obscurciraient autrement le contenu de la page
  • Contenu dynamique — attendre que le contenu rendu côté client (modifications de route, DOM injecté tardivement) apparaisse avant de scanner

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 dans le scan.

L'outil before prend en charge jusqu'à 20 étapes. Chaque étape dispose de 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
Action Champs requis Champs facultatifs Objectif
click selector Cliquez sur l'élément correspondant au CSS selector (par ex. un bouton de soumission, un bouton « Ignorer » sur une bannière).
fill selector, value Remplir une entrée correspondant à selector avec value. Utiliser pour les identifiants, les requêtes de recherche ou les champs de formulaire. Une chaîne vide efface la saisie.
waitFor selector state — l'un de "visible" (par défaut), "attached", "hidden", "detached" Attendre que l'élément correspondant à selector atteigne state. Utiliser pour cadrer l'étape suivante ou le scan lui-même. Choisissez un sélecteur qui existe uniquement dans l'état post-interaction (par ex. un bouton de déconnexion ou un titre de tableau de bord) — les sélecteurs génériques comme body ou #app existent déjà avant l'interaction et se résolvent instantanément, ils ne cadreront donc rien.
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" }
  ]
}
important

fill.value est traité comme sensible. L'outil axe MCP Server ne journalise jamais fill.value, ne l'affiche jamais dans les messages d'erreur, et ne l'envoie jamais en télémétrie. Utilisez fill pour toute saisie utilisateur ou entrée secrète (mots de passe, jetons API, etc.) afin que les secrets restent masqués dans tout le pipeline — et n'intégrez jamais de valeurs sensibles dans un selector, qui **apparaît** dans les journaux et les messages d'erreur.

note

**L'agent résout** value, pas le serveur. Le serveur axe MCP traite value comme une chaîne littérale — il ne **pas** lit les fichiers, n'expanse pas les variables d'environnement, et n'interprète pas la syntaxe des espaces réservés comme ${VAR}, $VAR, ou {{VAR}}. Votre agent IA (Claude, Copilot, Cursor, etc.) est chargé de convertir l'intention de l'utilisateur en une chaîne concrète avant d'appeler l'outil.

En pratique, cela signifie :

  • **Formulez des invites naturellement** — « utiliser NOM_UTILISATEUR/MOT_DE_PASSE de .env.local» fonctionne. L'agent lit le fichier avec ses propres outils de système de fichiers et remplace les valeurs.
  • **Ne collez pas de syntaxe d'espace réservé** — écrire value: "${USERNAME}" dans une invite entraînera la saisie de la chaîne littérale ${USERNAME} dans l'entrée.
  • **Soyez explicite sur les sources ambiguës** — si vous dites « utiliser mes identifiants enregistrés » sans indiquer un fichier ou une variable d'environnement à l'agent, un agent bienveillant demandera plutôt que de deviner. Dites-lui où chercher.
caution

**Certains flux d'authentification ne sont pas pris en charge.** before les actions pilotent la page à travers des interactions de style Playwright dans une instance de Chromium dockerisée. Les éléments suivants sont volontairement en dehors du périmètre :

  • **Captcha** défis (reCAPTCHA, hCaptcha, etc.)
  • **2FA / TOTP / SMS** codes de vérification
  • **SSO tiers** chaînes de redirection (p.ex., « Se connecter avec Google », pages de connexion hébergées par Okta)

Quand votre flux d'authentification réel nécessite l'un des éléments ci-dessus, recherchez un point d'entrée alternatif :

  • Un **cookie de session pré-authentifié** intégré dans un environnement de préproduction
  • Un **jeton de session** ou **URL de contournement** utilisé par votre équipe pour les tests automatisés
  • Un **URL de préproduction avec authentification désactivée** pour les tests d'accessibilité

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 des tests cohérents auprès de tous les utilisateurs
  • **Couverture complète** - Utilise la plateforme axe leader du secteur
  • **Tests réactifs** - Testez à des dimensions de fenêtre spécifiques pour détecter les problèmes d'accessibilité spécifiques aux points de rupture
  • Analyses ciblées - Limitez une analyse à une région spécifique, une iframe, ou une racine shadow avec le selector paramètre
  • **Pages authentifiées et interactives** - Analysez les pages derrière une connexion, fermez les bannières de cookies ou attendez le contenu dynamique en utilisant before des actions

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 outil

L'outil remediate outil 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 par lot, de sorte qu'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. Crédit IA Utilisation - 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 à partir de l'expertise approfondie de Deque en matière d'accessibilité.
  3. **Remédiation générée par l'IA** - Conçoit des corrections d'accessibilité de haute qualité et exploitables que les agents de codage peuvent interpréter et mettre en œuvre dans le code source.
note

Si les crédits d'IA sont épuisés, l' remediate outil ne fonctionnera plus jusqu'à ce que vos crédits soient rétablis (soit en en achetant plus, soit une fois votre cycle mensuel réinitialisé). Cependant, l' analyze outil continuera de fonctionner.

Remédiation par lot

L'outil accepte un issues tableau. Soumettez tous les problèmes d'une même analyze ou igt exécution ensemble en un seul appel au lieu 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 :

Champ Obligatoire Description
id Oui Un identifiant choisi par l'appelant, unique au sein du lot (par exemple, l'ID de la règle plus un compteur : color-contrast-0). Utilisé uniquement pour mettre chaque résultat en corrélation avec son entrée.
rule Oui L'ID de la règle axe du analyze/igt sortie (par exemple, color-contrast, image-alt).
elementHtml Oui L'extrait HTML de l'élément en infraction.
remediation Oui Une description de ce qui ne va pas et de ce qui doit être corrigé, tirée du résumé du problème (enrichi éventuellement avec sa description, son texte d'aide ou son raisonnement AI).
pageUrl Non L'URL de la page en cours de remédiation, à partir de la analyze réponse.

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 renvoie un tableau de résultats par problème, chacun associé à 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 résolu
{
  "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 outil fait partie du Système de gestion des crédits d'IA. Chaque problème d'un lot consomme des crédits de l'allocation mensuelle de votre organisation. Les administrateurs peuvent surveiller l'utilisation des crédits via le portail de compte axe.

L'outil igt outil

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

Aujourd'hui, l'outil prend en charge le IGT Clavier, qui évalue si les éléments interactifs d'une page peuvent être atteints et activés en utilisant uniquement le clavier.

Fonctionnalités

  1. Authentification - Valide les informations d'authentification de l'utilisateur—soit une clé API, soit 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 de Chromium avec l'extension axe DevTools montée que le analyze outil utilise
  3. Navigation de page - Navigue vers l'URL fournie par l'utilisateur dans leur invite à l'agent IA
  4. IGT Clavier Automatisé - Parcourt la page tout en analysant chaque point d'arrêt à l'aide de l'IA, évaluant l'ordre de mise au point et l'opérabilité du clavier—aucune entrée manuelle requise
  5. Livraison des résultats - Renvoie des conclusions structurées à l'agent

Utilisation

L'outil accepte un url et un igtTools tableau nommant quels IGTs exécuter. L'IGT Clavier est actuellement la seule valeur supportée :

{
  "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 le analyze outil, igt accepte un before optionnel 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 d'exécuter un test guidé contre des pages protégées par connexion, de fermer des bannières de cookies, ou d'attendre que le contenu dynamique apparaisse d'abord.

Les étapes se déroulent dans le même contexte de navigateur comme le test (donc les cookies, localStorage, et les changements de route persistent), utilisent le même click, fill, et waitFor actions, et sont limitées de la même manière 20 étapes. Voir Actions supportées sous le analyze outil pour la référence complète, y compris la gestion des valeurs sensibles de fill.value et les règles de sélection.

{
  "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 d'accessibilité au clavier trouvées lors de l'exécution
  • unanalyzedElements - Points d'arrêt que l'IA n'a pas pu analyser. Ceux-ci sont signalés séparément de issues afin qu'ils puissent être examinés manuellement, plutôt que d'être signalés à tort comme réussis ou échoués.
  • terminatedReason - Présente uniquement quand l'exécution a été interrompue avant que chaque arrêt de tabulation ne soit analysé. La valeur actuelle est "keyboard-trap", ce qui signifie que le test a rencontré un piège clavier dont il ne pouvait s'échapper ; les étapes restantes sont arrêtées et les arrêts de tabulation analysés jusqu'à ce point sont renvoyés dans issues.

Utilisation de crédits

L'outil igt outil est une fonctionnalité alimentée par l'IA et fait partie de la 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 surveiller l'utilisation des crédits via le Portail de compte axe.

note

Si les crédits d'IA sont épuisés, l' igt outil ne fonctionnera plus jusqu'à ce que vos crédits soient rétablis (soit en en achetant plus, soit une fois votre cycle mensuel réinitialisé). Cependant, l' analyze outil continuera de fonctionner.

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 IA, voir la 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.

Support

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

FAQ Sécurité et confidentialité

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

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

Lorsque l'outil analyze s'exécute, la réponse inclut le code source HTML des éléments avec des problèmes d'accessibilité pour le contexte et le 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 ?

Ils ne résident pas. Les résultats des tests MCP ne sont pas conservé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 ?

Seulement en utilisant 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 l'élément(s) affecté(s)
  • Métadonnées des problèmes - Description de la violation et orientation de correction 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 ne transmet aucune donnée aux serveurs Deque au-delà des requêtes d'authentification (validation de votre clé API ou jeton d'accès 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é depuis les appels analyze Appels
    • Guides de remédiation depuis les appels remediate Appels
    • 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 voulez que l'agent applique automatiquement des corrections de code, il doit avoir accès à 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) soit un jeton d'accès OAuth 2.0 (obtenu via @deque/axe-auth); fourni via une variable d'environnement

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

Meilleures pratiques

  • Sécurité des identifiants - Stockez votre AXE_API_KEY ou AXE_ACCESS_TOKEN comme variable d'environnement, pas dans le code. Avec OAuth 2.0, @deque/axe-auth garde les jetons dans le trousseau de votre système d'exploitation et injecte un nouveau jeton d'accès au démarrage, de sorte qu'aucun secret à longue durée de vie n'a besoin de vivre dans votre configuration
  • Tests locaux - Testez les URLs de développement local (localhost) ou de pré-production pour garder le 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 - Vérifiez toujours les modifications de code générées par l'IA avant de les valider dans votre code source

Is this page helpful?

Help us improve this page

Still need help?