Evaluar accesibilidad en 2026: decisiones estratégicas para combinar auditoría manual, automatización e IA

Sabéis que no me gustan las auditorías, pero creo que era necesario hablar sobre como evaluar accesibilidad en 2026.

Este es un tema del que ya he escrito antes e incluso he participado en eventos pero y como en casi todo creo que a veces hay frenar un poco, ver lo que hay y planificar, y eso es lo que quiero hacer en este post.

Cuando hablamos hablábamos de “evaluación de accesibilidad” estábamos describiendo, básicamente, una combinación de dos cosas: herramientas automáticas y revisión manual experta, (esto de revisión manual experta creo que va a ser la clave de este post, pero lo vemos al final).

Ahora hay un tercer actor en escena, la Inteligencia Artificial, (IA), que no sólo añade más capas de automatización, sino que cambia cómo pensamos el propio proceso de evaluación de una página web.

Qué es realmente la evaluación de accesibilidad (y cómo la hemos hecho hasta ahora)

Cuando una guía clásica habla de evaluación de accesibilidad, lo que describe es el análisis, revisión y validación de sitios y aplicaciones web frente a estándares como WCAG o EN 301 549, con el objetivo de que ninguna persona quede excluida al usar esos contenidos. Esa evaluación persigue localizar barreras, relacionarlas con criterios de conformidad y documentar recomendaciones de corrección de forma estructurada (qué falla, por qué, a qué criterio afecta y cómo solucionarlo).

Hasta ahora, el modelo “por defecto” en la industria ha sido algo así:

• Evaluación automática basada en reglas: Motores como axe-core, Lighthouse, WAVE, etc., analizan el DOM y detectan violaciones evidentes: falta de texto alternativo, problemas de contraste, formularios sin etiquetas, roles ARIA incorrectos, traps de teclado, etc.
• Evaluación manual experta: Un auditor recorre la interfaz con teclado, lector de pantalla, ampliación, diferentes configuraciones, y contrasta lo que ve con las WCAG: estructura, jerarquía, foco visible, mensajes de error, comportamiento dinámico, comprensión del contenido, etc.

Toda la literatura seria insiste en el mismo punto: las herramientas automáticas (por muy buenas y caras que sean) sólo cubren una parte de los criterios, (que dependiendo de a quién preguntes es un porcentaje mayor o menos) el diagnóstico completo y fiable siempre exige revisión manual, y, en muchos casos, pruebas con personas con discapacidad.

Así que el modelo tradicional ya era híbrido: máquinas para escanear y personas para interpretar, priorizar y decidir si la experiencia “funciona” de verdad para usuarios reales.

Llega la tercera capa: IA como nueva pieza en el puzle

En los últimos años ha aparecido una capa adicional sobre este binomio: la IA aplicada al testing de accesibilidad, especialmente en forma de modelos de lenguaje y sistemas generativos que entienden código, contenido y contexto.

Los análisis recientes distinguen tres tipos de herramientas con IA en este ámbito: las que sólo evalúan, las que evalúan y sugieren correcciones y las que evalúan e intentan arreglar automáticamente el problema en el código o la interfaz.

¿Qué añade la IA a lo que ya teníamos?

• Motores que combinan reglas con modelos de ML/NLP para detectar patrones complejos y reducir falsos positivos (por ejemplo, priorizando problemas que impactan flujos reales de usuario).
• Asistentes generativos especializados en accesibilidad que responden dudas, generan ejemplos de código accesible, explican criterios WCAG en lenguaje llano y ayudan a redactar informes o declaraciones de accesibilidad.
• Agentes autónomos que orquestan varias herramientas: escanean repositorios, lanzan tests, agrupan hallazgos, los mapean a WCAG y generan planes de remediación o documentación casi en tiempo real.

El consenso es bastante claro: la IA mola mucho y puede acelerar y enriquecer la evaluación, (y creo que todo el mundo que trabaja en accesibilidad ha jugado con la IA, aunque sea solo para ver que hace), pero no reemplaza el criterio ni la experiencia; su valor está en mejorar el workflow (velocidad, cobertura, documentación), no en decidir por sí sola si una experiencia es accesible o no.

Qué sí se puede hacer hoy: axe-core, plataformas IA y assistants especializados

Axe-core como motor y plataforma

