La nueva versión de EN 301 549 va más allá de las WCAG 2.2

Para quienes trabajamos habitualmente con accesibilidad web, documentos y aplicaciones, probablemente el cambio más reconocible de la nueva versión publicada EN 301 549 V4.1.1, de septiembre de 2026, sea la actualización de WCAG 2.1 a WCAG 2.2.

Y no es un cambio menor. Las cláusulas 9, 10 y 11 incorporan, cuando corresponde, los nuevos criterios de nivel A y AA de WCAG 2.2:

• Focus not obscured (minimum) (foco no oculto [mínimo])
• Dragging movements (movimientos de arrastre)
• Target size (minimum) (tamaño del objetivo [mínimo])
• Consistent help (ayuda consistente)
• Redundant entry (entrada redundante)
• Accessible authentication (minimum) (autenticación accesible [mínimo])

Al mismo tiempo, el apartado correspondiente a Parsing (procesamiento) pasa a quedar vacío tras la eliminación de este criterio en WCAG 2.2.

Pero, después de comparar EN 301 549 V4.1.1 con EN 301 549 V3.2.1, de marzo de 2021, creo que quedarse ahí sería perderse algunos de los cambios más interesantes.

Porque actualizar una metodología de evaluación de V3.2.1 a V4.1.1 no consiste simplemente en sustituir WCAG 2.1 por WCAG 2.2. Cambia también qué consideramos parte de la tecnología de la información y la comunicación (TIC) que evaluamos, cómo determinamos qué requisitos son aplicables y qué evidencia podemos utilizar para demostrar su conformidad.

Los criterios funcionales pasan a formar parte de la evaluación

Uno de los cambios que puede pasar más desapercibido está en la cláusula 4.

La versión anterior contiene once declaraciones de rendimiento funcional (functional performance statements) relacionadas con necesidades como la ausencia o limitación de visión, audición, capacidad vocal, manipulación, alcance o determinadas capacidades cognitivas. Sin embargo, el anexo C indica expresamente que esta cláusula es informativa y no contiene requisitos que deban probarse.

La nueva versión cambia el planteamiento. Pasa a denominarlos criterios de rendimiento funcional (Functional Performance Criteria) y, aunque 4.1 continúa siendo informativo, los apartados 4.2.1 a 4.2.11 utilizan shall, que identifica una obligación, y cuentan con procedimientos de evaluación en C.4.2.

¿Y esto qué significa en la práctica?

La nueva versión permite superar cada uno de esos criterios de dos maneras:

• La primera consiste en cumplir todos los requisitos técnicos identificados para ese criterio en el anexo B con una P o una S. La P indica una relación primaria: el requisito contribuye directamente a satisfacer el criterio funcional. La S indica una relación secundaria: ofrece un apoyo parcial que puede resultar útil para algunas personas o en determinadas situaciones.
• La segunda posibilidad consiste en aportar evidencia directa de que la TIC proporciona el resultado funcional exigido.

Por tanto, la accesibilidad funcional deja de actuar únicamente como contexto para entender los requisitos técnicos y entra de forma mucho más directa en el modelo de evaluación.

“No aplica” y “no puedo utilizar esta prueba” no son lo mismo

Quizá uno de los cambios más relevantes para quienes hacemos evaluaciones esté precisamente en cómo la nueva versión formaliza la aplicabilidad y la demostración de conformidad.

La nueva versión define expresamente conceptos como requisito aplicable, escenario aplicable y prueba aplicable. También establece que todos los requisitos determinan por sí mismos su alcance, una característica que la norma denomina self-scoping.

Esto significa que cada requisito comienza con una precondición que determina si resulta aplicable a la TIC evaluada. Si la precondición es verdadera, debe cumplirse el requisito; si es falsa, el requisito no resulta aplicable.

Pero hay otra diferencia especialmente interesante en 14.1: el papel del anexo C.

En la versión anterior, la conformidad se vincula a superar la prueba correspondiente del anexo C. En la nueva versión, las pruebas del anexo C (que sigue siendo normativo) se consideran medios suficientes para demostrar la conformidad, pero se admiten expresamente otros enfoques de evaluación cuando estén justificados.

Es un matiz importante: el anexo C proporciona una vía suficiente, pero no necesariamente la única vía posible para evaluar un requisito.

Esto se entiende mejor con un ejemplo. Imaginemos que, por las características de una determinada tecnología, no se cumplen las premisas necesarias para ejecutar la prueba prevista en el anexo C. Eso no significa automáticamente que el requisito sea “no aplicable”.

