Accesibilidad web y SEO: qué comparten y cómo audité mi web

Si buscas «accesibilidad web y SEO» te vas a encontrar con dos mensajes opuestos: que la accesibilidad posiciona y que no tiene nada que ver. Ninguno es exacto. Google no puntúa tu conformidad con WCAG, pero casi todo lo que WCAG te pide en HTML es lo que un buscador necesita para entender la página.

Aquí separo lo documentado de lo que se repite sin fuente, resumo los criterios de WCAG 2.2 que más pesan y dedico la mayor parte al caso práctico: lo que medí en cristofercruz.net con axe-core, lo que corregí en el código y lo que dejo pendiente con su dato.

Qué dice Google sobre accesibilidad y ranking

No he encontrado en la documentación de Search Central una frase que diga «la accesibilidad es un factor de ranking», ni una que diga lo contrario con esas palabras. Lo que sí está escrito, en la página sobre experiencia de página, es que no hay una señal única, que los Core Web Vitals son usados por sus sistemas de clasificación y que otros aspectos de la experiencia de página no ayudan directamente a posicionar mejor. La accesibilidad no aparece como señal. Pasa algo parecido con E-E-A-T: tampoco es un factor de ranking específico, y conviene no venderlo como una puntuación.

La cita más clara es de John Mueller, en marzo de 2022 según la recopilación de BOIA (no he visto el vídeo original): «it's not something that we would pick up and use as a direct ranking factor when it comes to search». Es decir, no es un factor directo. Mueller añadió que podría cambiar con el tiempo, pero eso es una posibilidad, no un plan.

Entonces, ¿por qué se asocian? Por efecto indirecto y por solapamiento. Un texto alternativo bien escrito ayuda a la búsqueda de imágenes, un encabezado bien jerarquizado ayuda a entender la estructura, un enlace con ancla descriptiva da contexto. Y una página que se puede usar sin ratón, con zoom y en móvil retiene mejor a la gente, algo que se mide con otras vías como los Core Web Vitals. Eso no es lo mismo que decir que una puntuación de axe suba tu posición, y yo no he medido ninguna relación de ese tipo.

WCAG 2.2: principios, niveles y qué cambió

WCAG 2.2 es Recomendación del W3C desde el 12 de diciembre de 2024. Sus pautas se agrupan en cuatro principios, el acrónimo POUR: perceptible, operable, comprensible y robusto. Cada criterio de éxito tiene un nivel: A (el mínimo), AA (el que suele exigirse en normativa y contratos) y AAA (deseable, no siempre alcanzable). Mi objetivo práctico es A y AA.

La versión 2.2 eliminó el criterio 4.1.1 (Parsing) y añadió, entre otros, el 2.4.11 (foco no oculto, mínimo) y el 2.5.8 (tamaño mínimo del objetivo), ambos de nivel AA.

Criterios WCAG con efecto en SEO y cómo comprobarlos

No todos los criterios tocan el SEO. Estos son los que, cuando fallan, suelen romper también algo que un buscador lee:

Sobre la tercera columna: el criterio 2.4.4 pide que el propósito de cada enlace se pueda determinar a partir del texto del enlace junto con su contexto. Las anclas descriptivas son accesibilidad y son, a la vez, la base de un buen enlazado interno. En el caso de las tarjetas clicables, hay un patrón que funciona para ambas cosas y lo explico en la guía de enlazar una card box.

ARIA: la primera regla es no usarla si no hace falta

WAI-ARIA sirve para describir roles, estados y propiedades que HTML no puede expresar por sí solo, como una pestaña personalizada o un menú desplegable complejo. La guía «Using ARIA» del W3C lo resume en su primera regla: si puedes usar un elemento o atributo HTML nativo con la semántica y el comportamiento que necesitas, úsalo en lugar de reutilizar otro elemento y añadirle un rol ARIA. Ese documento figura hoy como borrador descontinuado (24 de febrero de 2026) y el W3C remite a la Authoring Practices Guide; la regla sigue siendo el criterio habitual.

La diferencia se ve en cualquier botón. Un <button> ya recibe foco con teclado, responde a Enter y espacio y se anuncia como botón. Un <div role="button"> necesita que le programes todo eso, y si el rol no coincide con el comportamiento, el lector de pantalla anuncia algo que no es.

<!-- Mejor -->
<button type="button">Enviar</button>

<!-- Peor: hay que añadir foco, teclado y estados a mano -->
<div role="button" tabindex="0">Enviar</div>

Lectores de pantalla y herramientas que «leen» tu web

Un lector de pantalla usa el árbol de accesibilidad que el navegador construye a partir del DOM, con el rol y el nombre de cada elemento. ¿Lo usan también los buscadores con IA? No he encontrado documentación de Google que lo diga, así que no lo afirmo. Lo que sí he comprobado es que mis scripts de prueba localizan controles por rol y nombre accesible (por ejemplo, el botón «Rechazar todas» del banner de cookies), y que un botón sin nombre accesible no se puede localizar así.

