CSS y Accesibilidad
Una de las cosas que más escucho entre profesionales de accesibilidad es el culto y adoración a HTML5 como máxima solución de la accesibilidad. Si bien es aproximadamente 80% cierto, la verdad es que con CSS podemos estar introduciendo algunos problemas de accesibilidad también.
Uso de la propiedad text-transform
Súper usado para igualar las versalitas/small capitals o incluso cambiar un texto que esta en minúscula a mayúscula. Esta propiedad crea problemas de lectura al entender las mayúsculas como siglas y en vez de leer la palabra, la deletrea.
Es el típico caso del "FOLLOW US" leído como "Follow U S" y parece que obligamos a seguir a Estados Unidos.
Ejemplo
Talkback & Android
"Registrate" en mayúsculas. [youtube RBI2J5RIpmw]
Posible solución
Uso de aria-label con el texto en minúscula o aria-labelledby que apunte hacia el ID de un span u otro elemento con el texto en minúscula.
<button class="uppercase" type="button" aria-label="registrate">Registrate</button>
Uso de la propiedad display
Esta propiedad parece muy inocente pero sus valores más problemáticos son:
inline-blockinline-flextableflex
Table
Este valor causa que el lector de pantalla interprete que ahí hay una tabla. A veces, dependiendo el contenido, solo con esto se puede producir el problema pero a veces viene en conjunto con el uso de display:table-cell en los elementos hijos.
Bloques en línea
Con el valor inline-block lee todo contenido "all at once" (de una vez). Problemático para, por ejemplo, el uso de botones ya que puede leer "aceptar" y "cancelar" en la misma oración y el usuario no sabe cual de los dos botones se acciona al presionar la barra espaciadora (SPACE BAR) o la tecla ENTER (las dos teclas que, por default, deberían activar un botón). Además, esto esta alterando la navegación por flechas con el uso del lector de pantalla.
Flex
Es un problema recurrente, lo usamos sin discreción, cambiamos la disposicion de elementos usando las propiedad flex-direction y align-self que quedan linda en pantalla pero rompe toda la logica de navegación para las personas con problemas motrices que utilizan el teclado como unico medio de interacción.
Tanto la lógica de navegación por TAB y la lógica de navegación por flechas con el lector de pantalla siguen la disposicion en el DOM y no el orden con el que se visualizan los elementos.
El uso de "content"
En los pseudo elementos como ::before y ::after el uso de la propiedad content el contenido es alcanzado por la gran mayoría de los lectores de pantalla.
Este elemento generalmente se utiliza para agregar iconografías o cambiar el diseño de un input (error grave de accesibilidad que voy a compartir en otra nota).
La mejor solución es simplemente agregar esas iconografías o emojis en un span oculto para el lector de pantalla.
<!DOCTYPE html>
<html>
<head>
<style>
.icon-mail::before {
content:'📧'
}
</style>
</head>
<body>
<p><span class="icon-mail" aria-hidden="true"></span> Contactános</p>
</body>
</html>
Uso de list-style-type: none
Es un problema que ocurre solo con Safari y VoiceOver. Remover el bullet (circulito) le quita la semántica de lista y el screen reader no anunca los elementos como lista. Si podemos evitar sacarlos pero cambiar el colorcito por algún color de nuestra guía de marca sería lo mejor.
Si no es posible por temas de diseño mantener el bullet, consideremos agregar a cada <ul> un role="list" para volver a insertarle la semántica.
Conclusión
Siempre que podamos probar nuestro código con alguna tecnología asistiva, como por ejemplo NVDA o simplemente probar la interacción del foco usando la tecla TAB, hagámoslo.
Un poco de datos:
La OMS –Organización Mundial de la Salud- nos confirma que cada cinco segundos una persona queda ciega en el mundo. Cada minuto, una de ellas es un niño.
La misma organización estima que cada año, en nuestro planeta, son más de siete millones las personas que pierden la visión
Por lo tanto, un pequeño cambio de CSS y una rápida pasada con una tecnología asistiva puede simplificar la vida de muchas personas.
Diseñá accesible.
Pensá accesible.