Il percorso verso il VPAT inizia nell’editor. Colleghi il nostro MCP

Ecco una cosa che vediamo ripetersi continuamente nei dati della piattaforma. Un cliente esegue un audit, legge i risultati, li condivide, e mesi dopo una quota significativa di quei problemi è ancora aperta. Nessuno ha contestato nulla. Semplicemente, il lavoro non è stato fatto.

Per molto tempo ho pensato che fosse una questione di priorità e che la soluzione fosse una valutazione migliore della gravità. In realtà è soprattutto un problema logistico. Il problema si trova nella dashboard di DevAlly e la persona che può correggerlo è nel proprio editor: passare dall’una all’altro significa fermarsi, trovare la scheda, trovare il prodotto, trovare il problema e leggerne abbastanza da ricostruire cosa intendesse davvero lo strumento di verifica. Diciamo tre minuti. Tre minuti non sono niente, se non fosse che arrivano proprio nel momento in cui uno sviluppatore ha slancio e non vuole sprecarlo: così il problema finisce nel backlog e il backlog slitta al trimestre successivo.

Perché l’ACR si discosta dal prodotto

La variante che alla fine Le costa denaro è ciò che succede al Suo ACR.

Lo si produce, il team acquisti di un cliente lo approva, viene archiviato. Poi si continua a rilasciare. Qualcuno aggiunge una finestra modale che intrappola il focus, oppure un restyling grafico porta il contrasto dei pulsanti secondari sotto 4,5:1, e il documento firmato a marzo descrive un prodotto che non esiste più. Lo si scopre all’audit successivo, oppure perché un cliente chiede un ACR aggiornato e il team commerciale Le inoltra la richiesta.

Nessuno dei problemi di fondo è difficile. Si tratta di rapporti di contrasto, campi di modulo senza etichetta, pulsanti senza nome accessibile, ordine del focus che segue il DOM anziché il layout visivo. Uno sviluppatore competente ne corregge uno qualsiasi in dieci minuti se ha davanti l’elemento e il contesto, e ci mette un’ora sei settimane dopo, quando il ticket riemerge a freddo.

Cosa fa il DevAlly MCP

MCP è uno standard per collegare gli assistenti di IA a strumenti esterni. Basta collegare DevAlly una sola volta e il Suo assistente può interrogare direttamente i dati sull’accessibilità: i risultati dell’audit compaiono così nell’editor, invece di restare in una dashboard in attesa che qualcuno vada a recuperarli.

Uno sviluppatore chiede, per esempio:

“Mostrami tutti i problemi critici del prodotto checkout.”

“Qual è la correzione per DEV-2487 e quali pagine interessa?”

“Cosa manca ancora prima di poter aggiornare l’ACR del prodotto login?”

“Quali elementi rientrano nel problema di contrasto della pagina dei prezzi e quali rapporti raggiungono?”

In risposta arrivano il criterio di successo WCAG, l’elemento che presenta il problema, la correzione consigliata e le pagine interessate. Gli stessi dati della dashboard, consegnati nel punto in cui qualcuno può intervenire nei trenta secondi successivi anziché nello sprint successivo.

Come gestisce autenticazione e accesso

L’autenticazione privilegia OAuth 2.1. Si accede con il proprio account DevAlly, si sceglie l’organizzazione e la configurazione è completata. L’abbiamo resa l’opzione predefinita, anziché una di due opzioni equivalenti, per via dell’offboarding. Una chiave API è un segreto di lunga durata che finisce in un file di configurazione in chiaro sul portatile di qualcuno, e la sua rotazione diventa un compito che non spetta a nessuno: si finisce così per gestire due sistemi e due checklist di offboarding, e prima o poi per dimenticarne uno. Con OAuth, revocare l’accesso a DevAlly di una persona revoca nello stesso istante l’accesso del suo assistente.

È disponibile anche l’autenticazione tramite chiave, con le stesse chiavi della nostra API pubblica, perché alcune configurazioni non consentono un accesso interattivo. Soprattutto pipeline di CI e agenti headless. In questi casi le chiavi si comportano esattamente come nel resto della piattaforma, quindi non c’è nulla di nuovo da capire. La maggior parte dei team non ne avrà bisogno.

Funziona come server remoto, quindi il Suo team non deve ospitare nulla e nessuno installa qualcosa che poi va aggiornato. Tutti usano la stessa versione, il che conta più di quanto sembri, se si è mai dovuto supportare uno strumento installato in locale in un team di trenta persone.

Inoltre non esiste un secondo modello di permessi, ed è una scelta voluta. Tramite OAuth l’MCP vede esattamente ciò che vede l’account connesso: se un prodotto non è visibile a una persona nella dashboard, nemmeno il suo assistente può interrogarlo. Le chiavi hanno ambito a livello di organizzazione, come nell’API pubblica, quindi una chiave può raggiungere tutto ciò che si trova nell’organizzazione. È una credenziale più ampia di una sessione utente, ed è il secondo motivo per cui privilegiamo OAuth anziché considerare le due opzioni equivalenti. In nessuno dei due casi si introduce un modello di permessi che il Suo team non stia già amministrando.

Avremmo potuto creare ambiti MCP separati, e in un questionario di sicurezza sarebbe sembrato più accurato, ma avrebbe significato mantenere due cose che devono restare allineate tra loro per sempre.

L’MCP non scrive nel Suo repository e non Le dice se il Suo prodotto è conforme. Segnala cosa non supera i controlli e cosa suggeriamo di fare. Una dichiarazione di conformità è qualcosa che la Sua organizzazione sottoscrive con il proprio nome, e deve restare in capo a una persona a cui si possa chiedere di giustificarla.

Perché la conformità integrata nel workflow conta per l’EAA, l’ADA e la Section 508

L’Atto europeo sull’accessibilità (European Accessibility Act) si applica dal 28 giugno 2025. Negli Stati Uniti, la norma del Department of Justice ai sensi del Titolo II dell’ADA fissa come scadenze per la conformità aprile 2026 per gli enti pubblici più grandi e aprile 2027 per quelli più piccoli, mentre la Section 508 continua a disciplinare gli acquisti federali.

Ciò che li accomuna è che il documento vale solo quanto il prodotto che c’è dietro. Un ACR fermo in una cartella degli acquisti significa ben poco se la build è andata avanti da quando è stato firmato, e i team che restano al passo sono quelli che verificano l’accessibilità come parte del lavoro ordinario, non nelle due settimane prima di un audit.

Come iniziare con il DevAlly MCP

L’MCP è incluso nei piani Growth e Compliance e si collega in circa un minuto. Si registri, aggiunga il connettore, effettui l’accesso e gli faccia una domanda.

Lo usiamo ogni giorno. Il set di strumenti nasce da ciò che volevamo davvero avere a portata di mano mentre correggevamo problemi di accessibilità reali nei nostri prodotti, non da una specifica, quindi siamo convinti che questi strumenti funzionino. Ma i workflow sono personali e ci saranno percorsi che non abbiamo pensato di supportare. Se gli chiede qualcosa a cui secondo Lei dovrebbe saper rispondere e non ci riesce, ci contatti. Vogliamo saperlo.

Configura il primo prodotto per iniziare → https://app.devally.com/auth/sign-up