Outil d'analyse

L'outil analyze effectue une analyse complète de l'accessibilité des pages Web en effectuant un scan via l'extension navigateur Axe DevTools 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 distantes.

Ce que ça fait

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 d'Axe spécifiques à l'organisation de l'utilisateur, y compris :
   • Standard de test d'accessibilité (par exemple, WCAG 2.2 AA)
   • version d'axe-core
   • Nécessite un examen / meilleures pratiques
   • préréglage Règles avancées
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 invite à l'agent IA
5. Scan d'accessibilité - Effectue une analyse complète de l'accessibilité de la page rendu en utilisant l'extension navigateur Axe DevTools, veillant à ce que l'expérience utilisateur réelle soit testée (pas seulement le HTML statique)
6. Diffusion des résultats - Retourne les résultats d'analyse complets à l'agent dans un format structuré

Test réactif

L'outil analyze prend en charge les paramètres optionnels viewportWidth et viewportHeight, vous permettant de tester des pages à des dimensions de fenêtre spécifiques. Cela est utile pour détecter les problèmes d'accessibilité qui n'apparaissent qu'à certaines tailles d'écran, comme les points d'arrêt 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. En passant viewportWidth seul, la hauteur par défaut est de 1080 ; viewportHeight exige que viewportWidth soit défini. Chaque dimension peut aller jusqu'à 7680 pixels.

Scans de page partiels

Par défaut, l'outil analyze scanne la page entière. 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 de sélecteurs CSS cible un élément dans le cadre supérieur :

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

• Un tableau de sélecteurs CSS passe à travers 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 dans une iframe ou 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 de la page, le scan renvoie 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 avec le navigateur avant le scan

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

• Pages protégées par connexion — remplissez les identifiants et soumettez avant de scanner la page post-connexion
• Bannières de cookies/de consentement — rejetez les bannières qui superposeraient ou cacheraient autrement le contenu de la page
• Contenu dynamique — attendez que le contenu généré par le client (changement de route, DOM injecté tardivement) apparaisse avant de scanner

Les étapes s'exécutent dans l'ordre du tableau, dans le même contexte du navigateur comme le scan, de sorte que les cookies, localStorage et tout changement de route déclenché par click ou fill persistent lors du 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 prises en charge

Exemple : Connexion avant le scan

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 semblable à :

{
  "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 facultatif cookies qui définit des cookies sur le contexte du navigateur avant la navigation — ainsi, ils accompagnent la toute première requête vers la page. Cela se distingue de before actions, qui s'exécutent après la navigation et ne peuvent donc pas influencer la façon dont la requête initiale est routée. Deux utilisations communes :

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

Le tableau cookies prend en charge jusqu'à 20 cookies.

Champs de cookie

Exemple : Atterrir 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 voir ce qui a été analysé. Passez le paramètre optionnel screenshot pour opter — 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 des pages chargées de photos :

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

L'image revient comme un 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 grande viewportHeight (par exemple 4096) afin que la zone visible couvre ce que vous souhaitez voir.
• La page telle qu'elle était juste avant le début de l'analyse. La capture se fait juste avant axe.run(), donc les modifications du DOM qui se produisent pendant l'analyse — re-rendus SPA, mises à jour useEffect, animations, requêtes en cours — ne sont pas reflétées. Sur les applications monopage, 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 réduisent les résultats d'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.

Enregistrement des captures d'écran sur le disque

La capture d'écran peut également être écrite dans un fichier, ce qui est un moyen fiable de voir une capture dans un client qui n'affiche 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 de fichier :

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

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

L'enregistrement s'applique à seulement les analyses réussies. Si l'analyse échoue après la capture de l'écran, l'image est renvoyée en ligne avec l'erreur, quel que soit inline, et n'est jamais écrite sur le disque.

Lorsque la capture échoue

La capture d'écran est un effort maximal et ne fait jamais échouer une analyse. Si la capture dépasse le temps imparti, l'analyse renvoie tout de même ses résultats avec une note dans le tableau messages de la réponse :

Screenshot capture failed: <reason>

Si analyse elle-même échoue après la prise de l'écran, l'image est renvoyée avec la réponse d'erreur de toute façon — l'état visuel de la page au moment où les choses ont mal tourné est généralement la preuve de débogage la plus utile que vous ayez.

Règles avancées

Au-delà de l'ensemble 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 avancés pour détecter des problèmes qu'axe-core ne peut pas détecter seul, tels que 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 d'Axe de votre organisation, et — là où votre administrateur le permet — peut être remplacé par serveur avec AXE_ADVANCED_RULES ou par analyse avec l'argument advancedRules :

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

Chaque réponse rapporte le préréglage qui a effectivement été utilisé et d'où il provient :

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

Les règles avancées sont fournies avec votre abonnement Axe DevTools for Web — le même qui vous donne l'Axe MCP Server. Elles ajoutent environ 15 à 20 secondes à une analyse, consomment Crédits IA, et sont le seul cas où analyze envoie des données de page (une capture d'écran de page entière plus 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 de confidentialité.

Principaux Avantages

• Test sur Navigateur Réel - 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 Axe Configuration de votre équipe pour des tests cohérents entre tous les utilisateurs
• Couverture Complète - Exploite la plateforme Axe, leader de l'industrie
• Test réactif - Test sur des dimensions de viewport spécifiques pour identifier les problèmes d'accessibilité spécifiques aux points d'arrêt
• Analyses Ciblées - Limitez une analyse à une région spécifique, un iframe ou un shadow root avec le paramètre selector
• Pages Authentifiées et Interactives - Analyser des pages derrière une connexion, fermer les bannières de cookies, ou attendre du contenu dynamique en utilisant les actions before
• Cookies de Session et d'Environnement - Arrivez déjà authentifié, ou redirigez 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 avec le rapport avec le paramètre screenshot, y compris lorsque l'analyse échoue
• Règles avancées - Détecter des problèmes nécessitant un raisonnement visuel ou contextuel, avec un seuil de confiance contrôlé par votre organisation
• Tests Guidés Intelligents - Exécuter les IGT Clavier, Éléments Interactifs et Dialogues Modaux sur la même page en un seul appel avec 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, sérieux, 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 utilisé et sa provenance
• Un tableau messages contenant toutes les notes sur l'exécution (par exemple, une échec de capture d'écran, une exécution dégradée de règles avancées, ou le chemin où une capture d'écran a été enregistrée)

Lorsque screenshot est défini, un bloc de contenu image suit le rapport. Lorsque igtTools est défini, les résultats IGT sont renvoyés avec les résultats Axe, indexés par nom d'IGT.