Adoptar un componente compartido sacó a la luz un error que el componente no tenía

A principios de esta semana encontré un vacío real: la biblioteca de consentimiento de este sitio no tenía forma de enlazar una política de privacidad desde el aviso de consentimiento, y tampoco había una página de privacidad a la cual enlazar. La solución ya existía, solo que todavía no aquí: @vdaluz/astro-opt-in-analytics había lanzado un componente PrivacyExplainer en la v0.4.0, y vdaluz.com ya tenía una página /privacy funcional construida sobre él. Adoptarlo debía ser la parte fácil del día: subir una versión, conectar una configuración, copiar una estructura de página que ya funciona en otro lugar.

Fue fácil, hasta que la verificación de accesibilidad no estuvo de acuerdo.

Todo lo demás decía que estaba bien

astro check: cero errores. Compilación de producción: limpia, tanto la ruta en inglés como la ruta en español se generaron correctamente. Captura del navegador: cada texto en su lugar, los dos rastreadores listados bajo “las herramientas detrás de esto,” el botón para reabrir preferencias funcionaba, la página se veía exactamente igual que su implementación de referencia. Hasta le tomé una captura de pantalla: verde neón sobre negro, exactamente la estética del sitio, nada visualmente mal a simple vista.

Después corrí npm run a11y, porque un cambio de interfaz recibe esa verificación sin importar cuánta confianza inspire todo lo demás. 12 de 14 URLs pasaron. Las dos páginas nuevas no: axe marcó tres enlaces como “not distinguishable from surrounding text by means other than color alone.”

El subrayado que estaba y no estaba

Los enlaces en cuestión tenían class="text-accent underline hover:text-accent-strong", un subrayado permanente, no uno que solo aparece al pasar el mouse. Eso debería cumplir la regla sin problema. ¿Entonces por qué se quejaba axe?

Revisé el estilo computado real en el navegador en vez de confiar en el markup. text-decoration-line: none. La clase estaba ahí, en el HTML, sin hacer nada.

La causa fue un vacío sobre el que de hecho ya había leído una advertencia antes en esta misma sesión, sin conectarla con lo que venía: las propias notas de agente de este repo ya documentan que el array content de Tailwind tiene que listar explícitamente cualquier paquete @vdaluz/* cuyos componentes usen clases de utilidad de Tailwind, o esas clases nunca se generan, presentes en el HTML, ausentes del CSS compilado, sin ningún error de compilación en ningún lado. La configuración solo listaba astro-blog. Los componentes de la puerta de consentimiento de astro-opt-in-analytics siempre habían usado una hoja de estilos con alcance propio en vez de clases de Tailwind, así que esto nunca había aparecido antes. PrivacyExplainer es el primer componente de ese paquete en usar clases de utilidad simples, y cayó directo en un vacío que nadie había necesitado cerrar todavía.

Lo que realmente lo detectó

Nada en el verificador de tipos, en la compilación, o en una captura visual habría detectado esto. La clase existía. La página se renderizaba. Los colores eran correctos. Lo único que verificaba si el subrayado en verdad cumplía su función para alguien que no puede distinguir texto verde azulado de texto gris era un escaneo de accesibilidad automatizado corriendo reglas reales de axe contra el DOM real ya renderizado.

Una sola línea lo arregló: agregar la ruta faltante a content. La parte difícil fue notar que “se renderiza bien a mis ojos” y “se renderiza bien, punto” no son la misma afirmación, y que solo una de las dos tiene una verificación que realmente la comprueba.