Cuando diseñamos una web, el color interviene en muchas más decisiones de las que puede parecer a simple vista. Define buena parte de su identidad visual, nos ayuda a establecer jerarquías, diferenciar elementos, destacar acciones o comunicar determinados estados. Pero una combinación que funciona perfectamente desde un punto de vista estético no tiene por qué funcionar igual de bien para todo el mundo.
El contraste entre texto y fondo es probablemente el ejemplo más evidente. Un texto puede parecernos perfectamente legible en nuestro monitor y, sin embargo, resultar difícil de leer en otras condiciones o para una persona con determinadas dificultades visuales. Pero los problemas de accesibilidad relacionados con el color no terminan ahí. También aparecen cuando dependemos únicamente de él para distinguir un enlace, señalar un error, identificar el estado de un elemento o transmitir información.
Por eso, cuando diseño una web, no considero que una paleta esté resuelta simplemente porque los colores funcionen bien juntos. También hay que pensar cómo se comportarán cuando los llevemos a una interfaz real y empecemos a combinarlos en textos, fondos, botones, formularios y otros elementos.
Esto no significa que tengamos que renunciar a una determinada identidad visual o limitar innecesariamente nuestras posibilidades como diseñadores web. En muchos casos basta con entender dónde está el problema y buscar una solución que conserve la intención del diseño. Y cuanto antes tengamos en cuenta la accesibilidad, menos probable será que acabemos intentando corregirla a base de parches durante la maquetación.
Cómo puede afectar el color a la accesibilidad
Cuando pensamos en accesibilidad y color, lo primero que suele venirnos a la cabeza es el contraste. Tiene sentido: si el color de un texto y el de su fondo son demasiado parecidos, habrá personas que tendrán dificultades para leerlo. Es un problema fácil de entender y, además, relativamente sencillo de medir.
Sin embargo, una combinación de colores puede tener un contraste perfectamente válido y seguir formando parte de un diseño poco accesible. Ocurre cuando utilizamos el color como única forma de comunicar algo que el usuario necesita percibir para entender o utilizar la interfaz.
Pensemos, por ejemplo, en un formulario que marca en rojo los campos que contienen un error, pero no muestra ningún icono, mensaje ni otra indicación que permita identificarlos. El problema no está necesariamente en qué rojo hemos elegido. Está en que hemos confiado toda esa información al color.
Algo parecido puede suceder con una gráfica cuyas series solo se distinguen mediante colores, con los estados de una aplicación, con determinados controles o incluso con algo tan habitual como los enlaces dentro de un texto. Si eliminar mentalmente el color hace que desaparezca información necesaria para entender qué estamos viendo o qué podemos hacer, probablemente convenga revisar el diseño.
Esto hace que al trabajar con el color tengamos que plantearnos dos cuestiones diferentes. Por un lado, si existe suficiente contraste para percibir correctamente los elementos. Por otro, si estamos utilizando el color como apoyo visual o le estamos encomendando una función que no debería desempeñar por sí solo.
Son problemas distintos y también requieren soluciones diferentes. Para el primero podemos medir y ajustar nuestras combinaciones de color. Para el segundo tendremos que revisar cómo hemos planteado la propia interfaz.
El contraste entre colores
Una de las primeras cosas que debemos comprobar al trabajar con una paleta es qué ocurre cuando empezamos a combinar sus colores. Podemos tener un tono corporativo perfectamente válido y un gris que funciona muy bien para los textos y descubrir que, al colocar uno sobre otro, la legibilidad se resiente.
Aquí entra en juego el contraste, que no depende simplemente de que dos colores nos parezcan suficientemente diferentes. Podemos percibir con claridad que son distintos y, aun así, no existir suficiente diferencia de luminosidad entre ellos para que determinados usuarios distingan correctamente el contenido.
Las pautas WCAG establecen una relación de contraste mínima de 4,5:1 para el texto normal y de 3:1 para el texto grande si queremos alcanzar el nivel AA. En el nivel AAA los valores aumentan hasta 7:1 y 4,5:1, respectivamente.
Conviene detenerse un momento en qué significa «texto grande», porque no depende de nuestra impresión visual. WCAG considera como tal el texto de al menos 18 puntos, o 14 puntos cuando está en negrita. Trasladado a las unidades que utilizamos habitualmente en una web, hablamos aproximadamente de 24 px y 18,66 px.
Estas cifras no deberían entenderse como una receta para diseñar una paleta ni como una frontera entre un diseño bueno y uno malo. Son criterios que nos permiten comprobar si una determinada combinación alcanza unos mínimos de accesibilidad. De hecho, un mismo color puede funcionar perfectamente como fondo con texto blanco y no hacerlo con otro de los colores que forman parte de la misma identidad visual.
Por eso me parece más útil pensar en combinaciones accesibles que en colores accesibles. Al diseñar podemos establecer qué colores funcionan entre sí y reservar determinadas variantes para aquellos usos en los que necesitemos mayor contraste. Así evitamos descubrir durante la maquetación que el color elegido para un botón, un texto secundario o un determinado fondo nos obliga a improvisar una solución.
Y el texto no es el único elemento que debemos tener en cuenta. Determinados componentes de la interfaz y objetos gráficos necesarios para comprender o utilizar la página también necesitan distinguirse de los colores adyacentes. WCAG establece en estos casos una relación mínima de 3:1. El borde que permite identificar un campo de formulario o un icono necesario para entender un control pueden plantear, por tanto, el mismo tipo de problema.
Esto último es especialmente fácil de pasar por alto cuando diseñamos interfaces muy limpias, en las que tendemos a utilizar diferencias de color muy sutiles para delimitar elementos. Visualmente pueden funcionar muy bien, pero conviene comprobar que esa sutileza no termine haciendo que una parte necesaria de la interfaz resulte difícil de percibir.
Comprobar el contraste antes de empezar a maquetar
No hace falta esperar a tener la web terminada para saber si una combinación de colores va a darnos problemas. De hecho, si estamos trabajando en el diseño, este es probablemente el mejor momento para comprobarlo. Cambiar ligeramente un tono o decidir que dos colores no deben utilizarse juntos resulta mucho más sencillo ahora que cuando esa combinación ya se repite por toda la interfaz.
Podemos hacer una primera selección de las combinaciones que realmente vamos a necesitar y comprobar su relación de contraste. No se trata de enfrentar todos los colores de la paleta entre sí, sino de pensar en su función. Qué color utilizaremos para el texto principal y el secundario, cuáles servirán como fondo, cómo serán los botones, qué variantes necesitaremos para los distintos estados o qué colores podrán aparecer superpuestos.
Para medirlo existen herramientas específicas como Contrast Checker de WebAIM, en las que basta con introducir los colores de primer plano y fondo para obtener su relación de contraste y comprobar qué niveles de WCAG alcanzan. Las propias herramientas de diseño también pueden incorporar esta comprobación mediante sus funciones nativas o plugins, lo que permite detectar el problema sin salir del proceso de diseño.
Lo importante es no fiarnos únicamente de nuestra percepción. Que nosotros leamos perfectamente un texto o distingamos con claridad el límite de un componente no nos dice cuál es su relación de contraste. La comprobación numérica tampoco sustituye nuestro criterio como diseñadores, pero nos aporta un dato objetivo que podemos incorporar a la decisión.
Detectar problemas de contraste en una web ya maquetada
Cuando la web ya existe, el planteamiento cambia. Podemos seguir comprobando manualmente una combinación concreta, pero ya no tenemos delante una paleta de colores aislada, sino una interfaz completa en la que esas combinaciones aparecen en numerosos elementos y estados.
En este caso resultan especialmente útiles las herramientas de auditoría del navegador y soluciones como axe DevTools, capaces de detectar automáticamente muchos problemas de contraste y señalar los elementos afectados. Esto nos permite localizar casos que pueden haber pasado inadvertidos durante el diseño o que han aparecido posteriormente al implementar la interfaz.
Las auditorías automáticas son muy útiles, pero no deberíamos entender un resultado sin errores como garantía de que hemos resuelto todos los problemas relacionados con el color. Hay situaciones que necesitan una revisión visual y funcional, especialmente cuando intervienen imágenes, degradados, transparencias, cambios de estado o elementos cuyo significado depende de cómo se utilizan dentro de la interfaz.
Por eso tiene sentido combinar ambas formas de trabajar. Durante el diseño podemos evitar buena parte de los problemas definiendo desde el principio combinaciones que sabemos que funcionan. Durante la maquetación y las pruebas podemos comprobar que esas decisiones se han trasladado correctamente a la web y detectar los casos que solo aparecen cuando el diseño empieza a comportarse como una interfaz real.
Corregir los problemas de contraste sin renunciar al diseño
Encontrar una combinación que no alcanza el contraste necesario no significa que tengamos que rehacer la paleta de colores. Antes de cambiar nada conviene preguntarnos qué función desempeñan esos colores y hasta qué punto necesitamos que aparezcan juntos.
En ocasiones la solución será tan sencilla como oscurecer el color del texto o aclarar el fondo hasta alcanzar el contraste necesario. Pero no hay un porcentaje de ajuste que funcione siempre ni tiene demasiado sentido hacerlo a ojo. Podemos modificar progresivamente el color y volver a medir hasta encontrar una variante que cumpla sin alejarnos innecesariamente de la intención original.
Otras veces resulta más interesante cambiar la combinación que modificar los colores. Un color corporativo que no funciona para un texto sobre fondo blanco puede seguir siendo perfectamente válido para otros elementos de la interfaz. Podemos mantenerlo dentro de la identidad visual y utilizar una variante más oscura allí donde necesitemos texto, iconos u otros elementos con mayor contraste.
Esto es especialmente útil cuando trabajamos con sistemas de diseño algo más amplios. En lugar de pensar que tenemos un azul, un gris o un color de acento para utilizar indistintamente en cualquier contexto, podemos definir variantes según su función. De esta forma no tenemos que resolver una y otra vez el mismo problema cada vez que aparece una combinación determinada.
Texto sobre imágenes, degradados y transparencias
Las cosas se complican cuando el fondo no tiene un color uniforme. Una fotografía puede ofrecer un contraste excelente detrás de una palabra y muy pobre unos píxeles más allá. Algo parecido sucede con determinados degradados y, en menor medida, con transparencias que hacen que el color resultante dependa de lo que haya debajo.
En estos casos no podemos limitarnos a comprobar dos valores de color y dar el problema por resuelto. Tenemos que asegurarnos de que el contraste se mantiene en toda la zona sobre la que puede aparecer el contenido.
Una solución habitual consiste en añadir una capa de color entre la imagen y el texto que reduzca sus variaciones y nos proporcione un fondo más predecible. También podemos reservar una zona de la imagen para el contenido, utilizar un fondo propio detrás del texto o elegir una composición en la que ambos elementos no tengan que competir entre sí.
Las sombras y los contornos pueden ayudar a separar visualmente el texto del fondo, pero no los utilizaría como sustitutos de una combinación con suficiente contraste. Si necesitamos una sombra muy marcada para conseguir que un título pueda leerse sobre una fotografía, probablemente merezca la pena revisar primero cómo hemos planteado esa parte del diseño.
No olvidarse de los estados de la interfaz
Una combinación accesible en su estado inicial tampoco garantiza que el componente lo siga siendo cuando interactuamos con él. Enlaces, botones, campos de formulario y otros controles pueden cambiar de color al pasar el cursor, recibir el foco, activarse o quedar deshabilitados.
Por eso las variantes de hover, focus, active y otros estados deberían formar parte de las decisiones de color desde el diseño, aunque algunas de ellas no se manifiesten hasta que maquetamos la interfaz. No tiene demasiado sentido comprobar cuidadosamente un botón para descubrir después que el texto pierde contraste precisamente cuando pasamos el cursor sobre él.
El modo oscuro plantea una situación parecida. No basta con invertir fondos y textos o reutilizar automáticamente los mismos colores que empleamos en la versión clara. Cada tema genera sus propias combinaciones y debemos comprobarlas como tales.
Al final, solucionar un problema de contraste suele resultar mucho más sencillo cuando podemos modificar una decisión concreta que cuando tenemos que perseguir sus consecuencias por toda la web. Diseñar teniendo previstas estas combinaciones no elimina la necesidad de revisar la interfaz una vez maquetada, pero sí reduce considerablemente la cantidad de correcciones que tendremos que hacer después.
Cuando el color es la única forma de transmitir información
Resolver el contraste no garantiza por sí solo que estemos utilizando el color de forma accesible. Podemos tener una interfaz en la que todas las combinaciones superen holgadamente los valores mínimos y, aun así, encontrarnos con usuarios que no puedan distinguir parte de la información que estamos comunicando.
La solución no consiste necesariamente en dejar de utilizar el color. Al contrario, el color es un recurso visual muy útil para reforzar significados y facilitar que identifiquemos rápidamente determinados elementos. Lo que debemos evitar es que sea la única pista disponible cuando esa diferencia resulta necesaria para comprender el contenido o utilizar la interfaz.
Errores, avisos y estados
Volvamos al ejemplo del formulario que planteábamos al principio. Si utilizamos un borde rojo para indicar que un campo contiene un error, podemos conservarlo, pero deberíamos acompañarlo de alguna otra indicación. Un mensaje que explique el problema no solo evita depender del color, sino que resulta bastante más útil para cualquier usuario que simplemente mostrarle que algo ha ido mal.
La misma idea se puede aplicar a mensajes de éxito, advertencias o estados de una interfaz. Verde, amarillo y rojo pueden ayudarnos a reconocerlos con rapidez, pero podemos acompañarlos de texto, iconos u otros recursos visuales que permitan diferenciarlos aunque el usuario no perciba esos colores como habíamos previsto.
Esto tiene además una ventaja desde el propio diseño. En lugar de pedirle al color que cargue con todo el significado, podemos utilizarlo para reforzar una jerarquía que ya se entiende por otros medios. La interfaz se vuelve menos dependiente de una única decisión visual y, generalmente, también más clara.
Enlaces que realmente parecen enlaces
Los enlaces dentro de un bloque de texto son otro caso especialmente habitual. Cambiar únicamente su color puede parecernos suficiente para diferenciarlos, sobre todo si utilizamos el color corporativo de la web, pero no todos los usuarios percibirán esa diferencia de la misma manera.
El subrayado sigue siendo una solución sencilla y reconocible porque añade una característica que no depende del color. Podemos trabajar su grosor, separación o comportamiento para integrarlo en el diseño sin renunciar a esa pista visual.
Esto no significa que absolutamente todos los enlaces de una interfaz tengan que estar subrayados. Un elemento situado dentro de una navegación o un botón con una forma y posición claramente identificables cuenta con otras pistas que permiten reconocer su función. El contexto también forma parte del diseño.
Gráficas y otros contenidos visuales
En una gráfica resulta tentador asignar un color a cada serie y confiar en la leyenda para que el usuario establezca la correspondencia. Cuantas más series añadimos y más próximos son sus colores, más difícil puede resultar distinguirlas para determinadas personas.
Podemos reforzar esa diferenciación mediante etiquetas, patrones, tipos de línea, símbolos o cualquier otro recurso apropiado para la representación que estemos utilizando. No se trata de añadir todos a la vez, sino de proporcionar alguna característica adicional que permita interpretar la información sin depender exclusivamente del color.
La misma lógica sirve para mapas, diagramas y otras visualizaciones. Una buena pregunta durante el diseño es qué ocurriría si el usuario no pudiera percibir la diferencia entre los colores que hemos elegido. Si la información dejara de entenderse, necesitamos otra forma de expresarla.
Diseñar para distintas formas de percibir el color
Hasta ahora hemos hablado de evitar que el color sea imprescindible, pero también podemos intentar que la propia paleta facilite la diferenciación. No todas las personas percibimos los colores de la misma manera y determinadas combinaciones pueden resultar especialmente difíciles de distinguir para usuarios con algún tipo de deficiencia en la visión del color.
Esto no implica diseñar una versión diferente para cada forma posible de percepción. Podemos utilizar simuladores durante el proceso de diseño para comprobar cómo se comportan nuestras elecciones y detectar combinaciones problemáticas antes de que se conviertan en una parte estructural de la interfaz.
De nuevo, estas herramientas deberían ayudarnos a tomar decisiones, no sustituirlas. Una simulación puede mostrarnos que dos estados resultan difíciles de distinguir, pero tendremos que decidir si la solución adecuada es modificar los colores, introducir otra pista visual o replantear cómo estamos comunicando esa diferencia.
El objetivo tampoco es conseguir una interfaz que se vea exactamente igual para todo el mundo. Eso no sería realista. Lo importante es que las diferencias en la percepción del color no impidan acceder a información necesaria ni comprender cómo utilizar la web.
Incorporar la accesibilidad al diseño del color
Después de revisar todos estos casos puede parecer que diseñar una paleta accesible consiste en acumular restricciones: comprobar ratios, evitar determinadas combinaciones, añadir indicadores y prever qué ocurrirá en cada estado. En la práctica, me parece más útil verlo como una parte más del proceso de diseño.
Cuando definimos los colores de una web ya estamos tomando decisiones sobre su función. Hay colores que utilizaremos principalmente como fondo, otros destinados al texto, colores de acento y otros asociados a determinadas acciones o estados. Incorporar la accesibilidad en ese momento consiste en añadir algunas preguntas más: qué combinaciones podemos utilizar, cuáles debemos evitar y qué elementos necesitan algo más que un cambio de color para comunicar correctamente su función.
Este planteamiento permite conservar colores que forman parte de una identidad visual aunque no funcionen en todos los contextos. Un color corporativo con poco contraste sobre blanco no tiene por qué desaparecer de la web. Podemos reservarlo para superficies más grandes, elementos decorativos o combinaciones en las que sí funcione, y crear una variante adecuada cuando necesitemos utilizarlo en texto o en componentes que requieran mayor contraste.
También podemos dejar documentadas estas decisiones. Si establecemos desde el diseño qué combinaciones están permitidas y qué variantes corresponden a cada uso, la maquetación deja de convertirse en el momento en el que tenemos que decidir sobre la marcha cómo resolver cada problema. Esto cobra todavía más importancia cuando el diseño va a crecer, se reutilizan componentes o intervienen varias personas en el proyecto.
Para mí, esta es una de las ventajas de entender diseño y maquetación como partes conectadas de un mismo trabajo. Una decisión visual no termina en cómo se ve una composición estática. Tiene que seguir funcionando cuando aparecen contenidos reales, estados de interacción, distintos tamaños de pantalla y todas las situaciones que convierten ese diseño en una web.
Integrar la accesibilidad desde el principio no cambia el objetivo del diseño. Seguimos buscando una interfaz atractiva, coherente y reconocible, pero procurando que las decisiones que tomamos para conseguirlo no sean precisamente las que dificulten su uso a una parte de las personas que van a visitarla.
Deja una respuesta