Los agentes de IA no leen su sitio web como usted. No ven su diseño, su imagen destacada ni el color de su marca. Prefieren leer el árbol de accesibilidad: un modelo estructural simplificado de la página, el mismo que ha impulsado a los lectores de pantalla durante dos décadas.
Hoy, eso importa más porque la audiencia que lee de esa manera ahora es mayoritaria.
Durante la semana del 30 de mayo al 5 de junio de 2026, Cloudflare Radar midió el 57,2% de las solicitudes HTTP a contenido HTML, las solicitudes que representan el tráfico de la página web, como bots automatizados, frente al 42,8% humano. El director ejecutivo de Cloudflare, Matthew Prince, que compartió los datos el 3 de junio, había pronosticado ese cruce para 2027. Se equivocó porque llegó más de un año antes.
Parte de ese tráfico automatizado son spams que probablemente quieras eliminar. Una proporción grande y creciente son los agentes de IA que leen páginas para personas reales. Y según los datos de accesibilidad publicados este año, la estructura de la que dependen esos agentes de IA está empeorando, por primera vez en seis años.
El árbol de accesibilidad es un modelo estructural que el navegador construye a partir de su DOM
El árbol de accesibilidad es una versión semántica de su página que el navegador calcula desde el DOM para que el software no visual pueda entenderla. El proceso es corto: de HTML a DOM y al árbol de accesibilidad para los consumidores (tecnología de asistencia y ahora agentes de IA).
WAI-ARIA 1.2 del W3C lo define como un “árbol de objetos accesibles que representa la estructura de la interfaz de usuario”, donde cada nodo “representa un elemento en la interfaz de usuario expuesto a través de la API de accesibilidad”. El navegador lo construye a partir del DOM (el mapeo se especifica en Core-AAM 1.2) y lo expone a través de la API de accesibilidad del sistema operativo, que, según el W3C, “puede ser utilizado por cualquier tecnología de asistencia, como lectores de pantalla”. MDN explica el proceso de esta manera: los navegadores “crean un árbol de accesibilidad basado en el árbol DOM”.
El árbol de accesibilidad descarta la mayor parte del DOM. Una página con varios miles de nodos colapsa en un conjunto interactivo y significativo: encabezados, enlaces, botones, campos de formulario, puntos de referencia, imágenes con sus alternativas de texto. Para el software que funciona dentro de una ventana de contexto limitada, es esa reducción la que hace que el árbol sea utilizable.
Cada nodo del árbol de accesibilidad tiene cuatro propiedades:
| Propiedad | lo que captura | Ejemplo |
|---|---|---|
| Role | Que tipo de elemento es | Botón, región de navegación, elemento de lista |
| Nombre | Como se refiere | Un enlace que dice “Leer más” se denomina “Leer más”. Un botón de solo icono sin etiqueta no tiene ningún nombre accesible. |
| Estado | Su condición actual | Marcado, ampliado, deshabilitado, seleccionado |
| Descripción | Cualquier contexto adicional más allá del nombre. | Una explicación más larga, como información sobre herramientas, que un lector de pantalla puede leer en voz alta. |
El árbol también registra lo que se puede hacer con un nodo: se puede seguir un enlace, se puede escribir una entrada de texto. Esa es exactamente la información que necesita un agente para actuar.
Los agentes de IA leen el árbol de accesibilidad porque cuesta menos y engaña menos que los píxeles
Un agente que maneja un navegador puede entender una página de tres maneras: leer el HTML sin formato, mirar una captura de pantalla con un modelo de visión o leer el árbol de accesibilidad. Existe una división real en la forma en que lo hacen los agentes de hoy.
- Confiando puramente en el árbol de accesibilidad. Playwright MCP de Microsoft, una herramienta ampliamente utilizada para permitir que un modelo opere un navegador, “utiliza el árbol de accesibilidad de Playwright, no entradas basadas en píxeles”, sin “necesidad de modelos de visión, opera únicamente con datos estructurados”. La descripción de su herramienta le dice al modelo que una instantánea de accesibilidad “es mejor que una captura de pantalla”.
- La visión es lo primero. El agente que utiliza computadora de OpenAI, el modelo detrás de Operador, funciona principalmente a partir de capturas de pantalla. No es leer su árbol de accesibilidad para decidir en qué hacer clic.
- Híbrido. Un tercer enfoque combina ambos: el árbol de accesibilidad estructurado para la mayor parte de la página, más la visión de las partes que el árbol no puede capturar, como aplicaciones renderizadas en lienzo y diseños visuales densos.
Dos fuerzas empujan a los agentes hacia el árbol de accesibilidad:
- Costo. Una captura de pantalla gasta una gran cantidad de tokens codificando una imagen que luego el modelo tiene que interpretar. El árbol de accesibilidad es texto compacto.
- Fiabilidad. Un modelo de visión tiene que adivinar qué píxeles forman un control en el que se puede hacer clic. El árbol lo dice claramente, con una función y un nombre para cada uno.
La señal más clara de hacia dónde va esto es la propia orientación de los proveedores. Las preguntas frecuentes de editores y desarrolladores de OpenAI dicen que ChatGPT Atlas “utiliza etiquetas ARIA, las mismas etiquetas y roles que admiten lectores de pantalla, para interpretar la estructura de la página y los elementos interactivos”, y advierte que hacer que un sitio web sea más accesible ayuda al agente a comprenderlo.
OpenAI es la empresa detrás de Computer-Using Agent, la que funciona analizando capturas de pantalla. Todavía recomiendan hacer que los sitios web sean más accesibles. Para la máquina, la accesibilidad y la legibilidad son el mismo problema. El desglose completo agente por agente se encuentra en un artículo complementario sobre cómo los agentes de IA ven su sitio web.
Una copia de Markdown no es una página lista para agentes
Una versión rebajada limpia de una página es una buena forma de proporcionarle a un agente su contenido, y proveedores como Cloudflare ahora generan una en el borde. Para leer, extraer y citar, Markdown está bien y, a menudo, es mejor que HTML sin formato.
Pero una copia rebajada sólo contiene las palabras. No puede decirle a un agente que un control es un botón, si ese botón está deshabilitado o entregarle algo para hacer clic. Permite que un agente lea la página, no la opere.
También es una copia separada de la página, y una copia separada puede decirle a un agente una cosa mientras que la página renderizada muestra a los humanos otra cosa. Uno mantenido a mano también se aleja del margen real con el tiempo. El árbol de accesibilidad no tiene ningún problema. El navegador lo construye a partir de la misma página que muestra a las personas, por lo que no hay nada adicional que mantener ni nada que encubrir, y contiene los roles, estados y referencias de elementos que un agente necesita para actuar. Por eso, para un agente que tiene que hacer algo, uno de los dos es casi inútil y el otro es el objetivo.
Puedes ver tu propio árbol de accesibilidad en aproximadamente 2 minutos
Todos los navegadores principales le muestran el árbol exacto que lee un agente.
En Chrome, según la documentación oficial de accesibilidad de DevTools:
- Abra DevTools, seleccione un elemento en el panel Elementos y abra el Accesibilidad para ver la función, el nombre y el estado calculados de ese elemento.
- Para ver la página completa como lo hace el árbol, active la opción “Mostrar árbol de accesibilidad” alternar, que “reemplaza el árbol DOM en el panel Elementos con un árbol de accesibilidad de página completa”.
Para lo mismo en el código, las instantáneas ARIA de Playwright producen “una representación YAML del árbol de accesibilidad de una página”, capturando roles, nombres accesibles, estados y anidamiento. Al ejecutar una instantánea de ARIA en su propia URL, se devuelve casi exactamente el texto estructurado que recibe un agente como Playwright MCP.
A continuación se muestra una prueba sencilla que puede ejecutar: para cada acción importante en la página, ¿muestra el árbol un nodo con la función correcta y un nombre claro? Un botón de “comprar” que aparece en el árbol como un elemento genérico sin nombre accesible es un botón que los agentes de sus clientes pueden ver pero no pueden usar con confianza.
Ejecute esto en algunas de sus propias páginas y los espacios en blanco aparecerán rápidamente.
Los datos de 2026 dicen que la Web se está volviendo más difícil, no más fácil, de leer para las máquinas
El árbol de accesibilidad es tan bueno como el marcado a partir del cual está construido. En 2026, ese margen empeoró. La accesibilidad web retrocedió por primera vez en seis años, al mismo tiempo que los agentes se convirtieron en la mayor parte del tráfico HTML.
WebAIM Million, el análisis automatizado anual del millón de páginas de inicio principales, informó en su edición de febrero de 2026:
- 95,9% de las páginas de inicio tenían fallas WCAG detectables, en comparación con el 94,8% del año anterior, lo que WebAIM describe como “revertir una tendencia de pequeñas mejoras en cada uno de los 6 años anteriores”.
- 56.1 errores detectados por página de inicio, un 10,1% aumento respecto a los 51 encontrados en 2025.
- 1.437 elementos por página de inicio, lo que WebAIM señala como “un aumento del 22,5% en sólo un año”.
Un aumento del 22,5 % en la complejidad de las páginas en un solo año no es normal. Más elementos significan más lugares para que la estructura se rompa, y el informe muestra exactamente dónde se rompe.
Las fallas más comunes son las que borran el árbol de accesibilidad
Las fallas de accesibilidad que WebAIM encuentra con mayor frecuencia son exactamente los defectos que quitan significado al árbol que lee un agente.
| Falla | Páginas de inicio afectadas | Qué le hace al agente |
|---|---|---|
| Texto de bajo contraste | 83,9% | Una falla visual para usuarios con baja visión y agentes basados en la visión. |
| Falta texto alternativo | 53,1% | La imagen no aporta nada a la comprensión del agente. |
| Faltan etiquetas de formulario | 51% | Una entrada que el agente no puede asignar a un propósito, por lo que no puede cumplirlo. |
| Enlaces vacíos | 46,3% | Un nodo con un rol pero sin nombre: una puerta sin signo |
| Botones vacíos | 30,6% | Un control que el agente ve pero no puede identificar. |
| Idioma del documento que falta | 13,5% | Se aplicó el modelo de lenguaje incorrecto a la página. |
Casi la mitad del millón de páginas de inicio principales tienen enlaces vacíos. Casi un tercio tiene botones vacíos. Para la clase visitante que ahora supera en número a los humanos, esos son callejones sin salida. Para citar el informe:
“Abordar sólo estos pocos tipos de problemas mejoraría significativamente la accesibilidad en la web”.
Lo que WebAIM mide cada año para los usuarios de lectores de pantalla es lo mismo que decide si un agente de IA puede leer y actuar en su página. Son públicos diferentes con idéntica estructura rota.
WebAIM vincula la creciente complejidad con los marcos y la “codificación Vibe”
WebAIM atribuye la creciente complejidad a “una mayor dependencia de marcos y bibliotecas de terceros y prácticas de codificación automatizadas o asistidas por IA (“codificación por vibración”)”.
Este es el primer WebAIM Million publicado en la era de generar sitios web de producción impulsando un modelo. Tenemos más código, enviado por más personas, más páginas implementadas más rápido, más complejidad acumulada sobre complejidad, con menos humanos en el bucle preguntando si un elemento necesita existir o si un control expone su nombre y función.
No hay manera de probar una causa única para una reversión de un año en un millón de sitios web, y afirmar una con certeza sería deshonesto. Pero es imposible ignorar el momento, y la contradicción es el punto: los humanos están utilizando la IA para construir una red que la IA por sí sola no puede consumir de manera confiable. DOM inflados, semántica rota, controles sin nombre. Los mismos defectos que perjudican a los humanos y a los lectores de pantalla perjudican a los rastreadores y a los agentes.
Es tentador pensar que no debería preocuparse, porque el próximo modelo será lo suficientemente bueno para solucionar el problema. Esa es una línea de marketing, no una estrategia. Los mismos productos que prometen que el modelo se encargará de cualquier cosa también le dicen, en letra pequeña, que el asistente puede cometer errores.
Mediciones independientes como WebAIM Million se encuentran entre las únicas señales objetivas que tenemos sobre lo que realmente está sucediendo en la web detrás de esa promesa. En este momento, la señal es que la web se está volviendo más difícil de analizar en el momento exacto en que una mayor parte de su tráfico depende de un análisis limpio.
La paradoja de ARIA: agregar atributos lo empeora
Más ARIA se correlaciona con más errores, no menos. WebAIM descubrió que las páginas de inicio con ARIA presente tenían un promedio de 59,1 errores, frente a 42 en las páginas sin él.
ARIA, abreviatura de Aplicaciones de Internet enriquecidas accesibles, es un conjunto de atributos que se agregan a HTML para entregarle al árbol de accesibilidad las funciones, nombres y estados que el marcado nativo no proporciona por sí solo.
La razón es sencilla. Un atributo vacío o incorrecto no deja el árbol de accesibilidad en blanco. Llena el árbol con información confiable, posiblemente incorrecta, lo cual es peor para un agente que una brecha honesta, porque el agente no tiene forma de saber que está siendo engañado.
Aquí es donde los proveedores y el organismo de normalización no están de acuerdo:
- Abierto AI indica a los desarrolladores que agreguen roles, etiquetas y estados de ARIA para que los agentes comprendan una página.
- El W3C La primera regla de ARIA (¡primero!) pone el HTML nativo en primer lugar: “Si puede usar un elemento HTML nativo… con la semántica y el comportamiento que necesita ya integrados, en lugar de reutilizar un elemento y agregar una función, estado o propiedad de ARIA para hacerlo accesible, entonces hágalo”.
- Especialistas en accesibilidad han rechazado directamente el marco del proveedor. El colaborador del W3C, Adrian Roselli, respondiendo a la guía de OpenAI, argumentó que invierte la disciplina, señalando a los equipos hacia atributos complementarios cuando la solución duradera es el marcado nativo correcto.
Los datos de WebAIM están del lado de los especialistas: las páginas que más llegan a ARIA contienen la mayor cantidad de errores. No se arregla el árbol de accesibilidad agregando atributos. Lo arreglas… arreglándolo. Haciendo que el marcado subyacente signifique lo que dice y reservando ARIA para los vacíos genuinos que el HTML nativo no puede expresar.
Haga que el marcado signifique lo que dice
Las soluciones no son glamorosas y se entienden bien, y dan doble resultado: una vez para los humanos que utilizan tecnología de asistencia y otra para los agentes que ahora constituyen la mayor parte de su tráfico.
- Utilice HTML nativo para un comportamiento nativo. A
es un botón en el árbol sin trabajo adicional. Awith a click handler is an unnamed, roleless node an agent cannot trust. The same holds fory.- Nombra cada control. Utilice un verdadero
en cada entrada del formulario. Texto accesible en cada enlace y botón, incluidos los que solo contienen íconos. Los enlaces vacíos y los botones vacíos son los primeros fallos que detecta un agente.- Procesa en servidor el contenido que importa. Es posible que un precio, una especificación o una acción principal que solo aparece después de ejecutar JavaScript del lado del cliente nunca llegue al árbol que lee un agente.
- Utilice ARIA para lagunas genuinas, no como parche. Corrija la semántica primero, los atributos después y solo cuando el HTML nativo no pueda expresar el estado. ¿Recuerdas la primera regla de ARIA?
- Inspeccione el resultado. Ejecute sus páginas clave a través del árbol de accesibilidad de DevTools o una instantánea de Playwright ARIA y confirme que cada acción importante aparezca con una función y un nombre claros.
No es demasiado tarde para empezar y nada de esto requiere un rediseño. La deuda de accesibilidad en la mayoría de los sitios web es real y tiene años de antigüedad, y las cifras de 2026 muestran que está creciendo en lugar de reducirse. Pero las correcciones aún son pequeñas: cambios a nivel de marcado que puedes hacer página por página, no una reconstrucción completa que llevaría meses. Comience con las páginas de mayor tráfico, verifique el árbol de accesibilidad y corrija primero los controles vacíos y las entradas sin etiquetar. Cada una de estas correcciones sirve a un visitante humano y a un visitante de máquina en el mismo cambio.
La accesibilidad solía ser una casilla de verificación de cumplimiento; Lo alcanzado después de que se lanzó el rediseño. Ahora es la interfaz que utilizan la mayoría de sus visitantes para leer su sitio web. Los equipos que construyen su marcado para que signifique lo que dice serán legibles para los agentes que deciden qué recomendar y qué comprar. Los equipos que apuestan a que un modelo futuro solucionará el problema están apostando a la hoja de ruta cuestionable de otra persona. La web nos ha entregado ya un año de datos sobre cómo va esa apuesta.
Al mismo tiempo, el interés por la accesibilidad web está en su punto más alto en cinco años.
Tendencias de Google: interés de búsqueda mundial en “accesibilidad web”, en los últimos cinco años (Imagen del autor, junio de 2026) El interés se mantuvo estable durante años, luego aumentó hasta 2025 y se disparó en 2026. Los factores son mixtos y vale la pena ser honesto: plazos de cumplimiento como la regla web del Título II de la ADA y la Ley Europea de Accesibilidad, una ola creciente de demandas de accesibilidad y una atención más amplia a medida que la IA cambia la forma en que se construye y lee la web. Nadie explica toda la curva, y afirmar que así es sería una conjetura.
Pero la dirección es el punto. La atención está llegando, las soluciones son manejables y la audiencia que depende de ellas es ahora mayoritaria. El momento de arreglar la web es ahora.
Más recursos:
Imagen de portada: Collagery/Shutterstock
- Nombra cada control. Utilice un verdadero