Normativa: European Accessibility Act y España

La Directiva (UE) 2019/882, conocida como European Accessibility Act, fija requisitos de accesibilidad para determinados productos y servicios. Según su artículo 2.2, se aplica a los servicios prestados a consumidores después del 28 de junio de 2025 que enumera, entre ellos los servicios de comunicaciones electrónicas, los servicios bancarios a consumidores, los libros electrónicos y el software específico, y los servicios de comercio electrónico.

El artículo 4.5 exime de cumplir los requisitos de accesibilidad a las microempresas que presten servicios. El artículo 3.23 define microempresa como la que emplea a menos de 10 personas y tiene un volumen de negocios anual o un balance general anual que no excede de 2 millones de euros. En España, la Ley 11/2023, de 8 de mayo (BOE del 9 de mayo de 2023), traspone la Directiva; su preámbulo menciona el 28 de junio de 2025 como plazo de aplicación efectiva. No he leído el articulado español sobre la exención de microempresas, así que para eso consulta el texto consolidado o a un abogado.

Mi lectura de mi propio caso, y no es asesoramiento jurídico: mi web no vende nada online, solo capta contactos con un formulario, así que no creo que sea un servicio de comercio electrónico. Si vendes a consumidores por internet y no eres microempresa, consulta tu caso con asesoría legal.

Cómo lo aplico en mi web

Ejecuté axe-core 4.14.0 con Playwright sobre las 88 URLs de los dos sitemaps (servicios, ciudades, casos de éxito, herramientas, blog), a 390 px y a 1440 px: 176 pasadas, con las reglas de WCAG 2.0, 2.1 y 2.2 de niveles A y AA más las buenas prácticas de axe. Escribí un segundo script para lo que axe no mide bien (orden de tabulación, tamaño de objetivos, foco y reflujo a 320 px), sobre una muestra de 21 páginas.

Qué salió antes de tocar nada

El resultado inicial fue bastante limpio. axe encontró 62 violaciones (una regla en una página y un viewport) y 189 nodos, en solo dos reglas:

• scrollable-region-focusable: 187 nodos en 40 artículos. Los bloques <pre> de código desbordan en horizontal y quien navega con teclado no podía desplazarlos, porque un pre no recibe foco.
• empty-table-header: 2 nodos, una celda <th> vacía en la esquina de una tabla comparativa del artículo sobre URLs absolutas y relativas.

Con mi script propio aparecieron tres cosas más. 82 enlaces y controles medían menos de 24 px de alto (sobre todo las migas de pan, de 19 px, y el enlace de LinkedIn de la sección de contacto, de 18 px). 23 controles de las herramientas mostraban un anillo de foco de color azul o rosa de marca con menos de 3:1 de contraste sobre blanco. Y el enlace de «Saltar al contenido» era el segundo en el orden de tabulación, detrás de un enlace del aviso superior (el séptimo en la primera visita, con el banner de cookies delante).

Qué cambié

Solo toqué lo que era claro y no cambiaba la identidad visual. La lista exacta:

El site.css se sirve minificado, así que el cambio de CSS solo se verá en producción cuando se regenere site.min.css. Para medir el después, serví una copia con el CSS sin minificar.

Un detalle sobre el enlace de salto. Lo había movido primero dentro de un contenedor y axe empezó a marcar la regla region en las 176 pasadas: no es contenido dentro de un landmark. Al dejarlo como primer elemento del body, antes del banner de cookies, la regla desaparece. El destino del salto es #main; los fragmentos los resuelve el navegador y no crean otra URL, como cuento en la guía de sintaxis de URLs.

Qué salió después

Los 4 objetivos que quedan son un campo de archivo oculto de 1 px en el analizador de logs y una casilla nativa de 20 px en el generador de redirecciones, cada uno en las dos anchuras. Mi contador es más estricto que WCAG: cuenta todo lo que mide menos de 24 px, sin aplicar la excepción de espaciado de la 2.5.8, que admite objetivos pequeños si hay 24 px de separación respecto a otros. El tamaño de los tap targets en móvil lo trato en la guía de SEO móvil.

Contraste de los colores de marca

El contraste lo calculé a mano con la fórmula de WCAG sobre las variables de site.css. Los pares que uso para texto cumplen con holgura, y el que usa color de acento sobre blanco, no:

El azul de trazo sí aparece como texto en un sitio: los números de las listas ordenadas de los artículos, con ::marker en azul y negrita. axe no revisa los marcadores de lista, y 2,64:1 no llega a 4,5:1. No lo he cambiado: es un acento de marca visible y la decisión de oscurecerlo o pasarlo a tinta es de diseño, no un arreglo mecánico. Queda anotado como pendiente. El tratamiento del CSS en general, incluido el texto oculto con visually-hidden, lo cuento en mi guía de CSS y SEO.

Lo que no he cambiado y lo que no he medido

