Un desarrollador ciego enseña a un agente de IA a no inventar errores de accesibilidad en el código

Imagine que un agente de IA revisa un formulario y anuncia con seguridad que a un campo le falta aria-describedby. Usted abre el código y descubre que el componente de formulario de la biblioteca lleva tiempo creando la asociación con la ayuda. Estos falsos positivos destruyen la confianza en una auditoría más rápido que los errores pasados por alto. A este problema se enfrentó un programador ciego que utiliza un lector de pantalla y desarrolla Accessibility Auditor Skill, un conjunto de instrucciones para un agente que comprueba la accesibilidad en el código fuente y en sitios web en funcionamiento.

Mirar la implementación, no el punto de llamada

El principal cambio de la habilidad consiste en que, antes de calificar algo como un problema, el agente sigue el recorrido desde el punto de uso hasta la implementación. Averigua qué elemento recibe el foco, de dónde procede su nombre accesible, dónde se crean la etiqueta, la ayuda y el mensaje de error, cómo se transmiten los identificadores y qué hace realmente la versión instalada de la biblioteca. También comprueba que el archivo encontrado participe de verdad en el flujo correspondiente: los repositorios suelen contener componentes antiguos con nombres parecidos, y modificar uno de esos archivos no cambia nada para el usuario.

Si la asociación se ha perdido realmente en un componente compartido, hay que corregirla allí y comprobar todos los campos afectados. Si ya existe, no es necesario duplicarla.

Lecciones de pull requests concretos

En un pull request para RTL, el agente analizó los mensajes de autenticación y carga. Los roles status y alert ya determinan el modo de anuncio, por lo que un assertive adicional o role="alert" puede interrumpir la voz del lector de pantalla. Para un indicador de carga situado junto a un texto, la regla es la siguiente: si el mensaje ya aparece como texto, el indicador decorativo no debe recibir el mismo nombre accesible, sino ocultarse mediante aria-hidden. Ese pull request se cerró sin fusionarse, de modo que el fragmento solo muestra el cambio propuesto; el anuncio real debe comprobarse en la aplicación en funcionamiento.

En Vets-Who-Code, la propiedad feedbackId se añadió de forma demasiado amplia a una interfaz compartida y quedó disponible para componentes que no la procesaban. De ahí surge otra regla: al añadir una propiedad, hay que averiguar quién la admite y si acabará convertida en un atributo HTML innecesario. Los identificadores se comprueban en dos variantes: generados internamente y proporcionados desde el exterior. De lo contrario, el ejemplo predeterminado funciona, pero un formulario con su propio ID pierde la asociación con el error.

En suitenumerique/docs, la corrección dependía de un elemento interno de Cunningham Select. La biblioteca puede cambiar el marcado y romper el selector. Ahora la habilidad prefiere la API pública y, cuando es necesario recurrir a detalles internos, exige una prueba de regresión para los valores finales de aria-hidden y tabindex. En aquella iteración, esas comprobaciones se añadieron a una prueba de Playwright, pero no se ejecutó el conjunto completo de pruebas de extremo a extremo.

Un resultado aceptado y limitaciones reconocidas

El único pull request aceptado que se cita es Nextcloud iOS #4111, aceptado el 28 de mayo de 2026. Las filas de carpetas de la ventana para elegir la ubicación de guardado no tenían un nombre accesible: VoiceOver enfocaba el elemento, pero no anunciaba el nombre de la carpeta. El agente compuso el nombre a partir del título y de los datos que ya se mostraban en la celda, descartó los valores vacíos y asignó a la fila el rasgo de botón. Solo se revisó el código fuente: no se compiló la aplicación para iOS ni se realizó una prueba con VoiceOver porque el entorno no disponía de Xcode.

El autor afirma expresamente que no dispone de una medición de la tasa de falsos positivos antes y después de los cambios. Lo que sí existe son las reglas y los casos que las originaron. Por eso, en su informe el agente debe indicar exactamente qué hizo: analizar el código, ejecutar pruebas o escuchar el lector de pantalla. Son niveles de confianza distintos.

Conclusiones

Si crea agentes para revisar código, no los limite a un solo archivo. Haga que el agente siga la cadena desde el punto de llamada hasta la biblioteca y compruebe quiénes consumen los componentes compartidos. Incorpore a las instrucciones las lecciones de pull requests reales para no tener que explicarlas de nuevo en cada proyecto. Y exija al agente que indique con sinceridad el tipo de verificación: leer el código no sustituye una prueba con un lector de pantalla en un dispositivo.