EN 301 549 v4.1.1 pasó a WCAG 2.2: qué tienes que construir hoy y qué sigue siendo ley
El estándar europeo de accesibilidad EN 301 549 v4.1.1 se publicó el 2 de septiembre de 2026 y mueve la referencia técnica de WCAG 2.1 AA a WCAG 2.2 AA, pero todavía no es la norma legal. Qué cambios llegan, cuáles ya te obligan hoy y cómo separar la hoja de ruta de ingeniería del estándar jurídico.
EN 301 549 v4.1.1 pasó a WCAG 2.2: qué tienes que construir hoy y qué sigue siendo ley
EN 301 549 v4.1.1 se publicó el 2 de septiembre de 2026 y mueve el estándar técnico europeo de accesibilidad de WCAG 2.1 Level AA a WCAG 2.2 Level AA, pero todavía no es la referencia legal: hasta que la Comisión Europea lo cite en el Diario Oficial de la UE, la norma que sigue contando es la v3.2.1 de 2021, basada en WCAG 2.1 AA. La lectura correcta es una división de trabajo: audita y reporta contra WCAG 2.1 AA hoy, construye y prueba contra WCAG 2.2 AA y la nueva cláusula 9.7 desde este sprint.
La confusión ya circula: consultoras anuncian que "la EAA ahora exige WCAG 2.2" mientras los equipos siguen archivando auditorías contra WCAG 2.1 como si nada hubiera cambiado. Esto es lo que cambió, lo que ya te obliga y lo que todavía no.
Qué cambió el 2 de septiembre de 2026
ETSI, CEN y CENELEC adoptaron el texto el 24 de agosto de 2026 y lo publicaron el 2 de septiembre: 276 páginas que se convierten en la edición técnica vigente de EN 301 549, después de la v3.2.1. Los cambios que afectan a quien construye sitios web son cuatro:
- Las cláusulas 9 (web), 10 (documentos no-web) y 11 (software) pasan a referenciar WCAG 2.2. Para páginas web eso significa todos los criterios Level A y AA de WCAG 2.2: seis nuevos respecto al punto de partida de 2.1.
- El criterio 4.1.1 Parsing queda marcado como "Void", porque WCAG 2.2 lo eliminó. No significa que el DOM roto sea aceptable; significa que ya no es un criterio con el que se audita.
- Se reestructuran las preferencias de usuario en tres cláusulas paralelas: 9.7 (páginas web), 10.7 (documentos) y 11.7 (software). Es un requisito que no existe en WCAG.
- Se añaden los anexos de mapeo: ZA (Directiva de Accesibilidad Web) y ZB (European Accessibility Act), más un Clause A.2 para evaluaciones por producto. La cláusula 6.2 sobre texto en tiempo real se revisa a fondo: ahí el impacto es telecomunicaciones y hardware.
La última vez que hablamos de la evolución de las normas fue mirando hacia adelante, con WCAG 3.0 en borrador. WCAG 3.0 sigue sin fecha. Esto, en cambio, ya está publicado.
Dos cronologías que tu equipo no debe mezclar
Este es el punto que separa una conversación de compliance seria de un titular mal traducido. La ingeniería y la ley van en dos tiempos distintos:
| Hoy, hasta que se cite en el DOUE | Después de la citación y la transposición nacional | |
|---|---|---|
| Referencia legal | EN 301 549 v3.2.1 (2021) → WCAG 2.1 Level AA | EN 301 549 v4.1.1 → WCAG 2.2 Level AA |
| Qué tiene que probar tu auditoría | WCAG 2.1 AA más el Anexo I de la Directiva | Cláusula 9 completa: los seis criterios nuevos más 9.7 |
| Presunción de conformidad (art. 15 EAA) | No existe: ninguna norma armonizada está citada en apoyo de la Directiva (UE) 2019/882 | Se activa al producirse la citación |
| Lenguaje correcto en el informe | "Probado contra cláusula 9 de EN 301 549, fecha, reviewer" | "Conforme con EN 301 549 v4.1.1" |
Hitos según la propia norma: adopción el 24 de agosto de 2026, publicación el 2 de septiembre, anuncio nacional (doa) el 30 de noviembre de 2026, publicación nacional el 31 de mayo de 2027 y retirada de normas en conflicto el 31 de mayo de 2028.
Sobre la citación hay que ser honestos con la evidencia: Deque afirma que v4.1.1 va "en torno al 30 de noviembre de 2026", fecha que coincide con el doa de la norma, pero el análisis jurídico escéptico lleva meses señalando que ninguna fecha de citación para la EAA tiene una fuente primaria detrás. Trabaja con ella como escenario probable, no como plazo de release.
Y hay un detalle que acelera las cosas en la dirección contraria: en algunos países la ley nacional referencia EN 301 549 sin número de versión. Cuando eso ocurre, una versión recién publicada puede convertirse en el estándar operativo sin que se apruebe legislación nueva. Esperar a la citación no es la postura conservadora que parece.
Los seis criterios nuevos, traducidos a cambios de código
Aquí es donde el estándar deja de ser un documento legal y toca tu backlog. Patrones que hemos corregido una y otra vez en auditorías:
| Criterio | Cómo se rompe en proyectos reales | Lo que implementamos |
|---|---|---|
| 2.4.11 Focus No Oculto (Mín.) AA | El header sticky o el banner de cookies se comen el foco al navegar con Tab | scroll-margin-block en anclas, foco visible real con :focus-visible y un recorrido manual de Tab por cada flujo crítico |
| 2.5.7 Movimientos de Arrastre AA | Filtros de precio, sliders de rango y carruseles que solo responden al ratón o al arrastre | Alternativa de un puntero: input type="range", botones +/-, orden con botones accesibles |
| 2.5.8 Tamaño del Objetivo (Mín.) AA | Chips, swatches y steppers de checkout en móvil por debajo de 24×24 px | min-height/min-width de 24 px o padding de separación; la excepción aplica a enlaces en línea |
| 3.2.6 Ayuda Consistente A | El chat flotante y el enlace de "ayuda" cambian de sitio entre páginas | Un único componente de ayuda, mismo orden relativo en todas las plantillas |
| 3.3.7 Entrada Redundante A | Formularios multi-paso que repiten dirección, teléfono o datos de facturación | Prellenar o permitir seleccionar lo ya enviado en el mismo proceso |
| 3.3.8 Autenticación Accesible (Mín.) AA | Campos OTP con "pegar" bloqueado y captchas que exigen memoria o resolución de puzzles | Habilitar copy-paste, no interferir con gestores de contraseñas, alternativa a los tests cognitivos |
Ninguno de los seis es exótico: todos atacan el mismo mal, interfaces dibujadas con div que ignoran lo que el usuario ya trae encima. Por eso la vía sigue siendo la de adiós ARIA, HTML nativo: elemento nativo primero, JavaScript solo donde aporta.
La cláusula 9.7: la regla que no está en WCAG
Esto es lo que casi todo el mundo se pierde al leer la nota de prensa. La v4.1.1 no solo absorbe los seis criterios de WCAG 2.2; añade un requisito propio para páginas web que no tiene equivalente en WCAG: no bloquees ni sobrescribas los modos del navegador que aplican la configuración de accesibilidad del usuario, salvo que sea esencial para la función.
La nota 5 de la cláusula da la lista concreta: filtros de color, contraste, tamaño del texto, tamaño del punteroy cursor de texto. Y la propia norma advierte que limita el uso de especificaciones que sobrescriben ajustes del usuario de forma explícita —nombra la propiedad CSS forced-color-adjust— a los casos en que sea esencial.
En cristiano: no te piden construir nada, te piden dejar de romper lo que el usuario ya encendió. Es el requisito más barato de todo el estándar si tu CSS está escrito en rem y sin !important de por medio.
| Preferencia del sistema | Palanca CSS | Comprobación manual |
|---|---|---|
| Colores forzados / alto contraste | @media (forced-colors: active), evitar forced-color-adjust: none | Activar alto contraste en el sistema: bordes, focos y estados no desaparecen |
| Tamaño de texto | Sizing en rem/em, sin alturas fijas en texto | Zoom al 200%: sin texto cortado ni scroll horizontal para leer |
| Esquema de color | color-scheme: light dark más @media (prefers-color-scheme: dark) | Con oscuro activo, controles y scrollbars no quedan en blanco |
| Contraste elevado | @media (prefers-contrast: more) | Subir contraste: anillos y bordes se refuerzan, no se pierden |
| Movimiento reducido | @media (prefers-reduced-motion) | Sin parallax ni autoplay de vídeo con la preferencia activa |
Lo que ya te obliga hoy, aunque el nuevo texto no esté citado
La obligación no nace de la norma técnica, nace de la Directiva, y está vigente desde el 28 de junio de 2025; la norma solo define cómo se presume cumplida. Mientras v3.2.1 siga citada, hay que pasar WCAG 2.1 AA más los criterios de WCAG 2.2 ya presentes en el día a día: 1.4.4 Resize Text (200% sin pérdida), 1.4.10 Reflow (320 px sin scroll bidimensional) y 1.4.12 Text Spacing.
El clima regulatorio no da para dormirse. La autoridad neerlandesa ACM comprobó en su revisión de marzo de 2026 que en el 61% de las grandes tiendas online era imposible hacer un pedido con tecnología asistiva, y prevé pasar a la ejecución formal en la segunda mitad de 2026. Las sanciones las fija cada estado miembro y los rangos publicados van desde 60.000 € en Irlanda hasta 100.000 € en Alemania y hasta 300.000 € por infracción en Francia. Para el detalle de los patrones de fallo que más aparecen, está nuestro análisis de enforcement del EAA con frameworks de priorización.
Cómo lo secuenciamos en proyectos reales
Nuestra regla, y es una opinión, no una cita: no compres una auditoría contra WCAG 2.1 y la presentes como evidencia lista para 2027. Las cuatro fases que ejecutamos:
- Inventario y mapa de aplicabilidad (1 semana). Web, apps en web views, PDFs y Office, autenticación y canales de ayuda, con la justificación de por qué aplica cada cláusula: la norma se condiciona con "Where ICT…".
- Gap analysis a nivel de cláusula contra el texto final (2 semanas). No te quedes en los seis criterios: 9.7, 10.7, Annex ZB y el Clause A.2 entran en el mismo análisis.
- Reglas de design system (continuo). Foco visible y no oculto, tamaño de objetivo, alternativas al arrastre, ayuda consistente, entrada redundante, autenticación accesible y soporte de preferencias de plataforma. Esto es trabajo de sistema, no de página.
- Criterios de aceptación y testing (cada release). Automatizado más teclado, screen reader, zoom, reflow y prueba de preferencias una a una. Un escaneo automático no valida ninguno de los criterios nuevos: la norma exige evaluación por tareas.
El resultado de las fases 1 y 2 es lo que te permite defender una posición con fecha, reviewer y evidencia archivada. Y si el tema te interesa a nivel de negocio, la accesibilidad como ventaja competitiva explica por qué el coste de esperar siempre es mayor que el de anticiparse.
Preguntas frecuentes
¿Debo migrar todo a WCAG 2.2 ahora? Sí para construcción y diseño; no todavía para afirmaciones de cumplimiento. Construir contra 2.2 AA es la decisión barata ahora y será obligatoria con la citación. Reportar "conforme con v4.1.1" antes de tiempo es una afirmación que no se puede sostener.
¿Sustituye esto a WCAG 3.0? No. WCAG 3.0 sigue en borrador con su modelo de puntuación graduada y niveles Bronce/Plata/Oro. V4.1.1 es el salto de 2.1 a 2.2; 3.0 es otra conversación, y hablarla demasiado pronto solo diluye el trabajo que hay que hacer este trimestre.
Preguntas Frecuentes
¿WCAG 2.2 es obligatorio en la UE ahora mismo?
No como referencia legal todavía. EN 301 549 v4.1.1 se publicó el 2 de septiembre de 2026 e incorpora WCAG 2.2 Level AA, pero hasta que la Comisión Europea lo cite en el Diario Oficial de la UE no da presunción de conformidad. Mientras tanto, la referencia sigue siendo EN 301 549 v3.2.1 (2021), basada en WCAG 2.1 Level AA. En la práctica: audita contra 2.1, construye contra 2.2.
¿Cuándo entra en vigor EN 301 549 v4.1.1?
La norma ya está publicada (adopción el 24 de agosto de 2026, publicación el 2 de septiembre de 2026), pero su efecto jurídico llega en tres pasos: citación en el Diario Oficial de la UE —Deque reporta que va en torno al 30 de noviembre de 2026, aunque ninguna fecha tiene respaldo de fuente primaria—, anuncio nacional (doa) el 30 de noviembre de 2026, publicación como norma nacional el 31 de mayo de 2027 y retirada de normas en conflicto el 31 de mayo de 2028.
¿Qué es la cláusula 9.7 de preferencias de usuario?
Es el requisito nuevo de EN 301 549 v4.1.1 que exige que una web page no bloquee ni sobrescriba los modos del navegador que aplican la configuración de accesibilidad del sistema (filtros de color, contraste, tamaño del texto, tamaño del puntero y cursor de texto), salvo que sea esencial para la función. No es un criterio de WCAG: es un requisito propio del estándar europeo y se satisface con CSS, no con JavaScript.
