Entendiendo el árbol de accesibilidad

Entendiendo el árbol de accesibilidad

Venga, hoy toca un post un poco más técnico, menos molón o divertido que los anteriores en los que hacemos cosas con Inteligencia Artificial, pero a veces hay que ponerse con este otro tipo de cosas, hoy toca entender el árbol de accesibilidad.

Como desarrolladores, diseñadores y creadores de contenido, trabajamos incansablemente para construir experiencias web visualmente atractivas y funcionales y para eso necesitamos conocer el Modelo de Objetos del Documento (DOM), una estructura de árbol que el navegador crea para representar y renderizar una página. Pero hay otro árbol, uno que trabaja en segundo plano y que es la clave para que la web sea verdaderamente para todos: el árbol de accesibilidad.

Comprender qué es, cómo funciona y por qué es tan crucial, no es solo una cuestión de cumplir con las normativas; es la diferencia entre construir una barrera digital y crear un puente hacia la inclusión.

¿Qué es el Árbol de Accesibilidad?

Piénsalo de esta manera: el navegador toma el complejo y, a menudo, desordenado código HTML (el DOM) y lo traduce en la página visual que vemos. De forma paralela, crea una segunda versión, una estructura simplificada y depurada, diseñada específicamente para ser interpretada por tecnologías de asistencia como los lectores de pantalla. Esta estructura es el árbol de accesibilidad (Accessibility Tree).

Este árbol es el puente fundamental entre tu contenido web y las API de accesibilidad de la plataforma (como MSAA en Windows o AXAPI en macOS), que a su vez comunican la información a los productos de apoyo que utilizan las personas con discapacidad. No contiene todos los <div> y <span> que usas para maquetar, sino solo los elementos que tienen un significado o una función relevante.

¿Cómo se Construye el árbol de accesibilidad?

El proceso de creación del árbol de accesibilidad es un ejercicio de filtrado y semántica. El navegador examina el DOM y decide qué incluir en esta estructura especializada.

1. Filtrado de Elementos: El navegador elimina todo lo que es puramente decorativo o irrelevante para un usuario que no puede ver la interfaz. Esto incluye:
   • Elementos ocultos con display: none o visibility: hidden.
   • Elementos explícitamente ocultos para las tecnologías de asistencia con aria-hidden="true".
   • Elementos sin semántica propia que solo se usan para maquetar, como un <div> o <span> sin un rol ARIA asignado.
   • Elementos cuyo rol ha sido definido como presentation o none, que le indica al navegador que ignore su semántica nativa.
2. Cómputo de Propiedades Accesibles: Para cada nodo que sí es relevante, el navegador calcula un conjunto de propiedades esenciales que lo definen para las tecnologías de asistencia. Estos son los pilares del criterio 4.1.2 de las WCAG: Nombre, Función y Valor.
   • Nombre (Name): ¿Cómo se llama este elemento? Es su etiqueta o nombre accesible. Se puede obtener de diversas fuentes, como el texto de un <button>, el atributo alt de una <img>, el contenido de un <label> asociado a un <input>, o un aria-label o aria-labelledby de ARIA.
   • Función (Role): ¿Qué es este elemento? Es su propósito o tipo. Puede ser un "botón", un "enlace", un "encabezado", una "región", etc. Esta información la proporciona la etiqueta HTML nativa (<button>, <h1>) o un role de ARIA explícito.
   • Estado (State): ¿En qué condición se encuentra? Puede estar "marcado" (aria-checked), "expandido" (aria-expanded), "deshabilitado" (aria-disabled), etc.
   • Valor (Value): ¿Cuál es su valor actual? Es relevante para elementos como un control deslizante (slider), que tiene un valor actual, mínimo y máximo (aria-valuenow, aria-valuemin, aria-valuemax).

El resultado final es un árbol limpio y lógico que un lector de pantalla puede recorrer para anunciar al usuario: «Botón, Buscar», «Encabezado nivel 2, Próximos Eventos» o «Casilla de verificación, marcada, Acepto los términos».

DOM vs. árbol de accesibilidad: Dos Caras de la Misma Moneda