Axe-core sigue siendo uno de los motores rule‑based de referencia para interfaces HTML: rápido, seguro, integrable en extensiones, pipelines de testing y herramientas de terceros.

Sobre ese motor se construye la Axe Platform y productos como axe DevTools, que añaden interfaces visuales, workflows guiados y, en sus versiones recientes, automatización avanzada con IA para encontrar más problemas, priorizarlos mejor y reducir ruido en los resultados.

Deque también ha lanzado Axe Assistant, un chatbot generativo especializado en accesibilidad, entrenado sobre contenido propio (Deque University, documentación, ejemplos) para responder cualquier duda de accesibilidad, generar código y apoyar a equipos de diseño y desarrollo.

El patrón es interesante: el motor rule‑based hace el “escaneo duro”, mientras que el assistant IA aporta contexto, explicaciones y ejemplos de remediación adaptados al stack del equipo.

MCPs y skills: el pegamento entre IA, código y herramientas de accesibilidad

Aquí entran los Model Context Protocols (MCP) y el concepto de skills/agents. MCP es un estándar abierto que permite conectar modelos de lenguaje con herramientas externas (APIs, bases de datos, servicios) de forma segura y estructurada.

En MCP, un servidor expone herramientas (“tools”) con nombre, descripción y esquema de parámetros, y el modelo puede descubrirlas y llamarlas cuando las necesita: lanzar un test, consultar un repo, analizar una página, etc.

En accesibilidad esto ya está aterrizando: por ejemplo, Evinced ofrece MCP Tools que permiten a sistemas de IA de coding hacer dos cosas clave: consultar un chatbot experto en accesibilidad y lanzar análisis automáticos de código y UI para detectar barreras antes de desplegar.

La filosofía es que el propio entorno de desarrollo eleve el listón mínimo: cualquier código generado o editado con ayuda de la IA pasa por un análisis de accesibilidad “por defecto”, sin que el desarrollador tenga que acordarse de pedirlo.

Desde el punto de vista de diseño de skills, puedes definir cosas como:

• scan_accessibility: “Analiza esta URL o este bundle con axe-core/Evinced y devuelve hallazgos mapeados a WCAG 2.2 AA”.
• a11y_code_review: “Revisa este pull request desde la óptica de accesibilidad e identifica riesgos”.
• a11y_report_draft: “Convierte estos hallazgos en un borrador de informe con resumen ejecutivo, tabla priorizada y recomendaciones de remediación”.

El propio estándar MCP contempla la idea de persona en el bucle (confirmación de operaciones, control de seguridad, validación de resultados), algo totalmente alineado con la necesidad de no entregar la accesibilidad a una automatización opaca.

Ejemplo 1: auditoría de accesibilidad con Antigravity + skills

Pero vamos al turrón, lo que os gusta y que estáis deseando usar, los ejemplos.

Si llevamos esto a un entorno concreto, Google Antigravity es un buen laboratorio mental: una plataforma de desarrollo agentic donde describes lo que quieres en lenguaje natural y varios agentes (conectados a Gemini, Claude, GPT, etc.) planifican y ejecutan el trabajo.

Antigravity se integra de forma nativa con MCPs y permite cargar paquetes de skills que encapsulan workflows complejos, incluyendo auditorías de accesibilidad.

Ya hay repositorios de skills que incluyen módulos específicos para accesibilidad, como el bloque de “Accessibility Audit and Testing” en antigravity-awesome-skills, cuyo objetivo es realizar auditorías completas, identificar barreras, ofrecer guías de remediación y garantizar que los productos sean accesibles.

Además, existen workflows de “Accessibility (a11y) Audit” que combinan Lighthouse y otras herramientas para generar informes visuales y métricas de accesibilidad sobre una URL o proyecto concreto.

Un flujo práctico podría ser:

1. Configurar el skill de auditoría de accesibilidad
   • Instalas el skill que ya sabe disparar Lighthouse, axe-core u otras herramientas, mapear hallazgos a WCAG y estructurar resultados.
   • Si necesitamos más control, ampliamos el skill para que use tu propia instancia de axe-core integrada en Playwright o Cypress, por ejemplo.
2. Conectar MCPs a tu código y entorno de pruebas
   • Antigravity se conecta a GitHub u otros repositorios vía MCP, clona el proyecto, lo construye y lo sirve en un navegador de pruebas.
   • El skill de auditoría usa otro MCP para lanzar el navegador y aplicar Lighthouse/axe-core sobre las vistas relevantes, recogiendo logs y capturas.
