Introducción al árbol de accesibilidad
Imagina que estás compilando una interfaz de usuario solo para usuarios de lectores de pantalla. Aquí, no necesitas crear ninguna IU visual, solo debes proporcionar suficiente información para que la use el lector de pantalla.
Lo que crearías es una especie de API que describe la estructura de la página, similar a la API de DOM, pero puedes obtener menos información y menos nodos, ya que gran parte de esa información solo es útil para la presentación visual. Puede ser algo así.
Esto es básicamente lo que el navegador presenta al lector de pantalla. El navegador toma el árbol del DOM y lo modifica para generar un formulario útil para la tecnología de asistencia. A este árbol modificado lo llamamos Árbol de accesibilidad.
Puedes visualizar el árbol de accesibilidad como algo parecido a una vieja página web de la década de 1990: algunas imágenes, muchos vínculos, tal vez un campo y un botón.
El escaneo visual de una página como esta te brinda una experiencia similar a la que tendría un usuario de lector de pantalla. La interfaz está allí, pero es simple y directa, como una interfaz de árbol de accesibilidad.
El árbol de accesibilidad es con lo que la mayoría de las tecnologías de asistencia interactúan. El flujo es más o menos así.
- Una aplicación (el navegador o alguna otra app) expone una versión semántica de su IU a la tecnología de accesibilidad mediante una API.
- La tecnología de accesibilidad puede usar la información que lee a través de la API para crear una presentación de interfaz de usuario alternativa para el usuario. Por ejemplo, un lector de pantalla crea una interfaz en la que el usuario escucha una representación hablada de la app.
- La tecnología de accesibilidad también puede permitir que el usuario interactúe con la app de otra manera. Por ejemplo, la mayoría de los lectores de pantalla proporcionan hooks para permitir que el usuario simule fácilmente un clic del mouse o una presión con el dedo.
- La tecnología de accesibilidad retransmite la intención del usuario (como "clic") a la app a través de la API de accesibilidad. Luego, la app tiene la responsabilidad de interpretar la acción de manera adecuada en el contexto de la IU original.
En el caso de los navegadores web, existe un paso adicional en cada dirección, ya que el navegador es, de hecho, una plataforma de apps web que se ejecutan en él. Por lo tanto, el navegador necesita traducir la aplicación web en un árbol de accesibilidad y debe asegurarse de que se activen los eventos adecuados en JavaScript según las acciones del usuario que provienen de la tecnología de accesibilidad.
Pero eso es responsabilidad del navegador. Nuestro trabajo como desarrolladores web es simplemente estar al tanto de esto y desarrollar páginas web que aprovechen este proceso para crear una experiencia accesible para nuestros usuarios.
Para ello, nos aseguramos de expresar la semántica de nuestras páginas de forma correcta, es decir, asegurarnos de que los elementos importantes de la página tengan las funciones, los estados y las propiedades de accesibilidad correctos, y especificar los nombres y las descripciones de accesibilidad. El navegador puede permitir que la tecnología de asistencia acceda a esa información para crear una experiencia personalizada.
Semántica en HTML nativo
Un navegador puede transformar el árbol del DOM en un árbol de accesibilidad porque gran parte del DOM tiene significado semántico implícito. Es decir, el DOM usa elementos HTML nativos reconocidos por los navegadores y que funcionan de forma predecible en varias plataformas. Por lo tanto, la accesibilidad de los elementos HTML nativos, como vínculos o botones, se controla automáticamente. Podemos aprovechar esa accesibilidad integrada escribiendo código HTML que exprese la semántica de los elementos de nuestra página.
Sin embargo, a veces usamos elementos que parecen elementos nativos, pero no lo son. Por ejemplo, este "botón" no es un botón.
Se puede construir en HTML de varias formas; una de ellas es la que se muestra a continuación.
<div class="button-ish">Give me tacos</div>
Cuando no usamos un elemento de botón real, el lector de pantalla no tiene forma de saber en qué llegó. Además, tendríamos que hacer el trabajo adicional de agregar tabindex para que pueda usarlo solo los usuarios de teclado, ya que, como está codificado ahora, solo se puede usar con un mouse.
Podemos solucionar fácilmente esto usando un elemento button normal en lugar de un div.
El uso de un elemento nativo también tiene el beneficio de ocuparse de las interacciones del teclado por nosotros. Además, recuerda que no tienes que perder tus efectos visuales atractivos solo porque usas un elemento nativo; puedes diseñar elementos nativos para que se vean como deseas y conservar la semántica y el comportamiento implícitos.
Anteriormente, observamos que los lectores de pantalla anunciarán la función, el nombre, el estado y el valor de un elemento. Cuando se usa el elemento semántico, la función, el estado y el valor correctos, se abordan, pero también debemos asegurarnos de hacer que el nombre de un elemento sea detectable.
En términos generales, hay dos tipos de nombres:
- Las etiquetas visibles, que todos los usuarios usan para asociar el significado a un elemento.
- Alternativas de texto, que solo se usan cuando no hay necesidad de una etiqueta visual.
Para los elementos a nivel de texto, no necesitamos hacer nada porque, por definición, tendrán algo de contenido de texto. Sin embargo, para los elementos de entrada o control, y el contenido visual como las imágenes, debemos asegurarnos de especificar un nombre. De hecho, proporcionar alternativas de texto para cualquier contenido que no sea de texto es el primer elemento de la lista de tareas de WebAIM.
Una forma de hacerlo es seguir su recomendación de que “Las entradas de formulario tienen etiquetas de texto asociadas”. Hay dos formas de asociar una etiqueta a un elemento de formulario, como una casilla de verificación. Cualquiera de los métodos hace que el texto de la etiqueta también se convierta en un objetivo de clics para la casilla de verificación, lo que también es útil para los usuarios del mouse o de la pantalla táctil. Para asociar una etiqueta a un elemento,
- Coloca el elemento de entrada dentro de un elemento de etiqueta
<label>
<input type="checkbox">Receive promotional offers?
</label>
o
- Usar el atributo
forde la etiqueta y hacer referencia aliddel elemento
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Cuando la casilla de verificación se etiquetó correctamente, el lector de pantalla puede informar que el elemento tiene el rol de casilla de verificación, está marcado y se llama “¿Recibir ofertas promocionales?”.
