Árbol de accesibilidad

Introducción al árbol de accesibilidad

Alice Boxhall

Dave Gash

Meggin Kearney

Imagina que estás compilando una interfaz de usuario solo para usuarios de lectores de pantalla. Aquí, no necesitas crear una IU visual, solo tienes que brindar suficiente información para que 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 terminar con menos información y menos nodos, porque mucha de esa información solo es útil para la presentación visual. Podría verse así:

Esto es básicamente lo que el navegador le presenta el lector de pantalla. El navegador toma el árbol del DOM y lo modifica para generar un formulario útil para la tecnología de accesibilidad. A este árbol modificado lo llamamos Árbol de accesibilidad.

Puedes visualizar el árbol de accesibilidad como semejante a una vieja página web de los años 90: pocas 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 el 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 similar al siguiente:

1. Una aplicación (el navegador o alguna otra app) expone una versión semántica de su IU a la tecnología de accesibilidad a través de una API.
2. 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.
3. La tecnología de accesibilidad también puede permitirle al usuario interactuar con la app de otra manera. Por ejemplo, la mayoría de los lectores de pantalla brindan vínculos que le permiten al usuario simular fácilmente un clic de mouse o el presionar con el dedo.
4. La tecnología asistencial transmite la intención del usuario (como "clic") a la app a través de la API de accesibilidad. La app tiene la responsabilidad de interpretar la acción de forma correcta en el contexto de la IU original.

Para los navegadores web, existe un paso adicional en cada dirección, porque el navegador es una plataforma de apps web que se ejecuten en él. Por lo tanto, el navegador debe traducir la app web en un árbol de accesibilidad y asegurarse de que se activen los eventos apropiados 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 estar al tanto de que esto sucede y desarrollar páginas web que se aprovechen de 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: nos aseguramos de que los elementos importantes de la página tengan los roles, estados y propiedades accesibles correctos, y especificamos nombres y descripciones accesibles. 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 un significado semántico implícito. Es decir, el DOM utiliza elementos HTML nativos que los navegadores reconocen y que funcionan de manera predecible en una variedad de plataformas. La accesibilidad para elementos de HTML nativos como vínculos o botones se controla automáticamente. Podemos aprovechar esa accesibilidad incorporada escribiendo 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 en absoluto.

Se puede construir en HTML de varias formas, una de ellas es la siguiente.

<div class="button-ish">Give me tacos</div>

Cuando no usamos un elemento botón real, el lector de pantalla no tiene forma de saber sobre qué ha aterrizado. Además, tendríamos que hacer el trabajo adicional de agregar tabindex para que se pueda usar solo para usuarios de teclado porque, como se codifica ahora, solo se puede usar con un mouse.

Podemos solucionar esto fácilmente 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. Y recuerda que no tienes que perder tus elegantes efectos visuales solo porque uses un elemento nativo. Puedes darles estilo a los elementos nativos para que luzcan como quieres y mantener los semantics y el comportamiento implícitos.

Antes observamos que los lectores de pantalla anunciarán el rol, nombre, estado y valor de un elemento. Al usar el elemento de semantic correcto, el rol, estado y valor están cubiertos, pero también tenemos que asegurarnos de que hacer que el nombre de un elemento sea detectable.

En términos generales, hay dos tipos de nombres:

• Etiquetas visibles, que todos los usuarios usan para asociar el significado a un elemento, y
• Alternativas de texto, que solo se usan cuando no hay necesidad de etiqueta visual.

Para los elementos de nivel de texto, no tenemos que hacer nada, porque, por definición, tendrán contenido de texto. Sin embargo, para los elementos de control o entrada, y el contenido visual como imágenes, tenemos que asegurarnos de especificar un nombre. De hecho, brindar alternativas de texto para cualquier contenido que no sea 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". Existen 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 clic para la casilla de verificación, lo cual también es útil para usuarios de mouse o pantalla táctil. Para asociar una etiqueta a un elemento, haz lo siguiente:

• Coloca el elemento de entrada dentro de un elemento de etiqueta

<label>
    <input type="checkbox">Receive promotional offers?
</label>

o

• Usa el atributo for de la etiqueta y haz referencia al id del elemento

<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>

Cuando se etiqueta correctamente la casilla de verificación, el lector de pantalla puede informar que el elemento tiene un rol de casilla de verificación, se encuentra en un estado de marcado y se llama "Receive promotional offers?".