¿Qué es el Árbol de Accesibilidad, en realidad?

Esta es una presentación de un equipo de la Plataforma Google Cloud, y estamos en un escenario virtual para mostrarles cómo construir una plataforma realmente poderosa y en rápido crecimiento. Es un gusto verlos a todos, especialmente sé que son las 5 en punto, sé que es tarde, tuvimos un gran día hoy, así que estoy feliz de ver que esta sala está llena y que todos se ven despiertos. Así que gracias por estar aquí. Comencemos. Cometí un error en esta primera diapositiva. Espero que no sea una mala señal para el resto de la presentación. El nombre de esta presentación es ¿Qué es la Accesibilidad 3? Hola, mi nombre es Mathilde, soy una desarrolladora de front-end y una profesional de la accesibilidad. Dejé mi trabajo en Shopify hace un par de semanas, así que ya no trabajo allí. Por mi acento pueden escuchar que soy originaria de Francia, pero vivo en Madrid, España. Así que el tema de hoy es ¿Qué es la Accesibilidad 3? y lo cubriremos, pero antes, me gustaría retroceder un poco en el tiempo y dar algo de contexto sobre por qué la accesibilidad es un tema interesante. En esta diapositiva, podemos ver una imagen de un teclado cuadrado de 18 teclas con nueve dígitos, y las letras A, B, C, D, y las teclas de ayuda y detener. Y por curiosidad, ¿pueden levantar la mano si saben qué es este dispositivo? No veo ninguna mano. En realidad, no me sorprende. Si hubiera visto alguna mano levantada, me habría sorprendido mucho. Pero este dispositivo es de 1988, y es un teclado de lectura de pantalla que fue desarrollado por IBM, y este teclado se acoplaba con un software de lectura de pantalla como parte de uno de los primeros sistemas de lectura de pantalla que se desarrollaron para permitir a las personas con discapacidad visual o ciegas acceder a las computadoras. Pero alguna vez te has preguntado cómo funcionaban los lectores de pantalla en ese entonces? De una manera muy simple, en un sistema operativo basado en texto como MS-DOS, era bastante fácil para los lectores de pantalla acceder a los caracteres que se presentaban en la pantalla, y todo lo que tenían que hacer era convertir este texto en voz. Pero como sabemos, las computadoras evolucionaron rápidamente, y ya a fines de los años 80, los sistemas operativos basados en texto fueron reemplazados por interfaces gráficas de usuario. Y se volvió mucho más complicado para los lectores de pantalla porque una interfaz gráfica de usuario no solo muestra los caracteres. Muestra los píxeles, y la información presentada en la pantalla es mucho más complicada de lo que era. Por ejemplo, el texto puede pertenecer a diferentes ventanas, pero los lectores de pantalla solo deben leer el texto de las ventanas actualmente seleccionadas. Así que tienes diferentes tipos de texto. Tienes menús. Tienes elementos. Tienes botones. Y además de eso, tienes elementos que son puramente visuales como iconos. Entonces, ¿cómo se adaptaron los lectores de pantalla a eso? Bueno, esta es una imagen de un artículo llamado `Haciendo que la GUI hable`, escrito en 1991. Y explica un nuevo enfoque que han estado desarrollando en IBM para hacer que los lectores de pantalla funcionen con interfaces gráficas de usuario. Y la idea era construir una especie de base de datos de texto que modele lo que se muestra en la pantalla. Y a esta base de datos se le llamó modelo fuera de pantalla, y en el artículo anterior, el autor explica que en el modelo fuera de pantalla, las tecnologías de asistencia tenían que hacer suposiciones sobre el rol de las cosas basadas en cómo se dibujan en la pantalla. Por ejemplo, si un texto tiene un borde.

