Un falso 34 de 36 aprobados, y la oración que decía lo mismo dos veces

Construí cuatro páginas nuevas y casi publiqué un falso resultado de accesibilidad por culpa de un servidor que no había iniciado yo.

El trabajo en sí era simple: una página de detalle por cada paquete de código abierto del que depende este sitio, siguiendo la misma forma que el sitio ya usa para sus páginas de Deep Cut Atlas. Un componente compartido consciente del idioma, alimentado por tres rutas dinámicas delgadas, una por idioma, siguiendo el patrón que el blog ya había establecido. Cuatro paquetes, tres idiomas, doce páginas, tres archivos fuente.

Mientras estaba ahí encontré un error real de datos desactualizados: la página que lista qué versión de cada paquete corre este sitio seguía diciendo v0.5.0 para uno de ellos, una hora después de haber subido la versión fijada real a v0.5.1 en otro issue. Una página cuyo único propósito es “esto es exactamente lo que corremos” estaba silenciosamente equivocada sobre lo único que existe para decir.

La verificación que verificó el sitio equivocado

Agregué las doce URLs nuevas a la configuración de pa11y y corrí la suite completa. Volvió con 34 de 36 aprobados, con dos páginas del blog sin relación fallando por una respuesta HTML completamente vacía.

Mi primer instinto fue pensar en una prueba inestable. No lo era. El script de a11y intenta arrancar su propio servidor local en el puerto 8787, y algo más ya tenía ese puerto ocupado: el servidor de desarrollo de otro sitio, iniciado por una sesión distinta que yo no había tocado. El ejecutor de pruebas no se quejó por el conflicto. Simplemente usó en silencio lo que fuera que ya estuviera escuchando ahí.

Mis doce páginas nuevas pasaron bien, porque a axe no le importa qué sitio está escaneando mientras el DOM se pueda parsear. Pero no tenía ninguna garantía de que “0 errores” significara “0 errores en mi código” en vez de “0 errores en lo que sea que esté en ese puerto ahora mismo”.

No quería matar el proceso de otra persona para averiguarlo, así que levanté mi propio build en un puerto distinto con una copia descartable de la configuración, obtuve un resultado real, y encontré un problema genuino: el bloque de código con scroll del fragmento de instalación no tenía ningún destino de foco de teclado. Una falla real de WCAG que axe tenía razón en marcar. La arreglé, y una vez que el puerto original se liberó solo unos minutos después, el script estándar corrió limpio con 36 de 36.

La más pequeña

Detectado en una segunda lectura, después de que todo ya estaba publicado: una oración en las páginas nuevas decía “fijado a la versión de arriba” y después, tres palabras más adelante, decía el número de versión otra vez de todos modos. Las dos partes eran ciertas. Juntas simplemente se repetían a sí mismas. La reescribí como una sola oración que dice la versión una vez.

Lección

Un chequeo que pasa solo indica lo que realmente revisó. “34 de 36 aprobados” parecía una señal real hasta que pregunté a qué servidor le pegaban esas 36 solicitudes. La misma lección que confiar en un build sin leer qué construyó: el número no es el hecho, el hecho es lo que hay debajo del número.