Google publicó 8 reglas para que tu sitio sea apto para agentes — y son las mismas 8 reglas de accesibilidad que llevas posponiendo

El 1 de abril de 2026, Google publicó en web.dev una guía oficial para hacer sitios apto para agentes de Ai. 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.

Si tienes prisa, esto se reduce a tres cambios concretos que puedes hacer esta semana: (1) arreglar el cursor de tus botones, (2) auditar tus 5 páginas críticas y (3) ordenar la semántica de tus formularios. Abajo está el contexto y, al final, el detalle accionable de cada uno.

Cómo "ven" los agentes tu sitio

Antes de las reglas, conviene entender el qué. Un agente de Ai (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 Ai" 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 Ai 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 Ai 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).

Los 3 cambios concretos que puedes hacer esta semana

• 01Cambio 1 — Arregla el cursor (5 minutos). Si usas Tailwind v4, pega el snippet de cursor: pointer en tu globals.css. Recuperas la regla 6 de un golpe en todos los botones del sitio, sin tocar componente por componente.
• 02Cambio 2 — Audita tus 5 páginas críticas (30 minutos). Homepage, formulario de captura, página de producto principal, checkout y login: pásales un Lighthouse en categoría Accessibility más un escaneo con axe DevTools o WAVE (los dos gratis). Anota cada error de "name/role" y cada botón primario con contraste bajo 4.5:1 — la Ai usa ese mismo criterio para decidir si algo "se ve clickeable".
• 03Cambio 3 — Ordena la semántica de tus formularios (1 a 2 horas). Cada <input> con su <label for="...">, cada botón como <button> nativo (no un <div onclick>), y los mensajes de error en texto legible por máquinas, no solo iconos rojos. Con este paso cubres las reglas 1, 4, 7 y 8 a la vez.

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.