Accesibilidad (WCAG 2.2) en 2026: Es legal tu sitio WordPress?

Desde el 28 de junio de 2025, los Estados miembros de la UE aplican las normas que trasponen la Ley Europea de Accesibilidad (EAA), la Directiva (UE) 2019/882. Para muchas tiendas online, servicios bancarios y plataformas de transporte, la accesibilidad web ha pasado de recomendación a obligación legal.

Para los desarrolladores WordPress y propietarios de sitios, el objetivo técnico práctico es WCAG 2.2 nivel AA. Esta guía explica qué criterios de WCAG 2.2 rompen con más frecuencia los temas WordPress, qué dice exactamente la directiva y cómo probar un sitio antes de cada versión. No sustituye una revisión jurídica de tu caso.

Referencias oficiales: la Recomendación WCAG 2.2, el texto de la Directiva 2019/882 y el manual de accesibilidad de WordPress.

#A quién se aplica la Ley Europea de Accesibilidad

Antes, las leyes de accesibilidad se aplicaban sobre todo al sector público. La EAA extiende requisitos a productos y servicios del sector privado, pero solo a categorías concretas. El artículo 2.2 de la directiva enumera los servicios prestados a consumidores después del 28 de junio de 2025:

• servicios de comunicaciones electrónicas;
• servicios que dan acceso a medios audiovisuales;
• elementos de los servicios de transporte aéreo, en autobús, ferroviario y por vías navegables (sitios web, aplicaciones móviles, billetes electrónicos, información de viaje);
• servicios bancarios para consumidores;
• libros electrónicos y su software específico;
• servicios de comercio electrónico.

La directiva define el comercio electrónico como los servicios prestados a distancia, mediante sitios web o aplicaciones móviles, a petición de un consumidor y con vistas a celebrar un contrato de consumo. Si tu WooCommerce vende a consumidores en la UE, el checkout entra en esa definición. Un sitio que solo presenta servicios a otras empresas, sin contratación online con consumidores, no figura en la lista.

#Qué excepciones prevé la directiva

• Microempresas que prestan servicios (artículo 4.5): están exentas de los requisitos de accesibilidad de servicios. La directiva define microempresa como la que emplea a menos de 10 personas y tiene un volumen de negocio anual o un balance general anual que no supera los 2 millones de euros. La exención no cubre a quien fabrica o comercializa productos.
• Carga desproporcionada o alteración fundamental (artículo 14): los requisitos se aplican solo en la medida en que no alteren la naturaleza básica del servicio ni impongan una carga desproporcionada. El operador debe hacer y documentar esa evaluación y conservar los resultados durante cinco años.
• Contenido excluido (artículo 2.4): por ejemplo, medios pregrabados y documentos ofimáticos publicados antes del 28 de junio de 2025, o contenido de terceros que el operador no financia, no desarrolla ni controla.

#Plazos de la directiva

La directiva no fija multas. El artículo 30 exige a cada Estado sanciones efectivas, proporcionadas y disuasorias que tengan en cuenta la gravedad del incumplimiento, el número de productos o servicios afectados y el número de personas perjudicadas.

#Cómo traspone España la EAA y qué multas hay

En España, el título I de la Ley 11/2023, de 8 de mayo, publicada en el BOE el 9 de mayo de 2023, incorpora la Directiva 2019/882. Igual que la directiva, exime a las microempresas que prestan servicios.

El régimen sancionador funciona por remisión. El artículo 30 de la Ley 11/2023 establece que los incumplimientos se sancionan conforme a la legislación sectorial correspondiente y, en lo no previsto, se aplica de forma supletoria el título III del Real Decreto Legislativo 1/2013. Su artículo 83 fija multas de 301 a 1.000.000 de euros: hasta 30.000 euros para infracciones leves y hasta 90.000 euros para las graves. La cuantía concreta depende de criterios como la intencionalidad, la cifra de negocio y el número de personas afectadas (artículo 84).

Si vendes a otros países de la UE, cada Estado tiene su propia ley de trasposición. Alemania usa la BFSG, Polonia una ley de 26 de abril de 2024 y Portugal el Decreto-Lei 82/2022. Puedes ver una comparación de multas y obligaciones por país.

#Qué norma técnica se usa para demostrar la conformidad

