Accesibilidad web y SEO: qué pide WCAG 2.2, qué coincide con Google y qué exige la ley europea

La accesibilidad web es que cualquier persona pueda usar tu web, también con un lector de pantalla, con zoom o solo con el teclado. Google no la presenta como factor de posicionamiento, pero usa las mismas piezas: texto alternativo, títulos, enlaces descriptivos y HTML semántico. Y desde el 28-06-2025, la ley europea la exige a muchas tiendas en línea.

Para comprobarlo en tu web: Auditoría SEO

Esta guía va de lo que coincide entre accesibilidad y posicionamiento web, de lo que más falla según los datos públicos y de cómo comprobarlo sin pagar una auditoría. No es asesoramiento legal: si tu empresa puede estar obligada, consúltalo con un abogado.

¿Qué es WCAG 2.2?

WCAG (Web Content Accessibility Guidelines) son las pautas de accesibilidad del contenido web del W3C, la referencia técnica que usan leyes y normas de todo el mundo. La versión 2.2 es Recomendación del W3C desde el 5 de octubre de 20231, y la versión vigente del documento es del 12 de diciembre de 20242.

Se organizan en cuatro principios: el contenido debe ser perceptible, operable, comprensible y robusto. Cada criterio tiene un nivel, A, AA o AAA, y el AA es el que suelen pedir las normas. WCAG 2.2 añade nueve criterios nuevos, como el tamaño mínimo de las zonas táctiles o que el foco del teclado no quede tapado, y retira uno, el 4.1.1 de análisis sintáctico, por obsoleto1.

Estos son los criterios que más se cruzan con el SEO y con la forma en que una máquina lee tu página2:

¿La accesibilidad es un factor de posicionamiento?

Google no la incluye en su documentación como factor de posicionamiento. Lo que sí documenta es que usa varias piezas que la accesibilidad también exige, así que arreglar una cosa suele arreglar la otra:

La última fila es un buen recordatorio de que no todo coincide. Declarar el idioma con <html lang="es"> es obligatorio para la accesibilidad y no cambia nada para Google. Se hace igual, porque sin él un lector de pantalla puede leer tu texto en castellano con pronunciación inglesa.

¿Qué es lo que más falla?

El dato público más amplio es el WebAIM Million, el análisis anual de las portadas del millón de webs más visitadas. En su edición de 2026, con datos de febrero, detectó fallos de WCAG en el 95,9 % de las portadas, con 56,1 errores de media por página6. Los seis más comunes:

Son detecciones automáticas, así que miden lo que una herramienta puede ver y no todo lo que falla. Pero los seis se arreglan en la plantilla, y cuatro de ellos (texto alternativo, enlaces, botones e idioma) son también lo que una máquina necesita para entender la página.

Cómo arreglar los fallos más comunes

1. Texto alternativo con sentido. Describe lo que aporta la imagen en ese contexto. Google pone su propio ejemplo: mejor «Cachorro de dálmata jugando a buscar la pelota» que «cachorro», y nada de listas de palabras clave3. Las imágenes decorativas llevan alt="", vacío pero presente, para que el lector de pantalla las salte. Más detalle en la guía de optimizar imágenes web.
2. Contraste suficiente. El gris #767676 sobre blanco da 4,54:1 y pasa el nivel AA para texto normal; el #999999, muy habitual en textos secundarios, da 2,85:1 y no pasa. Lo calculamos con la fórmula de luminancia relativa de WCAG.
3. Un nombre para cada botón y cada enlace. Un botón que solo tiene un icono necesita un texto que lo nombre. Y si el botón tiene texto visible, el nombre accesible debe contenerlo (criterio 2.5.3).
4. El idioma declarado en la etiqueta html, y lang en los fragmentos en otro idioma.
5. Zoom permitido. MDN advierte de que user-scalable=no impide leer la página a las personas con baja visión7.
6. Zonas táctiles de 24 × 24 píxeles CSS como mínimo, o con espacio suficiente alrededor1.

Este fragmento resume los puntos 3 a 5, con lo que no hay que hacer y lo que sí:

<!-- Mal: sin idioma y con el zoom bloqueado -->
<html>
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

<!-- Bien: idioma declarado y zoom libre -->
<html lang="es">
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- Mal: botón vacío y «enlace» que Google no rastrea -->
<button><svg aria-hidden="true">…</svg></button>
<span onclick="location.href='/presupuesto/'">Pide presupuesto</span>

<!-- Bien: botón con nombre accesible y enlace real con texto descriptivo -->
<button aria-label="Abrir el menú"><svg aria-hidden="true">…</svg></button>
<a href="/presupuesto/">Pide presupuesto para reformar tu cocina</a>

Accesibilidad y agentes de IA

Hay una razón nueva para cuidar los nombres de los controles. OpenAI explica en sus preguntas para editores que el agente de ChatGPT Atlas entiende mejor las webs accesibles, porque usa las etiquetas ARIA, las mismas que usan los lectores de pantalla, para interpretar la estructura y los elementos interactivos. Recomienda añadir funciones, etiquetas y estados descriptivos a botones, menús y formularios8.

