Un rastreador y un lector de pantalla resuelven un problema parecido: los dos tienen que entender una página sin poder "verla" de la forma en que la ve una persona con visión, mirando el diseño y deduciendo la estructura por su disposición visual. Los dos dependen del mismo material de partida para hacerlo: el HTML semántico, la estructura de encabezados, el texto alternativo de las imágenes y las relaciones explícitas entre elementos. Esta coincidencia no es casualidad ni marketing: es la razón técnica real por la que mejorar accesibilidad casi siempre mejora, como efecto colateral, cómo un motor de búsqueda entiende esa misma página.
Esta guía no trata la accesibilidad como un checklist legal aparte del SEO técnico, sino como una capa de señales que se solapa con él en varios puntos muy concretos, y explica dónde el solape es real y dónde son objetivos distintos que conviene no confundir.
HTML semántico: la base que comparten accesibilidad y rastreo
Un lector de pantalla no "ve" que un bloque parece un botón por su color y su sombra; necesita que sea, en el código, un elemento <button> o un enlace <a> real, o al menos un elemento con el rol ARIA correspondiente, para poder anunciarlo como interactivo y permitir operarlo con teclado. Un rastreador tiene exactamente la misma limitación: no interpreta visualmente el diseño, solo la estructura del documento, así que un <div> con un manejador de clic en JavaScript que visualmente parece un enlace no es, para ninguno de los dos, un enlace real.
<!-- Ni accesible ni rastreable como enlace -->
<div class="boton-azul" onclick="location.href='/contacto'">Contacto</div>
<!-- Accesible y rastreable -->
<a href="/contacto" class="boton-azul">Contacto</a>Esta es probablemente la señal con más solape directo entre ambas disciplinas: usar el elemento HTML correcto para lo que realmente es (botón, enlace, lista, tabla, encabezado) no es una elección estética, es información estructural que ambos sistemas necesitan para funcionar.
Jerarquía de encabezados: un mapa que ambos usan para orientarse
Un lector de pantalla ofrece a la persona usuaria la posibilidad de navegar una página saltando de encabezado en encabezado (h1, h2, h3...) para hacerse una idea rápida de su estructura sin tener que escuchar todo el contenido de corrido. Google usa esa misma jerarquía como una de las señales para entender qué partes de una página son secciones principales y cuáles son subsecciones, y también la usa para generar enlaces de salto directo a partes específicas de una página en algunos resultados de búsqueda.
Cuando la jerarquía de encabezados se rompe (saltar de un h2 a un h4 sin h3 intermedio, usar varios h1 en la misma página, o usar encabezados solo por el tamaño de letra que produce visualmente sin importar el nivel semántico) ambos sistemas pierden la misma información: la persona usuaria de lector de pantalla pierde el mapa de navegación rápida, y el rastreador pierde una señal de qué contenido depende jerárquicamente de qué otro contenido.
Texto alternativo de imágenes: la misma descripción, dos consumidores distintos
El atributo alt de una imagen tiene un origen puramente de accesibilidad (describir la imagen a quien no puede verla), pero es también la fuente principal de información textual que Google tiene sobre el contenido de esa imagen, ya que no "ve" la imagen de la misma forma en que entiende texto. Un alt bien escrito (descriptivo, específico, sin relleno de palabras clave forzadas) sirve exactamente igual a ambos consumidores; un alt vacío en una imagen decorativa (alt="") también es correcto para ambos, porque le dice tanto al lector de pantalla como a Google que esa imagen no aporta información y puede omitirse sin pérdida.
El error que perjudica a ambos por igual es el alt relleno de palabras clave sin relación real con la imagen: un lector de pantalla lo lee tal cual, generando una experiencia confusa o directamente inútil, y Google lo identifica como una señal de manipulación en vez de como una descripción genuina, con el mismo resultado negativo en ambos casos.
Contraste de color y legibilidad: señal de UX que Google también mide
El contraste de color entre texto y fondo es un requisito WCAG (con ratios mínimos concretos, normalmente 4.5:1 para texto normal) pensado para personas con baja visión o daltonismo. No es una señal de rastreo en el sentido técnico de robots.txt o canonical, pero sí es un factor que Google evalúa indirectamente a través de señales de experiencia de página, y un texto con contraste insuficiente es, literalmente, más difícil de leer y usar para cualquier persona, no solo para quien tiene una discapacidad visual diagnosticada.
Foco de teclado y navegación sin ratón: estructura interactiva legible
Que un sitio se pueda navegar completamente con teclado (tabulando entre elementos interactivos en un orden lógico, con un indicador visible de qué elemento tiene el foco) es un requisito de accesibilidad, pero también revela algo técnico: si el orden de tabulación es caótico o si hay elementos interactivos que el teclado no puede alcanzar, normalmente es porque esos elementos no están implementados con HTML semántico interactivo real (botones, enlaces, campos de formulario), la misma carencia estructural que afecta a cómo un rastreador interpreta esos mismos elementos.
Dónde accesibilidad y SEO técnico NO son lo mismo
El solape es real pero no es total, y conviene no forzarlo donde no existe. Cosas puramente de accesibilidad sin efecto de rastreo: el orden de anuncio de regiones ARIA live para lectores de pantalla, los atajos de teclado personalizados, o el comportamiento de foco al abrir y cerrar un modal. Y cosas puramente técnicas de SEO sin relación con accesibilidad: la configuración de hreflang, el crawl budget, o la estructura de un sitemap XML. Tratar la accesibilidad como "SEO gratis" en todos los casos lleva a implementaciones superficiales que cumplen la letra de una auditoría automática pero no resuelven ni la experiencia real de la persona usuaria ni aportan la señal técnica que se busca.
Preguntas frecuentes
¿Mejorar la accesibilidad de mi web mejora directamente mi posicionamiento?
No hay una señal de ranking llamada "accesibilidad" que Google puntúe de forma aislada, pero varias prácticas de accesibilidad (HTML semántico, jerarquía de encabezados, alt de imágenes) coinciden exactamente con señales técnicas que sí influyen en cómo Google entiende e indexa el contenido.
¿Un lector de pantalla y Googlebot procesan la página de la misma forma?
No de forma idéntica, pero comparten una limitación de fondo importante: ninguno de los dos interpreta el diseño visual, ambos dependen de la estructura semántica del HTML para entender qué es cada elemento y cómo se relacionan entre sí.
¿Basta con pasar una herramienta automática de accesibilidad para estar cubierto?
Las herramientas automáticas detectan un subconjunto de problemas (contraste, alt ausente, etiquetas de formulario) pero no todos los criterios WCAG son verificables automáticamente; problemas de orden lógico de foco o de sentido real de un texto alternativo necesitan revisión manual.
¿Los roles ARIA sustituyen al HTML semántico?
No deberían usarse como sustituto cuando existe un elemento HTML nativo equivalente. La primera regla de ARIA es "no uses ARIA si puedes resolverlo con HTML semántico nativo", porque un elemento nativo trae comportamiento de teclado y semántica incorporados sin necesidad de replicarlos manualmente.
¿La accesibilidad afecta a Core Web Vitals?
Indirectamente en algunos casos: por ejemplo, un foco de teclado mal gestionado puede provocar saltos de layout al abrir modales, lo cual sí afecta a Cumulative Layout Shift, una de las métricas de Core Web Vitals.