Las Herramientas para desarrolladores de Chrome lanzarán un árbol de accesibilidad completo para que los desarrolladores puedan obtener una descripción general de este árbol con mayor facilidad. En esta publicación, descubrirás cómo se crea este árbol y cómo usarlo en tu trabajo.
¿Qué es el árbol de accesibilidad?
La tecnología de accesibilidad, como los lectores de pantalla, usan la API de accesibilidad de Chromium para interactuar con el contenido web. El modelo subyacente de esta API es el árbol de accesibilidad, un árbol de objetos de accesibilidad en los que la tecnología de accesibilidad puede consultar atributos y propiedades, y realizar acciones. Los desarrolladores web definen y manipulan el árbol de accesibilidad principalmente a través de propiedades DOM, como los atributos ARIA para HTML.
En las herramientas para desarrolladores de Chrome, proporcionamos el panel de accesibilidad para ayudar a los desarrolladores a comprender cómo se expone su contenido a la tecnología de accesibilidad. De manera concreta, cuando se selecciona un nodo en el visor del árbol del DOM, las propiedades del nodo de accesibilidad correspondiente se muestran en el panel junto con una vista de los elementos principales del nodo y sus elementos secundarios inmediatos.
¿Cómo se crea el árbol?
Antes de ver cómo se ve esta nueva vista de árbol completa en Herramientas para desarrolladores, repasemos brevemente qué es el árbol de accesibilidad en términos más tangibles. El árbol de accesibilidad es una derivada del árbol del DOM. Su estructura es más o menos la misma, pero está simplificada para quitar nodos sin contenido semántico, como un elemento <div> que solo se usa para diseñar. Cada nodo del árbol tiene un rol como Button o Heading y, a menudo, un nombre que puede ser de atributos ARIA o derivado del contenido del nodo. Si vemos un documento HTML:
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
El procesador de Chromium, llamado Blink, deriva un árbol de accesibilidad interno más o menos de la siguiente manera.
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
Ten en cuenta que esta representación contiene varios nodos superfluos con la función genericContainer, que aparentemente contradice la afirmación anterior de que el árbol de accesibilidad es una derivada simplificada del árbol del DOM. Sin embargo, la mayoría de estos nodos solo ocurren en el árbol interno y no estarían expuestos a la tecnología de asistencia. Dado que Herramientas para desarrolladores recopila su información de accesibilidad directamente del proceso del renderizador, esta es la representación de árbol que maneja Herramientas para desarrolladores.
Árbol de accesibilidad completo en Herramientas para desarrolladores
El nuevo árbol de accesibilidad completo se sincroniza con el árbol del DOM para que los desarrolladores puedan alternar entre los dos árboles. Esperamos que el nuevo árbol sea más explorable, útil y fácil de usar.
Ahora que sabes cómo funciona el árbol de accesibilidad, puedes usar Herramientas para desarrolladores para ver cómo se ve la nueva vista de árbol. El siguiente documento HTML con un título, encabezado y dos botones se usa para mostrar el árbol.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
La vista de árbol anterior solo te permitiría explorar un solo nodo y sus elementos principales.
Ahora, cuando actives el nuevo árbol, reemplazará la vista de árbol del DOM y te permitirá ver el árbol de accesibilidad completo de la página:
Construcción diferida de árboles
Para que el árbol tenga un buen rendimiento incluso en sitios más grandes, el árbol se construye de forma diferida en el frontend a medida que se explora. Una vez que se expande un nodo en el árbol, los elementos secundarios de los nodos se recuperan a través del Protocolo de Herramientas para desarrolladores de Chrome (CDP) y se reconstruye el árbol.
Transmisiones en vivo
La nueva vista de árbol está activa y se actualiza de forma dinámica si el árbol de accesibilidad cambia en el procesador. Se conecta a la misma mecánica que notificaría a la tecnología de asistencia sobre cambios en el árbol y la usa para emitir eventos al frontend de Herramientas para desarrolladores con nodos actualizados. En la práctica, el backend de CDP detecta actualizaciones del árbol, lleva un registro de los nodos que se solicitaron antes y envía eventos al frontend de Herramientas para desarrolladores si alguno de estos nodos cambia.
La historia de muchos árboles
En la descripción de el árbol de accesibilidad, aprendiste cómo Blink construye un árbol de accesibilidad para el DOM que está renderizando, y las Herramientas para desarrolladores recuperan este árbol a través de CDP. Si bien esto es cierto, dejamos de lado algunas complicaciones en esta descripción. En realidad, hay muchas formas diferentes de experimentar el árbol de accesibilidad en Chromium. Al diseñar la nueva vista de árbol para Herramientas para desarrolladores, tomamos algunas decisiones sobre qué parte de los componentes internos de accesibilidad de Chromium queríamos mostrar.
Plataformas
Cada plataforma tiene una API de accesibilidad diferente y, si bien la forma del árbol es la misma en todas las plataformas, la API para interactuar con el árbol es diferente y los nombres de los atributos pueden variar. Las Herramientas para desarrolladores muestran el árbol interno de Chromium, donde los roles y atributos tienden a coincidir con los definidos en la especificación de ARIA.
Varios marcos y aislamiento de sitios
Dado que Chromium no solo coloca el contenido de cada pestaña en diferentes procesos del renderizador, sino que también aísla documentos entre sitios en diferentes procesos del renderizador, debemos conectarnos a cada documento secundario fuera del proceso por separado a través de CDP y recuperar su árbol de accesibilidad. Luego, unimos estos subárboles en el frontend para crear la ilusión de un árbol coherente, aunque se encuentran en diferentes procesos de renderizado en Chromium.
Nodos ignorados y poco interesantes
Ocultaremos algunos nodos según la configuración predeterminada: nodos ignorados y nodos con rol “genérico” sin nombre. Estos nodos no tienen significado semántico y, en el caso de los nodos ignorados, no están expuestos a tecnología de accesibilidad. Ocultaremos estos nodos para evitar desordenar la vista de árbol. Si no lo hiciéramos, el árbol de accesibilidad de la mayoría de las páginas web se vería así:
La salvedad es que esto significa que necesitamos construir un árbol más que el que está disponible en el backend. Digamos, por ejemplo, que tenemos los nodos A, B, C y X, donde A tiene X y B secundarios, y X tiene el secundario C. Si X es un nodo ignorado, eliminamos X del árbol y, en su lugar, creamos un árbol en el que C es un elemento secundario de A.
En el frontend, construimos el árbol completo, incluidos los nodos ignorados, y solo los podemos recortar antes de procesarlos. Lo hacemos por dos motivos:
- Facilita mucho el manejo de las actualizaciones de nodos desde el backend, ya que tenemos la misma estructura de árbol en ambos extremos. Por ejemplo, si se quita el nodo B en el ejemplo, recibiríamos una actualización para el nodo X (ya que sus elementos secundarios cambiaron), pero si lo hubiéramos reducido, tendríamos dificultades para averiguar qué actualizar.
- Garantiza que todos los nodos del DOM tengan un nodo de accesibilidad correspondiente. Cuando se activa el árbol, seleccionamos el nodo correspondiente al nodo seleccionado actualmente en el árbol del DOM. En el ejemplo anterior, si el usuario activa o desactiva el árbol mientras el nodo DOM correspondiente a X está seleccionado, inyectamos X entre los nodos A y B, y seleccionamos X en el árbol. Esto permite al usuario inspeccionar el nodo de accesibilidad de todos los nodos del DOM y ayudar a determinar la razón por la cual se ignora el nodo.
Ideas para el futuro
El lanzamiento del nuevo árbol de accesibilidad es solo el comienzo. Tenemos algunas ideas para proyectos futuros que podríamos desarrollar a partir de la nueva vista, pero también estamos ansiosos por escuchar tus comentarios.
Filtrados alternativos
Como se explicó anteriormente, actualmente filtramos los nodos que se consideran poco interesantes. Podríamos proporcionar una forma de inhabilitar este comportamiento y mostrar todos los nodos, o bien proporcionar filtros alternativos, como Mostrar nodos de puntos de referencia o Mostrar encabezados.
Destacar problemas de a11y
Podríamos incorporar un análisis de “práctica recomendada de accesibilidad” con el árbol y destacar los problemas de accesibilidad directamente en los nodos infractores.
Muestra acciones de accesibilidad en Herramientas para desarrolladores
El árbol que mostramos actualmente es puramente unidireccional: nos permite tener una idea de qué información se proporcionaría a la tecnología de asistencia al navegar por una página web específica. Las acciones de accesibilidad representan la comunicación en la dirección opuesta: permiten que la tecnología de accesibilidad actúe en la IU presentada. Podríamos mostrar esas acciones en Herramientas para desarrolladores a fin de permitir acciones como “hacer clic, desplazarse o cambiar valores en la página mediante el uso de la API disponible para la tecnología de asistencia.