ARIA no es un parche que se pone encima de todo. La guía de prácticas de ARIA del W3C advierte de que un ARIA incorrecto falsea lo que ve la persona, y que los roles ARIA no dan al navegador el comportamiento de teclado que sí traen los elementos nativos9. Por eso el orden es: primero <button>, <a href>, <label> y encabezados reales; ARIA solo donde el HTML no llega. Lo que hace que un asistente te cite, más allá de entender la página, está en contenido que la IA cite.

¿A quién obliga la ley europea de accesibilidad?

La Directiva (UE) 2019/882, conocida como Acta Europea de Accesibilidad, fija requisitos de accesibilidad para una lista de productos y servicios, entre ellos el comercio electrónico10. En España la traspone la Ley 11/2023, de 8 de mayo, y estos son los puntos que más afectan a una web11:

• Desde cuándo: los requisitos se aplican desde el 28 de junio de 2025.
• A qué servicios: entre otros, los servicios de comercio electrónico (artículo 2.2.f), la banca para consumidores y parte de los servicios de transporte de viajeros.
• Quién está exento: las microempresas que presten servicios (artículo 3.3). La ley define microempresa como la que emplea a menos de 10 personas y no supera los 2 millones de euros de volumen de negocios anual o de balance.
• Qué contenidos quedan fuera: entre otros, los vídeos y audios pregrabados y los documentos de ofimática publicados antes del 28 de junio de 2025, y el contenido de terceros que no controlas.
• Periodo transitorio: hasta el 28 de junio de 2030 para seguir prestando el servicio con productos que ya se usaban legalmente, y los contratos firmados antes del 28 de junio de 2025 pueden seguir hasta su vencimiento, con un máximo de cinco años.

La ley no cita WCAG por su nombre en estos puntos. La referencia técnica habitual es la norma europea EN 301 549, que según la Iniciativa de Accesibilidad Web del W3C incluye literalmente los criterios de WCAG 2.1 nivel AA para el contenido web12. WCAG 2.2 mantiene esos criterios casi sin cambios y añade otros1, así que trabajar con 2.2 AA te cubre por arriba.

Cómo comprobarlo

1. Lighthouse o PageSpeed Insights. La categoría de accesibilidad pasa pruebas automáticas, cada una de aprobado o suspenso, y pondera el resultado según el impacto para el usuario13. Un solo botón sin nombre suspende la prueba de nombres de botón entera.
2. El teclado. Recorre la página con la tecla Tab: ¿ves siempre dónde está el foco?, ¿llegas a todos los menús y botones?, ¿puedes cerrar una ventana emergente?
3. El zoom. Amplía al 200 % en el ordenador y comprueba que no se corta texto ni aparece desplazamiento horizontal.
4. Un lector de pantalla. NVDA en Windows o VoiceOver en Mac e iPhone, durante cinco minutos en tu página principal, enseñan más que cualquier informe.

Una herramienta automática no sabe si un alt describe bien la imagen ni si el orden de lectura tiene sentido. Por eso los puntos 2 a 4 no se pueden saltar.

Qué revisa SmoothSeen

Declaración de interés: este blog es de SmoothSeen, una herramienta de auditoría web. En el apartado de móvil y accesibilidad de su análisis de posicionamiento web comprueba el texto alternativo de las imágenes, el contraste de color, que botones y controles tengan nombre accesible, el idioma declarado, la etiqueta viewport y que el zoom esté permitido, el tamaño del texto en móvil y el de las zonas táctiles. Son comprobaciones automáticas: no sustituyen a la prueba con teclado y lector de pantalla ni dicen si cumples la ley.

Qué hacer esta semana

Pasa tu página principal y una ficha o página de servicio por PageSpeed Insights, apunta los fallos de accesibilidad y recorre las dos con el teclado. Empieza por el contraste y los botones sin nombre, que suelen arreglarse en una sola plantilla. Si quieres verlos junto al resto del análisis técnico, haz una auditoría SEO gratuita.

Preguntas frecuentes

¿Mejorar la accesibilidad mejora el SEO?

No de forma directa: Google no documenta la accesibilidad como factor de posicionamiento. Pero muchas correcciones coinciden con lo que Google sí usa: el texto alternativo para entender las imágenes, el título de la página, el texto descriptivo de los enlaces y los enlaces construidos con etiquetas a. Al arreglar esas piezas para las personas, se las das también a los buscadores.

¿Qué nivel de WCAG tengo que cumplir?

El nivel AA es la referencia habitual de normas y leyes. La norma europea EN 301 549 incluye WCAG 2.1 AA para el contenido web, y WCAG 2.2 mantiene esos criterios y añade otros, como el tamaño mínimo de las zonas táctiles. Trabajar con WCAG 2.2 AA es la opción más segura si empiezas hoy.

¿Mi tienda online está obligada por la ley de accesibilidad?

En España, la Ley 11/2023 incluye los servicios de comercio electrónico desde el 28 de junio de 2025, pero exime a las microempresas que presten servicios: menos de 10 empleados y no más de 2 millones de euros de facturación anual o de balance. Si superas esas cifras o tienes dudas sobre tu caso, consúltalo con un abogado.

¿Basta con un plugin o una capa de accesibilidad?

Una capa que se añade por encima no corrige el HTML de la página: un botón sin nombre o un enlace hecho con span siguen ahí para el lector de pantalla y para los rastreadores. Lo que funciona es corregir las plantillas: texto alternativo, contraste, nombres de controles, idioma y enlaces reales. Después, compruébalo con el teclado y un lector de pantalla.