3. Dar una orden de alto nivel al agente
   • Por ejemplo: “Audita la accesibilidad de la rama develop de este repo. Usa axe-core y Lighthouse. Devuélveme un informe en Markdown con resumen ejecutivo, tabla de issues priorizados, mapeo a WCAG 2.2 AA y propuestas de remediación en código”.
   • El agente planifica los pasos, llama a los MCPs correctos, ejecuta los tests y genera el informe como artefacto dentro del proyecto.
4. Revisión humana y mejora iterativa del skill
   • Tú revisas el informe, corriges interpretaciones erróneas, ajustas severidades y refinas el prompt/skill (por ejemplo, decidiendo qué se etiqueta como bloqueante o qué recomendaciones no tienen sentido en tu contexto).
   • Con el tiempo, ese skill se convierte en tu plantilla personalizada de auditoría automática, alineada con tu criterio profesional.

La clave: el corazón técnico sigue siendo el mismo (axe-core, Lighthouse…), pero ahora empaquetado como un flujo agentic que se adapta al contexto del repo y de tus procesos, en lugar de estar “suelto” como extensión de navegador.

Ejemplo 2: pipeline de accesibilidad con Codex (u otro LLM) y skills de testing

Podemos replicar el patrón en entornos donde el modelo principal es Codex o un LLM similar. OpenAI ha descrito cómo usa Codex para entender y refactorizar código, generar tests y mejorar sistemas existentes a partir de prompts estructurados.

Guías de QA para código generado con Codex recomiendan añadir verificación en navegador, tests E2E y CI alrededor de ese código, en lugar de fiarse de que “como lo ha escrito la IA, estará bien”. (igual fiarse de la IA a ciegas no es buen plan)

Un pipeline razonable podría ser:

1. Integrar axe-core en tu suite de tests
   • Añades axe-core a tus tests E2E (Playwright, Cypress, Selenium) para que cualquier flujo de usuario importante pase automáticamente por un chequeo de accesibilidad.
   • Estos tests se ejecutan en CI en cada PR, lo haya escrito quien lo haya escrito (humano o IA).
2. Exponer navegador y tests como tools/skills para el agente
   • Plataformas de QA para IA describen patrones donde un agente puede abrir la app real en un navegador automatizado, recorrer pasos definidos y verificar resultados, convirtiendo esas verificaciones en tests persistentes.
   • Desde la óptica de skills, tendrías herramientas como run_a11y_e2e_tests (lanza Playwright + axe-core) o manual_a11y_probe (abre el navegador, navega a un componente y comprueba roles, foco, estados, etc.).
3. Crear un agente “accessibility-audit” ligado a los PR
   • Cada vez que Codex propone un cambio (o tú abres un PR), el agente ejecuta los tests de accesibilidad, analiza los resultados y genera un resumen en lenguaje natural: qué falló, qué criterios WCAG se ven afectados y ejemplos concretos de corrección.
   • Ese resumen se adjunta al PR y tú lo usas como input, no como verdad absoluta: decides qué aceptar, qué matizar y qué descartar.
4. Usar la IA para documentación, no para firmar la conformidad
   • Tras tu auditoría manual, puedes pedir a la IA que genere borradores de declaraciones de accesibilidad VPAT, secciones de informes, resúmenes para dirección o explicaciones personalizadas para el equipo técnico.
   • La comunidad insiste en que esta es la zona segura: la IA te ahorra tiempo de documentación, pero la decisión de conformidad la toma el equipo de accesibilidad.

En este escenario, el modelo actúa como compañero de testing: ayuda a escribir código, a lanzar y mantener tests, y a explicar lo que encuentra; tú sigues siendo quien decide el veredicto sobre la accesibilidad real de la experiencia.

El punto ciego de las skills: ¿y si la skill está mal?

Cuando empezamos a usar skills de repositorios públicos (GitHub, marketplaces, directorios tipo QASkills, etc.) tendemos a asumir que “si está publicado, estará bien”. Pero una skill no deja de ser código + criterios encapsulados en un archivo (normalmente un SKILL.md con frontmatter y texto), y si alguien comete un error ahí, ese error se replica en todas las auditorías que se apoyan en esa skill.

Si alguien comete un error en una skill, ese error se replica en todas las auditorías que se apoyan en esa skill

