Usar skills de IA en accesibilidad digital sin morir en el intento: protocolo para no delegar tu criterio

Cada vez más equipos están incorporando skills de IA a sus flujos de trabajo, en desarrollo, en documentación, en testing y, por supuesto, también en accesibilidad digital. Si lo miramos con calma, tiene sentido, una buena skill puede ayudar a acelerar revisiones, estructurar hallazgos, recordar criterios WCAG y convertir tareas difusas en procesos más consistentes.

El problema empieza cuando dejamos de tratarlas como lo que son (paquetes de instrucciones, recursos y flujos especializados) y empezamos a tratarlas como si fueran criterio experto empaquetado y listo para usar.

En accesibilidad digital, eso es especialmente delicado, porque una skill mal planteada no sólo se equivoca una vez: puede repetir el mismo sesgo, la misma omisión o la misma mala interpretación en decenas de revisiones distintas.

Este post no intenta convencer a nadie de que deje de usar skills de IA, la idea es otra, si vas a usarlas, úsalas bien.

Usarlas bien implica revisarlas, probarlas, acotar su papel y decidir en qué punto deja de hablar la skill y vuelve a hablar el criterio profesional.

Qué son las skills de IA y por qué están entrando en accesibilidad digital

Las skills de IA son capacidades modulares que amplían el comportamiento de un agente mediante instrucciones persistentes, metadatos y, a veces, recursos adicionales como scripts o ejemplos. A diferencia de un prompt aislado, una skill está pensada para reutilizarse y para enseñar al agente a comportarse de una forma relativamente consistente frente a una tarea concreta.

Eso las hace especialmente atractivas en accesibilidad digital, una skill puede recordar al agente que tenga en cuenta WCAG 2.2, que revise headings, foco, nombres accesibles o errores de formulario, o que redacte un borrador de informe con una estructura más útil para un equipo técnico.

También puede servir para introducir patrones de diseño inclusivo antes de escribir una sola línea de código, algo que algunos autores ya están explorando con skills abiertas y model-agnostic.

El valor está claro, más consistencia, menos improvisación y una forma de encapsular experiencia acumulada.

Pero precisamente por eso una skill también puede convertirse en un punto ciego si nadie revisa cómo está escrita, qué presupone y qué deja fuera.

El riesgo real: una skill no es experiencia, es texto con autoridad aparente

Uno de los mayores peligros de las skills de IA es que suenan mejor de lo que a veces están pensadas.

Como empaquetan instrucciones estables y se presentan como “capacidades”, es fácil asumir que detrás hay una metodología sólida, cuando en realidad puede haber simplemente una cadena de buenas intenciones, ejemplos mediocres y criterios mal priorizados.

En accesibilidad digital, ese riesgo se amplifica, si una skill interpreta mal un criterio WCAG, confunde accesibilidad con simple linting del DOM, o sugiere correcciones que técnicamente “pasan” pero empeoran la experiencia real, el problema no se queda en una salida aislada.

Se multiplica cada vez que la skill se invoca y se normaliza dentro del equipo como si fuera una forma aceptable de revisar accesibilidad.

Por eso el error más común no es técnico, sino cultural: dejar de ver la skill como una ayuda y empezar a verla como un sustituto del juicio experto. En cuanto ocurre eso, el equipo deja de preguntarse si la salida tiene sentido y pasa a preguntarse sólo cómo integrarla más rápido en su flujo.

Primer filtro: leer una skill como si fuera una metodología

Antes de instalar una skill, conviene hacer algo poco glamuroso pero esencial «leerla entera», no como quien hojea un README, sino como quien revisa una metodología que va a influir en decisiones reales sobre accesibilidad.

Las buenas skills suelen explicar qué hacen, para qué sirven y cómo deben usarse.

Los ecosistemas actuales de agent skills describen precisamente las skills como paquetes ligeros y reutilizables orientados a tareas concretas, no como soluciones mágicas para dominios completos.

Eso ya da una pista importante: una skill de calidad suele ser específica y acotada, mientras que una skill sospechosa promete resolver “la accesibilidad” como si fuera una sola tarea homogénea.

Preguntas que deberías hacerle a cualquier skill de IA en accesibilidad digital

Antes de incorporarla a tu flujo, merece la pena revisar si responde bien a estas preguntas:

• ¿Explica claramente qué problema intenta resolver?
• ¿Tiene un alcance concreto o dice hacer “auditorías de accesibilidad” en general?
• ¿Menciona qué criterios, heurísticas o herramientas toma como referencia?
• ¿Incluye ejemplos reales de uso y de resultados esperables?
• ¿Reconoce sus límites y la necesidad de revisión humana?
• ¿Está pensada para un tipo de tarea específico (por ejemplo, revisión de componentes, borradores de informe, patrones inclusivos) o mezcla demasiadas funciones?

