**axe MCP Server**

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

Panoramica

Il Server axe MCP è un server Model Context Protocol (MCP) che integra il testing di accessibilità di livello enterprise direttamente nel tuo flusso di lavoro di sviluppo. Basato sulla consolidata piattaforma axe, consente agli sviluppatori di eseguire scansioni di accessibilità complete e ricevere guide di correzione esperta senza lasciare il loro IDE.

Il server fornisce tre funzionalità - analyze, remediate, e igt.

Questi strumenti si integrano perfettamente con i client compatibili MCP (come Claude Desktop, VS Code con Copilot, o Cursor) e rispettano le impostazioni di configurazione axe della vostra organizzazione.

Accesso

Il Server axe MCP è incluso nel bundle Axe DevTools per Web pacchetto. Un abbonamento che abilita l'accesso al server axe MCP si configura parlando con un rappresentante commerciale di Deque.

Strumenti e Capacità

Lo analyze Strumento

Lo analyze strumento esegue un'analisi completa dell'accessibilità delle pagine web effettuando una scansione tramite l'estensione del browser axe DevTools in un ambiente reale del browser. Funziona perfettamente con URL di sviluppo locale (es. localhost:3000) e URL di produzione remota.

Cosa Fa

  1. Autenticazione - Convalida le credenziali dell'utente (sia una chiave API che un token di accesso OAuth 2.0) per garantire l'accesso autorizzato
  2. Recupero Configurazione - Recupera la configurazione specifica dell'organizzazione dell'utente Configurazione axe , includendo:
    • Standard di Testing dell'Accessibilità (es. WCAG 2.2 AA)
    • Versione axe-core
    • Necessità di revisione / buone pratiche
  3. Analisi Basata su Browser - Avvia un'istanza del browser in background con l'estensione axe DevTools montata
  4. Navigazione della Pagina - Naviga all'URL fornito dall'utente nel loro prompt all'agente AI
  5. Scansione di Accessibilità - Esegue un'analisi completa dell'accessibilità sulla pagina visualizzata utilizzando l'estensione del browser axe DevTools, garantendo che l'esperienza utente reale sia testata (non solo l'HTML statico)
  6. Consegna dei Risultati - Restituisce i risultati dell'analisi completa all'agente in un formato strutturato

Test reattivo

Lo analyze strumento supporta opzionalmente viewportWidth e viewportHeight parametri, permettendoti di testare le pagine a dimensioni specifiche del viewport. Questo è utile per rilevare problemi di accessibilità che appaiono solo a certe dimensioni dello schermo, come i punti di interruzione di mobile o tablet.

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

Quando questi parametri vengono omessi, il browser utilizza la dimensione predefinita del viewport.

Scansioni Parziali della Pagina

Per impostazione predefinita, lo analyze strumento esegue la scansione dell'intera pagina. Per delimitare la scansione a una regione specifica, passa il parametro opzionale selector — utile per concentrarsi su un singolo componente o escludere le parti rumorose e irrilevanti della pagina dai risultati.

  • Una singola stringa di selettore CSS individua un elemento nel frame superiore:

    {
      "url": "http://localhost:3000",
      "selector": "#main"
    }
  • Un array di selettori CSS attraversa i confini di iframe o shadow-DOM — ciascun segmento seleziona l'host per il successivo. Usa un array solo quando il target si trova all'interno di un iframe o di una radice shadow:

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

Un array supporta fino a 10 segmenti. Se il selettore non corrisponde a nessun elemento sulla pagina, la scansione restituisce un errore. Quando selector è omesso, l'intera pagina viene scansionata.

Chiedi al tuo agente AI in linguaggio naturale — l'agente traduce le tue intenzioni nella chiamata allo strumento:

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

Interazioni del Browser Prima della Scansione

Lo analyze strumento supporta un'opzionale before array di passaggi di interazione che vengono eseguiti dopo il caricamento della pagina ma prima della scansione di accessibilità. Questo sblocca diversi scenari di test nel mondo reale:

  • Pagine con accesso limitato — inserire le credenziali e inviare prima di eseguire la scansione della pagina post-login
  • Banners sui cookie/consenso — chiudere i banner che altrimenti sovrapporrebbero o oscurerebbero il contenuto della pagina
  • Contenuto dinamico — attendere che compaia il contenuto generato dal client (cambi di rotta, DOM iniettato tardivamente) prima di eseguire la scansione

I passaggi vengono eseguiti nell'ordine dell'array, nello stesso contesto del browser della scansione, quindi i cookie, localStorage, e qualsiasi cambiamento di rotta attivato da click o fill persistono nella scansione.

Lo before supporta fino a 20 passaggi. Ogni passaggio ha il proprio timeout di BROWSER_TIMEOUT_MS (predefinito 30000 ms); non c'è sovrascrizione per singolo passaggio.

Azioni supportate
Azione Campi richiesti Campi opzionali Scopo
click selector Cliccare l'elemento che corrisponde al CSS selector (esempio, un pulsante di invio, un pulsante "Chiudi" su un banner).
fill selector, value Riempi un input che corrisponde a selector con value. Usare per credenziali, query di ricerca o campi dei moduli. Una stringa vuota cancella l'input.
waitFor selector state — uno di "visible" (predefinito), "attached", "hidden", "detached" Attendere che l'elemento che corrisponde a selector raggiunga state. Usare per condizionare il passo successivo o la scansione stessa. Selezionare un selettore che esiste solo nello stato post-interazione (esempio, un pulsante di logout o l'intestazione di un dashboard) — selettori generici come body o #app esistono già prima dell'interazione e si risolvono istantaneamente, quindi non condizionano nulla.
Esempio: Effettuare il login prima della scansione

