El marcado ARIA que implementas para superar una auditoría de accesibilidad también proporciona a los motores de IA un código fuente especialmente claro. Los lectores de pantalla y los agentes de IA interpretan las páginas web de forma muy similar: no se fijan en el cuidado diseño visual, sino que descomponen el HTML en un árbol de etiquetas, jerarquías y nombres. Una misma configuración puede facilitar el acceso a las personas con discapacidad visual y, al mismo tiempo, permitir que motores como ChatGPT, Perplexity y Claude extraigan y citen correctamente el contenido. Aunque este aspecto se señala con frecuencia, sigue siendo uno de los más desatendidos en GEO.
Los lectores de pantalla y los agentes de IA interpretan el mismo árbol
Un navegador visual combina CSS, imágenes y animaciones para componer la página que ve una persona. Un lector de pantalla funciona de otra manera: recorre el árbol de accesibilidad generado por el navegador y explica cada capa al usuario: esta es la zona de navegación, este es el contenido principal y este es un botón llamado «Añadir al carrito». Los rastreadores de los motores de IA suelen seguir un proceso más directo. Muchos no ejecutan JavaScript: obtienen el HTML original, convierten las etiquetas, la jerarquía de títulos, los textos de los enlaces y los atributos aria en texto plano y después lo envían al modelo. La coincidencia es clara: ninguno puede interpretar por sí solo las pistas puramente visuales; necesitan estructura y texto.
Por eso, un falso botón creado con un <div> y un evento de clic, una imagen de producto sin alt o un texto en negrita que simula un título mediante el tamaño de fuente pueden parecer correctos a simple vista, pero resultar invisibles para ambos tipos de lectores. Por muy bueno que sea el contenido, si la capa extraída pierde su estructura, la IA solo puede hacer conjeturas o, sencillamente, omitir la página.
Primero, construye una base sólida con HTML semántico nativo
Cuando se habla de ARIA, muchos equipos piensan primero en añadir numerosos atributos role y aria-, pero el orden correcto es el contrario. La primera regla de las directrices de accesibilidad del W3C es clara: si la semántica puede expresarse con elementos HTML nativos, no debe sustituirse por ARIA. <button> ya es un botón, <nav> ya define una zona de navegación y <h2> ya identifica un subtítulo. Estas etiquetas incorporan tanto la semántica como el comportamiento predeterminado del teclado, y pueden reconocerlas los rastreadores y los lectores de pantalla sin mantener una correspondencia adicional. ARIA sirve para cubrir carencias, no para construir los cimientos.
Cuatro ajustes que benefician a ambos desde una sola implementación
Concentra los recursos de ingeniería en los cuatro ámbitos siguientes para obtener el mayor retorno. Son aspectos que las auditorías de accesibilidad detectan sistemáticamente y, a la vez, las señales de las que más depende la IA para extraer contenido.
- Regiones estructurales: utiliza <header>, <nav>, <main>, <aside> y <footer> para definir el esqueleto de la página. Los rastreadores de IA se apoyan en estas regiones para separar el contenido principal de la navegación y las plantillas del pie de página. Así pueden citar el contenido relevante sin mezclarlo con el texto de los menús.
- Jerarquía de títulos: utiliza un solo <h1> por página y no saltes niveles entre <h2> y <h3>. Este árbol funciona como un índice que ayuda a la IA a entender la estructura del artículo y permite a quienes usan lectores de pantalla desplazarse rápidamente entre secciones.
- Texto alternativo de las imágenes: describe mediante alt el contenido de las imágenes que aportan información. En las imágenes puramente decorativas, deja vacío el valor de alt para que puedan ignorarse. Los puntos clave de una infografía deben figurar en alt o en un texto adyacente; de lo contrario, para la máquina los números del gráfico no existen.
- Nombres de los elementos interactivos: cada botón y enlace debe tener un nombre comprensible. Añade texto mediante aria-label a los botones compuestos únicamente por un icono para que el agente de IA sepa qué acción realizan.
Botones con iconos y enlaces: el vacío más habitual
En las auditorías técnicas que realizamos para nuestros clientes, uno de los problemas más frecuentes son los componentes exclusivamente gráficos. El menú hamburguesa, el carrito, la lupa de búsqueda o los controles para compartir en redes sociales suelen ser un <div> que envuelve un SVG, sin ningún texto. En ese caso, el lector de pantalla solo anuncia «botón», si es que anuncia algo, mientras que el agente de IA detecta un objeto sin nombre en el que se puede hacer clic. Un cliente de comercio electrónico tenía este problema en su botón de pago: la herramienta de prueba para agentes ni siquiera encontraba el acceso. Tras añadir un aria-label con el nombre «Finalizar compra», el mismo botón pasó a ser identificable tanto para las personas con discapacidad visual como para los agentes automatizados. Con los enlaces ocurre lo mismo. Si toda una fila dice «Más información» o «Haz clic aquí», al separarla del contexto visual nadie sabe a dónde conduce cada enlace. Un texto específico y autónomo para cada uno resuelve el problema para ambos lectores con un solo ajuste.
Elementos dinámicos: indica al agente de IA qué puede hacer en cada momento
Además de interpretar contenido estático, cada vez se espera más que los agentes de IA realicen acciones dentro de una página: desplegar menús, cambiar de página o enviar formularios. En estos casos, el nombre no basta; también necesitan conocer el estado del componente. Los atributos de estado de ARIA expresan de forma legible por máquina si un elemento está abierto o cerrado y qué opción se encuentra seleccionada. Así, el agente sabe cuál debe ser su siguiente paso y puede confirmar si la acción anterior tuvo efecto.
- aria-expanded: indica si un menú plegable, un acordeón o una lista desplegable están abiertos o cerrados. Los agentes utilizan este estado para decidir si primero deben hacer clic en el elemento.
- aria-current: identifica la ubicación actual en una paginación o una ruta de navegación y evita que el agente repita acciones dentro del mismo nivel.
- aria-selected y aria-checked: reflejan el estado seleccionado de pestañas, opciones y casillas de verificación, de modo que el agente pueda confirmar si la acción se ha realizado correctamente.
- aria-live: marca como regiones activas las zonas que se actualizan en tiempo real, como los errores de un formulario o los resultados de una carga, para que los agentes y los lectores de pantalla detecten el cambio.
Verificación: no te conformes con que «se vea bien»
- Utiliza curl o la función «Ver código fuente» del navegador para comprobar el HTML que realmente entrega el servidor. Si el contenido solo aparece después de ejecutar JavaScript, la mayoría de los rastreadores de IA no podrá leerlo.
- Ejecuta la auditoría de accesibilidad de ax DevTools o Lighthouse para detectar nombres ausentes, contraste insuficiente y saltos en la jerarquía de títulos, entre otros problemas.
- Prueba la página con un lector de pantalla: usa VoiceOver en Mac o NVDA en Windows, recórrela con el teclado y escucha qué información anuncia.
- Utiliza pruebas de preparación para agentes como isitagentready para simular si un agente de IA puede reconocer y utilizar tus componentes clave.
La accesibilidad no es un coste de cumplimiento adicional. Cada etiqueta semántica que implementas para las personas con discapacidad visual también será interpretada por los agentes de IA. Es una de las pocas inversiones de ingeniería capaces de generar dos tipos de valor al mismo tiempo.— Tenten GEO Technical Audit
ARIA y el marcado semántico no mejorarán directamente tu posicionamiento orgánico, pero sí determinan si un motor de IA puede comprender, extraer y citar tu contenido con precisión. Esa es la base de GEO. Si no sabes cómo interpreta tu sitio web un agente de IA ni qué componentes clave le resultan invisibles, puedes solicitar un diagnóstico GEO de 30 minutos. Una revisión práctica te mostrará dónde se encuentran las carencias.