Cuando una skill no responde bien a estas preguntas, no significa necesariamente que sea inútil, significa que no debería entrar en un proceso serio sin una revisión adicional por parte del equipo.

Qué señales dan confianza y cuáles deberían hacer saltar alarmas

Hay indicadores bastante sencillos que permiten hacer un cribado inicial, ninguno garantiza calidad, pero sí ayudan a distinguir una skill prometedora de una skill escrita con demasiada prisa.

En el lado contrario, conviene desconfiar de skills que:

• Prometen revisar “toda la accesibilidad” sin matices.
• No citan ningún estándar, enfoque o referencia reconocible.
• Mezclan análisis, decisión, remediación e informe final como si todo fuese una misma cosa.
• No muestran ejemplos reales.
• Parecen diseñadas para sonar expertas más que para ser verificables.

En accesibilidad digital, la opacidad metodológica casi siempre sale cara más tarde.

Segundo filtro: probar la skill con casos que ya conoces

Una skill no debería entrar en tu flujo real sólo porque su README esté bien escrito, antes necesita pasar por una prueba más honesta: enfrentarse a casos donde tú ya sabes qué problemas existen y qué tipo de análisis esperarías.

Las guías sobre validación de outputs de IA recomiendan precisamente eso: comprobar exactitud, coherencia, utilidad y alineación con criterios externos antes de confiar en una salida generada.

En accesibilidad digital, esa validación tiene que hacerse sobre ejemplos concretos y no sobre demos preparadas para impresionar.

Cómo montar un banco de pruebas mínimo

No hace falta construir un laboratorio enorme, basta con reunir un pequeño conjunto de ejemplos que representen situaciones habituales:

• Una página con problemas claros de contraste, foco o jerarquía de encabezados.
• Un formulario con errores de etiquetado y validación.
• Un componente custom donde el DOM parece correcto, pero la interacción no lo es.
• Un caso aparentemente correcto que suele disparar falsos positivos en herramientas superficiales.
• Un flujo donde el problema principal es de comprensión o carga cognitiva, no de marcado.

La pregunta importante no es sólo “¿cuántos fallos encuentra?”, sino otras más útiles: (y ojo, porque son muy útiles)

• ¿Qué detecta bien?
• ¿Qué omite de forma repetida?
• ¿Qué problemas inventa o exagera?
• ¿Cómo prioriza lo que encuentra?
• ¿Propone correcciones realmente útiles o sólo reformula obviedades?

Una skill que encuentra bastante pero prioriza mal puede ser más peligrosa que una skill limitada pero honesta.

Al final, los equipos no sólo necesitan detectar errores: necesitan saber cuáles importan, por qué y con qué urgencia.

Tercer filtro: separar ayuda de sustitución del criterio

Aquí está el punto clave, una skill puede ayudar mucho y, al mismo tiempo, no estar capacitada para cerrar una decisión. Esa distinción debería quedar escrita en cualquier flujo serio de accesibilidad digital.

Hay tareas donde una skill puede aportar bastante valor:

• Recordar criterios relevantes para un tipo de componente.
• Generar un checklist inicial.
• Redactar un borrador de informe técnico.
• Agrupar hallazgos repetidos.
• Sugerir preguntas para una revisión manual.

Pero hay otras donde la responsabilidad no debería delegarse:

• Decidir si una experiencia es usable de verdad para una persona con discapacidad.
• Confirmar impacto real en flujos críticos.
• Resolver tensiones entre criterio técnico, contexto de uso y diseño.
• Firmar el sentido final de una auditoría o de una recomendación de cumplimiento.

El error aparece cuando una organización usa la skill para acelerar una parte del trabajo y, sin darse cuenta, termina permitiendo que la skill marque también el marco de interpretación. A partir de ahí, la herramienta ya no asiste: condiciona.

Cómo integrar una skill sin desprofesionalizar la auditoría

Usar skills de IA en accesibilidad digital con responsabilidad no significa renunciar a su utilidad, significa introducirlas de forma que aumenten la capacidad del equipo sin erosionar su criterio.

Las mejores prácticas de evaluación de outputs generativos insisten en combinar automatización con revisión humana, trazabilidad y criterios externos de validación.

Una forma sana de integrarlas puede ser esta:

1. Skill para preparar el trabajo. Sirve para ordenar criterios, generar preguntas, proponer estructura o recordar puntos de revisión.
2. Persona experta para validar. Recorre la interfaz, contrasta el resultado y corrige omisiones o errores de interpretación.
3. Skill para ayudar a documentar. Reorganiza hallazgos, redacta un borrador o transforma notas en un formato más útil para compartir.
4. Persona experta para cerrar. Decide qué se entrega, cómo se explica y qué peso tiene cada hallazgo.

