Como optimizar el arbol de accesibilidad para agentes de AI

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 principal de Google sobre sitios preparados para agentes en web.dev explica que los agentes modernos pueden combinar tres representaciones: capturas de pantalla, HTML crudo o el DOM, y el árbol de accesibilidad. El AX tree aporta información estructurada sobre la interacción; la visión ayuda a interpretar el layout y el contexto visual.

Qué le Dice el Árbol de Accesibilidad a un Agente

El DOM registra elementos, atributos, texto y relaciones. Una captura registra cómo se ve la página renderizada. El AX tree 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 AI en Common Crawl comprueba presencia en un rastreo público. Una auditoría de renderizado JavaScript para asistentes de AI 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 mouse, 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, Landmarks 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.

Workflow 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 landmarks, la jerarquía de headings, las etiquetas de formulario, los enlaces y los botones. Usa Source Order Viewer cuando el orden visual pueda diferir del DOM.

2. Captura un baseline 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 sirvió como inspiración práctica para este modelo de auditoría. Acredito la idea, pero no traslado sus benchmarks ni su conclusión más fuerte sobre rankings. 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 de scoring de Agentic Browsing aportan una capa de regresión para etiquetas, roles, relaciones y contenido excluido del AX tree.

No conviertas 7/9 en una supuesta puntuación de 78. Conserva el reporte original y compara la misma plantilla después de una release. 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 un diff de QA

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 Copy

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 AI.

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 landmarks y jerarquía de headings;
• 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 checkout 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 el schema 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 AI 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 landmarks y jerarquía de headings. Mantén los hallazgos de auditorías experimentales en un backlog vigilado.

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

FAQ

Sobre el Autor

Francisco Leon de Vivero es VP de Growth 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 enterprise. 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