Tu IA está copiando código defectuoso. Así es como puedes hacer que pare.

Diseñamos un experimento controlado con cuatro herramientas populares—Builder Fusion, Claude Code (Sonnet 4), GitHub Copilot (GPT-5) y Vercel V0—enfocado en el mismo mini proyecto: una página de inicio minimalista para relojes de lujo con un encabezado fijo y mega menú, un diálogo de bienvenida, búsqueda predictiva, dos carruseles, una cuadrícula de journal con botón "cargar más" y un pie de página estándar. Probé los cinco componentes más propensos a fallos y evalué los resultados según WCAG 2.1 AA.

El giro no estaba en el proyecto. Estaba en los prompts.

Fase 1: No mencionar nada sobre accesibilidad. Nuestro prompt inicial describía la página y los componentes, con restricciones para entregar en tres archivos (HTML, CSS, JS). Sin orientación sobre accesibilidad. Los resultados se veían elegantes pero fallaban de manera predecible: faltaba estructura semántica, ARIA inconsistente o incorrecta, soporte deficiente para teclado, imágenes y controles de formulario sin etiquetas. La conformidad se agrupaba en el rango del 70-80%. Bonito, pero defectuoso.

Fase 2: Decir "hazlo compatible con WCAG 2.1 AA". Esta simple indicación ayudó. Las cuatro herramientas mejoraron la estructura de encabezados y el etiquetado; algunas comenzaron a añadir automáticamente texto alternativo y etiquetas de formulario. Pero los problemas persistentes siguieron siendo persistentes: gestión inestable del foco, comportamiento inconsistente del teclado y actualizaciones en vivo que no se anunciaban a las tecnologías de asistencia. Las puntuaciones se estancaron alrededor del 82-83%. Mejor, pero no bueno.

Fase 3: Pedir a un LLM que reescriba el prompt con criterios de éxito explícitos. Aquí le pedimos a la IA que ampliara nuestras instrucciones con requisitos detallados de accesibilidad. Lo hizo, principalmente añadiendo ARIA por todas partes. Vimos mejores puntos de referencia y algunos avances en teclado, pero también una nueva clase de fallos de "nivel A" creados por roles innecesarios e incorrectos. El efecto neto: movimiento mínimo en la puntuación y algunas regresiones, con la mayoría de las herramientas rondando el ~81-83%. En algunos casos, arreglamos problemas AA mientras introducíamos nuevos problemas A. Eso no es progreso.

Fase 4: Comenzar con una lista de verificación de accesibilidad nativa. En lugar de enterrar la accesibilidad dentro de la solicitud de construcción, la pusimos al frente como un prerrequisito y la mantuvimos simple: HTML semántico primero, ARIA solo si es necesario; orden lógico de tabulación; enfoque visible; enlace de salto respetado; etiquetas claras y manejo de errores; regiones en vivo discretas para búsquedas y asertivas para errores de formulario; objetivos de contraste; respeto a la reducción de movimiento. Luego pedimos la misma página. Esto cambió el patrón. La búsqueda predictiva y los diálogos se apoyaron en elementos nativos; los menús se comportaron correctamente; el etiquetado dejó de multiplicarse; la navegación por teclado se sintió natural. Las puntuaciones volvieron a subir —Claude Code y V0 destacaron— mientras que Copilot bajó algunos puntos debido a algunos usos incorrectos persistentes de ARIA.

La conclusión es contundente: pasar de una "accesibilidad sobrecargada de ARIA" a una estrategia de prompting centrada en lo nativo produjo código más limpio y compatible, con menos falsos positivos y un soporte de teclado más sólido.

En todas las fases, la tendencia general fue clara. La conformidad básica se situaba aproximadamente entre el 70% y el 80%. Añadir "hazlo accesible" empujó a las herramientas hasta poco más del 80%. La reescritura sobrecargada de ARIA no desbloqueó un nuevo nivel; de hecho, arriesgaba nuevas fallas. La instrucción de priorizar elementos nativos estabilizó la semántica y elevó la calidad nuevamente, con Claude Code y V0 tomando la delantera en nuestra ronda final, mientras que Copilot mostró una pequeña caída relacionada con errores específicos en atributos ARIA.

Sin embargo, los números no cuentan toda la historia. La sensación del resultado cambió. Cuando las herramientas se basaban primero en patrones nativos, el orden de enfoque tenía sentido, las interacciones con teclado funcionaban sin complicaciones y las tecnologías de asistencia anunciaban los cambios de manera confiable. Cuando las herramientas recurrían a ARIA prematuramente, etiquetaban en exceso, etiquetaban incorrectamente o mezclaban patrones—más visiblemente en torno al comportamiento de cuadros combinados en búsquedas predictivas. Ese es exactamente el tipo de "ayuda" que puede sabotear la accesibilidad en el mundo real.