o fondo, entonces probablemente está seleccionado. O si hay una barra de inserción parpadeante alrededor de él, probablemente el usuario pueda ingresar texto. Estoy bastante seguro de que pueden imaginar lo complejos que eran los sistemas y lo difícil que era mantenerlos, y había cierta ambigüedad. Entonces, además de eso, cada vez que salía una nueva versión de la interfaz de usuario, los lectores de pantalla tenían que asegurarse de que el modelo fuera de pantalla siguiera siendo preciso. Hora de tomar un trago, disculpen. ¿Cuál es una mejor solución? Bueno, ya a finales de los años 90, se introdujeron las APIs de Accesibilidad, y el papel de las APIs de Accesibilidad era permitir que los programas y aplicaciones construyeran la base de datos de texto que las tecnologías de asistencia construían previamente. Concretamente, permiten a los sistemas operativos describir los elementos de la interfaz de usuario como objetos con nombres y propiedades, para que las tecnologías de asistencia puedan acceder a esos objetos. Y puse APIs de Accesibilidad en forma plural porque hay muchas, son específicas de la plataforma. Hay algunas para Mac, algunas para Windows, algunas para Android, y son prácticamente estándares. Entonces, podrían preguntarse ¿cómo se ve una API de Accesibilidad? Y en la práctica, es una representación en forma de árbol de la interfaz. Por ejemplo, en Mac, una ventana sería una aplicación que contiene dos hijos, una barra de menú, lo que está en la parte superior, y una ventana que contiene la propia aplicación. Luego, la barra de menú también contendría, como hijos, todos los elementos del menú, y la ventana contendría una barra izquierda, un botón de cierre, campos de búsqueda, etc. Para cada elemento de la interfaz de usuario, los desarrolladores generalmente pueden establecer roles, ¿es esa ventana, es ese un menú? Pueden establecer propiedades. ¿Cuál es la posición de esta ventana? ¿Cuál es su tamaño? Pueden establecer estados. ¿Este elemento del menú está seleccionado o no? Y otras propiedades que son útiles para los desarrolladores, como eventos. Bueno, ahora todos sabemos, sabemos todo sobre los lectores de pantalla y las APIs de Accesibilidad, pero ¿qué pasa con el árbol de Accesibilidad entonces? Bueno, el árbol de Accesibilidad es una representación separada del DOM que se centra en la información relacionada con la accesibilidad. Es construido por el navegador que luego pasa esta información a la API de Accesibilidad de la plataforma. Entonces, en resumen, el árbol de Accesibilidad establece el vínculo entre su HTML, la API de Accesibilidad de la plataforma y la tecnología de asistencia. Ahora veamos cómo los navegadores generan este árbol. Si pensamos en una página típica que está destinada a ser interactuada con una pantalla, un mouse y un teclado, una ruta de representación crítica típica se vería así. El navegador crea el DOM y el modelo de objetos CSS, luego crea el árbol de renderizado, que básicamente es el DOM sin algunos elementos que están ocultos por CSS. Cuando el árbol de renderizado está listo, el navegador puede determinar el tamaño y la posición exactos del elemento, realiza el paso de diseño y luego pinta los nodos en la pantalla uno por uno. Y después de eso, el usuario puede interactuar con la página con su mouse, teclado, etc. Ahora, mirando la experiencia desde el punto de vista de un usuario que utiliza tecnología de asistencia, era diferente. Bueno, el paso de diseño y el paso de pintura no son relevantes aquí porque no es algo que las tecnologías de asistencia aprovecharán. Sin embargo, el navegador utilizará el árbol de renderizado, el árbol sin los elementos ocultos, para construir el árbol de Accesibilidad. Luego, el árbol de Accesibilidad pasará la información a la API de Accesibilidad de la plataforma que puede ser consultada por tecnologías de asistencia como lectores de pantalla. Entonces, veamos cómo se ve el árbol. Cómo mostrar el árbol de Accesibilidad. La mejor manera de entenderlo es verlo usando DevTools. Voy a usar las DevTools de Chrome en esta presentación.

