Si crees que los agentes de IA navegan tu web como lo haría un usuario con el ratón, te llevas un susto. No ven tu hero, no aprecian el gradiente del botón ni el microcopy que te costó tres reuniones. Lo que leen, en muchos casos, es el árbol de accesibilidad: la misma estructura semántica que llevan décadas usando los lectores de pantalla. Y en 2026 esa capa ha pasado de ser un tema de cumplimiento a ser, literalmente, la interfaz por la que la mayoría del tráfico HTML entiende tu página.
Te lo cuento porque en hosting y desarrollo web llevamos años vendiendo accesibilidad como obligación legal o como gesto bonito. Ahora hay un argumento de negocio encima de la mesa: si tu markup está roto, no solo pierdes usuarios con discapacidad; pierdes visibilidad ante agentes que resumen, comparan y hasta completan formularios en nombre de otras personas.
Qué es el árbol de accesibilidad (sin tecnicismos innecesarios)
Cuando el navegador renderiza una página, construye a partir del DOM un árbol simplificado con lo que importa para software no visual: encabezados, enlaces, botones, campos de formulario, landmarks e imágenes con su texto alternativo. Cada nodo lleva un rol (qué es), un nombre (cómo se llama), un estado (activo, deshabilitado, expandido…) y, a veces, una descripción extra.
Un botón con icono y sin etiqueta aparece en el árbol como control vacío. Un enlace con solo una flecha SVG y sin texto accesible es una puerta sin cartel. Para un agente que opera con tokens limitados, eso no es un detalle estético: es un callejón sin salida.
En mi experiencia auditando webs de clientes, el 90% de los problemas no están en el diseño sino en capas intermedias: componentes de React mal nombrados, modales que no devuelven el foco, inputs con placeholder en lugar de label. Cosas que en pantalla «se ven bien» pero en el árbol son ruido.
Por qué importa ahora: bots mayoritarios y datos que empeoran
A principios de junio de 2026, Matthew Prince (CEO de Cloudflare) publicó que el tráfico automatizado a contenido HTML superó por primera vez al humano en su red: alrededor del 57% frente al 43%, según datos de Cloudflare Radar. Lo preveía para 2027; llegó más de un año antes, impulsado sobre todo por agentes de IA.
Paralelamente, el informe WebAIM Million de febrero de 2026 trae una noticia incómoda: el 95,9% de las homepages del millón más visitado tienen errores WCAG detectables, subiendo desde el 94,8% del año anterior. Es la primera regresión en seis años. Más elementos por página (un 22,5% de aumento en un solo año), más errores por página (56,1 de media) y los mismos fallos de siempre arriba del ranking: contraste bajo, alt vacíos, formularios sin etiqueta, enlaces y botones sin nombre.
WebAIM apunta a frameworks de terceros y al auge del «vibe coding»: webs generadas o aceleradas con IA sin revisión semántica. No puedes probar causalidad con un solo informe, pero el timing apunta a una paradoja: usamos IA para construir más rápido y acabamos con un web que la propia IA lee peor.
Cómo leen los agentes: árbol, HTML crudo o capturas
No todos los agentes funcionan igual. Herramientas como Playwright MCP trabajan directamente sobre el árbol de accesibilidad, sin modelo de visión. OpenAI combina enfoques: su agente de uso de ordenador mira capturas, pero en su documentación para publishers recomienda mejorar ARIA y accesibilidad para que asistentes como Atlas interpreten mejor la estructura. Híbrido, en la práctica, es lo habitual: texto estructurado donde se puede, visión donde el canvas o el layout lo obligan.
El árbol gana por coste y fiabilidad. Una captura consume muchos tokens y obliga al modelo a adivinar qué pixel es un botón. El árbol te dice «button, name: Comprar, disabled: false». Para una acción concreta — rellenar un formulario, añadir al carrito — no hay comparación.
Ojo con el markdown generado al vuelo (tipo llms.txt o copias en texto plano): sirve para que un agente lea contenido, pero no para operar la interfaz. No sabe si un botón está deshabilitado ni puede hacer clic. El árbol se construye del mismo DOM que ve el usuario; no hay copia paralela que se desincronice.
Qué puedes revisar esta semana en tus proyectos
No hace falta rediseñar nada. Esto es lo que yo revisaría en las páginas con más tráfico o más conversión:
- Abre DevTools → pestaña Accessibility y activa «Show accessibility tree». Recorre cada acción crítica: ¿aparece con rol y nombre claros?
- HTML nativo antes que parches. Un
<button>real ya es un botón en el árbol. Un<div onclick>sin rol es una caja negra. - Etiqueta todo input. Placeholder no sustituye a
label. Es el fallo que más bloquea agentes en formularios de contacto y checkout. - Cuidado con ARIA mal puesto. WebAIM detecta más errores en páginas con ARIA que sin él. Un atributo incorrecto no deja el hueco vacío: miente con confianza.
- Contenido crítico en el servidor. Si el precio o el CTA solo aparecen tras JavaScript, puede que nunca lleguen al árbol que lee el agente en el primer paso.
Además, si trabajas con clientes sujetos a la Ley Europea de Accesibilidad (vigente desde junio de 2025 para muchos servicios digitales), estas mismas correcciones te acercan al cumplimiento real. La norma y los agentes de IA piden lo mismo: markup que signifique lo que dice.
La oportunidad que casi nadie está vendiendo
En agencias y estudios de hosting seguimos hablando de Core Web Vitals, caché y CDN. Todo eso importa. Pero si el 57% de las peticiones HTML las hacen máquinas que dependen del árbol de accesibilidad, optimizar LCP sin tocar semántica es optimizar la fachada y dejar la puerta principal atascada.
Propongo un cambio de discurso con clientes: no «hagamos accesibilidad por ley», sino «hagamos tu web legible para humanos, lectores de pantalla y agentes de IA con el mismo trabajo». Cada enlace con nombre, cada botón etiquetado, cada formulario bien ligado, es una mejora doble. En 2026 eso ya no es futurismo; es mantenimiento básico.
Si mañana un agente de IA tuviera que completar el formulario de contacto de tu web sin ver la pantalla, solo leyendo el árbol de accesibilidad, sabrias decir con certeza que lo conseguiría?