Este esquema parece sencillo, pero cambia mucho la cultura del equipo. La skill deja de ser “quien audita” y pasa a ser “quien ayuda a preparar y documentar mejor una auditoría” y esa diferencia importa.

Revisión continua: una skill buena hoy puede no servir mañana

Otro error frecuente es pensar que una skill ya validada queda aprobada para siempre. Pero las skills evolucionan, cambian de versión, se reutilizan en contextos nuevos y, a veces, mejoran en unas cosas mientras empeoran en otras.

Por eso conviene revisarlas periódicamente con preguntas muy concretas:

• ¿Sigue siendo útil para el propósito original?
• ¿Ha empezado a generar más ruido del que ahorra?
• ¿Introduce patrones de redacción o priorización que empobrecen el análisis?
• ¿Se apoya en ejemplos ya desactualizados?
• ¿Está arrastrando al equipo a aceptar salidas demasiado uniformes?

Una skill no debería quedarse en el proceso por inercia, si deja de mejorar la calidad del trabajo, o si empieza a degradar el criterio del equipo, hay que cambiarla, limitarla o retirarla.

Protocolo rápido para revisar skills de IA en accesibilidad digital

Para quien quiera una versión resumida, este protocolo puede servir como guía mínima:

1. Leer antes de instalar. Revisar qué hace, qué no hace y cómo está planteada.
2. Desconfiar de lo demasiado amplio. Una skill genérica para “auditar accesibilidad” suele ser menos fiable que una skill acotada.
3. Probar con casos reales conocidos. No confiar en demos ni en ejemplos preparados.
4. Comparar con criterio experto. Medir omisiones, falsos positivos, priorización y utilidad real.
5. Definir límites de uso. Saber en qué tareas ayuda y en cuáles no debe decidir.
6. Revisar periódicamente. Una skill útil no está validada para siempre.

Repositorio de skills y recursos de confianza para accesibilidad digital

Si se va a empezar a experimentar con skills de IA en accesibilidad digital, conviene hacerlo desde recursos razonablemente transparentes y conectados con el ecosistema real de accesibilidad. No como atajos, sino como puntos de partida más sólidos.

Recursos recomendados

• Agent Skills – Claude API Docs: buena base para entender qué es exactamente una skill, cómo se estructura y qué papel juega dentro de un agente.
• Agent Skills Overview: útil para entender el formato de skills como extensión ligera y reutilizable para flujos especializados.
• Microsoft Agent Skills: aporta otra formulación útil de las skills como paquetes portables con instrucciones, scripts y recursos.
• Intopia – Can AI Agent Skills Help Developers Ship Accessible Code?: muy relevante por su foco específico en skills orientadas a accesibilidad y desarrollo accesible.
• I Built 40 Inclusive Design Skills for AI Agents: interesante como ejemplo de skills model-agnostic aplicadas a diseño inclusivo antes del código.
• Repositorios curados de skills como VoltAgent o marketplaces similares: útiles para explorar patrones, siempre recordando que “curado” no significa “validado metodológicamente”.

Cómo usar este repositorio sin engañarte

El objetivo de este bloque no es darte una lista para instalar sin pensar, es justo lo contrario: ofrecerte puntos de partida con suficiente transparencia como para poder leer, contrastar y probar antes de confiar.

En accesibilidad digital, la pregunta importante no es qué skill parece más lista para usar, sino cuál te permite mantener mejor el criterio mientras automatizas sólo lo que tiene sentido automatizar.

No se puede evitar que las skills de IA entren en accesibilidad digital, y seguramente tampoco sería deseable intentarlo, bien usadas, pueden hacer que los equipos trabajen con más estructura, más memoria metodológica y menos improvisación.

Pero esa utilidad no cambia una verdad básica: una skill no es experiencia; es texto con instrucciones, ejemplos y supuestos.

Por eso el reto no es decidir si usarlas o no, sino decidir cómo evitar que sustituyan el criterio que deberían apoyar, una buena skill puede ayudarte a pensar mejor, a revisar con más orden y a documentar con más claridad. Una mala skill, o una buena skill mal usada, puede hacer justo lo contrario: volver más uniforme el análisis, más pobre la discusión y más cómodo el error.

No puedo hacer que no las uses, (ni quiero hacerlo, que no parezca que soy un hater de la IA), pero sí puedo decirte algo más útil: si vas a apoyarte en skills de IA para accesibilidad digital, no las uses nunca a ciegas.