Son dos cuestiones distintas. Si no se cumple la precondición del requisito, el requisito no aplica. Si el requisito sí aplica, pero no pueden cumplirse las premisas de una determinada prueba, ese enfoque de evaluación no es válido y habrá que utilizar otro.

De hecho, la nueva versión deja de utilizar el resultado excepcional not testable (no comprobable) que aparecía en la versión anterior. Cuando no se cumplen las premisas necesarias para una prueba, el resultado indica Test approach cannot be used: el enfoque de evaluación no puede utilizarse y será necesario emplear otro.

Los overlays también entran en la evaluación

Hay otro detalle de la nueva versión que me parece especialmente interesante: el tratamiento explícito de las herramientas de superposición (overlays), los complementos y otros añadidos.

La nueva versión establece que estos elementos pasan a formar parte de la TIC evaluada. Es la combinación completa la que debe satisfacer los requisitos aplicables.

Esto permite hacer una distinción importante. La norma no está diciendo que haya que realizar necesariamente una auditoría independiente del overlay como si fuera un producto separado. Lo que impide es dejarlo fuera del perímetro de la evaluación cuando forma parte de la solución que estamos evaluando.

Pensemos, por ejemplo, en un overlay que modifica una página para intentar resolver determinados problemas de accesibilidad. Si modifica la gestión del foco, incorpora nuevos controles, cambia nombres accesibles o altera el comportamiento mediante teclado, esas modificaciones también forman parte del resultado que evaluamos.

Si consigue corregir una barrera, esa corrección forma parte del resultado. Pero, si al hacerlo introduce otra, el nuevo problema también.

En la práctica, por tanto, evaluar la combinación puede acabar revelando problemas atribuibles específicamente al propio overlay, aunque el objeto de la evaluación siga siendo la TIC completa.

Y quizá esto añada una preocupación que antes no existía para las empresas que desarrollan este tipo de soluciones. Ya no tendrán solo que convencer al cliente de cuántos problemas puede corregir su herramienta: también tendrán que asegurarse de que su intervención no introduce nuevas barreras que hagan que el resultado final incumpla requisitos aplicables y puedan terminar generando incidencias o reclamaciones.

Que la nueva versión mencione los overlays no significa, por tanto, que les otorgue una vía especial para conseguir conformidad. Significa algo bastante más sencillo: si forman parte de la solución, también forman parte de lo que se evalúa y podrían formar parte también de las barreras encontradas.

EN 301 549 sigue siendo más que WCAG

La actualización a WCAG 2.2 tampoco debería hacernos olvidar que EN 301 549 contiene requisitos propios.

La nueva versión ofrece algunos ejemplos interesantes precisamente en los ámbitos con los que trabajamos habitualmente. Las preferencias de usuario, que la versión anterior ya contemplaba para software, se extienden ahora también a web en 9.7 y a documentos no web en 10.7.

También cambia la forma en que algunos criterios WCAG se adaptan a cada tecnología. No todo criterio que existe para web se traslada automáticamente de la misma manera a documentos o software. Consistent help (ayuda consistente), por ejemplo, se incorpora donde corresponde, pero queda vacío para software no web.

Es una diferencia relevante cuando hablamos de metodologías de evaluación. Evaluar la conformidad con EN 301 549 no consiste simplemente en ejecutar una auditoría WCAG y cambiar el nombre del informe. Hay que atender a las precondiciones, adaptaciones y requisitos adicionales que establece la propia norma para cada tipo de TIC.

Actualizar la metodología, no solo la lista de comprobación

Por supuesto, la nueva versión contiene muchos otros cambios. La revisión afecta a comunicaciones, hardware, información sobre productos y servicios y a los anexos que relacionan la norma con el marco regulatorio europeo.

Pero, para quienes trabajamos principalmente evaluando webs, documentos y aplicaciones, creo que hay una consecuencia más inmediata: pasar de V3.2.1 a V4.1.1 debería implicar algo más que añadir seis criterios de WCAG 2.2 a nuestras listas de comprobación.

Habrá que revisar:

• ¿Cómo determinamos qué requisitos son aplicables?
• ¿Cómo documentamos las evidencias?
• ¿Cómo incorporamos los criterios funcionales a la evaluación?
• ¿Qué hacemos cuando el método previsto en el anexo C no resulta adecuado?
• ¿Qué consideramos exactamente parte de la TIC evaluada, incluidos los complementos y overlays?

WCAG 2.2 cambia algunos requisitos; V4.1.1 cambia también, de una forma bastante más sutil, cómo debemos razonar y justificar una evaluación de conformidad. Y quizá sea ese el cambio al que más atención deberíamos prestar.

Ainara Blanco 
Especialista en Accesibilidad Digital
Auditoría, consultoría y desarrollo accesible