Cuando empezamos un proyecto de diseño nos centramos en definir requisitos y empezar a bocetar wireframes, crear sistemas de diseño o guías de estilo y diseñar las pantallas. Pero (generalmente) no pensamos en hacerlo accesible ni condiciona excesivamente nuestras decisiones.
Habitualmente diseñamos con un sesgo inmenso: consideramos que la mayoría (o todos) nuestros usuarios no tienen problemas de visión, discapacidades en sus habilidades motrices o problemas cognitivos.
Y esto es un error.
Con este artículo quiero enseñarte qué es A11Y, WCAG, cómo diseñar de manera accesible y mostrarte que hacerlo no añadirá elementos innecesarios o “feos” a tu proyecto. Sigue leyendo, porque te cuento cómo aplicarlo de manera sencilla.
El Proyecto A11y ha sido creado por la propia comunidad de desarrolladores y diseñadores que promueve la creación y diseño de páginas web y aplicaciones que sean accesibles. En su página web encontrarás contenido de todo tipo que te ayudará a implementarlo fácilmente.
World Content Accessibility Guidelines (WCAG) busca definir las pautas que debe cumplir cualquier producto digital para ser considerado accesible. Si eres una empresa privada no tienes la obligación legal de considerarlas, pero sería conveniente hacerlo: todos tus usuarios tienen derecho a una misma experiencia.
Cada pauta del WCAG tiene definidos tres niveles: A (mínimo), AA (medio) y AAA (alto). Se considera “estándar” el nivel AA. (lee aquí las pautas del WCAG en español).
Es cierto que ambos están un poco más enfocados a la parte del desarrollador, pero esto no excluye que como diseñadores debamos tenerlas mínimamente en cuenta.
En general, a los diseñadores nos gusta diseñar con poco contraste.
Si podemos utilizar un tono de gris sobre un fondo gris para que quede todo “mejor integrado”, usaremos este recurso antes de poner texto negro o de otro color que se vea más.
El WCAG define en el criterio 1.4.3 los parámetros que deben seguirse al establecer el contraste de color. Para el nivel AA se pide un ratio de contraste de 4,5:1 entre el fondo de pantalla y el contenido (texto).
Para hacerlo fácilmente, puedes utilizar Colorable o la Color Tool de Material Design 2.0 que te comenté en este artículo.
Como ves, en este caso el ratio sería de 9,51:1 🙂
Te voy a dejar con dos herramientas que te van a ser muy útiles para poder medir el contraste.
Una de ellas es Contrast, que se instala en tu Mac y, con una ventana flotante, te permite ir seleccionando colores de fondo y de texto para ver la información. Cuesta 6,99$ en la AppStore.
Existe otra aplicación, esta vez gratuita, que hace lo mismo. En este caso se llama Contraste (son muy originales los nombres…) y basta con instalarla para que funcione, no requiere ningún tipo de configuración.
Más allá de lo comentado en el punto anterior, hay que tener en cuenta que hay un porcentaje de la población que es daltónica.
Se trata de determinados defectos de la vista que limitan la percepción de algunos colores, que se confundan algunos de los que se persiguen e, incluso, una total ceguera de color.
Es útil trabajar con el plugin de Sketch Stark, que te va a permitir simular estos perfiles de color e incluso comprobar el contraste del mismo.
Muchas veces escogemos el rojo para señalar un error, azul para informar, amarillo para mostrar una alerta y verde para indicar
Pero… ¿qué pasa si nuestro usuario es daltónico? Sencillamente verá todo en color gris. Uno más oscuro que otro, sí, pero seguirán siendo dos tonos de gris.
Como ves, si añadimos un icono y, además, un mensaje descriptivo del error, lo tenemos solucionado:
Una página web y/o una aplicación suelen estar llenos de distintos tipos de contenidos que habitualmente separamos por bloques.
Es importante que esto esté bien jerarquizado y separado con suficientes espacios para que el usuario sepa qué contenido va con cuál.
Ojo, tampoco te pases con el espacio y dejes al título muy alejado del párrafo de texto… o al revés.
De esta forma tan sencilla facilitaremos la lectura y la comprensión del producto.
Hay veces que, por el motivo que sea, diseñamos pequeños titulares utilizando mayúsculas. Y, aunque no lo parezca, esto crea diferentes casuísticas a nivel de accesibilidad:
Quizás pensemos que este aspecto es un asunto más “de programadores”, pero es algo que debe nacer del diseño: lo que diseñemos es lo que se va a programar.
Muchas veces diseñamos botones con poco padding y muy pegado a los elementos que lo rodean, o usamos enlaces de texto muy juntos y en cuerpo de texto pequeño. Esto provoca que algunos botones o enlaces generen complicaciones: dificultad para hacer tab correctamente, seleccionar el de al lado, etc.
Aquí tienes las recomendaciones del World Wide Web Consortium (W3C) y las UI Guidelines de Apple.
O incluso, además, con combinaciones cromáticas que quizás no cumplen el criterio 1.4.3 con estándar AA de WCAG comentado en el primer punto.
Si hacemos esto -donde me incluyo- estamos dificultando el uso a aquellas personas con discapacidades motrices que tienen dificultad para controlar movimientos.
Por último, hablemos de los lectores de pantalla.
En pocas palabras, se trata de una aplicación de software que identifica e interpreta todo aquello que se muestra en pantalla y se lo “explica” al usuario mediante sintetizadores de texto a voz, sonidos o con una salida braille.
Mira aquí cómo leen una página web (no te asustes):
Para que funcionen correctamente y puedan leer y comunicar el contenido, debemos diseñar y programar así:
Naturalmente no se trata de un artículo que contemple todas las casuísticas, pero sí he intentado incluir las más comunes y las que podemos resolver de una forma más sencilla.
Como habrás visto, no es taaaan complicado diseñar teniendo en cuenta unos parámetros mínimos de accessibilidad 🙂
Si quieres ampliar información sobre el tema, te recomiendo el episodio 2×06 «Accesibilidad práctica» de WeCodeSign.
Me encantan todos tus artículos. Siempre aprendo cosas nuevas y releeo los que ya leí para aplicarlos a mi trabajo diario. Muchas gracias.
Fantásticos post Cris, muy agradecido por tu trabajo!
Un saludo!