La idea clave: WCAG 2.2 AA es el estándar técnico al que apunta la mayor parte de la legislación europea de accesibilidad, y se reduce a cuatro principios — perceptible, operable, comprensible, robusto — pero en la práctica, la mayoría de los sitios WordPress fallan en un pequeño conjunto repetible de problemas: contraste de color, texto alternativo ausente, lagunas en la navegación por teclado y jerarquía de encabezados rota.
Por qué esto importa ahora, no eventualmente
La Ley Europea de Accesibilidad (Directiva (UE) 2019/882) se aplica desde el 28 de junio de 2025, exigiendo que categorías específicas de productos y servicios vendidos a consumidores de la UE — comercio electrónico, banca, libros electrónicos, servicios de transporte y telecomunicaciones entre otros — cumplan requisitos de accesibilidad. Ya no es un plazo futuro; ya es ley activa en los estados miembros de la UE.
La Ley hace referencia a WCAG 2.2 en el nivel de conformidad AA como el estándar técnico práctico que la mayoría de las organizaciones usa para demostrar el cumplimiento, incluso donde la propia EAA está redactada en un lenguaje legal más amplio. Eso convierte a WCAG 2.2 AA en el objetivo concreto que vale la pena perseguir, independientemente de si un sitio específico entra exactamente en el alcance de la EAA.
Lo que WCAG 2.2 AA exige realmente
WCAG organiza sus requisitos en torno a cuatro principios, comúnmente abreviados como POUR:
- Perceptible — el contenido debe poder presentarse de formas que los usuarios puedan percibir, cubriendo cosas como el texto alternativo para imágenes y un contraste de color suficiente para el texto.
- Operable — los componentes de la interfaz deben poder usarse solo con teclado, no únicamente con ratón, y los usuarios necesitan suficiente tiempo para leer e interactuar con el contenido.
- Comprensible — el contenido y el comportamiento de la interfaz deben ser predecibles y legibles, incluyendo etiquetas de formulario claras y navegación coherente.
- Robusto — el contenido debe funcionar de forma fiable en las distintas tecnologías de asistencia como los lectores de pantalla, lo cual depende en gran medida de un HTML limpio y semántico y del uso correcto de ARIA.
WCAG 2.2 añadió nueve nuevos criterios de éxito sobre 2.1, varios de ellos dirigidos específicamente a la accesibilidad móvil y cognitiva — un tamaño mínimo de objetivo para elementos clicables, una ubicación coherente de los mecanismos de ayuda en todas las páginas, e indicadores de foco visibles más claros para los usuarios de teclado.
Los fallos de accesibilidad más comunes en WordPress
Ejecutamos una auditoría completa de accesibilidad con axe-core más Playwright en este sitio — 14 páginas en modo oscuro y claro — y es una muestra útil del mundo real de exactamente dónde suelen fallar los sitios WordPress, ya que los problemas encontrados fueron totalmente típicos en lugar de específicos del sitio.
- Contraste de color en elementos decorativos. Las etiquetas de categoría y las insignias de colores usaban colores hexadecimales de marca en bruto directamente como color de texto sobre fondos teñidos, alcanzando solo unos 3,3-4,0:1 — por debajo del mínimo de 4,5:1 para texto normal en AA. La solución fue definir tokens de color "seguros para texto" separados y creados con ese propósito, en lugar de reutilizar directamente los colores de marca como texto.
- Saltos en la jerarquía de encabezados. Una página de listado saltaba de un H1 directamente a secciones H3 sin un H2 en medio, algo invisible visualmente pero que rompe el esquema lógico del documento en el que se apoyan los usuarios de lectores de pantalla para navegar.
- Enlaces distinguidos solo por el color. Los enlaces en línea en bloques de texto más largos tenían un color distinto al del texto circundante pero no estaban subrayados, incumpliendo el requisito de que la distinción enlace-vs-texto no dependa únicamente de la percepción del color.
- Atributos ARIA ausentes en componentes interactivos personalizados. Un acordeón de preguntas frecuentes personalizado no tenía aria-expanded, aria-controls ni role="region" — funcional para un usuario de ratón, pero ambiguo para un usuario de lector de pantalla sin ninguna señal sobre el estado del acordeón.
Ninguno de estos problemas se detectó con solo mirar la página — salieron a la luz mediante una combinación de escaneo automatizado y revisión manual, el patrón que vale la pena replicar en cualquier sitio WordPress.
Un proceso práctico de auditoría
| Paso | Herramienta/Método | Detecta |
|---|---|---|
| Escaneo automatizado | Extensión de navegador axe-core o WAVE | Texto alternativo ausente, fallos de contraste, etiquetas de formulario faltantes |
| Recorrido solo con teclado | Navegar con tabulador por toda la página sin ratón | Orden de foco roto, elementos interactivos inalcanzables |
| Comprobación puntual con lector de pantalla | VoiceOver (Mac) o NVDA (Windows) | ARIA ambiguo, estructura de encabezados confusa |
| Comprobación manual de contraste | Herramientas de desarrollador del navegador o un verificador de contraste | Problemas de contraste en estados que las herramientas automatizadas pasan por alto (hover, foco) |
| Ambos modos de color | Repetir todo lo anterior en modo oscuro y claro | Regresiones de contraste que solo aparecen en un tema |
Puntos problemáticos comunes específicos de WordPress
- Los ajustes por defecto de temas y page builders suelen venir con problemas de contraste o estructura de encabezados integrados en las plantillas, que luego se repiten en cada página que usa esa plantilla.
- Los widgets añadidos por plugins (carruseles, acordeones, pestañas) frecuentemente carecen de atributos ARIA adecuados, ya que no todos los autores de plugins prueban con tecnología de asistencia.
- Las imágenes subidas sin texto alternativo son una de las infracciones más comunes y más fáciles de corregir — revisar en bloque una biblioteca de medios en busca de texto alternativo ausente detecta de una vez años de lagunas acumuladas. Erdo Image Optimizer incluye una auditoría integrada que señala las imágenes sin texto alternativo en toda una biblioteca de medios, además de la optimización del tamaño de archivo que cubrimos en nuestra guía de SEO de imágenes.
- Los banners y modales de consentimiento de cookies se pasan por alto habitualmente en las pruebas de foco por teclado, ya que se añaden después de que carga la página principal y quedan fácilmente fuera del orden de tabulación habitual de un sitio.
La accesibilidad es mantenimiento, no un proyecto puntual
Una auditoría WCAG corrige lo que existe en el momento en que se ejecuta; cada nueva entrada de blog, cada nuevo plugin y cada cambio de plantilla es una nueva oportunidad de reintroducir un problema que esa auditoría ya había cerrado. Tratar las comprobaciones de accesibilidad como parte del flujo de trabajo regular de publicación y desarrollo — no como un proyecto que se marca como terminado una vez — es lo que mantiene un sitio conforme seis meses después, no solo el día del lanzamiento.
Errores comunes
- Confiar solo en un escáner automatizado, pasando por alto los problemas manuales de teclado y lector de pantalla que ningún escáner puede juzgar.
- Corregir el contraste solo en modo claro, cuando un sitio con alternancia de modo oscuro necesita comprobar ambos de forma independiente.
- Asumir que un tema o page builder popular es accesible por defecto, cuando los problemas de contraste y encabezados a nivel de plantilla se repiten en cada página construida a partir de él.
- Tratar una auditoría de accesibilidad como una tarea puntual en lugar de una comprobación continua aplicada al nuevo contenido y funciones a medida que se publican.
- Omitir el texto alternativo en las nuevas subidas de imágenes incluso después de que una auditoría masiva corrigiera el rezago existente, dejando que la laguna se vuelva a acumular silenciosamente.
Para terminar
En resumen, el cumplimiento de WCAG 2.2 AA para un sitio WordPress se reduce a una lista corta y repetible de puntos de fallo del mundo real — contraste de color, texto alternativo ausente, navegación por teclado, estructura de encabezados y uso de ARIA en componentes personalizados —, detectada de forma fiable solo mediante una combinación de escaneo automatizado y pruebas manuales, y mantenida mediante un hábito continuo en lugar de una auditoría única. Con la Ley Europea de Accesibilidad ya en vigor en lugar de pendiente, tratarla como mantenimiento rutinario en lugar de una tarea futura es la diferencia entre un sitio conforme y un riesgo legal.