La Accesibilidad es un aspecto fundamental de la Web. Para construir herramientas accesibles para el mayor número de personas posibles, conozcamos cuáles son los errores que cometemos con más frecuencia y de qué manera solucionarlos.
La Accesibilidad Web es un estándar desarrollado por el World Wide Web Consortium (W3C) que incluye guías, herramientas y material de soporte. Nos permite optimizar nuestras interfaces para garantizar el acceso a personas con discapacidades o que puedan experimentar algún tipo de impedimento para acceder al contenido, ya sea temporal o permanente.
Al navegar en la web, estas personas hacen uso de funcionalidades propias del dispositivo o del navegador, sumando en algunos casos tecnologías de asistencia adicionales, como lectores de pantalla o controles de navegación. Estas herramientas requieren que nuestro código respete una serie de recomendaciones o buenas prácticas que muchas olvidamos. Tan así es que el útimo WebAIM Millon (un test anual que realiza el W3C sobre una muestra de un millón de sitios web) arrojó un resultado alarmante: el 98.1% de los sitios analizados mostraron problemas de Accesibilidad. Peor aún, este porcentaje viene aumentando en los últimos años.
Las herramientas utilizadas en este análisis fueron la Guía de Accesibilidad para Contenido Web WCAG 2.0 y un software de evaluación de uso libre llamado Wave. Si bien el análisis no cubre la totalidad de los requerimientos para hacer que un sitio sea accesible, es un buen punto de partida.
Repasemos entonces cuáles son los seis errores más comunes identificados por el estudio del millón (el número corresponde al porcentaje de sitios donde se encontró el error):
- Bajo contraste 86.3%
- Imágenes sin texto alternativo 66%
- Links vacíos 59.9%
- Entradas sin etiqueta label en formularios 53.8%
- Botones vacíos 28.7%
- Documento sin atributo de lenguaje 28%
Existen muchos problemas que exceden las posibilidades del testing automático, ya que requieren un análisis cualitativo o lo que es aún mejor, realizar pruebas con personas usuarias reales. Pero desde nuestro lugar, podemos empezar a contribuir solucionando estos errores que, como veremos a continuación, no requieren un gran esfuerzo técnico, de tiempo o presupuesto.
Bajo contraste (86.3%)
El contraste entre texto y fondo es fundamental para lograr legibilidad. WCAG 2.0 establece para el nivel AA que el contraste mínimo entre el color de texto y el de fondo debería ser mayor o igual a 4,5:1, en una escala dónde 1:1 es blanco sobre blanco y 21:1 negro sobre blanco.
Este ratio puede variar en función al tamaño, estilo y finalidad del texto. Lo bueno es que no necesitamos aprender todos esos números de memoria y tomarnos el tiempo para hacer los cálculos, podemos utilizar esta herramienta online para chequear contraste de colores que hará todo el trabajo por nosotros. Solo debemos ingresar los colores con los que queremos trabajar y nos indicará, en cada caso, si el contraste es adecuado o necesitamos hacer ajustes.
Imágenes sin texto alternativo (66%)
El texto alternativo alt es un atributo de la etiqueta html Imagen <img> y como su nombre lo indica, ofrece una alternativa en formato texto al contenido expresado o representado en la imagen.
<img src="imagen.jpg" alt="Texto alternativo de la imagen" />
El texto que debemos incluir en este atributo varía según la función que cumple la imagen, veamos algunos casos:
Imágenes decorativas
Si se trata de una imagen decorativa, que no transmite información indispensable para comprender el contenido, como por ejemplo un borde, o una textura de fondo, debemos utilizar un atributo alt vacío. Aunque parezca un error, esta es la manera correcta de indicar que una imagen es irrelevante para la comprensión del contenido.
<img src="textura-fondo.png" alt="" />Íconos y botones gráficos
En un interface de usuario, es común que utilicemos imágenes en forma de íconos que actúan como botones. Aquí podemos distinguir dos situaciones diferentes.
Si no hay texto acompañando a la imagen / ícono, podemos utilizar el atributo alt para indicar la función que cumple ese ícono, por ejemplo:
<a href="documento.pdf">
<img src="icono-descargar.jpg" alt="Descargar documento en formato PDF." />
</a>En cambio, si la imagen está acompañada de texto, ese texto debería ser suficiente para describir la acción. La imagen, al ser solo un elemento decorativo, debe incluir un atributo alt vacío.
<a href="./documento.pdf">
<img src="icono-descargar.jpg" alt=""/>
Descargar documento en formato PDF.
</a>Imágenes ilustrativas o representativas
Por último, encontramos las imágenes o gráficos que se utilizan para transmitir contenido. En este caso, el texto alternativo debe ser equivalente a esa información que transmite la imagen, teniendo en cuenta el contexto en el que se presenta.
Es importante prestar atención a los siguientes aspectos:
- Tratar de ser conciso y específico al describir el contenido o la acción.
- No excluir información vital para entender el significado de la imagen en relación con el contenido que acompaña y al contexto en el que se presenta.
- No incluir información redundante.
- No es necesario incluir las palabras “Imagen de.. ” o “Imagen que representa.. “. Si el formato de la imagen es relevante para el contenido, puede indicarse al final, por ejemplo
alt="Paisaje montañoso y nevado, ilustración digital." - Siempre terminar la frase con un punto (.) para que la oración no suene inconclusa.
Links Vacíos (59.9%)
En el punto anterior vimos un ejemplo de este error. Si definimos un enlace con la etiqueta html <a> pero dentro de la etiqueta solo agregamos una imagen, ese link será considerado vacío. Como ya vimos, podemos utilizar el atributo alt para incluir este texto y permitir que las tecnologías de asistencia puedan leer nuestro enlace.
<a href="index.html">
<img src="logotipo.png" alt="Ir a la página principal">
</a>Elementos interactivos sin etiqueta label en formularios (53.8%)
En html disponemos de muchos elementos interactivos que nos permiten ingresar datos en un formulario, como por ejemplo entradas de texto <input type="text"> o desplegables con opciones para seleccionar <select>. Estos elementos deben ir siempre acompañados de una etiqueta que describa su propósito. En la mayoría de los casos, usaremos la etiqueta html <label> con un atributo for que debe apuntar al id del elemento interactivo, por ejemplo:
<label for="nombre">Ingrese su nombre:</label>
<input type="text" id="nombre"/>
Ahora bien, supongamos que el departamento de diseño determinó que la función del elemento interactivo es obvia y no necesita una descripción textual que sea visible en la pantalla. En este caso tenemos algunas opciones:
- Incluir la etiqueta
<label>pero ocultarla utilizando CSS - Utilizar el atributo
aria-label
<input type="text" aria-label="Ingrese su nombre."/>
- Utilizar el atributo
aria-labelledbyapuntando alidde otro elemento que describa esa funcionalidad:
<h3 id="titulo">Ingrese su nombre</h3>
<input type="text" aria-labelledby="titulo"/>
Botones vacíos 28.7%
En el caso de los botones, vemos el mismo patrón que en las imágenes. Si un botón no contiene texto en su interior, necesitamos incluirlo de alguna manera. Si tenemos una imagen en el interior, podemos usar el atributo alt como vimos antes.
<button>
<img src="cerrar.png" alt="Cerrar ventana." />
</button>
Si el botón está completamente vacío, porque la imagen es un fondo o pseudo elemento css, también podemos utilizar el atributo aria-label
<button aria-label="Cerrar ventana."></button>
Documento sin atributo de lenguaje 28%
La regla verifica que al menos el elemento raíz de una página HTML incluya un atributo lang con un valor de idioma conocido, por ejemplo es (español) o en (inglés):
<html lang="es">
<head>...</head>
<body>
<!-- Contenido en español -->
</body>
</html>
También podemos agregar el atributo lang en un elemento interior, que contenga contenido en otro idioma:
<html lang="es">
<head>...</head>
<body>
<!-- Contenido en español -->
<section lang="en">
<!-- Contenido en inglés -->
</section>
</body>
</html>
Como podemos imaginar, esta información será de gran utilidad para que el contenido pueda ser transmitido adecuadamente por los lectores de pantalla, pero también supone beneficios a la hora de traducir e indexar ese contenido.
¡Buen trabajo!
Logramos solucionar al menos algunos de los errores más comunes en el desarrollo de sitios web accesibles. Como ya mencionamos, este análisis solo cubre los errores que pueden ser detectados con herramientas automáticas, pero sirven como punto de partida para empezar a prestar atención y contribuir a transformar obstáculos en herramientas de inclusión.