La EAA no menciona WCAG. El anexo I exige que los sitios web y las aplicaciones móviles sean accesibles de forma coherente y adecuada, haciéndolos perceptibles, operables, comprensibles y robustos: los mismos cuatro principios que estructuran WCAG. El artículo 15 añade que los servicios conformes con normas armonizadas publicadas en el Diario Oficial se presumen conformes con la directiva.

En la práctica, auditores y licitaciones hablan el idioma de WCAG nivel AA. WordPress ya ha elegido versión: los estándares de código de accesibilidad establecen que el código integrado en el ecosistema WordPress, incluido el núcleo, los sitios de WordPress.org y los plugins oficiales, debe cumplir WCAG 2.2 nivel AA, y animan a aplicar ATAG 2.0 en las interfaces de edición nuevas.

#Qué criterios nuevos trae WCAG 2.2

WCAG 2.2 se publicó como Recomendación del W3C el 5 de octubre de 2023 y la versión vigente es del 12 de diciembre de 2024. Según la página What’s new in WCAG 2.2, añade nueve criterios de conformidad a WCAG 2.1:

Para un objetivo AA cuentan seis de ellos. Los tres AAA son útiles como referencia de diseño.

#Por qué WCAG 2.2 eliminó el criterio 4.1.1

El criterio 4.1.1 Procesamiento (Parsing) se eliminó por obsoleto. El W3C explica que las tecnologías de apoyo ya no analizan el HTML por su cuenta, sino que se apoyan en el navegador, y los problemas que antes fallaban 4.1.1 ahora fallan 1.3.1 Información y relaciones o 4.1.2 Nombre, función, valor. Atención: una normativa nacional basada en WCAG 2.1 puede seguir exigiéndolo.

#Cómo cumplir los criterios de WCAG 2.2 en un tema WordPress

#2.4.11 Foco no oscurecido (mínimo) (AA)

Cuando un componente recibe el foco del teclado, no puede quedar totalmente oculto por contenido creado por el autor. La versión AAA (2.4.12) exige que no quede oculta ninguna parte.

• El problema: navegas con Tab por una página. Un elemento recibe el foco, pero tu cabecera fija o tu banner de cookies lo tapa. El usuario sabe que está en algún lugar, pero no puede ver dónde.
• La solución: usa scroll-padding-top en el elemento html para que los elementos enfocados se desplacen al área visible debajo de la cabecera fija.

html {
  scroll-padding-top: 80px; /* Altura de tu cabecera fija */
}

En WordPress, asegúrate de que el tema ajuste este valor si la altura de la cabecera cambia, por ejemplo cuando aparece una barra de aviso. Mantén el banner de cookies en el orden de tabulación con un botón de cierre visible y evita overflow: hidden en contenedores que recorten el contorno de foco.

#2.4.7 Foco visible y 2.4.13 Apariencia del foco

Muchos temas eliminan outline por estética y no lo sustituyen. Eso falla 2.4.7 Foco visible, que sigue siendo nivel AA. El criterio 2.4.13 (AAA) da una medida útil para diseñar el indicador: su área debe ser al menos la de un perímetro de 2 píxeles CSS alrededor del componente sin foco, con un contraste mínimo de 3:1 entre los mismos píxeles en estado enfocado y sin enfocar.

En temas de bloques, define el estilo :focus-visible en theme.json o en una hoja de estilos pequeña que se cargue tanto en el editor como en el frontend.

#2.5.7 Movimientos de arrastre (AA)

Toda función que se maneje arrastrando debe poder hacerse con un solo puntero sin arrastrar, salvo que el arrastre sea esencial. Afecta a menús ordenables, controles deslizantes y constructores tipo tablero. Gutenberg ofrece alternativas para muchas interacciones; los bloques propios que solo escuchan eventos de arrastre necesitan botones o campos equivalentes.

#2.5.8 Tamaño del objetivo (mínimo) (AA)

Los objetivos de puntero deben medir al menos 24 por 24 píxeles CSS. El criterio admite cinco excepciones:

• Espaciado: un objetivo más pequeño cumple si un círculo de 24 píxeles CSS de diámetro centrado en él no se cruza con otro objetivo ni con el círculo de otro objetivo pequeño.
• Equivalente: la misma función está disponible en otro control de la página que sí cumple.
• En línea: el objetivo está dentro de una frase o su tamaño lo limita la altura de línea del texto.
• Control del agente de usuario: el tamaño lo determina el navegador y el autor no lo modifica.
• Esencial: una presentación concreta es esencial o la exige la ley.

