Qué significan la EAA y la WCAG 2.1 para los sitios WordPress
Desde el 28 de junio de 2025, la Ley Europea de Accesibilidad (EAA, Directiva 2019/882) se aplica a productos y servicios puestos en el mercado de la UE por primera vez. Para un sitio web o una aplicación web, eso significa cumplir la WCAG 2.1 AA, un estándar del W3C que define cómo debe ser el contenido digital para resultar perceptible, operable, comprensible y robusto. La EAA no enumera por sí misma los criterios de éxito de la WCAG; remite a la norma europea armonizada EN 301 549, que hoy incorpora la WCAG 2.1 nivel AA. La WCAG 2.2 es ya la recomendación vigente del W3C, pero el suelo legal que la mayoría de sitios WordPress deben cumplir hoy sigue siendo el 2.1 AA, razón de más para entenderlo en sus propios términos antes de ir más allá.
Este artículo es el punto de partida. Explica quién está realmente dentro del ámbito, qué exenciones se sostienen y cuáles no, cómo se ve la WCAG 2.1 AA en un proyecto WordPress real, y hacia dónde ir después. Descubre más sobre los servicios de desarrollo WordPress de WPPoland si necesitas un equipo que construye proyectos accesibles, no solo los auditoria.
Dos cifras explican por qué esto no es un asunto de nicho. Alrededor del 15% de la población de la UE vive con alguna forma de discapacidad, y una proporción mucho mayor se beneficia de forma situacional: personas mayores, alguien con una lesión temporal, cualquiera que use una pantalla pequeña bajo luz solar intensa. El trabajo de accesibilidad también se solapa fuertemente con los fundamentos de SEO - la estructura semántica, el texto alternativo descriptivo y el markup limpio ayudan tanto a los buscadores y a los motores de respuesta de IA como a las tecnologías de asistencia. Ambos hilos recorren el resto de esta guía.
Fechas clave y quién está dentro del ámbito
La fecha de aplicación de la EAA es fija, pero “estar dentro del ámbito” no es una respuesta simple de sí o no - depende de la categoría del producto o servicio, de la fecha del contrato y del tipo de cliente atendido. La tabla siguiente es el resumen práctico; los matices legales en casos límite corresponden a un abogado, no a una entrada de blog.
| Plazo | Qué cubre | Matiz B2C vs. B2B |
|---|---|---|
| 2025-06-28 | Los requisitos de accesibilidad de la EAA se aplican a productos y servicios puestos en el mercado de la UE por primera vez: comercio electrónico, banca de consumo, libros electrónicos, comunicaciones electrónicas, servicios de acceso a medios audiovisuales e interfaces de transporte de pasajeros (anexo I) | La categoría de comercio electrónico está definida en torno a un contrato con consumidor (artículo 3(30)); otras categorías, como la banca y las comunicaciones electrónicas, no tienen esa misma limitación al consumidor |
| 2025-06-28 a 2030-06-28 | Ventana transitoria: los contratos de servicios celebrados antes del 2025-06-28 pueden continuar en sus condiciones originales como máximo hasta esta fecha | Se aplica con independencia del tipo de cliente - lo decisivo es la fecha del contrato, no si el comprador es consumidor o empresa |
| Fecha de instalación + hasta 20 años | Los terminales de autoservicio (cajeros, máquinas de billetes, quioscos de facturación) ya instalados antes del plazo pueden seguir en servicio hasta el fin de su vida útil, con un límite de 20 años | Sobre todo una cuestión de hardware para terminales físicos; raramente relevante para un proyecto puramente WordPress, salvo que controle un quiosco en una tienda física |
| Continuo, por ejercicio fiscal | Reevaluación de microempresa: si el número de empleados o el volumen de negocio de un prestador de servicios supera el umbral del artículo 4(5), la exención deja de aplicarse desde ese ejercicio fiscal | Se aplica solo a prestadores de servicios - las obligaciones del lado del producto nunca estuvieron cubiertas por esta exención, sea cual sea el tamaño |
| Fechas nacionales de transposición | La mayoría de los Estados miembros transpusieron cerca de la fecha de la UE - en España, la Ley 11/2023 se publicó en el BOE el 8 de mayo de 2023 y su Título I produce efectos plenos desde el 28 de junio de 2025 - pero los organismos de vigilancia, las estructuras sancionadoras y las reglas de la declaración de accesibilidad varían de un país a otro | Se aplica al mercado donde se pone el producto o se presta el servicio, no al país de origen del operador |
La lectura práctica: si un sitio WordPress vende a consumidores de la UE, opera un checkout de WooCommerce, o presta un servicio de una de las categorías del anexo I, el plazo ya ha pasado y la obligación está activa ahora, no es algo que planificar para “más adelante”.
Exenciones y ámbito para microempresas
Esta es la sección que más se malinterpreta. “Somos pequeños, así que estamos exentos” es una suposición habitual, y es errónea con más frecuencia de la que es correcta. La Directiva 2019/882 define varias excepciones estrechas, no un pase general para pequeñas empresas.
| Exención | Quién puede reclamarla | Condiciones | Qué NO cubre |
|---|---|---|---|
| Exención de microempresa (artículo 4(5)) | Empresas con menos de 10 empleados Y volumen de negocio anual o balance total inferior a 2 millones de EUR | Ambas condiciones deben cumplirse a la vez; la exención se pierde desde el ejercicio fiscal en que se supere cualquiera de los dos umbrales | Exime solo servicios. Las obligaciones de fabricación, importación o distribución de productos se aplican con independencia del tamaño de la empresa |
| Carga desproporcionada (artículo 14, anexo VI) | Cualquier operador económico, de cualquier tamaño | Requiere una evaluación documentada frente a los criterios del anexo VI, sopesando el coste frente al beneficio para los usuarios; debe renovarse al menos cada cinco años y presentarse a las autoridades si lo solicitan | No es una exención general - el operador sigue obligado a aplicar todo requisito que no se demuestre desproporcionado |
| Alteración fundamental (artículo 14) | Cualquier operador económico, de cualquier tamaño | Se aplica solo cuando cumplir un requisito cambiaría fundamentalmente la naturaleza del producto o servicio | Rara vez aplicable a funciones típicas de WordPress (navegación, formularios, contenido); más relevante para hardware especializado o software a medida |
| Contratos de servicios preexistentes (artículo 32) | Cualquier tamaño | Los contratos de servicios celebrados antes del 2025-06-28 pueden continuar en sus condiciones originales como máximo hasta 2030-06-28 | No se extiende a nuevos contratos firmados después del plazo, ni siquiera con un cliente ya existente |
| Terminales de autoservicio en uso (artículo 32) | Cualquier tamaño, típicamente operadores de hardware | Los terminales ya instalados antes del plazo pueden continuar hasta el fin de su vida útil, con un límite de 20 años | No se aplica a terminales nuevos comprados o instalados después del plazo |
| Contenidos pregrabados publicados antes del 28 de junio de 2025 (artículo 2(4)) | Cualquier tamaño | Los medios basados en el tiempo (audio/vídeo) publicados antes del plazo quedan fuera del ámbito con carácter retroactivo | Los nuevos contenidos pregrabados publicados después del plazo deben cumplir los requisitos desde el primer día |
Un caso real de delimitación de ámbito, explicado paso a paso. Tomemos una tienda WooCommerce con cuatro empleados y un volumen de negocio muy por debajo de los 2 millones de EUR, que vende directamente a consumidores. Según el artículo 4(5) es una microempresa de servicios, así que las obligaciones de accesibilidad para el propio servicio de compra y checkout no le aplican. Esa exención termina en el momento en que la tienda contrata al quinto empleado hasta el décimo y supera los diez, o el volumen de negocio pasa de 2 millones de EUR - la propia directiva no prevé ningún periodo de gracia, así que la suposición de planificación más segura es perder la exención desde el ejercicio fiscal en que se supera el umbral, no desde una fecha de renovación posterior.
Ahora cambiemos un dato: la misma tienda de cuatro personas, pero opera como proveedor mayorista bajo un contrato negociado con una empresa más grande, sin ningún checkout directo al consumidor. Aquí ocurren dos cosas distintas, no una sola. Primero, la categoría de comercio electrónico en la EAA está definida en torno a la celebración de un contrato con consumidor (artículo 3(30), considerando 42) - un canal de venta exclusivamente B2B puede quedar fuera de esa categoría solo por eso, con independencia de la exención de microempresa. Segundo, y esta es la parte que más confunde: quedar fuera de la obligación de comercio electrónico de la propia EAA no significa que la tienda esté libre de requisitos de accesibilidad en esa relación. Si el comprador mayor está a su vez sujeto a la EAA, al NIS2 o a cláusulas de accesibilidad en contratación pública, su propio programa de cumplimiento puede exigir contractualmente herramientas de proveedores conformes con la WCAG, con independencia de que el proveedor sea una microempresa o esté fuera de la categoría de comercio electrónico según el derecho de la UE. La exención de la EAA protege frente a la aplicación de la propia EAA; no hace nada frente a una cláusula contractual de accesibilidad de un cliente.
En España, esto tiene una fecha y un marco concretos: la Ley 11/2023, de 8 de mayo, publicada en el BOE, transpone en su Título I la Directiva 2019/882 y produce efectos plenos desde el 28 de junio de 2025, exigiendo que los productos y servicios afectados cumplan la norma técnica UNE-EN 301549. El incumplimiento puede acarrear sanciones de entre 30.000 y 600.000 EUR según la gravedad de la infracción, además de las obligaciones adicionales para servicios de emergencias del 112 previstas para 2027.
Este es un planteamiento factual, no asesoramiento legal - si una clasificación concreta está en disputa, o los números de facturación están cerca del umbral, confírmalo con un abogado antes de apoyarte en una exención en una declaración pública o en una respuesta a un concurso.
La WCAG 2.1 AA en la práctica en WordPress
La WCAG 2.1 AA no es una checklist que se marca una vez; es un conjunto de criterios de éxito comprobables que se cumplen o no en una página, formulario o componente dado. Cuatro áreas explican la mayor parte del trabajo real en un sitio WordPress.
Operabilidad por teclado. Todo elemento interactivo - menú, desplegable, modal, control de carrusel, botón de añadir al carrito - tiene que ser alcanzable y operable únicamente con Tab, Shift+Tab, Enter y las flechas, con un indicador de foco visible en cada paso. Aquí es donde más fallan los constructores de páginas y los plugins de slider: un slideshow que solo avanza al pasar el ratón por encima, o un mega-menú que se abre con hover pero nunca con foco, bloquea en silencio a cualquiera que no pueda usar un ratón. La solución rara vez implica reescribir código; suele bastar con añadir los manejadores de eventos de teclado que faltan y un estilo :focus visible con suficiente contraste.
Contraste de color. La WCAG 2.1 AA exige un ratio de contraste de al menos 4.5:1 para texto normal y 3:1 para texto grande frente al fondo. Las paletas de marca diseñadas para un logotipo, no para el cuerpo del texto, son el fallo más habitual: un gris claro sobre blanco que luce elegante en una maqueta pero no supera el ratio para alguien con baja visión. Los fallos de contraste son baratos de corregir una vez detectados y caros de dejar sin corregir, porque afectan a cada página que hereda los ajustes de tipografía del tema.
Formularios. Cada campo necesita una etiqueta asociada programáticamente (<label for="id">, no solo un texto de marcador de posición que desaparece al enfocar), cada campo obligatorio debe anunciar que lo es, y cada error de validación debe describirse en texto cerca del campo, no transmitirse solo mediante un borde rojo. Los formularios de checkout y contacto son las superficies de mayor riesgo aquí, porque un formulario que un usuario de lector de pantalla no puede completar es una transacción perdida, no solo una brecha de cumplimiento.
Contenido multimedia. El vídeo necesita subtítulos, el audio necesita transcripción, y toda imagen con significado necesita un texto alternativo que describa su función o contenido en lugar de repetir el nombre del archivo. Las imágenes decorativas (texturas de fondo, espaciadores) deben llevar un alt="" vacío, para que la tecnología de asistencia las ignore en vez de anunciar ruido. Esta es una de las áreas donde la disciplina editorial pesa tanto como el código: un desarrollador puede construir un componente de imagen accesible, pero solo un editor de contenido formado mantiene cada carga nueva conforme.
Patrones de fallo en WordPress que vemos habitualmente en auditorías
Algunos patrones se repiten en casi todas las auditorías WordPress que realizamos, con independencia del tema o el nicho. La jerarquía de encabezados falla primero: los constructores de páginas suelen emitir un <h1> o <h2> para el texto hero de cada sección, sin importar su lugar real en la estructura del documento, de modo que una página puede tener cinco etiquetas h1 y ningún anidamiento lógico de h2/h3 debajo. Los usuarios de lectores de pantalla navegan por la estructura de encabezados; una estructura rota hace que la página sea mucho más difícil de escanear de lo que jamás notaría un usuario que ve.
Los controles solo con icono vienen después - un botón de añadir al carrito o de búsqueda renderizado como un icono desnudo sin texto visible y, a menudo, sin aria-label tampoco, deja a la tecnología de asistencia sin nada que anunciar. Los carruseles con rotación automática son un tercero muy cercano: sin control de pausa, sin navegación por teclado, y contenido que cambia cada cuatro segundos con independencia de si el lector ha terminado de leer la diapositiva actual.
El cuarto patrón es más discreto, pero igual de importante: los banners de consentimiento de cookies y los modales de newsletter que atrapan el foco del teclado. Un usuario tabula hacia el modal y nunca puede volver a tabular hacia el contenido de la página, porque el desarrollador nunca conectó una trampa de foco que se libere con Escape o con una acción de cierre. Es invisible en una prueba de QA guiada por ratón e inmediatamente evidente la primera vez que alguien prueba solo con teclado.
Ninguno de estos es un error exótico. Son el resultado directo y repetible de plugins y temas populares usados como la mayoría de los sitios los usan, y es precisamente por eso por lo que una auditoría encuentra el mismo puñado de patrones en proyectos no relacionados entre sí. El artículo sobre la pila de cumplimiento 2026 recorre la lista de fallos plugin por plugin - constructores de páginas, plantillas de WooCommerce, plugins de slider, plugins de formularios - con el criterio de éxito de la WCAG concreto que incumple cada uno y la solución concreta para cada caso.
Ruta de implementación: auditoría, corrección, declaración, monitorización
Convertir “necesitamos cumplir” en un resultado entregado y defendible sigue la misma ruta de cuatro etapas en todos los proyectos que realizamos.
Auditoría. Empieza con una revisión acotada de la WCAG 2.1 AA sobre los recorridos reales de los clientes del sitio - página de inicio, navegación, búsqueda, formularios y cada paso del checkout crítico para el negocio - no solo un escaneo automático de la página de inicio. Las herramientas automatizadas (axe-core, Lighthouse, WAVE) detectan aproximadamente la mitad de los problemas reales; el resto necesita un tester humano con teclado y lector de pantalla.
Corrección. Corrige en el orden que protege primero los recorridos de mayor valor: trampas de teclado y controles de checkout sin etiqueta antes que ajustes cosméticos de contraste en un enlace del pie de página. Una sola corrección en un componente compartido - el estilo de foco del tema, el markup de etiquetas del plugin de formularios - suele resolver decenas de hallazgos repetidos a la vez, y por eso la corrección debe apuntar primero a las plantillas compartidas antes que a páginas individuales.
Publica una declaración de accesibilidad. Una declaración que indique el nivel de conformidad, cualquier limitación conocida y un canal de contacto funcional para quejas de accesibilidad es obligatoria según varias leyes nacionales de transposición y buena práctica en todos los demás casos. También le da a los equipos de compras algo concreto para el expediente.
Monitorización. La accesibilidad se degrada en el momento en que una nueva actualización de plugin, una nueva plantilla de constructor de páginas, o un nuevo editor de contenido entra sin formación. Una comprobación automatizada en CI detecta regresiones en cada despliegue; un retest manual anual detecta lo que la automatización no puede ver.
Para la pila legal completa - los nueve nuevos criterios de éxito de la WCAG 2.2, la relación entre la EAA y las leyes nacionales, y el detalle de corrección a nivel de plugin - lee la pila de cumplimiento 2026 para WordPress. Si quieres una auditoría acotada y por escrito en lugar de una checklist de autoservicio, la auditoría de cumplimiento UE para WordPress cubre la accesibilidad junto con la exposición a NIS2/DORA y la AI Act en un único encargo, con presupuesto individual basado en el alcance real de tu sitio.
Por qué la accesibilidad se solapa con el SEO y la legibilidad para IA
La mayor parte del trabajo técnico detrás de la WCAG 2.1 AA es también, por separado, buen SEO y buena higiene para los motores de respuesta de IA, razón por la que los presupuestos de accesibilidad son más fáciles de justificar de lo que parecen a primera vista. Una jerarquía de encabezados limpia y secuencial es exactamente lo que usan los rastreadores de buscadores y los modelos de lenguaje que resumen contenido para entender de qué trata realmente una página; la misma corrección que ayuda a un usuario de lector de pantalla a navegar una página también ayuda a un sistema de IA a extraer la sección correcta al responder una consulta sobre ella. El texto alternativo descriptivo hace un doble servicio - como señal para la búsqueda de imágenes y como descripción de respaldo que cualquier sistema de IA que lea el markup de la página puede usar cuando la imagen en sí no se procesa.
El HTML semántico - elementos <button> y <nav> reales en lugar de una sopa de <div> con estilos, asociaciones <label> correctas en los formularios - produce un markup que es a la vez accesible y más fácil de analizar de forma fiable para sistemas automatizados, sea ese sistema un lector de pantalla, un rastreador de búsqueda, o un pipeline de recuperación detrás de un asistente de IA. Nada de esto es casualidad: tanto la accesibilidad como la legibilidad para máquinas convergen en el mismo requisito subyacente, que es contenido que lleva su propia estructura y significado en el markup, en lugar de depender por completo del estilo visual. Tratar un proyecto de corrección de la WCAG solo como un coste legal ignora que buena parte del trabajo se amortiza en visibilidad orgánica.
Hacia dónde ir después
¿Listo para pasar de la evaluación a la acción? Contáctanos para acotar una revisión de accesibilidad de tu sitio WordPress, o empieza por el recurso que corresponde a tu punto de partida:
- ¿Necesitas el mapa legal y técnico más profundo, incluyendo la WCAG 2.2? Lee el artículo sobre la pila de cumplimiento 2026.
- ¿Necesitas una auditoría acotada y por escrito con un backlog de corrección que puedas entregar a un desarrollador? Consulta la auditoría de cumplimiento UE para WordPress.
- ¿Necesitas un equipo que construya la corrección, no solo la diagnostique? Explora nuestros servicios de desarrollo WordPress.