Sin embargo, debido a que el árbol es construido por el navegador y porque está construido para la plataforma API, tienes un árbol ligeramente diferente si lo ves en otro navegador o en otra plataforma. Sin embargo, estas diferencias no son muy grandes. Entonces, en Chrome, lo primero que debes hacer es abrir las DevTools. Luego, en el panel inferior, donde tienes la pestaña de tamaño, tienes una pestaña de accesibilidad. Asegúrate de que la casilla de verificación de habilitar el árbol de accesibilidad de página completa esté marcada. Y ahora, en la pestaña de elementos del panel superior, donde normalmente inspeccionas el DOM, hay un botón llamado cambiar a la vista del árbol de accesibilidad. Y al hacer clic en este botón, se mostrará el árbol de accesibilidad de página completa. Justo en el panel donde normalmente está el DOM. Veámoslo en acción. Aquí hay una página HTML muy pequeña. Podemos ver que tiene una etiqueta main. Tiene un par de encabezados. Tiene una lista ordenada, un pie de página, y un enlace en su interior. Y si observamos el árbol de accesibilidad para esta página, podemos ver que se ve bastante similar al DOM. Vemos el main, los encabezados, los elementos de la lista. Hay algunas pequeñas diferencias. El pie de página se llama content info y la etiqueta de ancla se llama enlace. Pero en general, la estructura es bastante similar. También notamos esos dos objetos que dicen ignorados. Y aquí se refieren a las etiquetas HTML y body. Y en realidad, no son los únicos elementos que no se incluyen en el árbol. Debido a que el árbol de accesibilidad está destinado a la tecnología de asistencia, excluye todos los elementos que no son relevantes para las tecnologías de asistencia. Por ejemplo, elementos que tienen una función de diseño y no una función semántica como los divs o los spans que solo se utilizan para estilos. Por lo tanto, excluye los elementos que están en el HTML pero que no son visibles. Pueden ser elementos ocultos por propiedades de CSS como display: none o visibility: hidden, o también el atributo hidden del HTML. También se excluyen las imágenes con atributos vacíos que no se muestran. Y hasta ahora, esto no debería ser confuso ni sorprendente. Ahora, se vuelve un poco más complejo cuando hablamos de ARIA. El árbol de accesibilidad no incluirá los elementos con ARIA hidden true, así como sus hijos. Y por cierto, si no estás seguro del propósito de ARIA hidden,

es exactamente esto. Si cito de MDN, el estado oculto de ARIA indica si el elemento está expuesto a una API de accesibilidad. En general, querrás dar este atributo a elementos que son puramente decorativos, a contenidos duplicados o a elementos colapsados como por ejemplo en un menú desplegable o algo similar. Y la última exclusión común son los elementos con rol none o presentation. Esos dos roles son sinónimos. Y es como ARIA hidden excepto que el nodo en sí no se va a exponer. Sin embargo, los hijos aún formarán parte del árbol. Y una vez más, para este atributo de ARIA, ocultar los elementos delaccesibilidad tree es el primer propósito del atributo.

Volviendo a los elementos que se incluyen en el árbol, cada elemento es en realidad un objeto y puede tener varias propiedades. En Chrome DevTools, puedes inspeccionar esas propiedades en el panel de accesibilidad. Los objetos en los árboles de accesibilidad pueden tener un rol, pueden tener un nombre, una descripción y otras propiedades. Así que veamos ahora un par de mapeos entre el código HTML y el objeto de accesibilidad en el árbol de accesibilidad. Así que no en el diseño de la diapositiva, en la izquierda, puedes ver el código HTML y a la derecha, el objeto de accesibilidad en el árbol de accesibilidad. Por ejemplo, un elemento de botón se presentará en el árbol de accesibilidad como un objeto con rol button y el nombre se refiere al contenido de texto aquí, toggle menu. Y esta información es útil para los lectores de pantalla porque ahora pueden anunciar correctamente el elemento como toggle menu button. En la parte inferior de la pantalla se muestra una captura de pantalla de la salida de voiceover, que es el lector de pantalla predeterminado de Mac. Representa lo que el lector de pantalla diría en voz alta. Además del nombre y el rol, los elementos con ciertos roles pueden tener estados y propiedades adicionales. Por ejemplo, una casilla de verificación puede tener un estado de selección o un encabezado puede tener una propiedad de nivel. Y no solo se utiliza esta información cuando se anuncia el elemento, como aquí en el caso de un encabezado, donde el texto del encabezado se precederá con nivel de encabezado 1, sino que también puede ser utilizada por los lectores de pantalla en otras partes de su experiencia de usuario. Por ejemplo, los lectores de pantalla suelen permitir a los usuarios navegar por la página mediante los encabezados. Entonces, utilizando el formato adecuado, nuestro encabezado también se incluirá en este menú. Profundizando en la propiedad de rol, los elementos semánticos suelen tener un rol implícito. Y hay un par de excepciones, pero más o menos es una correspondencia uno a uno entre las etiquetas HTML y los roles. Por ejemplo, la etiqueta nav tiene un rol de navegación y una lista ordenada tiene un rol de lista. Otra forma en que los lectores de pantalla pueden aprovechar esta información es, por ejemplo, si tienes una lista, el lector de pantalla dirá cuántos elementos hay en esta lista y cuál es la posición de los elementos que se ven actualmente. Entonces, ¿qué sucede si establecemos manualmente un atributo de rol en un elemento HTML? Por ejemplo, aquí, convertimos nuestra URL para tener el rol de lista de pestañas y el elemento de lista para tener un rol de pestaña. Cuando el valor del rol tiene prioridad sobre el rol HTML nativo del elemento, también significa que, por ejemplo, los elementos de la lista heredarán todas las propiedades que normalmente se asignarían a un elemento de pestaña y no a un elemento de lista. Y hay buenas razones para establecer roles personalizados en elementos HTML como este. Construir un widget como una pestaña es un buen ejemplo, pero en general, se recomienda tener un poco de precaución al

