Su camino hacia el VPAT empieza en el editor. Conecte nuestro MCP

Hay algo que vemos una y otra vez en los datos de la plataforma. Un cliente realiza una auditoría, lee los resultados, está de acuerdo con ellos y, meses después, una parte considerable de esas incidencias sigue abierta. Nadie cuestionó nada. Simplemente, el trabajo no se hizo.

Durante mucho tiempo di por hecho que era un problema de priorización y que la solución pasaba por una mejor puntuación de la gravedad. En realidad, es sobre todo un problema de logística. La incidencia está en el panel de DevAlly y la persona que puede corregirla está en su editor, y pasar de uno a otro implica pararse, buscar la pestaña, buscar el producto, buscar la incidencia y leer lo suficiente para reconstruir qué quería decir realmente la herramienta de comprobación. Pongamos tres minutos. Tres minutos no son nada, salvo porque llegan justo cuando un desarrollador tiene impulso y no quiere gastarlo, así que la incidencia acaba en el backlog y el backlog acaba en el próximo trimestre.

Por qué el ACR se desvía del producto

La versión de esto que acaba costándole dinero es lo que le ocurre a su ACR.

Usted elabora uno, el equipo de compras de un cliente lo aprueba y se archiva. Después, sigue lanzando versiones. Alguien añade un modal que atrapa el foco, o un rediseño reduce el contraste de los botones secundarios por debajo de 4,5:1, y el documento que firmó en marzo describe un producto que ya no existe. Se entera en la siguiente auditoría, o porque un cliente pide un ACR actualizado y el equipo comercial le reenvía la solicitud.

Ninguno de los fallos de fondo es difícil. Se trata de relaciones de contraste, campos de formulario sin etiquetas, botones sin nombre accesible u orden del foco que sigue el DOM en lugar del diseño visual. Un desarrollador competente corrige cualquiera de ellos en diez minutos si tiene delante el elemento y el contexto, y tarda una hora cuando el ticket reaparece seis semanas después, ya sin contexto.

Qué hace el DevAlly MCP

MCP es un estándar para conectar asistentes de IA con herramientas externas. Conecta DevAlly una sola vez y su asistente puede consultar directamente sus datos de accesibilidad, lo que significa que los resultados de la auditoría aparecen en el editor en lugar de esperar en un panel a que alguien vaya a buscarlos.

Un desarrollador pregunta algo como:

«Muéstrame todas las incidencias críticas del producto de checkout.»

«¿Cuál es la corrección para DEV-2487 y a qué páginas afecta?»

«¿Qué queda pendiente antes de poder actualizar el ACR del producto de inicio de sesión?»

«¿Qué elementos abarca la incidencia de contraste de la página de precios y qué relaciones de contraste alcanzan?»

La respuesta incluye el criterio de conformidad de las WCAG, el elemento que falla, la corrección recomendada y las páginas afectadas. Los mismos datos que en el panel, entregados allí donde alguien puede actuar en los próximos treinta segundos en lugar de en el próximo sprint.

Cómo gestiona la autenticación y el acceso

La autenticación se basa principalmente en OAuth 2.1. Inicia sesión con su cuenta de DevAlly, elige su organización y la configuración queda terminada. Lo convertimos en la opción predeterminada, y no en una de dos opciones equivalentes, por las bajas de personal. Una clave de API es un secreto de larga duración que acaba en un archivo de configuración en texto plano en el portátil de alguien, y rotarla se convierte en una tarea que no es de nadie, así que se acaba manteniendo dos sistemas y dos listas de comprobación para las bajas y, tarde o temprano, olvidando una de ellas. Con OAuth, al retirar a alguien el acceso a DevAlly, se retira en ese mismo momento el acceso de su asistente.

También está disponible la autenticación por clave, con las mismas claves que nuestra API pública, porque algunas configuraciones no permiten un inicio de sesión interactivo. Sobre todo, pipelines de CI y agentes headless. Si es su caso, las claves se comportan exactamente igual que en el resto de la plataforma, así que no hay nada nuevo que analizar. La mayoría de los equipos no las necesitará.

Funciona como servidor remoto, así que su equipo no aloja nada y nadie instala nada que después haya que actualizar. Todo el mundo usa la misma versión, algo que importa más de lo que parece si alguna vez ha dado soporte a una herramienta instalada en local en un equipo de treinta personas.

Tampoco hay un segundo modelo de permisos, y fue algo deliberado. Con OAuth, el MCP ve exactamente lo que ve la cuenta que ha iniciado sesión, de modo que si un producto no es visible para alguien en el panel, su asistente tampoco puede consultarlo. Las claves tienen alcance de organización, igual que en la API pública, lo que significa que una clave puede acceder a todo lo que hay en la organización. Es una credencial más amplia que una sesión de usuario, y es el segundo motivo por el que priorizamos OAuth en lugar de tratar ambas opciones como equivalentes. En ningún caso se introduce un modelo de permisos que su equipo no esté ya administrando.

Podríamos haber creado ámbitos específicos para el MCP, y habría parecido más exhaustivo en un cuestionario de seguridad, pero habría supuesto mantener para siempre dos cosas que se supone que deben coincidir entre sí.

El MCP no escribirá en su repositorio ni le dirá si cumple la conformidad. Informa de lo que falla y de lo que sugerimos hacer al respecto. Una declaración de conformidad es algo que su organización respalda con su nombre, y debe quedar en manos de una persona a la que se le pueda pedir que la justifique.

Por qué el cumplimiento dentro del flujo de trabajo es importante para la EAA, la ADA y la Section 508

El Acta Europea de Accesibilidad se aplica desde el 28 de junio de 2025. En EE. UU., la norma del Departamento de Justicia en virtud del Título II de la ADA fija como fechas de cumplimiento abril de 2026 para las entidades públicas más grandes y abril de 2027 para las más pequeñas, y la Section 508 sigue rigiendo las compras federales.

Lo que todas tienen en común es que el documento solo vale lo que vale el producto que lo respalda. Un ACR guardado en una carpeta de compras significa muy poco si la versión del producto ha cambiado desde que se firmó, y los equipos que van por delante son los que comprueban la accesibilidad como parte del trabajo habitual y no en las dos semanas previas a una auditoría.

Cómo empezar con el DevAlly MCP

El MCP está incluido en nuestros planes Growth y Compliance y se conecta en aproximadamente un minuto. Regístrese, añada el conector, inicie sesión y hágale una pregunta.

Lo usamos a diario. El conjunto de herramientas surgió de lo que realmente queríamos tener delante al corregir incidencias de accesibilidad reales en nuestros propios productos, no de una especificación, así que confiamos en que estas herramientas funcionan. Pero cada flujo de trabajo es personal, y habrá casos que no se nos ocurrió contemplar. Si le pregunta algo que cree que debería poder responder y no puede, póngase en contacto con nosotros. Queremos saberlo.

Configure su primer producto para empezar → https://app.devally.com/auth/sign-up