Simular deficiencias de visión y preferencias del usuario
Las emulaciones de visión disponibles, qué representa cada una y a cuánta gente afecta, y las preferencias del sistema que cambian tu interfaz sin que lo sepas.
Diseñar una interfaz mirándola con visión normal, en un buen monitor, con luz controlada y sin ninguna preferencia de accesibilidad activa es diseñar para una fracción del público. Las simulaciones del navegador no sustituyen a probar con usuarios reales, pero convierten en visible en diez segundos un problema que de otro modo solo descubre alguien que lo sufre. Y hay una categoría entera de fallos —los que aparecen cuando el sistema fuerza colores o reduce el movimiento— que solo se detectan emulando, porque tu máquina no tiene esas preferencias activas.
- Activar las simulaciones de deficiencia de visión y saber qué modela cada una.
- Diseñar una interfaz que no dependa solo del color para transmitir información.
- Emular las preferencias del usuario y verificar que tu interfaz las respeta.
- Detectar los fallos que solo aparecen en modo de colores forzados.
Las simulaciones disponibles
Viven en la pestaña de renderizado del cajón inferior, accesible desde el menú de comandos buscando rendering. La lista habitual incluye seis.
Protanopía. Ausencia de los conos sensibles al rojo. El rojo se percibe oscuro y se confunde con el verde y con el marrón. Afecta aproximadamente al uno por ciento de los hombres.
Deuteranopía. Ausencia de los conos sensibles al verde. Es la deficiencia más común de todas, con una prevalencia en torno al uno por ciento de los hombres para la forma completa y bastante mayor para la parcial. Confunde el rojo con el verde igualmente.
Tritanopía. Ausencia de los conos sensibles al azul. Mucho más rara, y afecta por igual a ambos sexos. Confunde el azul con el verde y el amarillo con el violeta.
Acromatopsia. Ausencia total de percepción del color. Rarísima como condición congénita, y muy útil como prueba: si tu interfaz funciona en escala de grises, funciona con cualquier deficiencia de color.
Visión borrosa. Modela una agudeza reducida sin corregir. No es una condición concreta sino una aproximación a leer sin gafas, con cansancio, o en una pantalla mala. Es sorprendentemente buena detectando texto demasiado fino o demasiado pequeño.
Contraste reducido. Modela la pérdida de sensibilidad al contraste, muy frecuente con la edad y en varias condiciones oculares. Es la que más problemas revela en interfaces modernas con mucho gris sobre gris.
Sumando las formas comunes de deficiencia de color, se estima que alrededor del ocho por ciento de los hombres y algo menos del uno por ciento de las mujeres de ascendencia europea tienen alguna. En una aplicación con cien mil usuarios eso son varios miles de personas.
La simulación más rentable de las seis no es ninguna de las de color: es la de contraste reducido, porque detecta el fallo más extendido en las interfaces actuales, que es el gris claro sobre blanco en textos secundarios, etiquetas de formulario y estados desactivados. Actívala en cualquier aplicación y cuenta cuántos elementos desaparecen.
La regla que las simulaciones enseñan
Casi todos los fallos que revelan estas simulaciones tienen la misma causa: el color es el único portador de una información. Los ejemplos se repiten en todos los proyectos.
Un campo de formulario con error marcado solo con borde rojo. Con deuteranopía, ese borde es indistinguible del gris normal. La solución es añadir un icono y un mensaje de texto, no cambiar el rojo.
Un gráfico con series distinguidas solo por color de línea. La solución son patrones de trazo distintos, marcadores de forma distinta, o etiquetado directo de cada serie.
Un enlace dentro de un párrafo distinguido solo por color. Es el caso que las pautas mencionan explícitamente: si el único distintivo es el color, el ratio de contraste entre el enlace y el texto circundante tiene que ser al menos 3, o hay que añadir otra señal, y el subrayado es la que todo el mundo entiende.
Un estado activo o seleccionado marcado solo con un fondo de color. La solución es añadir un borde, un peso tipográfico o un icono.
Un semáforo de estado con puntos rojo, ámbar y verde. Sin formas ni texto, es exactamente el peor caso posible.
La regla operativa que las cubre todas: cualquier información transmitida por color debe estar transmitida también por otra vía. Y la prueba de que se cumple es activar la acromatopsia y comprobar que la interfaz sigue siendo comprensible.
Emular las preferencias del sistema
El segundo grupo de emulaciones, en el mismo panel, no simula la visión del usuario sino su configuración. Son las que cambian qué reglas de tu CSS casan.
prefers-reduced-motion con valor de reducción. Debería desactivar o suavizar tus animaciones. Casi ningún proyecto lo implementa y muchos usuarios lo tienen activo porque el movimiento les produce mareo o migraña. La prueba: actívalo y comprueba que nada se mueve más de lo imprescindible.
prefers-contrast con más y menos contraste. Menos probado todavía y con soporte creciente.
prefers-reduced-transparency. Para interfaces con cristales esmerilados y superposiciones translúcidas.
prefers-color-scheme, ya visto, para el modo oscuro.
forced-colors, que merece su propio apartado.
El modo de colores forzados
Es el más destructivo y el menos probado. Cuando el sistema operativo activa un tema de contraste alto, el navegador sustituye tu paleta entera por un conjunto reducido de colores del sistema: un color de texto, uno de fondo, uno de enlace, uno de botón, uno de elemento desactivado. Tus colores dejan de existir.
Los fallos que produce son característicos y todos aparecen con la emulación activada.
Los iconos dibujados con fondos desaparecen, porque el fondo pasa a ser el del sistema y el icono también. Los iconos de SVG con fill: currentColor sobreviven; los que dependen de un fondo, no.
Las imágenes de fondo se conservan pero el texto encima cambia de color, produciendo combinaciones ilegibles.
Los bordes desaparecen o aparecen donde no los había. Un elemento que dependía de un fondo de color para delimitarse se vuelve invisible; hay que darle un borde real, aunque sea transparente en el modo normal, porque en colores forzados los bordes transparentes se pintan.
Los estados dejan de distinguirse. Un botón activo y uno inactivo que se diferenciaban solo por el tono acaban idénticos.
Las propiedades para trabajar con este modo son forced-color-adjust, que permite decirle al navegador que respete tus colores en un elemento concreto —usar con muchísima moderación—, y la media query forced-colors para escribir reglas específicas. Los colores del sistema se referencian con palabras clave como CanvasText, Canvas, LinkText, ButtonFace y ButtonText.
Todas las emulaciones de esta lección tienen la misma propiedad peligrosa que ya vimos con los estados forzados y con el throttling: son intervenciones silenciosas que persisten mientras las DevTools estén abiertas y que no dejan ninguna señal llamativa. Una simulación de deuteranopía activada hace media hora hace que veas la aplicación con los colores mal, y la primera reacción de cualquiera es pensar que alguien ha roto la paleta. Un prefers-reduced-motion olvidado hace que las animaciones no se disparen, y estás depurando por qué tu librería de animación no funciona cuando lo que ocurre es que sí funciona y está respetando correctamente una preferencia que tú mismo le pediste emular. Un forced-colors residual convierte la interfaz en algo irreconocible. Los tres casos han producido informes de bugs contra código perfectamente sano. Hay dos hábitos que lo evitan y ambos son baratos. El primero, específico: la pestaña de renderizado muestra qué emulaciones están activas de un vistazo, así que tenerla abierta en el cajón mientras trabajas con ella hace visible el estado. El segundo, general y ya enunciado varias veces en esta guía porque es el más rentable de todos: cuando algo se comporte de forma inexplicable, la primera hipótesis no es un bug del navegador ni de tu código, es una intervención tuya que se te olvidó. La secuencia de comprobación cuesta veinte segundos y descarta casi todo: cerrar las DevTools y recargar, o abrir la página en una ventana nueva sin panel. Si el comportamiento desaparece, era tuyo. Si persiste, ahora sí, empieza a investigar.
Coge la pantalla más importante de tu aplicación y recórrela con las seis simulaciones activadas una por una, apuntando cada elemento que deje de ser comprensible. Después activa el modo de colores forzados. La lista que salga es, casi con seguridad, la lista de deudas de accesibilidad más rentable que vas a producir en una tarde, y no requiere ninguna herramienta externa ni ninguna auditoría.