Chiedi al tuo agente AI in linguaggio naturale — l'agente traduce le tue intenzioni nella chiamata allo strumento:

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'agente risolve il prompt e chiama lo strumento analyze con un payload simile a:

{
  "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 è considerato sensibile. Il server axe MCP non registra mai fill.value, non lo riporta mai nei messaggi di errore e non lo invia mai alla telemetria. Usare fill per qualsiasi input fornito dall'utente o segreto (password, token API, ecc.) in modo che i segreti rimangano nascosti per tutta la pipeline — e non incorporare mai valori sensibili in un selector, che appaiono nei registri e nei messaggi di errore.

note

L'agente risolve value, non il server. Il server MCP di Axe tratta value come una stringa letterale — non legge file, espande variabili d'ambiente o interpreta la sintassi dei segnaposto come ${VAR}, $VAR, o {{VAR}}. Il tuo agente AI (Claude, Copilot, Cursor, ecc.) è responsabile di convertire l'intento dell'utente in una stringa concreta prima di chiamare lo strumento.

In pratica, ciò significa:

  • Formula i prompt in modo naturale — «usa NOMEUTENTE/PASSWORD da .env.local» funziona. L'agente legge il file con i suoi strumenti del filesystem e sostituisce i valori.
  • Non incollare la sintassi dei segnaposto — scrivere value: "${USERNAME}" in un prompt farà sì che la stringa letterale ${USERNAME} venga scritta nell'input.
  • Sii esplicito sulle fonti ambigue — se dici «usa le mie credenziali salvate» senza indirizzare l'agente a un file o a una variabile d'ambiente, un agente comportato correttamente chiederà invece di indovinare. Indicalo dove cercare.
caution

Alcuni flussi di autenticazione non sono supportati. before le azioni guidano la pagina attraverso interazioni in stile Playwright in un'istanza Chromium Dockerizzata. I seguenti sono intenzionalmente fuori ambito:

  • Sfide Captcha (reCAPTCHA, hCaptcha, ecc.)
  • Codici di verifica 2FA / TOTP / SMS
  • SSO di terze parti catene di reindirizzamento (ad esempio, «Sign in with Google», pagine di login ospitate da Okta)

Quando il tuo vero flusso di login richiede uno degli elementi sopra, scansiona un punto di accesso alternativo:

  • Un cookie di sessione pre-autenticato integrato in un ambiente di staging
  • Un token di sessione o URL di bypass che il tuo team utilizza per i test automatizzati
  • Un URL di staging con autenticazione disabilitata per i test di accessibilità

Vantaggi principali

  • Test del browser reale - Testa la pagina realmente renderizzata, non solo il codice sorgente, garantendo risultati accurati
  • Standard dell'organizzazione - Rispetta le impostazioni di configurazione axe del tuo team per test coerenti su tutti gli utenti
  • Copertura completa - Sfrutta la piattaforma axe leader del settore
  • Test reattivo - Testa a specifiche dimensioni di viewport per individuare problemi di accessibilità specifici dei breakpoint
  • Scansioni Mirate - Delimita una scansione a una regione specifica, iframe o radice shadow con il parametro selector parametro
  • Pagine Autenticate e Interattive - Scansiona pagine dietro un login, chiudi i banner dei cookie o attendi il caricamento di contenuti dinamici utilizzando before azioni

Output

Lo strumento restituisce una risposta JSON strutturata contenente:

  • Tutte le violazioni dell'accessibilità riscontrate
  • Livelli di gravità delle violazioni (critico, serio, moderato, minore)
  • Selettori specifici degli elementi e codice sorgente
  • ID delle regole e descrizioni

Lo remediate Strumento

Lo remediate lo strumento prende uno o più problemi di accessibilità identificati dallo analyze o igt strumento e genera suggerimenti di correzione contestuali e basati sull'intelligenza artificiale che gli agenti di codifica possono tradurre in soluzioni di codice effettive. I problemi vengono inviati in blocco, quindi una singola chiamata può restituire correzioni per ogni violazione trovata su una pagina.

Cosa Fa

  1. Autenticazione - Valida le credenziali dell'utente — sia una chiave API che un token di accesso OAuth 2.0 — per garantire l'accesso autorizzato
  2. Crediti AI Uso - Ogni problema nel batch consuma crediti AI dall'allocazione della vostra organizzazione, consentendo l'uso di modelli avanzati di intelligenza artificiale addestrati sulla vasta esperienza di accessibilità di Deque
  3. Correzioni Generate dall'IA - Crea soluzioni di accessibilità di alta qualità e attuabili che gli agenti di codifica possono interpretare e implementare nel codice sorgente
note

Se i crediti AI sono esauriti, lo remediate strumento non funzionerà più fino a quando i tuoi crediti non saranno ripristinati (acquistandone di più o al ripristino del tuo ciclo mensile). Tuttavia, lo analyze strumento continuerà a funzionare.

Rimediazione del Batch

Lo strumento accetta un issues array. Invia tutti i problemi da un singolo analyze o igt eseguiti insieme in una sola chiamata piuttosto che chiamare lo strumento una volta per problema — un batch supporta tra 1 e 25 problemi.

Ogni problema ha i seguenti campi:

Campo Richiesto Descrizione
id Un identificatore scelto dal chiamante, unico all'interno del batch (ad esempio, l'ID della regola più un contatore: color-contrast-0). Utilizzato solo per correlare ciascun risultato al suo input.
rule L'ID della regola axe dal analyze/igt output (ad esempio, color-contrast, image-alt).
elementHtml Il frammento HTML dell'elemento che viola.
remediation Una descrizione di cosa c'è di sbagliato e cosa deve essere corretto, tratta dal sommario del problema (opzionalmente arricchita con la sua descrizione, il testo di aiuto o il ragionamento AI).
pageUrl No L'URL della pagina in via di correzione, dal analyze risposta.

