¿Qué es la Accesibilidad Web?

Utilizando técnicas de diseño accesible logramos que un rango amplísimo de personas en situaciones dispares sea capaz de disfrutar de experiencias que van más allá de “leer” la web, como poder rellenar una solicitud de empleo, reírse de un chiste que se cuenta en un video, o hacer una videoconferencia con la familia. Y todo ello sin importar si la persona que accede a nuestra experiencia tiene una discapacidad, es poco hábil, está en un entorno complicado o se conecta a través de un dispositivo con funcionalidad limitada
— Accesibilidad Web, WCAG 2.1 de forma sencilla

Aclaración: Este artículo es una reescritura de un post que existia en mi antiguo blog que decidí rehacerlo desde un punto de vista más didáctico con enfoques prácticos que apliqué en esta web. Bajo ningún punto de vista me considero un profesional en accesibilidad pero es un tópico que me interesa mucho y considero muy importante.

¿Qué significa que un sitio sea “accesible”?

Siempre creí que denominar a un sitio web como “accesible” significaba que las personas con discapacidades tambien puedan disfrutar del contenido del mismo, y sí bien es razón más que suficiente para comenzar a tomar un enfoque más accesible en el diseño de nuestras webs, la realidad es que trasciende eso. Hay un enfoque muy interesante en el libro de Accesibilidad Web, WCAG 2.1 de forma sencilla que me hizo dar cuenta de esto: los problemas que pueden afectar a personas de forma temporal o permanente, tambien los podemos sufrir nosotros en situaciones cotidianas. Por ejemplo: la dificultad de una persona tetrapléjica para apuntar con el cursor, son parecidas a las que tienen las personas mayores.

Entonces, ¿qué es la accesibilidad en un sitio web?. Para mí es crear webs con el objetivo de que sean usables para la mayor cantidad de personas posibles, sin importar en que circunstancia se encuentren.

Si todo esto no te pareció un motivo suficiente para interesarte por la accesibilidad, es esencial destacar que las WCAG 2.0 son legalmente obligatorias en muchos países. Incluso, el incumplimiento de estas pautas puede generar sanciones económicas en ciertas jurisdicciones.

Pautas de Accesibilidad para el Contenido Web (WCAG)

Las Pautas de Accesibilidad para el Contenido Web (WCAG) son un estándar técnico, desarrollado por la W3C, que tiene como fin satisfacer las necesidades de las personas, organizaciones o gobiernos a nivel internacional.

El estándar consta de 13 pautas agrupadas en 4 principios:

Perceptible: debemos contar con alternativas textuales para cualquier contenido no-textual para que pueda ser intercambiado a otras formas que la gente necesite (braille, narrador, simbolos, etc.).
Operable: los componentes de la interfaz de usuario y navegación deben ser operables, es decir, manejados por usuarios de diferentes capacidades.
Comprensible: la información y forma de operar que presentemos en nuestra web debe ser comprensible.
Robusto: maximizar la compatibilidad con agentes de usuario actuales y futuros, incluyendo tecnologias de apoyo.

Para cada pauta contamos con tres criterios de conformidad: A, AA y AAA

WAI-ARIA

Muchas veces, las aplicaciones webs actuales cuentan con controles no nativos que los lectores de pantallas no comprenden. Por ejemplo: HTML no cuenta con una forma semántica de describir un menú desplegable (como si tenemos para describir un menú de navegación <nav> o un footer <footer>), nosotros creamos esos componentes manualmente y las tecnologías de apoyo no tienen forma de comprender o describirlos excepto que lo especifiquemos.

Ahí es donde entra ARIA (Accesible Rich Internet Aplications) a desempeñar un papel fundamental. WAI-ARIA es una especificación escrita por la W3C que nos ayuda con estos problemas añadiendo una serie de atributos HTML que pueden aplicarse a elementos para otorgarle semántica adicional y mejorar la accesibilidad. Esto hace que los navegadores y las tecnologias de apoyo puedan reconocer estos elementos más claramente y describirles correctamente el contenido de nuestro sitio a un usuario.

En la especificación se definen 3 caracteristicas principales que contribuyen a mejorar la accesibilidad web: roles que describen la función de los elementos, propiedades que agregan un significado o mayor semántica a los elementos y estados que son propiedades especiales encargadas de representar el estado actual del elemento que puede cambiar a lo largo del ciclo de vida de nuestra aplicación (ej. aria-expanded)

Por ejemplo, una forma de aplicar esta especificación es la siguiente:

<div role="button" tabindex="0" id="submit-btn">
    Enviar
</div>

Este ejemplo muestra como aplicar la especificación ARIA para que un <div> se comporte como un <button>, utilizando el role y el tabindex para que nuestro elemento sea focusable.

