Problemas de Accesibilidad asociados al color.

Primero indicar que es necesario no basarse en el color, tal y como se indica en las WCAG.

En el punto de verificación 2.1 de las WCAG 1.0 se indica ” Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores”.

Pongamos un ejemplo, que ocurre cuando por alguna razón diseñamos una tabla con barras de diferentes tonalidades de rojos, y ponemos una tablita indicando que significa cada tono de rojo. Vale, preciosa tabla, pero y si esa persona tiene por ejemplo Protanopia?. Los usuarios que tiene esta “disfunción visual“, tienen una carencia de sensibilidad al color rojo.

Genial hemos conseguido que los usuarios con esa discapacidad no puedan acceder, ni comprobar la información, solo por que hemos decidido poner ese color.

Puedo decir sin animo de equivocarme que la mayoría de los sitios que certifican Accesibilidad (no digamos los que no certifican), tienen carencias graves en los valores de brillo y contraste de los tonos empleados. Algunas veces por un leve descuido, otro por que el diseñador tiene mayor peso que la necesidad implícita de Accesibilidad, y otras por que no se ha tenido en cuenta. Existen otras situaciones pero prefiero obviarlas por los términos que se suelen emplear.

Información transmitida por el color.

Por ejemplo observemos este ejemplo, en el observamos un error de lo mas común. Indicamos y planteamos una funcionalidad basada en el color. El campo obligatorio está en color rojo.

Uso incorrecto de transmisión de información por el color

Esto es un grave problema para muchos usuarios, pues en cierta medida anteponemos criterios estéticos y comportamientos visuales corporativos a toda costa, sin valorar ni constatar el perjuicio que estamos ocasionando.

Como se resuelve este tipo de problemas?

Pues simplemente debemos poner por ejemplo, “Los campos obligatorios están marcados en rojo y con asterisco”, tal y como aparece en el ejemplo siguiente. La información se sigue transmitiendo por el color, pero también por el marcado. Independientemente del dispositivo o de la discapacidad visual, el asterisco está perfectamente marcado.

Caso de uso de transmisión de información por el color y marcado.

Brillo y color

El Punto de Verificación 2.2 de las WCAG 1.0 nos indica que las combinaciones de color de fondo y de primer plano deben ofrecer suficiente contraste para ser visualizadas por personas con discapacidad visual, o tener el suficiente contraste para pantallas en blanco y negro.

Para ello el W3C nos sugiere la utilización de un algoritmo que nos determinará un valor de contraste suficiente.

Por ejemplo debemos tener mucho cuidado con las combinaciones empleadas en el site. Los diseñadores tenemos una facilidad innata por poner tonos imposibles (muchos de mis profesores, dirían que en determinadas situaciones atentan contra la teoría del color), y sobre todo por poner una degradaciones de color, que queden bellísimas pero que a simple vista puedan pasar inadvertidas por muchos usuarios que no tengan ningún tipo de discapacidad visual, por lo que imaginemos lo que puede ocurrir con los que si la tengan.

A continuación os pongo una captura de mi pagina de FACEBOOK, en la que se puede observar como ese tono NO cumple las necesidades requeridas para validar en Brillo y Color.

Problemas en el todopoderoso Facebook.

En la captura de imagen anterior, podéis observar una de mis herramientas de cabecera, un magnifico plugin para Firefox (ColorChecker). Os animo a que lo instaléis, y que por ejemplo probéis haciendo click en la casilla de verificación “Selector de texto“,

Revisad por encima las siguiente webs, y comprobad que tipo de problemas de accesibilidad tienen los cuerpos de texto.

http://www.bde.es/webbde/es/

http://www.iberia.es

http://mailchimp.com/

Ahora bien, a pesar de que el W3C en las WCAG 1.0 recomienda la utilización del algoritmo anteriormente citado, el cual se basa en la diferencia de brillo y color, os recomiendo lo que a mi me han recomendado desde que salieron las WCAG 2.0.

Hay que utilizar el nuevo algoritmo de Luminosidad. Por que? pues por que las WCAG 2.0 conllevan una serie de revisiones y mejoras, el nuevo algoritmo ya es una mejora evidente.

Diferencias entre algoritmos

WCAG 1.0 (Algoritmo de Brillo y Color)

• La diferencia de brillo debe tener un rango igual o superior a 125 como mínimo.
• La diferencia de color debe tener un valor mínimo de 500.

OJO hay muchos sitios en los que los validadores o chequeadores de color, comentan algunas variaciones realizadas por HP creo recordar.

WCAG 2.0 (Algoritmo de Luminosidad)

• En función de la tamaño y estilo del texto e incluso de nivel de conformidad, se establecen como ratio mínimo de luminosidad, 3:1, 4.5:1 o 7:1.

Brillo y color en imágenes, logotipos, etc.

Cuando por ejemplo las imágenes lleven texto, esa información debe aparecer si o si en el ALT.

En las WCAG 2.0 los logotipos están exentos de cualquier tipo de restricción por contraste. Anteriormente en las WCAG 1.0 no es que se obligase a cumplir la restricción y ahora en las WCAG 2.0 no, simplemente que antes no se tenían en cuenta algunas particularidades como la implantación, o la experiencia documentada que genera el tiempo transcurrido entre las ambas WCAG.