Introducción al árbol de accesibilidad
Imagina que estás creando una interfaz de usuario solo para usuarios de lectores de pantalla. Aquí, no necesitas crear ninguna IU visual, sino solo proporcionar suficiente información para que la use el lector de pantalla.
Lo que crearías es un tipo de API que describe la estructura de la página, similar a la API del DOM, pero puedes obtener menos información y menos nodos, ya que mucha de esa información solo es útil para la presentación visual. Podría verse de la siguiente manera.
Básicamente, esto es lo que el navegador presenta al lector de pantalla. El navegador toma el árbol del DOM y lo modifica para que tenga un formato útil para la tecnología de accesibilidad. Nos referimos a este árbol modificado como el árbol de accesibilidad.
Puedes visualizar el árbol de accesibilidad como una página web antigua de los años 90: algunas imágenes, muchos vínculos, tal vez un campo y un botón.
Explorar visualmente una página como esta te brinda una experiencia similar a la que tendría un usuario de lector de pantalla. La interfaz está ahí, pero es simple y directa, como una interfaz de árbol de accesibilidad.
El árbol de accesibilidad es con lo que interactúan la mayoría de las tecnologías de accesibilidad. El flujo es más o menos así.
- Una aplicación (el navegador o cualquier otra app) expone una versión semántica de su IU a la tecnología de accesibilidad a través de 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 alternativa de la interfaz de usuario 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 un usuario simule fácilmente un clic del mouse o un toque con el dedo.
- La tecnología de accesibilidad retransmite la intención del usuario (como "hacer clic") a la app a través de la API de Accessibility. Luego, la app tiene la responsabilidad de interpretar la acción de forma adecuada en el contexto de la IU original.
En el caso de los navegadores web, hay un paso adicional en cada dirección, ya que el navegador es, de hecho, una plataforma para las apps web que se ejecutan 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 adecuados en JavaScript según las acciones del usuario que provienen de la tecnología de accesibilidad.
Pero todo eso es responsabilidad del navegador. Nuestro trabajo como desarrolladores web es simplemente tener en cuenta que esto está sucediendo y desarrollar páginas web que aprovechen este proceso para crear una experiencia accesible para nuestros usuarios.
Para ello, nos aseguramos de expresar correctamente la semántica de nuestras páginas: nos aseguramos de que los elementos importantes de la página tengan los roles, estados y propiedades de accesibilidad correctos, y de que especifiquemos nombres y descripciones de accesibilidad. Luego, el navegador puede permitir que la tecnología de accesibilidad 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 usa elementos HTML nativos que los navegadores reconocen y funcionan de manera predecible en una variedad de plataformas. Por lo tanto, la accesibilidad de los elementos HTML nativos, como los vínculos o los botones, se controla automáticamente. Podemos aprovechar esa accesibilidad integrada escribiendo HTML que exprese la semántica de nuestros elementos de página.
Sin embargo, a veces usamos elementos que parecen nativos, pero no lo son. Por ejemplo, este "botón" no es un botón en absoluto.
Se puede construir en HTML de varias maneras; a continuación, se muestra una de ellas.
<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é se detuvo. Además, tendríamos que hacer el trabajo adicional de agregar tabindex para que los usuarios que solo usan el teclado puedan usarlo porque, tal como está codificado ahora, solo se puede usar con un mouse.
Para solucionar fácilmente este problema, usa un elemento button normal en lugar de un div.
Usar un elemento nativo también tiene el beneficio de encargarse de las interacciones del teclado por nosotros. Y recuerda que no tienes que perder tus efectos visuales elegantes solo porque usas un elemento nativo; puedes aplicar diseño a los elementos nativos para que se vean como quieras y, al mismo tiempo, conservar la semántica y el comportamiento implícitos.
Anteriormente, mencionamos que los lectores de pantalla anunciarán el rol, el nombre, el estado y el valor de un elemento. Si usas el elemento semántico correcto, se abarcan el rol, el estado y el valor, pero también debemos asegurarnos de que el nombre de un elemento sea detectable.
En términos generales, existen dos tipos de nombres:
- Etiquetas visibles, que usan todos los usuarios para asociar un significado con un elemento
- Alternativas de texto, que solo se usan cuando no se necesita una etiqueta visual
En el caso de los elementos a nivel de texto, no necesitamos hacer nada, ya que, por definición, tendrán 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 tengan etiquetas de texto asociadas". Existen dos maneras de asociar una etiqueta con 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 que también es útil para los usuarios de mouse o pantalla táctil. Para asociar una etiqueta con un elemento, puedes hacer 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
forde la etiqueta y haz 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 un rol de casilla de verificación, está en un estado marcado y se llama "¿Recibir ofertas promocionales?".