En la práctica, revisa los botones “X” de cierre de los popups, las flechas de paginación, las filas de iconos sociales, los checkboxes y los controles de carrusel. Se arreglan con padding, min-width y min-height sin cambiar el tamaño visual del icono.

#3.2.6 Ayuda consistente (A)

Si una página ofrece mecanismos de ayuda y estos se repiten en varias páginas, deben aparecer en el mismo orden relativo respecto al resto del contenido. El criterio cubre cuatro tipos: datos de contacto humano, un mecanismo de contacto humano, una opción de autoayuda y un mecanismo de contacto totalmente automatizado, como un chatbot. En WordPress, mantén el enlace de soporte o el widget de chat en la misma parte de la plantilla en todo el sitio.

#3.3.7 Entrada redundante (A)

La información que el usuario ya introdujo en el mismo proceso debe rellenarse automáticamente o estar disponible para seleccionarla. Las excepciones son que repetirla sea esencial, que se requiera por seguridad o que el dato anterior ya no sea válido. En WooCommerce, ofrece la casilla “Usar la misma dirección para la facturación” en lugar de pedir la dirección dos veces.

#3.3.8 Autenticación accesible (mínimo) (AA)

Ningún paso del inicio de sesión puede exigir una prueba de función cognitiva, como recordar una contraseña o resolver un puzzle, salvo que ese paso ofrezca al menos una de estas opciones: un método alternativo sin prueba cognitiva, un mecanismo de ayuda (por ejemplo un gestor de contraseñas), una prueba de reconocimiento de objetos o la identificación de contenido no textual que aportó el propio usuario. El nivel AAA (3.3.9) elimina las dos últimas excepciones.

• El impacto en WordPress: no bloquees el pegado en los campos de contraseña ni de códigos de un solo uso, para que funcionen los gestores de contraseñas. Ofrece enlaces mágicos por correo o WebAuthn y passkeys donde el producto lo permita. Revisa los scripts de plugins de membresía que desactivan el pegado y los muros antibots de terceros.

#Cómo usar HTML semántico accesible en WordPress

La mayoría de las correcciones duraderas son HTML correcto, sin plugins ni overlays.

#Regiones landmark (main, nav, aside, footer)

Usa <main>, <nav>, <aside>, <footer>. Los usuarios de lectores de pantalla saltan entre estas regiones para navegar. Un sitio WordPress bien estructurado tiene exactamente un <main>, una <nav> principal y landmarks claramente definidos.

#Jerarquía de encabezados

h1 a h6 es una jerarquía, no una elección de estilo. No saltes de h2 a h4 solo porque quieres una fuente más pequeña. Usa CSS para el tamaño. En WordPress esto falla a menudo cuando los editores usan encabezados para dar estilo visual al texto.

Conoce más sobre servicios de SEO y GEO en WPPoland.

#Cuándo usar un botón y cuándo un enlace

• ¿Va a una nueva URL? Usa <a>.
• ¿Cambia algo en la página actual, como abrir un menú? Usa <button>.
• Nunca uses <div onClick="...">. No recibe el foco del teclado y los lectores de pantalla no lo anuncian como elemento interactivo.

Un lector de pantalla anuncia enlaces y botones de forma distinta, y los usuarios confían en esa distinción para entender la página. ARIA complementa al HTML cuando el HTML nativo no basta: un <button> real es mejor que role="button" en un span.

#Qué bloques de Gutenberg fallan más en accesibilidad

Los bloques del núcleo y el editor han mejorado el soporte de teclado en varias versiones, pero eso no hace accesible cada página publicada. Patrones que siguen fallando:

• Bloques Grupo y Portada con texto de bajo contraste sobre imágenes. Comprueba el contraste después de aplicar la paleta del tema.
• Bloque Navegación con megamenús que solo se abren al pasar el ratón. Activa la apertura con clic o Intro y el cierre con Escape.
• Bloques propios que pintan widgets interactivos sin elementos enfocables o con aria-expanded incorrecto.
• Patrones de marketplaces con encabezados mal anidados o un h1 duplicado.

