Del síntoma a la causa: inspeccionar el árbol de accesibilidad

Cuando un lector de pantalla anuncia algo extraño, o no anuncia nada, el auditor tiene que responder a una pregunta antes de escribir el hallazgo: ¿el problema está en el código, en el navegador, en el lector o en la configuración de su propio equipo? Y el equipo de desarrollo necesita algo más que «NVDA dice “botón”»: necesita la causa. En la primera lección viste que el lector lee el árbol de accesibilidad, y en el protocolo de pruebas lo usaremos como evidencia; en esta aprenderás a inspeccionarlo para pasar del síntoma a la causa.

Las capas: del código a la voz

Entre el HTML y lo que oye la persona usuaria hay varias capas. El navegador combina DOM, CSS y ARIA para calcular el árbol de accesibilidad (roles, nombres, estados, relaciones). Después lo expone a través de la API de accesibilidad del sistema operativo: UI Automation e IAccessible2 en Windows, la API de accesibilidad de macOS, UIAccessibility en iOS o la de Android. Por último, el lector interpreta esa información y la verbaliza según su configuración. Un fallo puede entrar en cualquiera de las capas:

Herramientas de inspección

Chrome y Edge

En las herramientas para desarrolladores (F12), panel Elementos, la pestaña Accesibilidad muestra para el nodo seleccionado su posición en el árbol de accesibilidad, los atributos ARIA y las propiedades calculadas: rol, nombre y la fuente de la que procede (aria-labelledby, aria-label, contenido, title…), y estados como enfocable o expandido. Las versiones recientes permiten además ver el árbol de accesibilidad completo de la página en lugar del DOM.

Firefox

El Inspector de accesibilidad (pestaña Accesibilidad de las herramientas para desarrolladores) muestra el árbol completo y las propiedades de cada nodo, y añade utilidades muy prácticas para auditar: comprobación de problemas de contraste, teclado y etiquetas de texto, visualización del orden de tabulación sobre la propia página y simulación de deficiencias en la visión del color.

Safari

Con las funciones para desarrolladores activadas en los ajustes avanzados de Safari, el Inspector web muestra en la barra lateral del panel Elementos una sección de accesibilidad con el rol, la etiqueta y los estados que expone WebKit. Es útil porque VoiceOver con Safari se comporta a menudo de forma distinta a Chrome.

Herramientas del sistema y del lector

Accessibility Insights for Windows (Microsoft, gratuita) y el Inspector de accesibilidad de macOS (incluido con Xcode) muestran lo que realmente llega a la API del sistema. En NVDA, NVDA+F1 vuelca en el visor de registro la información de desarrollador del objeto actual: rol, nombre, estados y atributos tal como los recibe el lector.

Cómo se calcula el nombre accesible

Buena parte de los hallazgos de 4.1.2 Nombre, función, valor y de 2.5.3 Etiqueta en el nombre se explican con el algoritmo de cálculo del nombre accesible (Accessible Name and Description Computation 1.2 del W3C). Simplificado, el orden de prioridad es:

1. aria-labelledby: el texto de los elementos referenciados; gana a todo lo demás.
2. aria-label.
3. El mecanismo nativo de HTML: <label> asociado, alt, <caption>, <legend>, el valor de un botón de tipo input.
4. El contenido del elemento, solo en roles que admiten nombre a partir del contenido: botones, enlaces, encabezados, celdas, pestañas, opciones; no campos de texto ni listas.
5. title y, en campos, placeholder, como último recurso (no deben usarse como etiqueta).

El panel de Chrome enumera las fuentes posibles e indica cuál se ha usado y cuáles han quedado descartadas. Con eso puedes explicar, por ejemplo, por qué un botón que muestra «Buscar» se anuncia como «Enviar consulta»: tiene un aria-label que sustituye al contenido visible.

<!-- Nombre vacío: el icono es un fondo CSS y no hay texto -->
<a href="/carrito" class="icono-carrito"></a>

<!-- Nombre correcto: texto accesible y SVG decorativo oculto -->
<a href="/carrito">
  <svg aria-hidden="true" focusable="false">…</svg>
  <span class="sr-only">Carrito</span>
</a>

Aislar el fallo paso a paso

1. Reproduce y anota el síntoma literal. Copia la salida del visor de voz y apunta la combinación exacta y sus versiones.
2. Inspecciona el nodo. ¿Rol, nombre, estado y relaciones son los que exige el patrón? Si el árbol ya está mal, la causa está en el código o en cómo lo interpreta el navegador: revisa el HTML, el CSS y el script que modifica el componente.
3. Cambia una sola variable cada vez. Mismo lector con otro navegador; mismo navegador con otro lector. Si falla en todas, casi con seguridad es el código. Si falla en una sola, sospecha de un problema de soporte o de un defecto del navegador o del lector.
4. Reduce a un caso mínimo. Copia el componente a un fichero HTML local con lo imprescindible. Si el caso mínimo funciona, la causa está en algo que has quitado: una hoja de estilos, un script, el framework.
5. Atribuye y documenta. Hallazgo del sitio con su causa técnica y su recomendación, o bien observación de soporte, con la combinación afectada. La lección siguiente explica cómo tomar esa decisión.

Causas que solo el árbol revela

• aria-hidden="true" heredado. Al abrir un modal, un script oculta el contenido principal con aria-hidden y olvida quitarlo al cerrar. La página se ve perfectamente, pero para el lector está vacía. En el inspector, todos los nodos aparecen ignorados.
• Estados congelados. El panel se abre visualmente, pero aria-expanded sigue en false porque el script cambia una clase CSS y no el atributo.
• CSS que altera la semántica. display: contents ha eliminado en distintos navegadores el rol de botones o tablas, y WebKit deja de exponer como lista algunas listas a las que se quitan las viñetas con list-style: none. El HTML es correcto, pero el árbol no.
• Referencias rotas. aria-labelledby o aria-describedby que apuntan a un id inexistente o duplicado: el nombre o la descripción quedan vacíos o equivocados.

Resumen

• Un fallo puede nacer en el código, en el navegador, en el lector o en la configuración del auditor; el árbol de accesibilidad permite saber en qué capa está.
• Chrome y Edge (pestaña Accesibilidad), Firefox (Inspector de accesibilidad), Safari (Inspector web), Accessibility Insights, el Inspector de macOS y NVDA+F1 son las herramientas de inspección.
• El nombre accesible sigue un orden: aria-labelledby, aria-label, mecanismo nativo, contenido y, por último, title o placeholder.
• Para aislar: reproducir, inspeccionar, cambiar una variable cada vez, reducir a caso mínimo, atribuir y documentar.
• El inspector no sustituye a la prueba con lector: la complementa y aporta la causa técnica al informe.