Esta web lleva un mes escribiéndose a ratos, entre versión y versión del motor. Antes de publicarla la pasamos por dos revisiones distintas: una de diseño, que busca los tics que delatan una plantilla, y otra de accesibilidad contra WCAG 2.2. De las dos salieron cosas, y las dos peores se pueden medir con un número.
3,09
El botón principal del sitio es azul con texto blanco. En tema claro el azul es #1B44E0, oscuro y
saturado, y el blanco encima da 7,12:1 de contraste. Con eso vas sobrado: WCAG pide 4,5:1 para texto
normal.
El tema oscuro no es una inversión del claro. Está diseñado aparte, y ahí el azul sube a #6E8BFF
porque el de arriba desaparece sobre un fondo casi negro. Ese azul claro con texto blanco encima da
3,09:1.
No llega. Y no llega en el botón del formulario de suscripción, que es el elemento más visible de la portada, para todo el que tenga el sistema en modo oscuro.
Lo que falla aquí no es el azul. Es haber escrito color: #fff dentro del botón y no haberlo vuelto
a mirar cuando se diseñó el tema oscuro. El color de la tinta que va encima del acento no puede
ser el mismo en los dos temas, porque el acento tampoco lo es. En claro toca blanco sobre azul
oscuro, en oscuro toca tinta sobre azul claro, y eso son 6,08:1.
Ahora es un token con su nombre, y el botón lo referencia. Un #fff suelto dentro de una regla es
la forma en que un sistema de diseño deja de ser un sistema.
El segundo botón
Arreglado el token, recompilamos, y el botón del formulario seguía en blanco.
Ese botón no usa nuestra clase. Lo pinta un componente de terceros, el que habla con el proveedor de
correo, y tiene su propio juego de variables. Fuimos a mirar la suya con cierta prevención, esperando
un #fff clavado en el paquete.
Estaba bien. El componente declara --accent-ink y lo deja caer a blanco solo si el sitio anfitrión
no dice nada. El hueco estaba en nuestro mapeo: definimos el color de acento y nos olvidamos del
color que va encima. El componente hacía lo correcto y nosotros le dábamos media información.
Ocho de veinticuatro
El segundo fallo es de accesibilidad y tiene su propio criterio en WCAG 2.2, el 2.4.11, que se llama «el foco no queda oculto» y es de nivel AA. Es nuevo en la versión 2.2 y se salta con una facilidad que da miedo.
La cabecera de este sitio es fija. Se queda arriba mientras bajas, mide 61 píxeles y hasta aquí todo normal. Ahora imagina que vas hacia atrás por la página con Mayús+Tab. El navegador tiene que traer a la vista el elemento que acaba de recibir el foco, y para eso lo sube hasta el borde superior de la ventana. Que es exactamente donde está la cabecera.
Resultado: el elemento enfocado aterriza detrás de ella. Pulsas Mayús+Tab, el anillo de foco desaparece de la pantalla, y no tienes ni idea de dónde estás.
Esto se puede medir sin instalar nada. Para cada elemento enfocable de la página: colocas el desplazamiento por debajo, le das el foco, dejas que el navegador haga su ajuste mínimo, y miras si el rectángulo resultante cae dentro de los 61 píxeles de la cabecera.
En la portada, ocho de veinticuatro elementos enfocables quedaban tapados por completo. Entre ellos el campo del correo y su botón, o sea el formulario entero.
El arreglo es una línea de CSS: scroll-margin-top en los elementos enfocables, con un valor por
encima de la altura de la cabecera. Le dice al navegador que deje ese hueco al desplazar. Volvimos a
pasar la misma medición después: cero.
Ojo con la primera medición, porque estuvo a punto de salir mal. La primera versión del script contaba ocho elementos tapados que resultaron ser los de la propia cabecera. Estar dentro de la cabecera no es estar tapado por ella. Corregimos el script para excluir sus descendientes, volvimos a medir, y salió cero: el criterio pasaba bajando. Solo simulando la navegación hacia atrás apareció el fallo de verdad.
Lo demás
Faltaba el enlace de salto al contenido, que es el criterio 2.4.1 y de nivel A. Sin él, quien navega con teclado atraviesa los ocho elementos de la cabecera en cada página antes de llegar al texto.
El botón que cambia de tema se anunciaba como «Theme, botón» a un lector de pantalla en español. Un nombre accesible es texto de interfaz y se traduce como el resto; se nos escapó porque nunca se ve en pantalla.
Y el menú no marcaba en qué página estabas. Un aria-current convierte una lista de enlaces en una
posición.
Lo que no tocamos, y por qué
De la revisión de diseño salió que varios enlaces miden 22 píxeles de alto, por debajo de los 24 que pide el criterio de tamaño de objetivo. Antes de cambiar nada fuimos a leer la excepción: un objetivo pequeño cumple igual si un círculo de 24 píxeles centrado en él no se cruza con el del vecino. En la navegación hay 20 píxeles de separación horizontal y 12 en vertical cuando envuelve, y con esos anchos los círculos no llegan a tocarse.
O sea que ya cumplía. Cambiarlo habría sido tocar una maquetación probada para mejorar un número que ya estaba bien.
También revisamos si hacía falta respetar prefers-reduced-motion. No hay ni una transición ni una
animación en toda la hoja de estilos, así que no hay movimiento que reducir. Y no hay una sola
etiqueta <img> en las treinta y una páginas, con lo cual no hay ningún texto alternativo que falte.
Las dos cosas son consecuencia de un sitio hecho solo con tipografía.
Lo que no pudimos comprobar
El criterio de reflujo pide que a 320 píxeles de ancho no haga falta desplazamiento horizontal. Chrome no deja encoger una ventana por debajo de 606, y ahí no desborda nada. En la hoja de estilos no hay ningún ancho fijo por encima de 99 píxeles, así que nada apunta a que se rompa, pero eso es un indicio y no una medición. Queda sin comprobar, y lo decimos porque la diferencia importa.
Por qué contamos esto
Podríamos haber publicado la web sin decir nada y arreglarlo por el camino. Pero vendemos una herramienta que le dice a la gente lo que está mal en su sitio, y el mínimo que se nos puede exigir es enseñar lo que estaba mal en el nuestro con el número al lado.
De paso, tres de los cinco fallos de esta entrada los encontró una máquina ejecutando una regla, y los otros dos alguien mirando con un caso concreto en la mano. Sigue ganando el segundo método.