Estamos haciendo esto porque puede tener consecuencias inesperadas. Ahora veamos la propiedad de nombre, también llamada nombre accesible. En primer lugar, el nombre está destinado a identificar los elementos de la interfaz de usuario. Entonces, muchos elementos simplemente toman el nombre accesible del contenido de texto. Ese es el caso de los encabezados, por ejemplo, pero también de elementos como botones o enlaces. Sin embargo, no todos los elementos tienen un nombre. Por lo general, los elementos decorativos no lo tienen, al igual que los elementos que solo contienen texto, como los párrafos. Para algunos elementos, el nombre accesible es opcional. Por ejemplo, la navegación. Por defecto, la navegación no tiene nombre y simplemente se anuncia como `navegación`, pero puedes darle un nombre utilizando los atributos area-label o area-label-byte, y este nombre se utilizará como lector de pantalla. Por ejemplo, anunciarían un menú con el área de etiqueta `menú principal` como `navegación menú principal`. Esto a veces tiene casos de uso, por ejemplo, si tienes muchos menús en tu página, es posible que desees etiquetarlos. Y puede que te preguntes de dónde proviene el nombre accesible, ¿del contenido de texto o de los atributos ARIA? Bueno, el nombre accesible es determinado por los agentes de usuario a partir de una lista de posibles fuentes que se clasifican por orden de preferencia. Esto se llama cálculo del nombre accesible. Y como regla general, el nombre accesible se determinará en el siguiente orden. Primero, el elemento al que se hace referencia mediante el atributo area-label-byte, luego el área de etiqueta, luego el contenido de texto, que incluye el contenido de los elementos before y after, y luego los atributos de título. Esto es una simplificación, hay más detalles en esto. Por ejemplo, si tienes un elemento de entrada, utilizarán la etiqueta como nombre accesible o las imágenes utilizarán el contenido del atributo. Pero lo más importante aquí es que los atributos ARIA siempre sobrescriben el nombre accesible del elemento. Y hay muchos casos de uso en los que esto está perfectamente bien. Pero también puede causar problemas. Un error común, por ejemplo, es que el contenido de los atributos HTML no se traduce. Entonces, si colocas la etiqueta de tu botón en un área de etiqueta en lugar de en el contenido de este elemento, y una persona utiliza un traductor automático, no obtendrán la traducción para ese elemento específico. Bien, nos acercamos al final de la presentación. Así que resumamos rápidamente. Si te preguntas qué puedes hacer en tu día a día con el árbol de accesibilidad, aquí tienes un par de ideas. Primero, verifica el efecto de los atributos ARIA. El propósito de ARIA es ampliar las capacidades nativas de HTML, y ARIA proporciona roles que de otra manera no estarían disponibles. También puede cambiar la semántica nativa de un elemento, y no siempre es obvio cuál es el efecto de ARIA solo al mirar el DOM. Entonces, si utilizas ARIA, definitivamente debes verificar el árbol de accesibilidad. Luego, verifica el nombre accesible. Nuevamente, especialmente si utilizas atributos ARIA, como area-label o area-label-byte. Y finalmente, si pruebas con tecnología de asistencia o si recibes un informe de error relacionado con la accesibilidad, el árbol de accesibilidad es una excelente herramienta de depuración para comprender qué pudo haber salido mal. Eso es todo. Gracias.