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 para que use el lector de pantalla.
Crearías una especie de API que describe la estructura de la página, similar con la API del DOM, pero puede salirse con menos información y menos nodos, porque mucha de esa información solo es útil para la presentación visual. Integra podría verse así.
![simulación de la API del DOM del lector de pantalla](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/screen-reader-dom-api-moc-86f15b848dd25.jpg?authuser=7&hl=es-419)
Esto es básicamente lo que el navegador le presenta al lector de pantalla. El navegador toma el árbol del DOM y lo modifica para generar un formulario útil para tecnología de accesibilidad. A este árbol modificado lo llamamos la estructura de accesibilidad Árbol.
Puedes visualizar el árbol de accesibilidad como si se parece a una página web antigua. de los años 90: pocas imágenes, muchos vínculos, tal vez un campo y un botón.
![una página web con estilo de los años 90](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/a-1990s-style-web-page-71a74592e602e.png?authuser=7&hl=es-419)
El escaneo visual de una página como esta te brinda una experiencia similar a la lo que recibirí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 es más o menos así.
- Una aplicación (el navegador u otra app) expone una versión semántica de su IU para tecnología de accesibilidad a través de una API
- La tecnología de asistencia puede utilizar 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 un mensaje representativa de la app.
- La tecnología de asistencia también puede permitir al usuario interactuar con la aplicación en de una manera diferente. Por ejemplo, la mayoría de los lectores de pantalla proporcionan enlaces para permitir que un simule fácilmente un clic del mouse o un toque con el dedo.
- La tecnología asistencial retransmite la intención del usuario (como "clic") a la app a través de la API de Accessibility. La app tiene la responsabilidad a 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. es una plataforma para apps web que se ejecutan en ella. Por lo tanto, el navegador necesita traducir la aplicación web en un árbol de accesibilidad y debe asegurarse de que el los eventos adecuados se activan en JavaScript según las acciones que el usuario realiza de la tecnología de asistencia.
Pero eso es responsabilidad del navegador. Nuestro trabajo como desarrolladores web es simplemente saber que esto está sucediendo y desarrollar páginas web que 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: asegúrate de que los elementos importantes de la página tengan la información de acceso correcta estados y propiedades, y que especifiquemos nombres de accesibilidad y descripciones. El navegador puede entonces permitir que la tecnología de asistencia acceda a 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 de el DOM tiene un significado semántico implícito. Es decir, el DOM usa HTML nativo que son reconocidos por los navegadores y que funcionan de manera predecible en una variedad de y plataformas de Google Cloud. La accesibilidad para elementos HTML nativos, como vínculos o botones, es así, se manejan automáticamente. Podemos aprovechar la accesibilidad integrada 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 diferentes formas: una manera se muestra a continuación.
<div class="button-ish">Give me tacos</div>
Cuando no usamos un botón real, el lector de pantalla no tiene forma de saber a dónde ha aterrizado. Además, tendríamos que hacer el trabajo adicional de agregar tabindex para que sea utilizable para los usuarios que solo usan el teclado porque, como está codificado, solo puede usarse con un mouse.
Esto se puede solucionar fácilmente usando un elemento button
normal en lugar de un div
.
El uso de un elemento nativo también tiene el beneficio de controlar el uso del teclado.
interacciones por nosotros. Y recuerda que no tienes que perder tu elegante imagen
efectos solo porque usas un elemento nativo; puedes definir el estilo de los elementos nativos
haz que se vean como quieres y aun así conserven la semántica implícita y
de tu modelo.
Antes notamos que los lectores de pantalla anunciarán el rol, el nombre estado y valor. Usando el elemento semántico, el rol, el estado y el valor correctos pero también debemos asegurarnos de que el nombre de un elemento esté incluido detectable.
En términos generales, hay dos tipos de nombres:
- Etiquetas visibles, que todos los usuarios utilizan para asociar el significado con un y
- Alternativas de texto, que solo se usan cuando no hay necesidad de elemento visual etiqueta.
Para los elementos de nivel de texto, no necesitamos hacer nada porque, por definición, tendrá contenido de texto. Sin embargo, para elementos de control o de entrada, y contenido como imágenes, debemos asegurarnos de especificar un nombre. De hecho, proporcionar alternativas de texto para cualquier contenido que no sea de texto es la primer elemento de la lista de verificación de WebAIM.
Una forma de hacerlo es seguir su recomendación de que “Las entradas del formulario tienen etiquetas de texto asociadas". Hay dos formas de asociar una etiqueta a un formulario como una casilla de verificación. Cualquiera de los métodos hace que el texto de la etiqueta también se convertirá en un objetivo de clics para la casilla de verificación, lo que también es útil para usuarios de pantallas táctiles. 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
- Usar el atributo
for
de la etiqueta y hacer referencia alid
del 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 estado marcado y se llama "Recibir ofertas promocionales?".
![resultado de texto en pantalla de VoiceOver en el que se muestra la etiqueta hablada de una casilla de verificación](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/on-screen-text-output-vo-2bf0c33d65f23.png?authuser=7&hl=es-419)