Cómo probar el contraste: herramientas y método

Una paleta que aprobó su auditoría de accesibilidad en marzo puede estar fallando en junio. No pasó nada dramático —marketing calentó un paso el azul de marca, se lanzó un tema oscuro, alguien añadió un panel tintado para los destacados— y cada cambio volvió a barajar en silencio decenas de combinaciones de texto sobre fondo que nadie volvió a comprobar. La auditoría fue real; simplemente midió un producto que ya no existe.

Probar el contraste tiene dos modos: auditar —comprobar combinaciones que ya existen, con un verificador de contraste de color, las herramientas de desarrollo del navegador o un escáner automatizado— y construir —crear la paleta de modo que cada combinación se compruebe en el momento en que se deriva—. Un flujo de trabajo que aguanta los combina: construye con los mínimos ya integrados, escanea cada versión en busca de regresiones y reserva la atención humana para las decisiones de criterio que ninguna herramienta puede tomar. Esta parte de nuestra guía de contraste expone el método y la aritmética que hay detrás.

¿Cuáles son las dos formas de probar el contraste?

Auditar toma la paleta como algo dado y pregunta si aprueba. Sus herramientas reciben dos colores y devuelven un ratio, o rastrean páginas renderizadas y marcan los fallos. Auditar es como conoces el estado de lo que existe: una base de código heredada, un sitio de marketing, el sistema de diseño del año pasado.

Construir mueve la comprobación al origen. En lugar de elegir colores y probarlos después, cada rol de color —texto de cuerpo, texto atenuado, un borde, un anillo de foco— se deriva frente a las superficies sobre las que se asentará, con el mínimo requerido aplicado en la derivación. Una combinación que fallaría nunca llega a emitirse, así que la salida no necesita una primera auditoría: aprueba por construcción.

Los dos modos no son rivales: prueban momentos distintos. La auditoría mira hacia atrás, a lo que ya se lanzó; la construcción mira hacia adelante, a lo que está a punto de lanzarse.

¿Por qué falla auditar solo a gran escala?

Por la aritmética. Una paleta de producto modesta lleva unos 17 roles de color semánticos: varios niveles de texto, bordes, foco, estados, rellenos y el texto sobre ellos. Distribuye esos roles entre, pongamos, 6 superficies (página, tarjeta, panel tintado, encabezado, dos rellenos) y 2 temas, y tienes en tus manos 17 × 6 × 2 = 204 combinaciones de rol y superficie. No todas las combinaciones aparecen en la interfaz, pero la superficie de auditoría honesta se adentra bien en las tres cifras, y cada retoque de marca, cada nueva superficie, cada tema añadido vuelve a barajar una parte.

Nadie vuelve a auditar doscientas combinaciones a mano después de cada cambio de paleta y, en la práctica, nadie finge hacerlo: las auditorías manuales muestrean. El muestreo encuentra los fallos que pensaste en buscar —texto de cuerpo sobre blanco— y se pierde los que no: texto atenuado sobre el panel tintado, en modo oscuro, después del cambio de marca de junio. La construcción invierte la economía. Las comprobaciones se ejecutan donde ocurren los cambios, así que un retoque de paleta vuelve a comprobar todo lo que toca, al coste de cero atención adicional.

¿Qué debe haber en el kit de auditoría?

Incluso con la construcción en marcha, auditar conserva tres funciones: evaluar lo que heredaste, atrapar regresiones y verificar la verdad renderizada. El kit, por categorías:

• Verificadores par a par: pega dos colores, lee el ratio. Adecuados para decisiones puntuales y para zanjar desacuerdos sobre una sola combinación.
• Herramientas de desarrollo del navegador: la mayoría de los navegadores muestran el ratio de contraste del texto seleccionado y marcan los fallos frente a los mínimos de WCAG, medidos en la página renderizada. Adecuadas para verificar la realidad más que la intención: lo que la pantalla del usuario realmente compone, incluyendo opacidad y superposición.
• Escáneres automatizados: rastrean páginas o se ejecutan en CI, marcan combinaciones que fallan en masa. Adecuados para cubrir regresiones entre versiones.
• Revisiones puntuales manuales: una persona mirando pantallas reales. Adecuadas para todo lo que las herramientas no pueden clasificar, que es de lo que trata la próxima sección.