En la práctica, ¿quién garantiza que una skill de “Accessibility Audit” está bien planteada?

• En repositorios abiertos, la “revisión” la hace la comunidad: issues, PRs, número de estrellas, descargas, etc. Algunos directorios añaden validadores de esquema para comprobar que el formato del SKILL.md es correcto, pero eso sólo verifica la estructura, no la calidad de los criterios de accesibilidad.
• Marketplaces y catálogos (por ejemplo, skills de accesibilidad para Claude Code) suelen ofrecer descripciones, ejemplos y cierto curado editorial, pero tampoco sustituyen una revisión sistemática por parte de especialistas en accesibilidad.

Desde el punto de vista de riesgo, una skill mal diseñada es un single point of failure, (lo que es un SPOF de toda la vída y es cualquier pieza que si falla, hace que falle todo el sistema): si tu proceso de auditoría depende por completo de esa skill, todos tus análisis heredan sus sesgos, sus omisiones y sus errores de interpretación de WCAG. Ahorras tiempo, sí, pero puedes estar certificando como “aceptables” interfaces con fallos sistemáticos simplemente porque la skill no los contempla.

Por eso, cuando hablamos de skills y MCP dentro de organizaciones, cada vez se insiste más en la idea de gobernanza:

• Mantener un registro interno de MCP/skills aprobadas, con información de origen, versión y propietario, en lugar de instalar skills “a pelo” desde GitHub.
• Fijar versiones concretas y evitar actualizaciones automáticas sin revisión, igual que harías con cualquier dependencia crítica.
• Revisar el contenido de la skill como revisas código: revisión por pares, participación de especialistas en accesibilidad, pruebas en entornos de staging y test sobre casos conocidos antes de ponerla en producción.

En resumen: usar skills de terceros está bien para experimentar o inspirarse, pero en cuanto una skill se convierte en parte central de tu proceso de auditoría, tienes que tratarla como tratarías a una librería de seguridad: con control de versiones, revisión experta, validación continua y la capacidad de retirarla si descubres que estaba equivocada.

Parte estratégica: integrar la IA en tus procesos sin perder calidad

IA como “junior muy rápido”, no como oráculo

Tanto organizaciones como WebAIM coinciden en que la IA debe verse como un ayudante potente que mejora herramientas y flujos, no como un sistema que sustituye al experto.

La metáfora que funciona mejor es la del “junior tester superveloz”: encuentra muchas cosas, redacta bien, pero hay que revisar lo que hace, porque no entiende contexto, impacto real ni prioridades de negocio como lo haría una persona con experiencia.

Esto implica redefinir tu objetivo: no buscamos “auditorías 100% automáticas con IA”, sino auditorías más rápidas, más completas y mejor documentadas, con el mismo o mayor nivel de criterio humano al final.

Dónde insertar la IA en tu pipeline de evaluación

Un mapa posible:

• Diseño y desarrollo (shift‑left)
  • Incluir requisitos de accesibilidad en los prompts base (vibe coding, coding copilots) y hacer que cualquier componente generado se revise con axe-core u otras herramientas antes de llegar a QA.
  • Conectar MCPs a tus repositorios para que agentes de accesibilidad puedan escanear ramas específicas o archivos parciales, no sólo sitios en producción.
• Testing automático
  • Orquestar varios scanners mediante agentes, usando IA para agrupar hallazgos, eliminar duplicados y priorizar según impacto.
  • Generar dashboards y resúmenes ejecutivos automaticamente para que el equipo dedique su tiempo a decidir y actuar, no a copiar-pegar resultados.
• Auditoría manual y pruebas con usuarios
  • Usar asistentes IA como “coaches” que te recuerdan checklists, sugieren casos de prueba, ayudan a interpretar fallos con lectores de pantalla, etc.
  • Mantener una capa explícita de tests con personas con discapacidad para validar tareas críticas, algo también subrayado desde la perspectiva de accesibilidad y regulaciones como el EU AI Act.

El problema del entrenamiento sin datos de personas con discapacidad

La mayoría de asistentes IA de accesibilidad se entrenan sobre documentación técnica, guías y ejemplos de buenas prácticas, no sobre datos sistemáticos de uso real por personas con discapacidad.

Esto limita su capacidad para anticipar problemas de usabilidad, carga cognitiva, fatiga, estrategias con tecnologías de apoyo o necesidades de determinados colectivos, incluso aunque “claven” la letra de las WCAG.