A pesar de ser una técnica válida, no es algo que querramos hacer. Cuando sea viable, es más conveniente utilizar la etiqueta HTML correspondiente.

<!-- Este sería el equivalente utilizando HTML semántico -->
<button id="submit-btn">
    Enviar
</button>

¿Cómo revisar la accesibilidad de nuestra web?

Para verificar la accesibilidad de nuestra web contamos con varias herramientas:

Lighthouse: un reporte de Lighthouse puede ser un buen punto de partida pero no garantiza que nuestra web sea accesible ya que al ser una prueba automática solo detecta algunos errores por lo que las pruebas manuales siguen siendo necesarias.
Devtools (Chrome): en Chrome podemos simular deficiencias visuales como visión borrosa, contraste reducido o ciertos tipos de daltonismos (More Tools -> Rendering)
Lectores de pantalla: con NVDA o VoiceOver vamos a poder escuchar como se anuncia cada elemento de nuestro sitio y determinar si es comprensible.

Existen muchas más herramientas y recursos que podemos utilizar para revisar la accesibilidad de nuestro sitio como el Servicio de Validación de W3C para validar nuestro código o Siteimprove que valida ciertos criterios de accesibilidad. Tambien hay sitios donde podemos verificar que el contraste ente colores cumpla con los criterios como este ContrastChecker de WebAIM

Manos a la obra 🔨

Llegó el momento de intentar implementar estos estándares y especificaciones en mi web.

Para comenzar tomé nota de algunos de los errores que me encontré emulando deficiencias visuales y navegando con los lectores de pantalla:

Al emular deficiencias visuales noté que en ciertas secciones de la web el texto no se logra leer con claridad. Con algunos ajustes en el diseño, las fuentes y colores ajuste bastante mejor el contraste.

Probando la navegación con el lector de pantalla NVDA noté algunos errores en enlaces, por ejemplo al utilizar este cáracter → se leé su nombre y no queda claro para qué sirve. Para que tenga más sentido, le agregué un aria-label al enlace, por lo que se leerá “Mi último artículo […] ¿Qué es la accesibilidad web?”

<a aria-label="Mi último artículo">
 Te invito a leer mi último artículo →
</a>

Tambien, en la sección principal, al tener el texto con varios niveles de anidación, la lectura del heading (“Hola, soy Thiago” + “Fullstack Developer”) era un poco rara.

Esto lo solucioné utilizando el aria-labelledby combinando ambos elementos para que el mensaje de presentación se lea seguido: “Hola, soy Thiago, Fullstack Developer.”

(...)
<h1 id="soy-thiago" aria-labelledby="soy-thiago work-role">
    Hola!
    <span>Soy Thiago!</span>
</h1>

<p aria-hidden="true" id="work-role">Fullstack Developer</p>
(...)

Al narrar las tecnologias con las que trabaje se leía como “Lista de 5 elementos, elemento 1, Next”. Consideré que se podia sumarle algo de contexto para que se lea “Tecnologías que utilizo, lista de 5 elementos (…)”:

<ul aria-label="Tecnologías que utilizo">
    (...)
</ul>

Despues de realizar algunas correcciones manuales, ejecuté algunas pruebas automáticas usando Lighthouse y Validator W3.

Obtuve errores más que nada en el formato de las fechas, resulta que estaba utilizando el atributo datetime del elemento <time> con el formato YYYY/MM/DD:

<!-- Incorrecto -->
<time datetime="YYYY/DD/MM"></time>

<!-- Correcto -->
<time datetime="YYYY-DD-MM"></time>

Adicional a estos, el Validator W3 resaltó algunos errores más como este:

Attribute astro-icon not allowed on element svg at this point.

Sin embargo, no los consideré “errores” como tal dado que desde las pruebas que realicé no tenian un impacto negativo en la accesibilidad.

Este sitio es simple, por lo que con el correcto uso de los elementos HTML y algunos atributos ARIA obtenemos una buena experiencia de usuario. De todas formas seguramente queden mejoras pendientes en cuanto accesibilidad se refiere que iré haciendo con el tiempo.

Por último, quiero recomendar realmente la lectura de Accesibilidad Web, WCAG 2.1 de forma sencilla que abarca este tema con mayor profundidad. Tambien nos ofrece el punto de vista de como seria aplicar la accesibilidad en un equipo de trabajo y a lo largo de todas las fases del desarrollo.

Creo que es importante como desarrolladores que consideremos seriamente este tema. Solamente teniendo en cuenta estos estándares durante el desarrollo podemos lograr buenos resultados que hagan a nuestro sitio más accesible contribuyendo a que la web sea un lugar más inclusivo.