El 1 de abril de 2026, Google publicó en web.dev una guía oficial para hacer sitios apto para agentes de iA. Son 8 reglas técnicas, escritas por el equipo de Chrome para developers. La novedad no es que existan — es lo que se ve cuando las miras al lado de la guía WCAG: son exactamente las mismas reglas que llevamos años pidiendo para usuarios con tecnología asistiva.
Para una marca chilena que tiene la accesibilidad en "lista de pendientes" desde hace tres años, la noticia es buena: el ROI dejó de ser solo ético — ahora también es comercial. Una sola auditoría, dos audiencias recuperadas.
Cómo "ven" los agentes tu sitio
Antes de las reglas, conviene entender el qué. Un agente de iA (Chrome auto-browse, Gemini Spark, ChatGPT con navegación) no consume tu sitio como humano. Lo procesa con 3 modalidades:
- 01Capturas de pantalla — modelos de visión analizan la página renderizada, identifican elementos por color, tamaño y proximidad. Caro en tokens, se usa como respaldo.
- 02HTML / DOM — análisis de la jerarquía estructural, atributos, anidación. Un botón "Comprar" dentro de un contenedor de producto es legible como "acción de compra del producto".
- 03Árbol de accesibilidad — la API nativa del navegador que destila roles, nombres y estados. Es el "resumen semántico" que ignora el ruido visual. Es lo que mejor entiende un agente.
La regla implícita: si tu sitio depende solo de capturas de pantalla para ser entendido (porque tu DOM es un mar de divs sin semántica), eres caro de procesar — y los agentes te abandonan.
Las 8 reglas oficiales de Google
Estas son las 8 reglas que Google publicó. Al lado de cada una marco la pauta WCAG que es exactamente la misma idea, escrita para otra audiencia:
- 011. Refleja cada acción en la interfaz. Cuando el usuario (o el agente) hace click en "Agregar al carro", tiene que pasar algo visible. Acciones silenciosas son invisibles para agentes. (WCAG 4.1.3, mensajes de estado)
- 022. Mantén el layout estable. Elementos interactivos en posiciones consistentes entre páginas. Saltos visuales rompen el análisis. (WCAG 3.2, predecible)
- 033. Sin elementos fantasma ni superposiciones transparentes. Cualquier elemento que cubra un componente interactivo lo descarta del análisis visual, aunque sea transparente. (WCAG 2.4.7, foco visible)
- 044. Usa HTML semántico. <button>, <a>, <nav>, <main>. Nada de divs estilizados para botones. (WCAG 4.1.2, nombre, rol, valor)
- 055. Si no puedes usar HTML semántico, usa role y tabindex como fallback. <div role="button" tabindex="0"> es legible. <div onclick="..."> sin más es invisible para agentes y para lectores de pantalla.
- 066. cursor: pointer en CSS para elementos interactivos. "Una señal fuerte de accionabilidad", según Google literalmente. (WCAG 1.3.3, características sensoriales)
- 077. Asocia <label> a <input> con el atributo for. Mapea el texto visible al campo subyacente. Sin esto, ni el agente ni el lector de pantalla saben qué campo es cuál. (WCAG 1.3.1, info y relaciones)
- 088. Elementos interactivos > 8 píxeles cuadrados. Los modelos de visión filtran lo más chico. (WCAG 2.5.5, tamaño del objetivo)
El bug de Tailwind v4 que rompe la regla 6 (y muchas pymes chilenas lo tienen)
Tailwind CSS v4 cambió el estilo nativo de los botones de cursor: pointer a cursor: default. Si tu sitio usa Tailwind v4 (mucha pyme chilena modernizó a v4 en 2025), todos tus <button> nativos rompen la regla 6 de Google sin que lo sepas. El fix son tres líneas en tu CSS global:
@layer base {
button:not(:disabled),
[role="button"]:not(:disabled) {
cursor: pointer;
}
}Cinco minutos de trabajo. Vuelves a cumplir la regla 6 — y, de paso, WCAG 1.3.3.
La oportunidad: una inversión, dos audiencias
La mayoría de los equipos de producto chilenos tratan accesibilidad y "preparación para iA" como dos workstreams distintos. Distintos planes, distintos presupuestos, distintos plazos. Es desperdicio.
Las 8 reglas de Google son la misma auditoría que pasa una persona con lector de pantalla. La empresa que se toma WCAG en serio ya tiene 80% del trabajo hecho para Chrome auto-browse, Gemini Spark y los agentes que vienen. La empresa que lo posterga paga dos veces: en clientes con discapacidad que no pueden completar la compra, y en agentes de iA que mandan al cliente a la competencia.
"Todo lo que sugerimos para que un sitio esté listo para agentes, también lo hace mejor para humanos."
Dato curioso: las búsquedas de "web accessibility" en Google Trends se mantuvieron planas entre 2021 y 2024, y se cuadruplicaron en 2025-2026 — cuando la cobertura de agentes de iA empezó a alinearse con accesibilidad. La presión de proveedores movió la aguja más que la regulación de la European Accessibility Act (vigente desde junio 2025).
Lo accionable esta semana
- 01Identifica tus 5 páginas con más tráfico (homepage, formularios de captura, página de producto principal, checkout, login).
- 02Pásales un Lighthouse en categoría Accessibility y un escaneo con axe DevTools o WAVE. Cada uno es gratis y se corre en 30 segundos.
- 03Si usas Tailwind v4, aplica el fix del cursor en tu globals.css. Se hace una vez y queda.
- 04Audita los formularios: ¿cada <input> tiene su <label for="...">? ¿Los mensajes de error son legibles por máquinas, no solo iconos rojos?
- 05Revisa el contraste de los botones primarios. WCAG AA pide 4.5:1 para texto normal. La iA usa el mismo criterio para detectar si un botón "se ve clickeable".
En una semana de trabajo de un developer, puedes resolver las 8 reglas para tus páginas críticas. Cuando llegue Chrome auto-browse (fines de junio en Android), tu sitio va a estar listo. Y de paso, vas a estar más cerca de cumplir la Ley 20.422 chilena de inclusión.
Referencias