Accesibilidad en WordPress
Haz tu sitio WordPress realmente accesible: EAA y WCAG, sin overlay
WordPress es flexible, pero no es accesible por defecto: los page builders, los plugins y los temas introducen barreras silenciosas. Nosotros las encontramos y te entregamos la corrección en el código de tu propia plantilla, sin un widget que ralentice tu sitio.
Así aborda Seviranta tu sitio WordPress desde la raíz
Dónde se esconden los obstáculos
Los temas, las extensiones y los formularios introducen barreras silenciosas. Nosotros las encontramos todas.
La corrección en la fuente, no por encima
Reparaciones concretas en su tema y plugins, no una capa de overlay que solo oculta los errores.
Sin widget, sin ralentización
Rastreamos desde fuera, desde servidores de la UE, con un 0 % de impacto en su velocidad de carga y sus Core Web Vitals.
Listo para la EAA
Evaluamos tu sitio según WCAG, al nivel en el que evalúan los reguladores.
Escaneo headless con axe-core, el mismo motor que incorpora Google Lighthouse, desde nuestros servidores en la UE. 0% de impacto en tu velocidad de carga.
La verdad: WordPress no es accesible por defecto
Un tema de bloques de WordPress cuidado como Twenty Twenty-Four arranca mejor que muchos sitios, pero rara vez alcanza WCAG 2.2 AA por sí solo. En cuanto empiezas a construir con Elementor, Divi o Gutenberg, dejas que los plugins inyecten marcado o añades imágenes sin texto alternativo, surgen barreras que tus visitantes, y la European Accessibility Act, no aceptan.
Lo que realmente está en juego
- Un checkout no accesible es una infracción directa de la EAA.
- Un widget de accesibilidad no cuenta como solución estructural.
- Los organismos de control prueban el HTML generado, incluidas tus apps.
- «Usamos WordPress» no es una defensa legal: la responsabilidad recae en la tienda online que está en vivo, no en la plataforma.
Lo que puede costar esperar
hasta € 1.000.000
Máximo UE · España/Luxemburgo
$ 4.000
EE. UU. · California (Unruh), por visita
No te multan de la noche a la mañana, primero llega un requerimiento de subsanación con plazo. Pero quien entonces puede mostrar un expediente fechado sale más barato.
Mira qué aplica a tu mercado →El riesgo oculto de las extensiones de WordPress de terceros
Los widgets de reseñas, los filtros, los bundlers y las apps de búsqueda inyectan HTML dinámico en tu frontend, y cada actualización de una app puede añadir una nueva barrera. En una auditoría ese código cuenta por completo, aunque no lo hayas escrito tú. Por eso Seviranta vigila de forma continua el resultado final tal como lo ve un organismo supervisor: tu tema WordPress más todas las apps y el contenido dinámico.
Lo que suele fallar en WordPress
- Los page builders generan una sopa de div ilegibleElementor y Divi anidan secciones, columnas y contenedores en decenas de niveles de profundidad. Esa sopa de div no tiene semántica, así que un lector de pantalla pierde la estructura lógica de tu página y solo lee fragmentos sueltos de texto.
- Marcado de plugins sin nombre accesibleLos sliders, pop-ups y formularios de los plugins a menudo inyectan botones y campos sin etiqueta ni aria-label. Quien usa lector de pantalla solo oye «botón» y no tiene ni idea de qué hace la acción.
- Orden de encabezados roto del builderLos page builders suelen elegir los encabezados por su tamaño en lugar de por su significado, así que de un h2 saltas de golpe a un h4. Quienes usan lector de pantalla navegan por los encabezados y pierden el hilo de tu página.
- Imágenes de la biblioteca multimedia sin texto alternativoLas imágenes de la biblioteca multimedia a menudo llegan a tu tema sin texto alternativo, o con el nombre del archivo como alt: ilegibles para lectores de pantalla e invisibles para Google.
Así es una corrección de verdad
Fíjate en un botón con icono de tu bloque de Elementor o Gutenberg. Sin un nombre accesible, una persona que usa lector de pantalla solo oye «botón». La corrección es un solo atributo, sin reconstruir nada:
<button class="elementor-button">
<i class="icon-cart" aria-hidden="true"></i>
</button><button class="elementor-button"
aria-label="<?php esc_attr_e( 'Bekijk winkelwagen', 'theme' ); ?>">
<i class="icon-cart" aria-hidden="true"></i>
</button>Dónde lo arreglas dentro de WordPress
WordPress promete WCAG 2.2 AA para el admin y los temas incluidos, siempre que sea posible. Para temas de terceros, plugins y tu contenido no promete nada. Exactamente ahí está el trabajo.
- 1Tema: leer accessibility-ready como está pensadoLa etiqueta significa una revisión manual de 18 requisitos básicos: skip link como primer elemento enfocable, foco visible de al menos 2 px, contraste 4,5:1 y 3:1 para elementos de interfaz, landmarks, etiquetas de formulario, sin medios parpadeantes. La propia WordPress añade que la etiqueta no significa que el tema cumpla WCAG AA, y que WCAG trata sobre contenido y no puede aplicarse a un tema.
- 2Texto alternativo: en el bloque y en la bibliotecaEl bloque Image tiene un campo 'Alternative text' y una casilla 'Mark as decorative'; el alt de la biblioteca de medios es el valor por defecto, el alt del bloque gana. Describe lo que aporta la imagen. Cuidado con el lightbox: ahí el pie de foto queda oculto (issue abierto) y con un alt vacío el diálogo de ampliación no tiene nombre.
- 3Encabezados y contraste en el editorUsa la pestaña Outline en Document Overview para comprobar el orden de los encabezados; el título de la página suele ser el h1, según el tema. El editor avisa cuando el contraste es bajo ('This color combination may be hard for people to read'), pero solo en el editor, solo en bloques con ajustes de color y no con colores transparentes. Define tu paleta en theme.json o en Global Styles y se aplicará en todas partes.
- 4Idioma, navegación y plantillasEl atributo lang sale de Ajustes → Generales → Idioma del sitio. El bloque Navigation tiene un issue abierto con una trampa de foco en el menú overlay cuando un submenú está desplegado; prueba tu menú solo con Tab y Esc. Las plantillas y partes de plantilla se sobrescriben en un child theme por nombre de archivo, o en el Site Editor en un tema de bloques.
- 5Page builders y pluginsElementor dice que solo tienes que aportar contenido accesible, pero el skip link solo lo obtienes con el tema Hello, en Canvas o Full Width defines tú mismo el ID CSS 'content', y ARIA va mediante atributos personalizados. Divi 4 remite a productos del marketplace para el foco de teclado y ARIA; Divi 5 añade semántica y ARIA mediante Custom Attributes. Todo lo que renderiza un builder o un plugin está en la misma página y cuenta en la auditoría.
El WordPress Accessibility Team desaconseja los widgets overlay: ninguna herramienta automatizada logra por sí sola el cumplimiento. Elementor vende un widget así como 'Ally' y el marketplace de Divi un 'Accessibility Sidebar'. Una capa sobre tu sitio no repara los bloques que hay debajo.
Lo que recibes
Por cada error: qué, por qué y cómo
Para cada hallazgo ves qué está mal, a quién afecta, qué regla WCAG implica y una solución concreta y pensada para WordPress, con un ejemplo de código siempre que sea posible.
Detección específica de la plataforma
Detectas los errores que surgen precisamente en WordPress, no solo lo que capta una comprobación genérica de WCAG.
Un expediente que aguanta
Un resumen fechado de tus escaneos y hallazgos que puedes mostrar en una auditoría o una inspección.
Con una herramienta de informes pagas la licencia y también a tus desarrolladores para resolver los errores. Con Seviranta la corrección va incluida: sin doble factura.
Protege tu conversión y tu situación legal
Una app que pega un icono de accesibilidad sobre tu sitio de WordPress es un riesgo para tu negocio. Los hechos, uno a uno:
Widgets de accesibilidad para WordPress
- Cargan scripts externos adicionales que perjudican tu velocidad de carga (LCP) y, con ello, tu conversión.
- Enmascaran el error en lugar de resolverlo: el código de fondo sigue estando mal.
- No te protegen frente a reclamaciones. La FTC multó al proveedor de overlays accessiBe en 2025 con 1 millón de dólares por afirmaciones engañosas sobre cumplimiento.
El enfoque de Seviranta
- 0 % de impacto en tu velocidad de carga: escaneamos de forma externa desde nuestros servidores en la UE.
- Reparamos el código fuente real de tus plantillas de WordPress.
- Construimos automáticamente tu expediente EAA conservable, listo para mostrar a un regulador.
Preguntas y respuestas
- Mi tema es accessibility-ready. ¿Ya he terminado?
- No. La etiqueta dice que el tema cumple los requisitos básicos del equipo de revisión; la propia WordPress dice que no es una declaración de WCAG AA. Tu contenido, tus plugins y tu builder se suman encima, y ahí es donde están la mayoría de los hallazgos.
- También vendo o publico para Alemania o Francia. ¿Qué se aplica allí a mi sitio WordPress?
- Alemania: el BFSG se aplica a las tiendas online B2C desde el 28 de junio de 2025, con una exención para microempresas (menos de diez personas y como máximo 2 millones de euros de facturación o de balance total); la supervisión corre a cargo de la Marktüberwachungsstelle der Länder (MLBF). Francia: desde el 28 de junio de 2025 el comercio electrónico entra en la transposición de la EAA en el Code de la consommation, con la misma exención para microempresas, bajo la supervisión de la DGCCRF; la vara de medir es el RGAA (WCAG 2.1 AA). En ambos países cuenta la página publicada, no el hecho de que uses WordPress.
- ¿Puedo aplicar la corrección yo mismo en el Site Editor o necesito a mi developer?
- Colores, encabezados, textos alternativos, estructura del menú y muchas partes de plantilla puedes cambiarlos tú mismo en el editor o en el Site Editor. El marcado de plugins o de un builder suele requerir un developer: una sobrescritura de plantilla en un child theme, un filtro o un ajuste del plugin. Nuestro informe indica por cada hallazgo dónde está, para que sepas quién puede encargarse.
- ¿Es suficiente un widget de accesibilidad de WordPress para la EAA?
- No. Un widget pone una capa sobre tu sitio, pero no repara el código de fondo y no cuenta como cumplimiento estructural.
- ¿Mi checkout de WordPress está sujeto a la EAA?
- Sí. El checkout y la navegación forman parte explícita de la obligación bajo WCAG 2.1 AA.
- ¿Seviranta también escanea mis apps de WordPress?
- Sí. Probamos el HTML final generado, tema más apps, tal y como lo hace un organismo de control.
- ¿Esto ralentizará mi sitio de WordPress?
- No. Escaneamos de forma externa desde nuestros servidores en la UE; no se coloca ningún script en tu sitio. 0 % de impacto en tu velocidad de carga y tus Core Web Vitals.
Nosotros también lo hacemos
Nos exigimos exactamente el mismo listón: nuestra propia web obtiene 0 errores en axe-core, el mismo motor que incorpora Google Lighthouse y con el que también escaneamos tu tienda WordPress. Lo que una máquina detecta con certeza lo resolvemos de forma automática, el resto lo valora una persona. Así de riguroso te lo entregamos: consulta un informe de ejemplo real.
Lo que la EAA exige a tu tienda de WordPress
Desde junio de 2025 tu tienda online tiene que cumplir WCAG 2.1 AA, y una tienda de WordPress no es una excepción. El escaneo gratuito te muestra en 60 segundos en qué punto estás, con la línea exacta que no cumple.
¿Vendes en más de un país?
WCAG es el estándar mundial. Casi todos los mercados se apoyan en él:
Adapta tu tienda WordPress a WCAG una sola vez y cubres el listón técnico en todos esos mercados. Lo que cambia según el mercado es la autoridad que lo aplica y las multas.
Consulta qué se aplica en cada mercado de destino →¿Gestionas varios sitios de WordPress para clientes?
Evita que las tiendas online que entregas se conviertan en un riesgo legal bajo la EAA para tus clientes. Usa Seviranta como tu sello de calidad automatizado en cada entrega y cada deploy: un escaneo, y cada sitio está demostrablemente en orden.
Conoce nuestro programa de partners →Otras plataformas
Sigue leyendo
Escanea tu tienda de WordPress gratis
Pega la URL de tu WordPress en el escaneo gratuito y descubre en menos de un minuto qué líneas no cumplen, con el punto exacto en tu tema o page builder.