Chrome DevTools lanzará un árbol de accesibilidad completo que facilitará que los desarrolladores obtengan una descripción general de todo el árbol. En esta publicación, descubre cómo se crea este árbol y cómo usarlo en tu trabajo.
¿Qué es el árbol de accesibilidad?
Las tecnologías 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 el que la tecnología de accesibilidad puede consultar atributos y propiedades, y realizar acciones. Los desarrolladores web dan forma y manipulan el árbol de accesibilidad principalmente a través de propiedades del DOM, como los atributos ARIA para HTML.
En Chrome DevTools, proporcionamos el panel de accesibilidad para ayudar a los desarrolladores a comprender cómo se expone su contenido a la tecnología de accesibilidad. Específicamente, cuando se selecciona un nodo en el visor de árbol del DOM, las propiedades del nodo de accesibilidad correspondiente se muestran en el panel junto con una vista de los ancestros 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 DevTools, repasemos brevemente qué es el árbol de accesibilidad en términos más tangibles. El árbol de accesibilidad es una derivación del árbol del DOM. Su estructura es aproximadamente la misma, pero se simplifica para quitar los nodos sin contenido semántico, como un elemento <div> que se usa solo para aplicar diseño. 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 observamos un documento HTML, veremos lo siguiente:
<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 renderizador de Chromium, llamado Blink, deriva un árbol de accesibilidad interno 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 el rol genericContainer, lo que parece contradecir la afirmación anterior de que el árbol de accesibilidad es una derivación 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 DevTools recopila su información de accesibilidad directamente del proceso del renderizador, esta es la representación del árbol que controla DevTools.
Árbol de accesibilidad completo en Herramientas para desarrolladores
El nuevo árbol de accesibilidad completo sincronizado 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 DevTools para ver cómo se ve la nueva vista de árbol. El siguiente documento HTML con un título, un 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 permitía explorar un solo nodo y sus ancestros.
Ahora, cuando actives el nuevo árbol, se reemplazará la vista de árbol del DOM y podrás ver el árbol de accesibilidad completo de la página:
Construcción de árboles diferidos
Para que el árbol tenga un buen rendimiento incluso en sitios más grandes, 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.
En vivo
La nueva vista de árbol está activa y se actualiza de forma dinámica si el árbol de accesibilidad cambia en el renderizador. Se conecta con 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 en el árbol, realiza un seguimiento de los nodos que se solicitaron anteriormente y envía eventos al frontend de DevTools si cambia alguno de estos nodos.
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 renderiza y DevTools 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 DevTools, tomamos algunas decisiones sobre qué parte de los elementos 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. Las Herramientas para desarrolladores muestran el árbol interno de Chromium, en el que los roles y los atributos suelen 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 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 dar la ilusión de un árbol coherente, aunque se encuentran en diferentes procesos de renderización en Chromium.
Nodos ignorados y poco interesantes
Ocultamos algunos nodos de forma predeterminada: los nodos ignorados y los nodos con el 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. Ocultamos estos nodos para evitar que la vista de árbol se vea desordenada. 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. Por ejemplo, supongamos que tenemos los nodos A, B, C y X, en los que A tiene como hijos a X y B, y X tiene como hijo a 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 podamos justo antes de renderizarlos. Lo hacemos por dos motivos:
- Facilita mucho la administración 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 está seleccionado el nodo DOM correspondiente a X, insertamos X entre los nodos A y B, y lo seleccionamos en el árbol. Esto permite al usuario inspeccionar el nodo de accesibilidad de todos los nodos del DOM y ayudar 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 proyectos futuros que podríamos crear en función de la nueva vista, pero también queremos 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 punto de referencia o Mostrar encabezados.
Destacar problemas de a11y
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.
Cómo mostrar acciones de accesibilidad en DevTools
El árbol que mostramos actualmente es unidireccional: nos permite tener una idea de qué información se le enviaría a la tecnología de accesibilidad cuando se navega por una página web específica. Las acciones de accesibilidad representan la comunicación en la otra dirección: permiten que la tecnología de accesibilidad actúe en la IU presentada. Podríamos mostrar esas acciones en DevTools para permitir acciones como “hacer clic”, desplazarse o cambiar valores en la página con la API disponible para la tecnología de accesibilidad.