Algunas implicaciones prácticas:

• La IA puede dar por “suficiente” un patrón que, en la práctica, es frustrante o inviable para determinados usuarios.
• Puede priorizar errores muy visibles desde el punto de vista técnico, pero olvidarse de barreras de flujo (tareas imposibles de completar, estados poco claros, etc.).

Para contrarrestar esto, conviene:

• Seguir incluyendo escenarios de discapacidad y rutas con tecnologías de apoyo en tus planes de prueba, tal y como recomiendan ya guías de IA responsable y el propio debate en torno al EU AI Act.
• Tratar los resultados de pruebas de usuario como “gold data” para calibrar tus skills: documentar patrones que la IA tiende a pasar por alto y usarlos para ajustar prompts, reglas y severidades.

Retroalimentación defectuosa: cuando la IA se entrena con sus propios errores

Otra trampa es dejar que la IA se retroalimente sólo de sus propios outputs: informes auto‑generados, código “corregido” por ella misma, explicaciones no revisadas.

La investigación sobre MCP y contextos extensibles advierte que, si no se controla, esa retroalimentación puede consolidar sesgos y errores (“model collapse”), especialmente cuando los agentes empiezan a consumir resultados de otros agentes como si fueran verdad.

Buenas prácticas para evitarlo:

• Mantener fuentes de verdad estables y externas: WCAG, EN 301 549, guías internas revisadas, patrones validados con usuarios, etc.
• Diseñar tus MCPs/skills para requerir confirmación humana cuando un resultado vaya a usarse como base para futuras decisiones (por ejemplo, actualizar patrones de diseño o cerrar un riesgo).
• Auditar periódicamente las recomendaciones de la IA: muestrear respuestas, comparar con lo que recomendaría un experto y registrar discrepancias como input para mejoras.

Buenas prácticas para que la IA mejore, y no degrade, tus auditorías

A modo de checklist rápido para evaluar accesibilidad en 2026:

• No cambies profundidad por volumen: más escaneos no significan mejor auditoría si no puedes revisar e interpretar lo que sale.
• Separa claramente en informes lo automático de lo validado manualmente, indicando qué hallazgos provienen de herramientas (incluida IA) y cuáles se han revisado y priorizado con criterio humano.
• Trata a la IA como a un miembro más del equipo: asigna roles explícitos (“detectar”, “documentar”, “proponer”), establece límites y revisa su trabajo.
• Aprovecha MCP y las capacidades de logging para tener trazabilidad: qué herramienta hizo qué, con qué parámetros y qué decisiones tomó luego el equipo.
• No te fíes a ciegas de las skills.

Se puede hacer con IA… ¿pero debemos hacerlo?

El post empezaba tratando el tema de que durante años hemos hablado de “herramientas automáticas y revisión manual experta”; el riesgo ahora es que, si nos apoyamos demasiado en los resultados de la IA, esa revisión deje de ser realmente experta.

La tentación de ir siempre a lo rápido y cómodo (aceptar sin más lo que dice un assistant, un agente o un informe “inteligente”) puede hacer que auditores y responsables de accesibilidad pierdan criterio técnico, dejen de entrenar su ojo clínico y acaben delegando decisiones que exigen contexto, ética y comprensión profunda de la experiencia de las personas con discapacidad.

La IA puede y debe ayudarnos, pero sólo tendrá sentido si la usamos para amplificar nuestra práctica profesional, no para sustituirla ni para justificar atajos que degradan, poco a poco, la calidad real de las auditorías y de las decisiones que tomamos. (y al final, nuestra profesión)

Y aquí hay una reflexión incómoda que conviene dejar por escrito: que una tarea se pueda hacer con IA no significa que debamos hacerla con IA, podemos generar informes enteros, justificar decisiones de producto y hasta “simular” opiniones de usuarios con un prompt, pero eso no convierte esos resultados en más fiables ni más justos.

Que una tarea se pueda hacer con IA no significa que debamos hacerla con IA

En accesibilidad, el listón es más alto: hablamos de derechos, de independencia y de participación social, cada vez que elegimos el atajo automatizado frente al análisis pausado, estamos tomando una decisión política sobre a quién escuchamos y a quién dejamos fuera, la responsabilidad de no deshumanizar la accesibilidad con IA es nuestra, no de los modelos.