• Números de lista en azul de trazo a 2,64:1 (decisión de marca, arriba).
• Banner de cookies sin decidir. Con el banner abierto, entre 0 y 5 paradas de foco por página quedaron detrás de él al tabular. Desaparece al decidir. No lo he medido con rigor ni lo he corregido.
• Botón fijo de móvil. En una página de servicio, un enlace quedó cubierto en parte por el botón fijo inferior. El 2.4.11 solo falla si queda totalmente oculto, así que cumple el AA, pero es mejorable.
• Lector de pantalla. No he probado la web con NVDA, VoiceOver ni TalkBack. Mis pruebas de teclado son simulaciones con Playwright, no una persona usándolo.
• Resultados «incompletos» de axe. axe devuelve como incompletos los casos que no puede resolver y que requieren revisión manual. No los he revisado uno por uno.

Lo que ya estaba bien: html lang="es" en todas las páginas muestreadas, un solo H1 y sin saltos de nivel en los encabezados, un main por página, ninguna imagen sin alt entre 202 imágenes (la revisión del criterio de cada alt está en la guía sobre el texto alternativo), ningún campo de formulario sin etiqueta (el único sin label es la trampa antispam, oculta y con aria-hidden), foco visible en todos los elementos tabulables de la muestra (hasta 60 paradas por página), el bloque prefers-reduced-motion que desactiva el scroll suave, y el banner de cookies con botones reales y un cuadro de diálogo nativo con título.

Cómo auditar la accesibilidad paso a paso

El orden que sigo, de lo automático a lo humano:

1. Analizador automático. axe-core, o Lighthouse, que pondera sus auditorías con las valoraciones de impacto de axe y no cuenta las pruebas manuales en su puntuación. WAVE queda como mención: es útil para ver los avisos sobre la propia página.
2. Teclado. Tab y Mayús+Tab por toda la página: orden lógico, anillo visible, sin trampas de foco, menús utilizables con Enter y Esc.
3. Zoom y reflujo. Ventana de 320 px y texto al 200 %, sin pérdida de contenido ni scroll en dos direcciones.
4. Lector de pantalla. Recorrer un flujo real (menú, formulario, un artículo) con NVDA o VoiceOver.

// Pasada de axe-core con Playwright (esquema)
await page.addScriptTag({ path: 'node_modules/axe-core/axe.min.js' });
const r = await page.evaluate(() => axe.run(document, {
  runOnly: { type: 'tag', values: ['wcag2a','wcag2aa','wcag21a','wcag21aa','wcag22aa','best-practice'] }
}));
console.log(r.violations.map(v => [v.id, v.nodes.length]));

El propio README de axe-core dice que encuentra de media el 57 % de los problemas de WCAG de forma automática, y que devuelve como «incompletos» los elementos de los que no está seguro. Un cero en axe no significa «accesible», significa que no hay fallos de los que axe detecta. En un sitio grande conviene auditar plantillas, componentes y flujos, no URLs sueltas. Los iframe necesitan un title para tener nombre accesible (axe tiene la regla frame-title); en mi web ahora mismo no uso ninguno fuera de las herramientas, y el resto de consideraciones SEO las trato en la guía de iframes y SEO.

Errores típicos

• Imágenes con alt de relleno o vacío cuando sí informan.
• Enlaces con «aquí» o «más información» repetido decenas de veces.
• div y span con onclick en lugar de button o a.
• Listas con scroll infinito que dejan el pie de página inalcanzable y el foco perdido (ver scroll infinito y SEO).
• Quitar el contorno de foco con outline: none sin una alternativa visible.
• Colores de acento usados como texto sin calcular su contraste.

Por dónde empezar

1. Pasa axe sobre una muestra: home, una landing, un artículo, el contacto. Guarda el resultado como línea base.
2. Arregla primero lo mecánico: lang, alt, nombres de botones y enlaces, etiquetas de formulario, celdas de cabecera.
3. Recorre cada plantilla con teclado y comprueba que el enlace de salto es el primer foco y que el anillo se ve en todos los controles.
4. Calcula el contraste de cada par de colores de la marca, incluidos los de acento, y decide qué se usa solo como decoración.
5. Mide los objetivos táctiles en 390 px y prueba un flujo con lector de pantalla antes de dar el trabajo por cerrado.
6. Si el diseño tiene que cambiar, plantéalo al diseñar la arquitectura de la web y no como un parche posterior.

Preguntas frecuentes

Referencias y fuentes

1. Web Content Accessibility Guidelines (WCAG) 2.2 W3C
2. Understanding page experience in Google Search results Google Search Central
3. What Does Google Say About Web Accessibility and Search Rankings? BOIA
4. Using ARIA W3C
5. axe-core Deque, GitHub
6. Lighthouse accessibility score Chrome for Developers
7. Directive (EU) 2019/882 on the accessibility requirements for products and services EUR-Lex
8. Ley 11/2023, de 8 de mayo, de trasposición de Directivas de la Unión Europea en materia de accesibilidad de determinados productos y servicios BOE