Invita il tuo agente AI in linguaggio naturale — assembla il batch dai risultati dell'analisi:

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

L'agente risolve il prompt e chiama lo strumento remediate con un payload simile a:

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

Output

Lo strumento restituisce un array di risultati per problema, ciascuno riportato al suo input tramite id. Un risultato può avere una delle due forme:

  • Successostatus: "ok", con un remediation oggetto contenente una descrizione generale, i passaggi di risoluzione e una correzione del codice concreto
  • Errorestatus: "error", con un error oggetto (code e message) per un problema che non poteva essere risolto
{
  "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": "..." }
    }
  ]
}

I risultati sono indipendenti: un fallimento in un problema non blocca le indicazioni per gli altri.

Utilizzo del Credito

Lo remediate strumento fa parte del Sistema di Gestione dei Crediti AI. Ogni problema in un batch consuma crediti dalla quota mensile della tua organizzazione. Gli amministratori possono monitorare l'utilizzo dei crediti tramite il Portale Account di axe.

Lo igt Strumento

Lo igt lo strumento esegue i Test Intelligenti Guidati Automatizzati (IGT) di Deque su una pagina web dal tuo IDE. Dove l'estensione del browser axe DevTools normalmente guida uno sviluppatore attraverso un IGT con prompt manuali, il igt strumento esegue il test automaticamente e restituisce risultati strutturati su cui un agente di codifica può agire.

Oggi lo strumento supporta il IGT Tastiera, che valuta se gli elementi interattivi su una pagina possono essere raggiunti e operati utilizzando solo la tastiera.