Para autores: revisa el orden de encabezados en la Vista de lista antes de publicar y usa los bloques nativos de Imagen y Galería para que el campo alt siga editable. Para desarrolladores de temas: prueba tanto el lienzo del Editor del sitio como el HTML del frontend, porque no siempre coinciden.

#Cómo probar temas clásicos y temas de bloques de WordPress

Los temas PHP clásicos fallan cuando las plantillas incluyen menús inaccesibles fijados en el código o cuando style.css elimina los estilos de foco. Las configuraciones híbridas (tema clásico con partes de plantilla en bloques) necesitan las mismas pruebas de elementos fijos y de foco en las plantillas PHP y HTML.

Los temas de bloques (theme.json, partes de plantilla) centralizan colores y tipografía. Eso ayuda al contraste si la paleta se diseña con ratios AA. También facilita publicar una cabecera fija global que incumple 2.4.11 en todas las páginas: se corrige una sola vez, en la parte de plantilla de la cabecera.

WooCommerce y los plugins de formularios funcionan sobre el tema. El checkout, la cuenta y el formulario de contacto necesitan cada uno su propia prueba con teclado.

#Qué exige la etiqueta accessibility-ready a un tema WordPress

El directorio de temas de WordPress.org solo concede la etiqueta accessibility-ready a temas que superan una revisión adicional. El manual del equipo de temas enumera 18 requisitos obligatorios:

1. enlace para saltar al contenido;
2. landmarks con roles y nombres significativos;
3. soporte completo de navegación por teclado;
4. controles con nombre, rol y estado accesibles;
5. campos de formulario etiquetados;
6. encabezados con estructura significativa;
7. enlaces subrayados dentro del texto;
8. sin textos de enlace ambiguos;
9. contraste suficiente de texto y controles;
10. texto alternativo en imágenes y gráficos;
11. audio, vídeo y animaciones accesibles;
12. soporte de reflow, cambio de tamaño y espaciado de texto;
13. sin cambios de contexto inesperados;
14. sin enlaces que abran ventanas o pestañas nuevas sin aviso;
15. contenido accesible al pasar el ratón o recibir el foco;
16. declaración de accesibilidad;
17. no recomendar ni exigir plugins inaccesibles;
18. soporte de texto solo para lectores de pantalla.

Elegir un tema con esta etiqueta no certifica tu sitio, porque los plugins, los patrones y el contenido pueden romperlo. Sirve como base revisada y como lista de control para temas propios.

#Sirven los plugins overlay de accesibilidad

Los has visto: el icono de una persona en un círculo que abre un menú para cambiar contraste o tamaño de fuente.

Evítalos como solución de cumplimiento.

• Falsa seguridad: prometen conformidad con una línea de JavaScript, pero no corrigen el HTML semántico del tema.
• Fricción para el usuario: los usuarios ciegos ya tienen lectores de pantalla configurados. Un overlay puede interferir con esas herramientas.
• Riesgo regulatorio: el 22 de abril de 2025 la Comisión Federal de Comercio de Estados Unidos (FTC) aprobó una orden definitiva que obliga a accessiBe a pagar un millón de dólares. La FTC consideró falsas, engañosas o sin fundamento sus afirmaciones de que el widget podía hacer cualquier sitio web conforme con WCAG.

La solución real es escribir código accesible desde el principio o corregir el código existente.

#Cómo probar la accesibilidad de un sitio WordPress

No puedes automatizar la accesibilidad al 100%. Las herramientas automáticas son un punto de partida y no ven la mayoría de trampas de teclado ni muchos casos de foco oculto.

#Pruebas de accesibilidad en tres pasos

1. Automatizado: usa axe-core o la auditoría de accesibilidad de Lighthouse en inicio, archivo, entrada, búsqueda, formulario y checkout. Detecta textos alternativos ausentes, bajo contraste, etiquetas ARIA inválidas y roles duplicados. Puede ejecutarse en cada despliegue dentro del pipeline de CI/CD.
2. Teclado manual: desconecta el ratón. ¿Puedes recorrer el menú, abrir los submenús y enviar el formulario de contacto usando solo Tab, Intro y Espacio? Comprueba que el indicador de foco es visible, que el orden de tabulación es lógico, que los modales retienen el foco correctamente y que se cierran con Escape.
3. Lector de pantalla: activa VoiceOver (Mac) o NVDA (Windows) en el mismo recorrido. ¿Los formularios tienen etiquetas descriptivas? ¿Las imágenes tienen textos alternativos útiles? ¿Se anuncian los cambios de estado?

