WCAG 2.2, BFSG y la Ley Europea de Accesibilidad: el stack de cumplimiento WordPress para 2026
Tres documentos definen lo que un sitio WordPress tiene que hacer en 2026 para ser legalmente accesible en la Unión Europea: las Web Content Accessibility Guidelines 2.2 del W3C, la Ley de Accesibilidad de la UE (Directiva 2019/882) y la Barrierefreiheitsstärkungsgesetz alemana. No son intercambiables; se apilan. Este artículo es el mapa de implementación.
El texto se vincula con el pilar de servicio headless WordPress donde se describe la superficie técnica, y con la lista patrones SEO para headless WordPress donde varios patrones de accesibilidad también afectan al SEO.
TL;DR
- WCAG 2.2 es la Recomendación actual del W3C, publicada el 2023-10-05.
- La Ley Europea de Accesibilidad se aplica desde el 2025-06-28 en cada Estado miembro.
- La BFSG alemana implementa la EAA en derecho federal en la misma fecha.
- Las exenciones para microempresas existen pero son más estrictas de lo que se asume.
- Las sanciones bajo el parágrafo 37 de la BFSG alcanzan el rango superior de cinco cifras en euros.
Las tres capas, en orden
Tres capas legales y técnicas se apilan para definir la obligación del sitio:
Capa uno, WCAG 2.2 (técnica). El conjunto de criterios de éxito medibles que definen el contenido web accesible. Elaborado por la Web Accessibility Initiative del W3C. WCAG 2.2 fue publicada como Recomendación el 2023-10-05 e incorpora nueve nuevos criterios de éxito sobre WCAG 2.1, incluyendo apariencia del foco, movimientos de arrastre y ayuda consistente.
Capa dos, la Ley Europea de Accesibilidad (UE). Directiva 2019/882, adoptada en 2019, aplicable desde el 2025-06-28. Define qué productos y servicios deben ser accesibles y remite a la norma europea EN 301 549, que incorpora WCAG por referencia. La EAA no dice literalmente “siga WCAG 2.2”; remite a la norma armonizada europea, que actualmente incorpora WCAG 2.1 nivel AA. Las transposiciones nacionales pueden exigir WCAG 2.2.
Capa tres, transposición nacional (Estado miembro). Cada Estado miembro aprueba su propia ley para transponer la EAA. La de Alemania es la BFSG, en vigor en la misma fecha de aplicación de la EAA. Otros Estados miembros transponen con nombres similares y requisitos similares (a veces más altos). El sitio debe cumplir con la ley de transposición en cada mercado en el que vende, no solo en el país de constitución.
El orden importa. WCAG es el umbral técnico. La EAA es el envoltorio legal a nivel UE. La ley nacional es el instrumento local de aplicación. Las auditorías van en este orden: técnica primero, legal después, local al final.
Lo que WCAG 2.2 realmente exige
WCAG 2.2 tiene 86 criterios de éxito repartidos en 13 directrices bajo 4 principios (Perceptible, Operable, Comprensible, Robusto). Tres niveles: A, AA, AAA. El estándar legal y contractual por defecto es AA. AAA es aspiracional y no siempre práctico para sitios con mucho contenido.
Los nueve nuevos criterios en WCAG 2.2 sobre WCAG 2.1:
- Apariencia del foco (AA, nivel AA solo en 2.2)
- Foco no oscurecido mínimo (AA)
- Foco no oscurecido mejorado (AAA)
- Movimientos de arrastre (AA)
- Tamaño de objetivo mínimo (AA, 24 by 24 CSS pixels)
- Ayuda consistente (A)
- Entrada redundante (A)
- Autenticación accesible mínima (AA)
- Autenticación accesible mejorada (AAA)
Para un sitio WordPress que ya apuntaba a WCAG 2.1 AA, el trabajo práctico en 2026 es verificar los nueve nuevos criterios, siendo el tamaño del objetivo y los movimientos de arrastre las brechas más comunes (iconos clicables pequeños, sliders solo arrastrables).
EAA: alcance, exenciones, plazos
La EAA cubre una lista definida de productos y servicios introducidos en el mercado desde el 2025-06-28. La lista relevante para la mayoría de operadores WordPress:
- Servicios bancarios al consumidor.
- Libros electrónicos y software dedicado de lectura.
- Servicios de comunicaciones electrónicas.
- Servicios de acceso a medios audiovisuales.
- Servicios de transporte de pasajeros (interfaces web y móviles).
- Servicios de e-commerce (la categoría general para la mayoría de tiendas WooCommerce).
La directiva define exenciones para microempresas: menos de 10 empleados Y volumen de negocios anual o balance total inferior a 2 millones de EUR. Estas exenciones se aplican a los proveedores de servicios; el umbral para fabricantes de productos es más estricto. La interpretación errónea común es “sitio pequeño, sin reglas”; la regla real es “operador pequeño, obligación más estrecha, exención más estrecha”.
Período transitorio: los contratos de servicio celebrados antes del 2025-06-28 pueden continuar bajo los términos previos a la EAA hasta como máximo el 2030-06-28. Los terminales de autoservicio ya en uso pueden continuar hasta el final de su vida útil, con un techo rígido de 20 años.
BFSG: la implementación alemana
Alemania aprobó la Barrierefreiheitsstärkungsgesetz (Ley de Refuerzo de la Accesibilidad) para transponer la EAA. Entró en vigor el 2025-06-28.
Tres cosas que la BFSG añade a la base de la EAA:
Uno, aplicación a nivel federal. La Bundesanstalt für Arbeitsschutz und Arbeitsmedizin y las autoridades federales de vigilancia del mercado supervisan el cumplimiento. Las estructuras de los Estados miembros varían; en Alemania, la supervisión federal es el mecanismo.
Dos, estructura de sanciones (parágrafo 37, BFSG). Las sanciones por incumplimiento están definidas en el parágrafo 37 de la BFSG. Determinados tipos de infracción atraen multas en el rango superior de cinco cifras en euros por infracción. El incumplimiento repetido o sistémico se acumula.
Tres, requisito de declaración de accesibilidad. El sitio debe publicar una declaración de accesibilidad enlazada desde un lugar localizable (el pie de página es lo convencional). La declaración indica el nivel de conformidad, las excepciones reclamadas y un mecanismo de contacto para reclamaciones de accesibilidad.
Los operadores que venden en Alemania sin constitución alemana siguen estando sujetos a la BFSG cuando sus productos o servicios se introducen en el mercado alemán. La defensa “no soy una empresa alemana” no existe.
Lo que esto significa para un sitio WordPress
El trabajo de implementación se divide en cuatro columnas.
Tema y core. Elija un tema marcado como accessibility-ready en WordPress.org y verifíquelo contra WCAG 2.2 AA. Audite la administración de WordPress, no solo el front-end; la BFSG cubre también la interfaz que usan los empleados si están sujetos a requisitos de empleo inclusivo. El core de WordPress es generalmente consciente de la accesibilidad (el equipo de Accesibilidad está activo) pero los plugins y el código personalizado rompen el umbral con regularidad.
Plugins. Audite la salida front-end de cada plugin activo. Patrones concretos de fallo que vemos auditoría tras auditoría:
- Page builders (Elementor, Divi, WPBakery): emiten
<h1>para el texto hero en cada sección, rompiendo la jerarquía de encabezados. Fallan WCAG 2.4.6 (Encabezados y etiquetas) y 1.3.1 (Información y relaciones). Solución: sobrescribir los niveles de encabezado en el template del tema, o migrar al editor de bloques. - WooCommerce añadir al carrito por defecto en archivos: solo icono con
aria-label, sin texto visible y sin indicador de foco visible. WCAG 2.4.7 (Foco visible) y 2.5.8 (Tamaño mínimo del objetivo, 24×24 píxeles CSS en WCAG 2.2). Solución: ampliar el área clicable a 24×24, anillo de foco visible con contraste 3:1, restaurar texto visible donde sea posible. - Plugins de slideshow (Slick, Owl Carousel, MetaSlider, Smart Slider): sin soporte para teclas de flecha, sin control de pausa en slides con rotación automática. Fallan WCAG 2.2.2 (Pausar, detener, ocultar) y 2.1.1 (Teclado). Solución: sustituir por una cuadrícula estática de imágenes donde sea posible; si es necesario, añadir botones visibles de pausa y anterior/siguiente con etiquetas adecuadas.
- Plugins de formularios (Contact Form 7, Gravity Forms, Ninja Forms): omiten asociaciones
<label for>, usan el placeholder como única etiqueta. Fallan WCAG 1.3.1 y 3.3.2 (Etiquetas o instrucciones). Solución:<label for="id">explícito, mensajes de error víaaria-describedby, campos obligatorios conaria-required="true".
Audite también la administración si la usa personal no técnico.
Contenido y disciplina editorial. La aplicación de WCAG a nivel editorial requiere reglas permanentes: cada imagen necesita texto alternativo, cada enlace texto descriptivo (no “haga clic aquí”), cada jerarquía de encabezados es secuencial, cada vídeo tiene subtítulos, cada PDF incrustado en una página se prueba en sí mismo. El CMS hace posible el cumplimiento técnico; el equipo editorial hace que ocurra de verdad.
Declaración de accesibilidad y mecanismo de reclamación. La declaración es obligatoria en Alemania bajo la BFSG. El mecanismo de reclamación (un correo de contacto o formulario) debe ser funcional, no vestigial. Las reclamaciones sobre accesibilidad deben ser acusadas y atendidas en un plazo razonable.
Por qué headless WordPress no es automáticamente accesible
Una build headless WordPress con un front Astro o Next.js no hereda accesibilidad del origen WordPress. El framework de front-end es responsable del HTML renderizado, del modelo de interacción por teclado, de la gestión del foco y de la semántica ARIA. Elegir el framework correcto ayuda (tanto Astro como Next.js tienen comunidades de accesibilidad fuertes) pero el trabajo debe hacerse de forma explícita.
Según nuestro posición en rings del Tech Radar, Astro 5+ y Next.js 15 están ambos en el anillo Adopt. Ninguno es automáticamente conforme con WCAG 2.2. La auditoría de accesibilidad es un flujo de trabajo separado de la elección del framework.
La build headless compra una cosa: control por ruta sobre el HTML renderizado, lo que hace que los parches de accesibilidad sean aterrizables y predecibles. Una build WordPress monolítica mediada por un page builder pesado es más difícil de remediar cuando el builder es el origen del marcado inaccesible.
Cadencia de auditoría y herramientas
Dos auditorías, dos cadencias:
Automatizada, en cada ejecución de CI. axe-core o pa11y ejecutándose contra una muestra representativa de rutas. Hace fallar la build ante cualquier violación nueva. Captura aproximadamente la mitad de los problemas WCAG; falla la mitad que requiere juicio humano (calidad del alt-text, intención del orden de foco, intención de los landmarks ARIA).
Manual, anualmente más en cambios mayores. Tester de accesibilidad capacitado ejecutando una auditoría WCAG 2.2 AA completa con pruebas de tecnología asistiva (lector de pantalla, control por voz, solo teclado). El resultado es un informe de brechas vinculado a criterios de éxito específicos.
Un sitio que solo ejecuta la auditoría automatizada no es conforme con WCAG 2.2 AA. Un sitio que solo ejecuta la auditoría manual deriva entre revisiones anuales. Ambas son necesarias.
Dónde encaja esto
Este pilar se ancla al clúster del servicio headless WordPress como dimensión de cumplimiento. Para la elección de framework, ver la matriz de decisión Next.js vs Astro. Para riesgos de migración SEO (algunos patrones de accesibilidad afectan también al SEO, en particular la jerarquía de encabezados y el texto de los enlaces), ver la lista de patrones SEO. Para el cumplimiento NIS2 y DORA, que aparecen a menudo en el mismo scorecard de adquisición, ver el artículo dedicado a NIS2 y DORA en WordPress.