Los navegadores modernos ya implementan una gran cantidad de comportamientos accesibles. El HTML semántico expone nombres, roles y estados que las tecnologías de asistencia comprenden. Cuando comienzas con esos elementos primitivos, heredas los valores predeterminados de accesibilidad correctos. ARIA es potente, pero está diseñado para llenar vacíos, no para reinventar controles cotidianos. Si le pides a una IA que añada ARIA, lo hará. Si le pides que use HTML nativo primero, utilizará el camino más seguro.

Los resultados se alinearon con ese principio. Nuestras mejores ejecuciones se apoyaron en puntos de referencia nativos de navegación, etiquetas de formularios, listas y encabezados, semántica de diálogos y botones que se comportaban como botones. Cuantos menos roles personalizados introdujimos, menos casos excepcionales creamos.

Si tu indicación predeterminada es "construye X y hazlo accesible", obtendrás mejoras inconsistentes y dolor recurrente. Cámbiala por un preámbulo tipo lista de verificación que establezca las reglas básicas, y luego describe tus componentes. Mantenlo humano y semántico, sin exceso de jerga técnica. No necesitas conocer la receta ARIA exacta para un cuadro combinado; lo que necesitas es indicar los resultados que deseas: orden lógico de tabulación, navegación con teclas de flecha en menús, tecla Enter para seleccionar, anuncios discretos en vivo para resultados de búsqueda, anuncios enfáticos de errores en formularios. El modelo puede traducir esos resultados en código, y funcionará mejor cuando se le oriente primero hacia elementos nativos.

Dos precauciones prácticas del experimento: 1. Las indicaciones no son una solución mágica. Incluso en las mejores ejecuciones, seguimos revisando los resultados con herramientas reales y detectando casos extremos. Mantén a los humanos en el proceso. 2. El comportamiento de las herramientas varía. En nuestras pruebas, Claude Code y Vercel V0 respondieron especialmente bien al enfoque centrado en elementos nativos; Builder Fusion necesitó más replanteamientos; Copilot (GPT5) fue sólido en general pero ocasionalmente se excedió con ARIA, lo que perjudicó su puntuación final en la Fase 4. Tu experiencia variará según el componente y la frecuencia de actualizaciones, así que verifica.

Aquí está el patrón y ejemplos de instrucciones (entre comillas) que funcionaron para mí—adapta según sea necesario:

1. Comienza con las reglas básicas. "Utiliza HTML semántico primero. Solo añade ARIA si un patrón nativo no puede expresar el comportamiento. Proporciona un orden lógico de tabulación, enfoque visible, un enlace de salto funcional y etiqueta todos los controles. Anuncia actualizaciones en vivo de manera discreta para búsquedas y de forma asertiva para errores de formulario. Cumple con el contraste de color WCAG 2.1 AA. Respeta la reducción de movimiento." 2. Describe los objetivos del componente, no el ARIA. "Construye un encabezado con logo, búsqueda predictiva y un mega menú. El menú debe admitir teclas de flecha y Enter para seleccionar. La búsqueda debe anunciar el recuento de resultados sin robar el enfoque. Los diálogos deben mantener el enfoque y cerrarse con Escape." 3. Solicita validación. "Añade una breve explicación de cómo esto cumple con los criterios de navegación y formularios mencionados anteriormente." 4. Itera por componente. Genera, prueba y refina un widget complejo a la vez—menú, búsqueda, diálogo, carrusel—en lugar de toda la página de una vez. Es más rápido aislar y corregir errores de interacción cuando no estás comparando mil líneas de código combinado.

Este es el flujo de trabajo que uso día a día. Es lo suficientemente simple para no expertos, y consistentemente produce código más cercano a ser publicable en el primer intento.

La IA refleja los patrones que recompensamos. Si pides una página, copiará patrones de la web—incluidos sus defectos. Si pides una página que priorice las necesidades humanas, se moverá en esa dirección. Nuestro experimento no logró que ninguna herramienta fuera perfecta, pero sí demostró una forma confiable de obtener mejores resultados: enseña a tu IA a comenzar con la accesibilidad incorporada en la plataforma, y luego añade solo lo que sea imprescindible. Ese único cambio nos llevó de "bonito pero defectuoso" a "más limpio, más compatible y accesible mediante teclado". Hará lo mismo por tu equipo.