Es fundamental entender que aunque están relacionados, el DOM y el Árbol de Accesibilidad no son lo mismo. Un código HTML que se ve perfectamente en el navegador puede generar un árbol de accesibilidad roto o inútil.

El error más común es asumir que si algo «se ve bien» y «funciona con el ratón», es accesible. Pero si la información semántica no llega al árbol de accesibilidad, para un usuario de lector de pantalla, ese componente simplemente no existe.

El rol de ARIA: El modificador del árbol de accesibilidad

Aquí es donde WAI-ARIA (Accessible Rich Internet Applications) entra en juego. ARIA es una especificación del W3C cuyo único propósito es permitir a los desarrolladores modificar el árbol de accesibilidad. Es importante recalcar esto: ARIA no cambia la apariencia, la funcionalidad del teclado ni el comportamiento del ratón de un elemento. Solo altera cómo ese elemento es presentado a la API de accesibilidad.

Y si queréis profundizar algo más en el tema, el otro día, (recordad que esto incluye un periodo de tiempo que no es hoy, y que puede ser cualquier día en el pasado) escribó un post sobre el tema: WAI-ARIA: Desde los Fundamentos Hasta un Uso Avanzado

• Cuando usas role="button" en un <div>: No haces que el div se vea o actúe como un botón. Simplemente le dices al navegador: «Oye, en el árbol de accesibilidad, donde normalmente no pondrías nada para este div, ahora pon un nodo con la función de botón». El desarrollador sigue siendo responsable de añadir el tabindex para el foco y los manejadores de eventos de teclado (como onKeyDown) para que sea operable.
• Cuando usas aria-label="Buscar": Le das un «nombre accesible» a un elemento que de otra manera no lo tendría.
• Cuando usas aria-expanded="true": Modificas el «estado» de un elemento para indicar que está expandido.

ARIA es la herramienta que nos permite corregir la semántica cuando el HTML nativo no es suficiente, especialmente en componentes dinámicos y complejos como menús, pestañas o ventanas modales.

¿Cómo puedo ver el árbol de accesibilidad?

La buena noticia es que no tienes que adivinar lo que hay en el árbol. Los navegadores modernos nos permiten inspeccionarlo directamente desde sus herramientas de desarrollo.

Os dejo cómo encontrarlo en los principales navegadores:

Google Chrome:

• Abre las Herramientas para desarrolladores (F12 o clic derecho > Inspeccionar).
• En el panel Elementos, selecciona un elemento de la página.
• En el panel de la derecha (donde ves los estilos CSS), busca y abre la pestaña Accesibilidad. Allí verás el nodo del árbol de accesibilidad y sus propiedades computadas (rol, nombre, estado, etc.).

Mozilla Firefox:

• Abre las Herramientas de desarrollo (F12 o clic derecho > Inspeccionar).
• Firefox le da a la accesibilidad un lugar prioritario. Busca y haz clic en la pestaña principal de Accesibilidad en la barra de herramientas de desarrollo.
• Esto activará el inspector de accesibilidad, que te permite examinar el árbol completo y las propiedades de cada elemento.

Microsoft Edge:

• Al estar basado en Chromium, el proceso es idéntico al de Chrome.
• Abre las Herramientas de desarrollo (F12) y selecciona la pestaña Accesibilidad en el panel de la derecha para ver las propiedades del elemento seleccionado.

Safari:

• Primero, debes activar el menú Desarrollo en las preferencias de Safari (Preferencias > Avanzado > «Mostrar el menú Desarrollo en la barra de menús»).
• Luego, abre el Inspector web (clic derecho > Inspeccionar elemento).
• En la pestaña Elementos, selecciona un nodo. Los detalles de accesibilidad aparecerán en la barra lateral de detalles del nodo.

Usar esta herramienta es fundamental para la depuración. Si un lector de pantalla anuncia algo incorrectamente, el primer paso es ver qué información está recibiendo del árbol de accesibilidad.

Como siempre, espero que os haya servido y que os ayude a mejorar la accesibilidad de vuestras cosas, (o a medir la accesibilidad de las cosas de otros)