Accesibilidad y SEO: un solo trabajo, dos beneficios

El rastreador de un buscador es, funcionalmente, un usuario ciego con conexión rápida: no ve el diseño, analiza la estructura del documento. Por eso casi todo lo que exige la accesibilidad (semántica, jerarquía, alternativas de texto, nombres de enlace con sentido) es también una señal SEO. Y desde junio de 2025 la European Accessibility Act (EAA) convierte la accesibilidad en requisito legal para la mayoría de los servicios digitales al consumidor en la UE: lo que antes era "deseable" ahora puede acarrear sanciones.

Lo común: una corrección, dos beneficiarios

• La jerarquía de encabezados (h1 → h2 → h3, sin saltos, un único h1) es el esquema por el que navegan los lectores de pantalla, y la estructura de la que rastreadores y motores de IA extraen y citan secciones.
• Los puntos de referencia semánticos (<nav>, <main>, <article>, <footer>) indican a las tecnologías de apoyo y a los parsers qué es cada región. Una sopa de <div> es más difícil de interpretar para los parsers y suspende las auditorías.
• El texto alt sirve a los lectores de pantalla y al buscador de imágenes con la misma cadena de texto.
• Nombres de enlaces: "haga clic aquí" no pasa WCAG (un enlace debe tener sentido fuera de contexto) y desperdicia la señal del anchor. Una sola reformulación arregla ambos problemas.
• Los atributos lang, en <html> y en los fragmentos en otro idioma, alimentan la pronunciación de los lectores de pantalla y la detección de idioma para su hreflang.
• El CLS es un problema de accesibilidad antes de ser una métrica: los saltos de diseño afectan sobre todo a personas con limitaciones motrices y visuales. Arreglar los Core Web Vitals es trabajo de accesibilidad.

La accesibilidad no es un factor de posicionamiento directo. Algunos elementos de su implementación, como la estructura semántica y el texto descriptivo, también ayudan a los sistemas de búsqueda a interpretar la página.

Next.js: imponerlo en el pipeline

// .eslintrc — jsx-a11y detecta alts ausentes, roles erróneos y controles sin describir en la fase de PR
{
  "extends": ["next/core-web-vitals", "plugin:jsx-a11y/recommended"]
}

• next/image ya exige alt: no se lave las manos con un alt="" vacío en imágenes con significado.
• Establezca <html lang={locale}> a partir del parámetro de ruta en el layout principal.
• Ejecute Lighthouse accessibility junto a performance en CI: es la misma herramienta que ya tiene para el monitoreo, solo una barrera más.
• La automatización detecta ~30–40 % de los problemas WCAG; recorrer los flujos principales solo con teclado detecta la mayor parte del resto. Si no llega a un elemento con Tab, puede que el rastreador tampoco llegue a él por enlaces.

EAA: el plazo que zanja la discusión

Desde el 28 de junio de 2025 la EAA abarca el comercio electrónico, la banca, el transporte, los libros electrónicos y la mayoría de los servicios digitales al consumidor vendidos en la UE (las microempresas de menos de 10 personas y 2 M€ están exentas). La aplicación es nacional y se basa en reclamaciones: un checkout inaccesible es ahora una exposición legal, no un punto del backlog. El listón práctico es WCAG 2.1 AA (a través de EN 301 549), justo el estándar al que apuntan las correcciones anteriores. En España la EAA está transpuesta por la Ley 11/2023.

Checklist:

• Un h1 por página; niveles de encabezado sin saltos; puntos de referencia semánticos en su sitio
• Toda imagen con significado tiene un alt real; todo enlace tiene sentido fuera de contexto
• lang establecido desde el locale en <html> y en los fragmentos en otro idioma
• jsx-a11y en ESLint + barrera Lighthouse a11y en CI; flujos principales probados con teclado
• Aplicabilidad de la EAA evaluada; los flujos de consumidor cumplen WCAG 2.1 AA