Cosa Fa

  1. Autenticazione - Valida le credenziali dell'utente—sia una chiave API che un token di accesso OAuth 2.0—per garantire l'accesso autorizzato
  2. Esecuzione Basata su Browser - Testa nella stessa istanza di Chromium con l'estensione axe DevTools montata che lo analyze strumento utilizza
  3. Navigazione della Pagina - Naviga all'URL fornito dall'utente nel loro prompt all'agente AI
  4. IGT Tastiera Automatizzato - Passa attraverso la pagina mentre l'AI analizza ogni fermata, valutando l'ordine del focus e l'operabilità tramite tastiera—senza necessità di input manuale
  5. Consegna dei Risultati - Restituisce le scoperte strutturate all'agente

Uso

Lo strumento accetta un url e un igtTools array che indica quali IGT eseguire. Attualmente l'unico valore supportato è IGT Tastiera:

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

Prompt del tuo agente AI in linguaggio naturale—l'agente trasforma la tua intenzione nella chiamata allo strumento:

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

Interazioni del Browser Prima del Test

Come il analyze strumento, igt accetta un opzionale before array di passaggi di interazione che vengono eseguiti dopo il caricamento della pagina ma prima che il test guidato si avvii. Questo ti permette di eseguire un test guidato su pagine con accesso tramite login, respingere i banner dei cookie o attendere che il contenuto dinamico appaia prima.

I passaggi vengono eseguiti nello stesso stesso contesto del browser del test (quindi cookie, localStorage, e i cambi di percorso persistono), utilizza lo stesso click, fill, e waitFor azioni, e sono limitate allo stesso 20 passaggi. Vedi Azioni supportate sotto lo analyze strumento per il riferimento completo, inclusa la gestione dei valori sensibili di fill.value e le regole del selettore.

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

Output

Lo strumento restituisce una risposta JSON strutturata:

{
  "pageUrl": "http://localhost:3000",
  "data": {
    "keyboard": {
      "issues": [],
      "unanalyzedElements": [],
      "terminatedReason": "keyboard-trap"
    }
  }
}
  • issues - Violazioni dell'accessibilità della tastiera trovate durante l'esecuzione
  • unanalyzedElements - Fermate della tabulazione che l'AI non ha potuto analizzare. Queste vengono segnalate separatamente da issues in modo che possano essere revisionate manualmente, anziché essere erroneamente riportate come superate o non superate.
  • terminatedReason - Presenta solo quando l'esecuzione è stata interrotta prima che ogni fermata del tabulatore fosse analizzata. Il valore corrente è "keyboard-trap", il che significa che il test ha incontrato una trappola da tastiera da cui non è riuscito a uscire; i passaggi rimanenti vengono interrotti e le fermate del tabulatore analizzate fino a quel punto vengono restituite in issues.

Utilizzo del Credito

Lo igt lo strumento è una funzione basata sull'intelligenza artificiale ed è parte integrante del Sistema di Gestione dei Crediti AI. Ogni esecuzione consuma crediti di intelligenza artificiale dalla quota mensile dell'organizzazione. Gli amministratori possono monitorare l'uso dei crediti tramite il Portale dell'Account axe.

note

Se i crediti AI sono esauriti, lo igt strumento non funzionerà più fino a quando i tuoi crediti non saranno ripristinati (acquistandone di più o al ripristino del tuo ciclo mensile). Tuttavia, lo analyze strumento continuerà a funzionare.

Introduzione

Configurare il server axe MCP comporta tre scelte indipendenti:

  1. Scegli una distribuzione — Docker o npm
  2. Imposta l'autenticazione — una chiave API o OAuth 2.0
  3. Configura il tuo clientVS Code con Copilot, Cursor, o **Claude Code**

Per le variabili di ambiente e le istruzioni consigliate per l'AI-agent, consulta il Riferimento di Configurazione. Se qualcosa va storto, consulta Risoluzione dei problemi.

Esempi di prompt

Garantire il richiamo degli strumenti attesi

In molti IDE, l'uso della seguente sintassi (prefisso "#") garantirà che gli strumenti di axe MCP Server vengano chiamati come previsto:

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

Analizzare un URL localhost per problemi di accessibilità:

Analyze http://localhost:3000 for accessibility issues

Analisi con correzione:

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

Analizzare una pagina dietro un login:

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.
Analyze https://example.com for accessibility issues, but first click the
#cookie-dismiss button to dismiss the cookie consent banner.

Supporto

Per domande, problemi o feedback riguardanti axe MCP Server:

FAQ Sicurezza & Privacy

Il server axe MCP memorizza o cattura il nostro codice sorgente?