Scale Composer está al otro lado de la línea: es una herramienta de construcción, que deriva roles con los mínimos aplicados a medida que se construye la paleta, así que la descripción honesta del flujo de trabajo es: construye ahí y luego audita lo que el renderizado hizo con el resultado.

¿Qué detectan los escáneres automatizados y qué se les escapa?

Los escáneres calculan ratios bien y sin cansarse; da esa parte por resuelta. Lo que no pueden hacer es saber qué significan las cosas. Un escáner no distingue el texto decorativo del contenido, así que marca marcas de agua que debería ignorar. No distingue un control deshabilitado de uno habilitado que simplemente se ve gris: el primero está exento de los mínimos, el segundo es un fallo real. No puede juzgar de forma fiable qué colores cuentan como adyacentes para un borde o un icono, ni si el texto que se asienta sobre una fotografía es accidental o está pensado para leerse. Cada una de esas decisiones cambia si un mínimo aplica siquiera, y cada una es un juicio sobre la intención, no aritmética.

Así que la división del trabajo es estable: las máquinas verifican números, las personas verifican el significado. Un flujo de trabajo que pide a las personas recalcular ratios malgasta la atención justo donde es escasa; uno que pide a los escáneres clasificar la intención produce tanto falsas alarmas como falsa tranquilidad.

¿Cómo es la comprobación en tiempo de construcción?

En Scale Composer, una paleta no es una lista de hex elegidos a mano, sino un conjunto de roles derivados: niveles de texto, bordes, foco, estados, cada uno calculado frente a cada superficie con el mínimo seleccionado —AA o AAA— aplicado en el momento de la derivación. Los roles de texto se puntúan por legibilidad en lugar de por contraste máximo, las etiquetas sobre rellenos recurren a un color de anclaje cuando el blanco o el negro puros no pueden sostenerlas, y una paleta oscura derivada vuelve a ejecutar cada comprobación en lugar de heredar los veredictos del modo claro. El valor Lc de APCA se calcula junto a cada ratio de WCAG como una segunda lectura.

Abre una paleta derivada y observa cómo suceden las comprobaciones — cambia un color semilla y cada combinación afectada se vuelve a derivar con su ratio recalculado en el sitio.

¿Cuál es el método, paso a paso?

1. Construye con los mínimos. Deriva los roles de la paleta frente a cada superficie con el mínimo AA (o AAA) aplicado en la derivación: aquí es donde las 204 combinaciones quedan cubiertas, una vez, de forma estructural.
2. Anota las decisiones de criterio. Decide qué es decorativo, qué está deshabilitado, qué está exento, y ponlo por escrito, para que escáneres y personas coincidan en qué entra en el alcance antes de que nadie mida nada.
3. Escanea cada versión. Deja que un escáner automatizado recorra el producto renderizado en busca de regresiones: hex codificados a mano, sorpresas de opacidad, un componente que se saltó la paleta.
4. Revisa puntualmente los casos de criterio. Ojos humanos sobre las cuestiones de adyacencia, el texto sobre imágenes, el color que porta significado y todo lo que el escaneo marcó como ambiguo.
5. Vuelve a derivar, no parchees. Cuando la marca cambia, cambia la semilla y deja que los roles se vuelvan a derivar con sus comprobaciones: parchear a mano un hex que falla es como las paletas se salen de nuevo del cumplimiento.

Mueve las comprobaciones al principio

La diferencia entre los dos modos se siente mejor haciendo ambos. Lleva una paleta por la auditoría y la construcción — primero lee las combinaciones como lo haría un verificador, una a una, y luego cambia la semilla y observa cómo cada rol afectado se vuelve a derivar frente a su mínimo de una sola vez.