Repite las pruebas después de actualizar el tema, de actualizar plugins que cambian el marcado y de editar plantillas en el Editor del sitio. Muchas regresiones llegan con un commit de CSS que pone outline: none.

#Herramientas para auditar la accesibilidad en WordPress

• axe DevTools: extensión de navegador que analiza la página actual y propone correcciones.
• WAVE: herramienta de WebAIM que muestra los problemas sobre la propia página.
• Pa11y: herramienta de línea de comandos para integrar en pipelines de CI/CD.
• Accessibility Checker (plugin WP): audita el contenido desde el editor de WordPress.

#Cómo hacer formularios accesibles en WordPress

Contact Form 7, Gravity Forms y los formularios propios comparten las mismas reglas.

#Etiquetas label en los campos

Cada campo necesita un <label> asociado programáticamente. Los placeholders no son etiquetas: desaparecen al escribir y el usuario pierde la referencia de qué dato se pide.

<!-- Correcto -->
<label for="email">Correo electrónico</label>
<input type="email" id="email" name="email">

<!-- Incorrecto -->
<input type="email" placeholder="Correo electrónico">

#Mensajes de error accesibles

“Error encontrado” es inútil. “La dirección de correo electrónico no contiene el símbolo @” es accesible. Asocia el mensaje al campo con aria-describedby y colócalo junto al campo con error.

#Foco en el primer campo con error

Cuando un usuario envía un formulario con errores, mueve el foco del teclado al primer campo inválido o a un resumen con enlaces a cada campo.

#Cómo marcar los campos obligatorios

No dependas solo del asterisco rojo. Usa el atributo required, explica qué significa el asterisco y comprueba que los lectores de pantalla anuncian el estado obligatorio.

#Cómo hacer accesibles WooCommerce y WordPress headless

#Checkout navegable por teclado

Todo el proceso, desde elegir el producto hasta la confirmación del pago, debe funcionar con teclado: añadir al carrito, cambiar cantidades, aplicar cupones, completar el checkout y recibir la confirmación.

Conoce más sobre desarrollo WooCommerce en WPPoland.

#Tablas de productos accesibles

Las tablas de comparación y las listas de variaciones deben usar <table> semántico con encabezados <th> y atributos scope para que los lectores de pantalla relacionen cada celda con su encabezado.

#Avisos del carrito con aria-live

Cuando se añade un producto o se aplica un descuento, usa aria-live="polite" para anunciar el cambio sin interrumpir lo que hace el usuario.

#WordPress headless con React o Astro

Los sitios WordPress headless con React, Next.js o Astro tienen problemas propios.

En una aplicación de una sola página, el cambio de ruta no recarga la página, así que el foco y los anuncios del lector de pantalla no se actualizan solos. Hay que mover el foco al contenido principal tras cada cambio de ruta, anunciar el título nuevo con una región aria-live y actualizar document.title.

Con renderizado en servidor, el contenido está en el HTML inicial y no depende de que se ejecute JavaScript. Los lectores de pantalla lo encuentran en cuanto carga la página.

#Lista de comprobación WCAG 2.2 AA para WordPress

• Estilos :focus-visible visibles en todo el tema y nunca tapados por cabeceras fijas o banners.
• Objetivos de 24 por 24 píxeles CSS o con el espaciado que permite 2.5.8.
• Alternativa sin arrastre para cada control que se arrastra.
• Ayuda en el mismo orden relativo en todas las plantillas.
• Formularios sin datos repetidos dentro del mismo proceso.
• Inicio de sesión que acepta pegar contraseñas y códigos.
• Evaluación del artículo 14 documentada si invocas carga desproporcionada.

Si necesitas una auditoría de accesibilidad de tus plantillas, bloques o checkout, WPPoland parte de una auditoría documentada de las plantillas que publicas, no de un overlay. Una revisión más amplia de las obligaciones europeas la describe la auditoría de cumplimiento UE. Contáctanos para una evaluación de tu sitio.