Cómo diseñar una web o una app accesible

Escrito por Cris Busquets. Publicado en Diseño UI

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.

Conoce A11y y WCAG

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.

Cómo diseñar de forma accesible

Contraste del color

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 🙂

Si no se cumple el ratio, dificultamos la lectura del contenido y la comprensión del propio texto. Y no queremos esto, ¿verdad?

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.

Daltonismo

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.

No uses solo colores para dar feedback

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:

Jerarquía visual (tamaños y espaciados)

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.

No escribas en mayúsculas

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:

• Algunos lectores de pantalla leen estos textos letra por letra en lugar de las palabras.
• Se ralentiza la lectura en un 10%, según un estudio de Jacob Nielsen.
• Son textos que serán más difíciles de leer: como todas las letras parecen rectángulos del mismo alto y ancho, eliminamos la diferenciación visual que encontramos en las letras en minúscula.

Área táctil grande

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.

Lectores de pantalla

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í:

• Utilizar una composición lógica y lineal. Por ejemplo, cabecera, zona de contenido y barra lateral, además de elementos como listas, párrafos y encabezados lógicos (H1, H2, H3…).
• Redactar los enlaces con títulos descriptivos. Es decir, olvídate del “clic aquí” y utiliza un “contáctanos” o “escríbenos”.
• Sé breve con los textos. Evita las redundancias para que el lector de pantalla lea rápido y el usuario pueda navegar correctamente.

Conclusiones

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.

Esto también te interesa 👇

Cómo diseñar en un entorno que no se para

Que es un empty state, mejores prácticas y ejemplos

Principios de UX: Efecto goal-gradient y regla peak-end