No. Il server MCP axe non acquisisce né memorizza il tuo codice sorgente in alcun database o sistema di archiviazione persistente.

Quando lo analyze strumento viene eseguito, la risposta include il codice sorgente HTML degli elementi con problemi di accessibilità per contesto e scopi di debug. Tuttavia, questi dati:

  • Vengono restituiti solo nella risposta API immediata al tuo agente AI
  • Non vengono mai memorizzati nei database gestiti da Deque
  • Rimangono all'interno del tuo ambiente di sviluppo locale
  • Vengono scartati dopo il completamento dell'analisi

Per quanto tempo i risultati dei test MCP sono conservati nell'infrastruttura gestita da Deque?

Non lo sono. I risultati dei test MCP non sono memorizzati in alcun database o sistema di archiviazione gestito da Deque.

Lo analyze strumento:

  • Funziona interamente sulla tua macchina — in un contenitore Docker, o come processo locale Node.js con la distribuzione npm
  • Restituisce direttamente i risultati al tuo agente AI
  • Non invia risultati di analisi ai server Deque

L'unica eccezione è quando si chiama lo remediate strumento, che può includere un minimo di dati sulle violazioni (vedere sotto) per generare indicazioni di correzione potenziate dall'AI.

Quali dati vengono inviati ai server Deque?

Solo quando si utilizza lo remediate strumento:

I seguenti dati sono inviati al punto finale di rimedio AI di Deque per generare indicazioni di correzione:

  • ID Regola - La specifica regola di accessibilità che è stata violata
  • HTML dell'elemento - Il markup HTML dell'elemento o degli elementi interessati
  • Metadati del problema - Descrizione della violazione e guida di rimedio da axe-core

Questi dati sono utilizzati esclusivamente per generare indicazioni di rimedio e non sono memorizzati a lungo termine nei database di Deque.

Lo analyze strumento non invia alcun dato ai server Deque oltre alle richieste di autenticazione (convalidando la tua chiave API o il token di accesso OAuth 2.0).

Quale livello di accesso è necessario affinché l'agente AI funzioni?

L'agente AI (Claude, Copilot, Cursor, ecc.) ha bisogno di accesso a:

  1. Comunicazione con il Server MCP - L'agente deve essere in grado di chiamare gli strumenti del server MCP tramite il Model Context Protocol

  2. Dati di risposta degli strumenti - L'agente riceve:

    • Dati di violazione di accessibilità da analyze chiamate
    • Guida di rimedio da remediate chiamate
    • Questi dati sono necessari per l'agente per comprendere i problemi e generare correzioni al codice
  3. Il tuo Codice (Opzionale) - Se desideri che l'agente applichi automaticamente le correzioni al codice, è necessario l'accesso ai file del tuo codice sorgente

  • Questo è standard per gli assistenti di codifica AI negli IDE (VS Code, Cursor, ecc.)
  • Non necessario se usi solo gli strumenti per analisi e guida (ad esempio, tramite l'app desktop Claude)

Il server MCP stesso ha bisogno di accesso a:

  • URL che specifichi per i test (supporta sia locali che remoti)
  • Le tue credenziali axe: o una chiave API (generata nel Portale Account axe) o un token di accesso OAuth 2.0 (ottenuto tramite @deque/axe-auth); fornite tramite variabile d'ambiente

Importante: Il server MCP viene eseguito localmente sulla tua macchina — in un contenitore Docker, o come processo Node.js con la distribuzione npm. Non richiede un ampio accesso al file system o privilegi elevati.

Best Practices

  • Sicurezza delle Credenziali - Memorizza la tua AXE_API_KEY o AXE_ACCESS_TOKEN come variabile d'ambiente, non nel codice. Con OAuth 2.0, @deque/axe-auth mantiene i token nella keychain del tuo sistema operativo e inietta un nuovo token di accesso all'avvio, quindi non è necessario mantenere segreti a lungo termine nella tua configurazione
  • Test Locale - Testa gli URL di sviluppo locali (localhost) o di staging per mantenere isolato il codice sensibile pre-produzione
  • Isolamento della Rete - Il server MCP comunica solo con:
    • URL che richiedi esplicitamente di analizzare
    • Server Deque per l'autenticazione (convalida della chiave API o del token OAuth 2.0) e rimedio (quando chiamato)
    • Il tuo agente AI locale attraverso il protocollo MCP
  • Revisione Prima di Applicare - Revisiona sempre le modifiche al codice generate dall'AI prima di integrarle nel tuo codebase