Fundamentos del Accessibility Tree: Cómo Ven las Máquinas

¿Por qué el Diseñador debe Conocer el Árbol de Accesibilidad?

Como diseñadores, solemos centrarnos en el DOM Visual (colores, formas, posiciones). Sin embargo, para los usuarios ciegos o con discapacidad visual, tu diseño es solo lo que el Árbol de Accesibilidad dice que es.

Si un botón en tu diseño parece una flecha azul, pero en el Árbol de Accesibilidad no tiene nombre, para una persona ciega ese botón “no existe” o es inútil. Entender este árbol es la clave para un handoff accesible a desarrollo.

Los 4 Pilares de un Nodo de Accesibilidad

Cada elemento de tu interfaz que es enviado al árbol tiene cuatro propiedades críticas que tú, como diseñador, debes definir:

1. El Rol (Role)

¿Qué es este objeto? Es el propósito funcional del elemento.

• Ejemplos: button, checkbox, heading, link, main.
• Importancia: Indica al usuario qué puede esperar hacer con ese elemento.

2. El Nombre (Name)

¿Cómo se llama este objeto? Es la etiqueta identificativa.

• Ejemplos: “Enviar formulario”, “Cerrar ventana”, “Buscar”.
• Fuente: Puede venir del texto visible dentro de un botón o de un atributo invisible (aria-label).

3. El Estado (State)

¿Qué está haciendo el objeto ahora?

• Ejemplos: checked, expanded, disabled, focused.
• Importancia: Comunica al usuario si un menú está abierto o si un checkbox está marcado sin necesidad de verlo.

4. El Valor (Value)

¿Cuál es la información actual del objeto?

• Ejemplos: En un slider, el valor sería “50%”. En un input de texto, el valor sería lo que el usuario ha escrito.

Cómo Diseñar para el Árbol de Accesibilidad

Tú, como diseñador de producto, eres el responsable de orquestar esta experiencia “no visual”:

• Define los Roles Claramente: Si diseñas algo que se comporta como un botón, asegúrate de documentarlo como tal para que los desarrolladores no lo construyan como un simple enlace o un div.
• Evita la Falta de Nombre: Todos los iconos interactivos (como el de la “X” para cerrar) deben tener un nombre accesible oculto. De lo contrario, el lector de pantalla dirá simplemente “botón” sin contexto.
• Cuidado con la Jerarquía de Encabezados (Headings): El árbol usa los encabezados (H1, H2, H3) como un índice para que el usuario pueda saltar de sección en sección. Si saltas de un H1 a un H4 por estética, estás rompiendo el índice para el usuario ciego.
• Oculta lo que no sea necesario: Algunos elementos visuales (como iconos decorativos o líneas de adorno) solo añaden ruido. Puedes pedir a los desarrolladores que los oculten del árbol de accesibilidad mediante aria-hidden="true".

El Handoff de Accesibilidad: Tu Nueva Tarea

En lugar de entregar solo píxeles, empieza a entregar Intenciones de Accesibilidad. Puedes usar anotaciones en Figma para indicar cuál debe ser el nombre accesible de un icono o qué orden debe seguir el lector de pantalla al navegar por el árbol.

Consejos de Mentor

• Usa el Inspector de Accesibilidad: Abre las DevTools de tu navegador y busca la pestaña de “Accesibilidad”. Podrás ver el árbol real de cualquier web y entender por qué algunas fallan.
• Regla de Oro: Si parece un botón, debe ser un botón. No intentes reinventar roles estándar si no es estrictamente necesario.
• Escucha tu diseño: Usa un lector de pantalla real (como VoiceOver en Mac o TalkBack en Android) sobre un prototipo web. La experiencia te abrirá los ojos sobre la importancia del Árbol de Accesibilidad.

Recursos y Herramientas

• W3C: Introduction to the Accessibility Tree
• MDN Web Docs: Understanding the Accessibility Tree
• Deque University: Accessibility Fundamentals
• Artículos: A Designer’s Guide to the Accessibility Tree

aria-vs-semantica gestion-de-foco pruebas-lectores-pantalla redlining-especificaciones