¿Tu web tiene barreras? Accesibilidad web
¿Cuándo desarrollas una web, piensas en la Accesibilidad? ¿Eres consciente de la barrera social que supone la falta de Accesibilidad en tu web? Esta semana, celebrando los 30 años que han cambiado la historia con World Wide Web, he reflexionado sobre los grandes avances que ha supuesto la web en nuestras vidas. Es por ello que hoy quiero hacer mención a un gran olvidado en muchos desarrollos web, la Accesibilidad.
El objetivo de la accesibilidad es capacitar a cada usuario, independientemente de las discapacidades, ofreciendo la misma experiencia, sin barreras.
“La discapacidad NO es una enfermedad, es una condición que tiene diferentes causas que dan como consecuencia que una persona tenga una capacidad (o varias) que lo hacen diferente a la mayoría en la sociedad.”
Estadística
Según la Organización Mundial de la Salud ...
- El 15% de la población mundial (más de mil millones de personas) tiene algún tipo de discapacidad.
- Se estima que 285 millones de personas tienen discapacidad visual.
- Se estima que 39 millones son ciegos
- Se estima que 246 millones tienen baja visión.
- 260 millones de personas en todo el mundo han perdido la audición
Aunque habitualmente pensamos que las discapacidades suelen ser auditivas o visuales, en realidad abarca mucho más, como por ejemplo, las deficiencias cognitivas.
No todos los usuarios interactúan con tu web o tu aplicación del mismo modo, y mucho menos como lo hacemos los que nos dedicamos a desarrollar. Aquí añado mi autocrítica, el tema es que como desarrollador no siempre tenga la capacidad de ponerme en la piel de un usuario. Es un tema importante que creo que se debe aclarar, dado que los desarrolladores no siempre tenemos la capacidad de ponernos en la piel del usuario, estamos contaminados por los requisitos que estamos programando. Si tenemos dificultades en ponernos en la piel de un usuario sin discapacidad, imagínate con un usuario con algún tipo de discapacidad…. Es complicado.
WCAG
Probablemente hayas visto o oído este acrónimo, Web Content Accessibility Guidelines (WCAG) es la guía por excelencia de accesibilidad web, publicada por Way Accessibility Initiative (WAI) del World Wide Web Consortium (W3C) .
WCAG 2.0 es público desde diciembre de 2008, con su última actualización WCAG 2.1 de Julio de 2018. Este consta de doce directrices organizadas según cuatro principios básicos: las webs deben ser ‘perceptibles’, ‘operables’, ‘comprensibles’ y ‘robustas’.
- Perceptible: Los usuarios deben poder usar la web accediendo a todo el contenido, proporcionando alternativas de texto para cualquier contenido multimedia como fotos, videos, iconos, etc. De este modo facilitaremos el acceso al contenido a usuarios con discapacidades visuales o auditivas.
- Operable: La web de ser navegable mediante el teclado, estableciendo una arquitectura de información clara.
- Comprensible: Hemos de asegurarnos que el universo sensorial sea comprensible, tanto a nivel de contenido como visual.
- Robusta: Hay que garantizar la compatibilidad en los diversos navegadores y dispositivos, sin olvidarnos de los lectores de pantalla.
HTML Semántico
El uso de HTML semántico tiene muchos beneficios, como un mejor rendimiento de la web, mejor SEO, mejor optimización móvil y compatibilidad con lectores de pantalla.
Un error de accesibilidad común es la navegación del menú en las webs. A menudo se utiliza una barra de navegación com una serie de elementos como <div> y <span>. INCORRECTO.
Según el W3C, la mejor manera de definir el menú de navegación es con una lista desordenada <ul> con sus respectivos <li>.
“Represente la estructura del menú mediante el uso de una lista. Dicha información estructural permite que las tecnologías de accesibilidad muestren la cantidad de elementos en el menú y proporcionan una correcta navegación.” WAI - W3
Este és un ejemplo de un menú de navegación accesible:
<ul>
<li><a href="…">Home</a></li>
<li><a href="…">Shop</a></li>
<li><a href="…">Space Bears</a></li>
<li><a href="…">Mars Cars</a></li>
<li><a href="…">Contact</a></li>
…
</ul>
En la Accessibility Developer Guide podrás encontrar multitud de casuísticas con detalles y ejemplos que te ayudarán a mejorar la semántica de tu web.
Navegable mediante el teclado
Si la semántica es correcta, el contenido debe ser navegable. Cuando no usamos elementos semánticos HTML básicos, perdemos muchos beneficios, como la accesibilidad mediante el teclado. Como por ejemplo, usar un <div> y diseñarlo como un botón. No lo hagas.
Hay usuarios con discapacidad que dependen únicamente la navegabilidad con un teclado para interactuar con el mundo ‘WWW’. Debemos verificar si el usuario puede o no recorrer todo el contenido de la web únicamente con un teclado. Si por ejemplo, un usuario puede pasar por todos los elementos de un formulario mediante los <input>, pero no puede enviar el formulario al presionar ‘Enviar’, la web no es accesible.
Si necesitas navegar con la tabulación del teclado con un orden determinado o no tabular por algún elemento concreto, puedes hacer uso del atributo tabindex. Veamos como funciona:
- Valor negativo: tabindex="-1", significa que el elemento será visible en la web, pero no será accesible a través de la navegación mediante el teclado.
- Valor 0: tabindex="0", es el valor por defecto, significa que el elemento será visible en la web además de ser accesible en la navegación mediante el teclado. El orden en el que aparece el elemento dependerá del lugar donde esté colocado, siguiendo el orden del contenido.
- Valor positivo: tabindex="5", igual que el valor 0, el elemento será visible en la web además de ser accesible en la navegación mediante el teclado. En el caso de valor positivo, el orden de navegación mediante el teclado será el especificado en el tabindex. Para los elementos que compartan el mismo valor de tabindex, se navegará en el orden del contenido.
Tablas
Afortunadamente, en la actualidad ya no usamos <table> para diseñar la estructura de una web. Es cosa del pasado… Sin embargo, sigue siendo un elemento útil en algún caso para representar su cometido, tablas. Veamos cómo representar correctamente una <table> con una accesibilidad óptima.
Si utilizas <tr> y <td> para diseñar el contenido de una tabla, no parece tan terrible, pero ojo. En realidad nos faltan algunos datos clave para disponer de accesibilidad. No podemos omitir los <thead> y <tbody> de la tabla, estos tienen la información semántica acerca de cómo está estructurada la tabla. Incluso se debería proporcionar un <caption> para describir al usuario el tipo de información que contiene la tabla.
Aquí te facilito más detalles para mejorar la accesibilidad en las tablas.
Texto alternativo en contenido multimedia
Probablemente ya estés familiarizado con el atributo alt. Lo usamos para proporcionar una alternativa al contenido multimedia como imágenes, videos, iconos, etc. El atributo alt siempre debe proporcionar una descripción de lo que representa el contenido multimedia. No debe incluir ninguna descripción adicional que no esté representada. Si necesitas proporcionar contenido o descripción adicional, puedes utilizar el atributo title.
Por ejemplo, si tienes un gráfico de barras con un conjunto finito de datos, puedes permitir que las secciones de la tabla puedan enfocarse con aria-describedby.
Sin embargo, si tienes un gráfico de líneas, no es tan factible esperar que los usuarios puedan enfocarse en cada uno de los puntos de datos. Por lo tanto, puedes implementar un botón o enlace que permita a los usuarios descargar los datos en un formato CSV (valor separado por comas).
Aquí te facilito más detalles para mejorar la accesibilidad en los contenidos multimedia.
Colores accesibles
El ‘contrast ratio’ nos permite valorar el contraste del contenido con el fondo establecido. Esta relación varía de 1:1 (colores iguales) a 21:1 ( colores totalmente opuestos, como blanco y negro).
Al diseñar una web, es imprescindible seleccionar los colores complementarios correctos. La normativa WCAG 2.1 AA indica que el contraste de color mínimo debe ser de 4.5:1 entre el fondo y el texto. Aunque si vemos la opción aumentada WCAG 2.1 AAA, debe ser de 7:1.
Puedes comprobar el contraste de colores utilizando la herramienta web Color Contrast Checker de WebIAM.
También es importante asegurarte de que la información importante no se base únicamente en el color, tienes que proporcionar métodos para indicar cambios de estado como el focus.
Fuentes accesibles
El tamaño de la fuente, el interlineado y la tipografía afectan a la legibilidad del contenido. Veamos cada una de estas:
Tamaño de fuente
El texto debe ser lo suficientemente grande para leer en dispositivos móviles y tablets. En el pasado 12px solía ser el tamaño de fuente estándar, hoy en día ha aumentado sustancialmente.
Para facilitar la lectura, debes aumentar el tamaño de la fuente en tu web. En ITDO optamos por un mínimo de 16px en contenido y 32px en headers.
Interlineado
Actualmente, el valor predeterminado de interlineado del navegador es aproximadamente de 1.2, sin embargo, según WCAG, debe ser al menos de 1.5.
Tipografía
Aunque las fuentes de Google sean fabulosas, pueden tener implicaciones de rendimiento o difíciles de digerir por los usuarios con discapacidad visual. En caso de duda, siempre es mejor utilizar fuentes que sean nativas en el sistema operativo, como Tahoma, Times New Roman y Arial.
Las fuentes se clasifican en familias en función de sus características. Algunas de las más comunes son:
- Serif
- Sans-serif
- Cursive
- Monospace
Conclusión
Lamentablemente, no siempre se incorpora la accesibilidad web preventivamente a lo largo del desarrollo de una web. Espero que ahora tengas motivos suficientes para incluir la accesibilidad como requisito, no sólo para facilitar el acceso al 15% de la población mundial, sino también para mejorar el SEO de la web.
Te invito a que analices tu web con herramientas como Wave o NoCoffee para evaluar cuánto de accesible es tu web.
Si necesitas ayuda para hacer más accesible tu web y mejorar el posicionamiento SEO, no dudes en contar con el soporte de ITDO.
Fotografía by Doran Erickson on Unsplash
Referencias: