Cómo optimizar el árbol de accesibilidad para agentes de IA

Una página puede parecer perfectamente usable y describir sus controles muy mal.

Un rectángulo azul parece un botón. Un chevron parece abrir una pregunta frecuente. Un texto junto a un campo parece identificarlo. Esas pistas visuales ayudan a una persona, pero el navegador no puede convertir cada decisión de diseño en significado programático.

El árbol de accesibilidad es donde el navegador expone ese significado. Un botón real puede aparecer con el rol button y un nombre útil. Un control desplegable puede indicar si está expandido. Un campo puede exponer la etiqueta que le corresponde.

Esto importa primero para las personas que usan tecnología de asistencia. También importa para los agentes de navegador. La guía de Google sobre sitios preparados para agentes en web.dev, revisada para esta edición el 8 de agosto de 2026, explica que los agentes pueden combinar tres representaciones: capturas de pantalla, HTML o DOM y árbol de accesibilidad. El árbol AX aporta información estructurada sobre la interacción. La visión ayuda a interpretar la disposición y el contexto visual.

Qué le dice el árbol de accesibilidad a un agente

El DOM registra elementos, atributos, texto y relaciones. Una captura muestra cómo se ve la página renderizada. El árbol AX es un resumen semántico calculado por el navegador.

Un agente capaz puede identificar un botón en el AX tree, revisar en el DOM su relación con una tarjeta de producto y usar una captura para confirmar que un banner de cookies no lo cubre. Ese modelo multimodal obliga a comprobar la coherencia entre estructura, interfaz visible y comportamiento real.

También separa esta auditoría de otras cercanas. Una auditoría de visibilidad de IA en Common Crawl comprueba presencia en un rastreo público. Una auditoría de renderizado JavaScript para asistentes de IA compara lo que existe antes y después de renderizar. La auditoría AX comprueba si el navegador expone estructura y estados accionables. Aprobar una no demuestra las otras.

Usa HTML semántico antes de añadir ARIA

La primera reparación suele ser HTML normal. Un elemento genérico disfrazado de control obliga a cada consumidor a adivinar su propósito y obliga al equipo de desarrollo a reconstruir comportamiento que el navegador ya ofrece.

<!-- Mal: parece clicable, pero no tiene semántica de control -->
<div class="cta" onclick="startCheckout()">Comprar ahora</div>

<!-- Usa un botón para una acción dentro de la interfaz -->
<button type="button" class="cta" onclick="startCheckout()">
  Comprar ahora
</button>

<!-- Usa un enlace para navegar -->
<a class="cta" href="/checkout/">Ir al checkout</a>

Un botón ejecuta una acción en la interfaz actual. Un enlace navega a una URL. No sustituyas ninguno por <span onclick>, ni uses <a href="#"> cuando no hay navegación. Un control personalizado con role="button" también necesita foco, soporte para Enter y Espacio, y un indicador visible de foco. El <button> nativo ya incluye el contrato básico.

Los formularios requieren la misma disciplina. Usa <form>, conecta <label for> con el ID del campo y prefiere <select> nativo cuando su comportamiento encaje con el producto. Un placeholder no sustituye una etiqueta persistente.

<form action="/search/" method="get">
  <label for="site-search">Buscar en el sitio</label>
  <input id="site-search" name="q" type="search">

  <label for="topic">Tema</label>
  <select id="topic" name="topic">
    <option value="technical-seo">SEO técnico</option>
  </select>

  <button type="submit">Buscar</button>
</form>

La referencia de semántica de MDN resume bien el principio: elige el elemento que comunica el significado y deja la presentación en manos de CSS. ARIA sigue siendo útil para nombres, estados y relaciones que la semántica nativa no expresa por completo. No implementa el comportamiento.

Prueba los estados dinámicos de JavaScript antes y después

Los acordeones de FAQ, pestañas, filtros, diálogos y formularios con varios pasos no se pueden validar solo en el estado inicial. Guarda una captura del árbol, opera el componente y guarda otra.

Este es un acordeón compacto basado en el patrón de acordeón de W3C:

<h3>
  <button
    type="button"
    id="shipping-trigger"
    aria-expanded="false"
    aria-controls="shipping-panel">
    Detalles de envío
  </button>
</h3>

<div id="shipping-panel"
     role="region"
     aria-labelledby="shipping-trigger"
     hidden>
  <p>Los pedidos salen en un máximo de dos días laborables.</p>
</div>

<script>
  const trigger = document.querySelector('#shipping-trigger');
  const panel = document.querySelector('#shipping-panel');

  trigger.addEventListener('click', () => {
    const isOpen = trigger.getAttribute('aria-expanded') === 'true';
    trigger.setAttribute('aria-expanded', String(!isOpen));
    panel.hidden = isOpen;
  });
</script>

La prueba no consiste en confirmar que los atributos existen. La interfaz tiene que contar una sola historia:

• El control tiene semántica nativa de botón y un nombre útil.
• aria-controls apunta al ID real del panel.
• aria-expanded cambia de false a true.
• La visibilidad real del panel cambia junto con ese estado.
• La activación funciona con ratón, Enter y Espacio.

Eso no significa que todo el contenido colapsado sea invisible para todos los agentes. El contenido puede permanecer en el DOM, quedar fuera del estado AX actual, insertarse después de una petición o aparecer tras una interacción. Hay que probar la implementación concreta.

Para datos de producto, requisitos, condiciones de precio y la respuesta central de un artículo, no dejaría el descubrimiento en manos de una interacción opcional. Renderiza la información esencial y reserva los desplegables para ampliar detalles. Es una recomendación para controlar el riesgo, no una prohibición universal del contenido oculto.

Valida jerarquía, regiones y enlaces falsos

Una página hecha de contenedores anónimos ofrece menos estructura al navegador. Empieza por un solo <main> principal, grupos importantes dentro de <nav>, un <article> coherente cuando corresponda, un H1 descriptivo y una anidación lógica H2/H3.

<nav aria-label="Principal">
  <a href="/es/services/">Servicios</a>
  <a href="/es/insights/">Insights</a>
</nav>

<main>
  <article>
    <h1>Auditoría del árbol de accesibilidad</h1>
    <section aria-labelledby="audit-process">
      <h2 id="audit-process">Proceso de auditoría</h2>
      <h3>Revisar controles interactivos</h3>
    </section>
  </article>
</main>

Da nombres distintos a landmarks de navegación repetidos, por ejemplo "Principal" y "Pie de página". Comprueba el orden de origen cuando CSS Grid o Flexbox cambian el orden visual. Localiza enlaces falsos implementados mediante manejadores JavaScript y confirma que cada acción de navegación auditada tenga un href rastreable.

Estas reparaciones no convierten un contenido débil en ganador. Eliminan contradicciones estructurales que pueden bloquear a usuarios de teclado y agentes orientados a tareas.

Proceso práctico para auditar el árbol de accesibilidad

1. Revisa Chrome DevTools

Abre DevTools, entra en Elements, selecciona un control y abre el panel Accessibility. Registra rol calculado, nombre accesible, estado, relaciones ARIA, si el nodo está ignorado y el nodo DOM correspondiente. La referencia oficial de accesibilidad de Chrome DevTools documenta el proceso.

Activa Show accessibility tree para sustituir la vista DOM por el árbol AX de toda la página. Revisa el orden de las regiones, la jerarquía de encabezados, las etiquetas de formulario, los enlaces y los botones. Usa Source Order Viewer cuando el orden visual pueda diferir del DOM.

2. Captura una referencia con AXray

AXray ofrece una segunda vista de extracción con un resultado filtrado y otro más completo. También permite comparar JavaScript activado y desactivado. No envíes URLs privadas, autenticadas o sensibles a un extractor de terceros.

El artículo de John McAlpin sobre el árbol de accesibilidad fue el punto de partida práctico para este modelo de auditoría. Reconozco esa aportación, pero no traslado sus cifras de referencia ni su conclusión más fuerte sobre posicionamiento. Las fuentes oficiales no sostienen esa conclusión.

3. Guarda capturas de cada interacción

Captura el estado inicial y cada estado crítico después de interactuar. En un acordeón, la evidencia antes/después debe mostrar un nombre estable, el cambio de estado expandido, una relación válida y un panel que aparece cuando corresponde. Para un diálogo o un paso de formulario, añade foco y secuencia de teclado.

4. Ejecuta Lighthouse Agentic Browsing como prueba experimental

Las pruebas de Chrome sobre accesibilidad para agentes y la documentación del sistema de puntuación de Agentic Browsing aportan una capa de regresión para etiquetas, roles, relaciones y contenido excluido del árbol AX.

No conviertas 7/9 en una supuesta puntuación de 78. Conserva el informe original y compara la misma plantilla después de una publicación. Aplico la misma separación en mi artículo sobre llms.txt y Lighthouse Agentic Browsing: una prueba para agentes de navegador puede ser útil sin convertirse en requisito de Google Search.

5. Termina con una comparación de control de calidad

Compara las capturas originales con las corregidas. Vincula cada reparación con una condición de aceptación: el control tiene el rol esperado, su nombre es distinto, su estado se actualiza, funciona con teclado y la tarea real se completa. Aprobar solo el árbol no basta.

Compara plantillas competidoras, no su texto

El análisis de competencia puede descubrir diferencias de implementación, pero no puede aislar por qué una página posiciona o consigue una cita de IA.

Compara entre tres y cinco páginas que respondan a la misma intención y tarea. Una ficha de producto se compara con otras fichas de producto, no con la homepage del competidor. Controla tipo de plantilla, intención, estado de sesión, ubicación y ancho de pantalla. Después registra:

• orden de las regiones y jerarquía de encabezados;
• enlaces reales frente a navegación JavaScript;
• roles y nombres accesibles de los controles;
• etiquetas de formulario y estados seleccionados;
• comportamiento del contenido oculto antes y después de interactuar;
• diferencias con JavaScript activado y desactivado;
• pasos necesarios para completar la misma tarea.

Clasifica cada resultado. "Nuestro acceso al proceso de compra es un elemento genérico sin nombre" es un defecto verificado. "Tres competidores usan botones nativos para las variantes" es una observación. "Los controles nativos pueden reducir fallos de interacción" es una hipótesis.

No copies la estructura de un competidor solo porque posiciona. El contenido, los enlaces, la autoridad, la demanda de marca, los datos de producto y muchas otras variables siguen sin estar controladas. Las citas y las posiciones muestran correlación, no causalidad.

La diferencia pesa especialmente en ecommerce. Los feeds y los datos estructurados pueden describir una oferta, pero los agentes de navegador necesitan controles fiables para pasar del descubrimiento a la acción. Mi análisis sobre agentes de IA de Google y ecommerce cubre esa capa de ejecución.

La Auditoría AX de 30 Minutos

Prioriza primero las acciones bloqueadas: botones falsos, enlaces falsos, campos sin nombre, controles de consentimiento inoperables y foco roto. Corrige después los estados contradictorios. Luego repara las regiones y la jerarquía de encabezados. Mantén los hallazgos de auditorías experimentales en una lista de seguimiento.

Este enfoque basado en evidencia también encaja en un proceso repetible de auditoría SEO técnica: recoger la prueba renderizada, clasificar el defecto y entregar una condición de aceptación comprobable.

Preguntas frecuentes

Sobre el Autor

Francisco Leon de Vivero es vicepresidente de crecimiento en Growing Search y cuenta con más de 15 años de experiencia en SEO para ecommerce, búsqueda internacional, búsqueda para adultos y sitios empresariales. Fue SEO Lead en Shopify durante más de siete años y trabajó más de cuatro años en el SEO de Pornhub.

LinkedIn · YouTube · Contacto