Claude escribió un DatePicker en React, pero lograr la accesibilidad WCAG llevó 3 días más

Un equipo de desarrollo pidió a Claude un DatePicker personalizado en React para un formulario de citas médicas, con soporte completo de navegación por teclado y lectores de pantalla. La IA resolvió rápido la primera versión. Después llegaron tres días de correcciones.

Lo que Claude hizo bien

Claude generó una base funcional del componente: la estructura JSX, atributos ARIA básicos (`role="dialog"`, `aria-label`, `aria-live`), manejadores de teclas para navegar con las flechas y la lógica de la cuadrícula del calendario. Como punto de partida era buena: el código compilaba, se veía bien y la revisión manual no rompió nada.

La IA resultó especialmente útil con el código repetitivo: generar las 42 celdas de la cuadrícula, calcular el desfase del primer día del mes y formatear las fechas para `aria-label`. Es un trabajo tedioso de hacer a mano y Claude lo resolvió con pulcritud.

El problema solo se hizo evidente al conectar tecnologías de asistencia reales.

Dónde se torció todo

La prueba de verdad empezó al ejecutar NVDA en Windows y VoiceOver en macOS. Surgieron varios problemas:

• La trampa de foco no funcionaba: al tabular dentro del diálogo, el foco pasaba al documento principal
• Las fechas se leían mal: el lector 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 al cambiar de mes
• Escape cerraba, pero no devolvía el foco: al cerrar el calendario, el foco se perdía en lugar de volver al botón que lo abrió
• Alto contraste de Windows: la fecha seleccionada no se distinguía de las demás, porque el componente dependía del color CSS sin atributos de estado

Cada uno de estos puntos parecía, en el código generado, «hay un manejador», pero el comportamiento con un lector de pantalla real difería de lo esperado.

Cómo lo arreglaron

La salvación fue la WAI-ARIA APG, la guía oficial del W3C con un patrón concreto para el diálogo de DatePicker. No se limita a decir «añade `aria-modal`», sino que fija la secuencia exacta: qué elemento recibe el foco al abrir, cómo mantener la trampa de foco, adónde devolverlo al cerrar y qué `aria-label` necesitan los botones de navegación entre meses.

«Leer el código generado no es lo mismo que comprobar la accesibilidad.

Solo un lector de pantalla real muestra la verdad.»

Reescribieron la trampa de foco con `querySelectorAll`, interceptando manualmente Tab y Shift+Tab. Cada celda de día recibió un `aria-label` completo del tipo «miércoles, 3 de junio de 2026», más `aria-pressed="true"` para el estado seleccionado. Para el modo de alto contraste añadieron `aria-selected` y un contorno con `outline`, en lugar de depender solo del color de fondo.

El punto más delicado fue `aria-live`: la región debe estar en el DOM antes de que se escriba texto en ella; de lo contrario, el lector de pantalla la ignora. Claude insertó la región de forma dinámica, y este matiz solo salió a la luz en las pruebas.

Qué significa

Claude acelera la escritura de código accesible, pero no sustituye las pruebas con lectores de pantalla. La buena noticia: una vez que el equipo domina la WAI-ARIA APG y documenta las soluciones, el siguiente componente accesible se escribe bastante más rápido. La IA asume el trabajo repetitivo, pero la verificación final con NVDA y VoiceOver no puede omitirse.