Las Herramientas para desarrolladores de Chrome lanzarán un árbol de accesibilidad completo, lo que facilitará que los desarrolladores obtengan una descripción general de todo el árbol. En esta publicación, descubrirás cómo se crea este árbol y cómo puedes usarlo en tu trabajo.
¿Qué es el árbol de accesibilidad?
La tecnología de asistencia, como los lectores de pantalla, usa 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 que la tecnología de accesibilidad puede consultar por atributos y propiedades, y sobre los cuales puede realizar acciones. Los desarrolladores web modelan y manipulan el árbol de accesibilidad, principalmente, con propiedades del DOM, como los atributos ARIA para HTML.
En las herramientas para desarrolladores de Chrome, proporcionamos el panel de accesibilidad que ayuda a los desarrolladores a comprender cómo se expone su contenido a la tecnología de accesibilidad. Concretamente, 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 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 en qué consiste el árbol de accesibilidad en términos más tangibles. El árbol de accesibilidad es una derivada del árbol del DOM. Su estructura es prácticamente la misma, pero se simplificó para quitar nodos sin contenido semántico, como un elemento <div> que solo se usa para aplicar estilos. Cada nodo del árbol tiene una función como Button o Heading y, a menudo, un nombre que puede ser de los atributos de ARIA o derivado del contenido del nodo. Si miramos 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, aproximadamente, 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, lo que aparentemente contradice la afirmación anterior, según la cual el árbol de accesibilidad es un derivado simplificado 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 desde el proceso del renderizador, esta es la representación de árbol que controla Herramientas para desarrolladores.
Árbol de accesibilidad completo en Herramientas para desarrolladores
El árbol de accesibilidad nuevo y completo sincronizado con el árbol del DOM, de modo que los desarrolladores pueden alternar entre los dos árboles. Esperamos que el nuevo árbol sea más útil, fácil de usar y más explorable.
Ahora que sabes cómo funciona el árbol de accesibilidad, puedes usar las Herramientas para desarrolladores para observar 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 principales.
Ahora, al activar o desactivar el árbol nuevo, se reemplazará la vista de árbol del DOM y se podrá ver el árbol de accesibilidad completo de la página:
Construcción de árboles perezosos
A fin de que el árbol funcione incluso para sitios más grandes, el árbol se construye de forma diferida en el frontend a medida que se explora. Una vez que un nodo se expande en el árbol, los elementos secundarios de los nodos se recuperan a través del protocolo Chrome Herramientas para desarrolladores (CDP) y se vuelve a compilar 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 con la misma mecánica que notificaría a la tecnología asistencial de los 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 escucha las actualizaciones del árbol, hace un seguimiento 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 qué es el árbol de accesibilidad, aprendiste cómo Blink construye un árbol de accesibilidad para el DOM que está renderizando, y Herramientas para desarrolladores recupera este árbol a través de CDP. Si bien esto es cierto, omitimos algunas complicaciones en esta descripción. En realidad, hay muchas formas diferentes de experimentar el árbol de accesibilidad en Chromium. Cuando diseñamos la nueva vista de árbol para Herramientas para desarrolladores, tomamos algunas decisiones durante el proceso 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 diferir. Herramientas para desarrolladores muestra el árbol interno de Chromium en el que los roles y atributos tienden a coincidir con los definidos en la especificación de ARIA.
Múltiples marcos y aislamiento de sitios
Dado que Chromium no solo coloca el contenido de cada pestaña en diferentes procesos de renderización, sino que también aísla los documentos entre sitios en diferentes procesos de renderización, 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 generar la ilusión de un árbol coherente, aunque se encuentran en diferentes procesos de renderizado en Chromium.
Nodos ignorados y poco interesantes
De forma predeterminada, ocultamos algunos nodos: los nodos ignorados y aquellos con la función “genérica” sin nombre. Estos nodos no tienen significado semántico y, en el caso de nodos ignorados, no están expuestos a tecnología de asistencia. Estos nodos se ocultan para no saturar la vista de árbol. Si no lo hiciéramos, el árbol de accesibilidad de la mayoría de las páginas web tendría el siguiente aspecto:
La salvedad es que esto significa que necesitamos construir un árbol más que el que está disponible en el backend. Por ejemplo, supongamos que tenemos los nodos A, B, C y X, en los que A tiene el secundario X y B, y X tiene el secundario C. Si X es un nodo ignorado, se puede eliminar X del árbol y, en cambio, crear 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 eliminamos justo antes de renderizar los nodos. Lo hacemos por dos motivos:
- Simplifica mucho el control de las actualizaciones de nodos desde el backend, ya que tenemos la misma estructura de árbol en ambos extremos. Por ejemplo, si se quitara el nodo B del ejemplo, recibiríamos una actualización para el nodo X (ya que sus campos secundarios cambiaron), pero si lo hubiéramos reducido, tendríamos dificultades para descubrir qué actualizar.
- Garantiza que todos los nodos del DOM tengan un nodo de accesibilidad correspondiente. Cuando se activa o desactiva el árbol, seleccionamos el nodo correspondiente al nodo actualmente seleccionado en el árbol del DOM. En el ejemplo anterior, si el usuario activa o desactiva el árbol mientras está seleccionado el nodo DOM que corresponde a X, insertamos X entre los nodos A y B, y seleccionamos X en el árbol. Esto permite que el usuario inspeccione el nodo de accesibilidad en busca de todos los nodos del DOM y que ayude a determinar por qué se ignora el nodo.
Ideas para el futuro
El lanzamiento del nuevo árbol de accesibilidad es solo el comienzo. Tenemos algunas ideas para futuros proyectos que podríamos desarrollar a partir de la nueva vista, pero también nos gustaría escuchar tus comentarios.
Filtros 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 accesibilidad
Podríamos incorporar un análisis de “prácticas recomendadas 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 recibirí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 asistencia actúe en función de la IU presentada. Podríamos mostrar esas acciones en Herramientas para desarrolladores para permitir acciones como “hacer clic”, desplazarse o cambiar los valores en la página usando la API disponible para la tecnología de asistencia.