Claude escribió un React DatePicker, pero lograr accesibilidad WCAG llevó otros 3 días

El equipo de desarrollo pidió a Claude que creara un DatePicker React personalizado para un formulario de cita médica—con soporte completo para navegación por teclado y lectores de pantalla. La IA manejó la primera versión rápidamente. Luego vinieron tres días de refinamiento.

Lo Que Claude Hizo Bien

Claude generó una base funcional para el componente: estructura JSX, atributos ARIA básicos (`role="dialog"`, `aria-label`, `aria-live`), manejadores de teclado para navegación con flechas y lógica de cuadrícula de calendario. Como punto de partida—sólido: el código se compilaba, se veía visualmente correcto, y las pruebas manuales no rompieron nada. La IA resultó especialmente útil para código repetitivo: generar 42 celdas de cuadrícula, calcular el desplazamiento del primer día del mes, formatear fechas para `aria-label`. Este es un trabajo tedioso de hacer manualmente, y Claude lo manejó limpiamente. El problema solo se hizo evidente después de conectar tecnologías asistivas reales.

Donde Todo Salió Mal

La prueba real comenzó cuando NVDA en Windows y VoiceOver en macOS se ejecutaron. Había varios problemas:

• La trampa de foco no funcionaba — al tabular dentro del diálogo, el foco volvía al documento principal
• Las fechas se leían incorrectamente — el lector de pantalla decía "1" en lugar de "Lunes, 1 de junio de 2026"
• El cambio de mes era silencioso — la región `aria-live` no se actualizaba cuando cambiaba el mes
• Escape cerraba pero no devolvía — después de cerrar el calendario, el foco se perdía en lugar de volver al botón disparador
• Alto contraste de Windows — la fecha seleccionada no se distinguía visualmente del resto: el componente dependía del color CSS sin atributos de estado

Cada uno de estos puntos en el código generado parecía "manejador presente"—pero el comportamiento con un lector de pantalla real difería de las expectativas.

Cómo Lo Arreglamos

La salvación fue WAI-ARIA APG—la guía oficial de W3C con un patrón específico para diálogos DatePicker. No solo dice "añade `aria-modal`," sino que prescribe la secuencia exacta: qué elemento recibe el foco al abrir, cómo mantener la trampa de foco, dónde devolverlo al cerrar, qué `aria-label` se necesita en los botones de navegación de mes.

"Leer código generado no significa verificar la accesibilidad.

Solo un lector de pantalla real revela la verdad."

La trampa de foco se reescribió usando `querySelectorAll` con intercepción manual de Tab y Shift+Tab. Cada celda de día recibió un `aria-label` completo como "Miércoles, 3 de junio de 2026" más `aria-pressed="true"` para el estado seleccionado. Para modo de alto contraste, añadimos `aria-selected` y contorno mediante `outline` en lugar de solo color de fondo. La parte más sutil fue `aria-live`: la región debe existir en el DOM antes de que se escriba texto en ella, si no el lector de pantalla la ignora. Claude insertó la región dinámicamente—este matiz solo surgió en las pruebas.

Lo Que Esto Significa

Claude acelera la escritura de código accesible pero no reemplaza las pruebas con lectores de pantalla. La buena noticia: una vez que has trabajado con WAI-ARIA APG una vez y documentado las soluciones, el siguiente componente accesible se escribe notablemente más rápido. La IA asume el trabajo repetitivo—pero saltarse la verificación final con NVDA y VoiceOver no es una opción.