TEST DE ACCESIBILIDAD E-LEARNING
¿Cumplen tus cursos con la Ley Europea de Accesibilidad?
28 de octubre de 2026
CONTENIDO CREADO POR:

Tabla de contenidos
La EN 301 549 es la norma europea que fija los requisitos de accesibilidad de los productos y servicios de tecnologías de la información y la comunicación (TIC). Publicada conjuntamente por CEN, CENELEC y ETSI, es el documento técnico que convierte las pautas de accesibilidad en requisitos exigibles dentro de la Unión Europea, y la referencia habitual en los pliegos de contratación pública. En formación corporativa, es la norma contra la que se evalúa si un LMS, una herramienta de autor o un curso e-learning pueden considerarse accesibles ante un requisito legal o un concurso público.
La elaboran de forma conjunta los tres organismos europeos de normalización: CEN, CENELEC y ETSI, a través de un grupo de trabajo conjunto de factores humanos y accesibilidad electrónica. No es una ley y no la aprueba ningún parlamento: es una norma técnica.
Lo que la convierte en relevante jurídicamente es su condición de norma armonizada. Cuando la Comisión Europea cita la referencia de una norma en el Diario Oficial de la Unión Europea en apoyo de una directiva, cumplir esa norma otorga presunción de conformidad con los requisitos de esa directiva. Es un mecanismo cómodo para todas las partes: el legislador fija el objetivo —que los productos sean accesibles— y la norma concreta cómo se demuestra. Para una empresa, la consecuencia práctica es que puede acreditar el cumplimiento mediante una norma técnica en lugar de tener que interpretar un texto legal.
Ese mecanismo tiene una letra pequeña importante, y es la que explica buena parte de las confusiones que verás más abajo: la presunción solo existe si la norma está citada, y solo para la directiva bajo la que se cita.
La norma no es una lista única de requisitos, sino un conjunto de cláusulas que se aplican según el tipo de producto o servicio. Esta organización es la que permite evaluar un LMS, una app móvil o un documento descargable con criterios distintos. Estas son las diez cláusulas principales y lo que implica cada una en un contexto de formación.
| Cláusula | Qué cubre | Qué implica en e-learning |
|---|---|---|
| 4. Criterios de rendimiento funcional | Qué debe lograr el producto en conjunto: uso sin visión, sin audición, sin habla, con destreza limitada, etc. | Es el filtro de cierre: aunque se cumplan los requisitos técnicos uno a uno, el conjunto tiene que ser usable |
| 5. Requisitos genéricos | Funcionalidad cerrada, biometría y herramientas de autor | Afecta directamente a la herramienta con la que se producen los cursos, no solo al curso |
| 6. Comunicación bidireccional en tiempo real | Texto en tiempo real, identificación de llamada, vídeo y conversación total | Relevante si tu formación incluye sesiones en directo, videoconferencia o tutoría síncrona |
| 7. TIC con capacidades de vídeo | Tecnología de subtítulos y audiodescripción | El reproductor debe soportar subtítulos y audiodescripción, no basta con que el vídeo los tenga |
| 8. Hardware | Partes operables, contraste y alcance en equipos fijos | Normalmente fuera de alcance, salvo formación en quioscos o terminales de planta |
| 9. Web | Contenido web, alineado con las WCAG | El núcleo: el campus del LMS y los cursos publicados en HTML |
| 10. Documentos no web | Documentos, alineado con las WCAG | PDF, presentaciones y materiales descargables. Es la cláusula que más se incumple sin saberlo |
| 11. Software no web | Aplicaciones, alineado con las WCAG | La app móvil del LMS y cualquier reproductor instalable |
| 12. Información sobre productos y servicios | Documentación y servicios de soporte | Manuales, ayuda y soporte deben ser accesibles en los mismos términos que el producto |
| 13. Acceso a servicios de retransmisión y emergencia | Relé y acceso a servicios de emergencia | Fuera de alcance en formación corporativa en la práctica totalidad de los casos |
De esas diez cláusulas, hay tres que concentran casi todo el trabajo de un equipo de L&D: la 9 para lo que se publica en web, la 10 para lo que se descarga y la 11 para lo que se instala. Y conviene subrayar un error frecuente: es muy habitual cumplir la cláusula 9 e incumplir la 10. Una organización puede tener un campus impecable y repartir el material de apoyo en PDF sin etiquetado estructural, sin orden de lectura y sin texto alternativo, lo que deja esos documentos fuera del alcance de un lector de pantalla. A efectos de la norma, eso es un incumplimiento tan real como el de la web.
Las cláusulas 9, 10 y 11 no inventan criterios propios: incorporan las WCAG por referencia. Esa es la razón por la que ambos marcos se citan siempre juntos y también la razón por la que se confunden. La distinción útil es esta: las WCAG dicen cómo tiene que ser el contenido accesible; la EN 301 549 dice qué partes de un producto o servicio TIC deben cumplirlas y qué más hace falta además.
Cada versión de la norma congela una versión concreta de las pautas, y por eso la cuestión de qué versión aplica no es un detalle burocrático: determina qué criterios son exigibles.
| Versión | Fecha | WCAG que incorpora |
|---|---|---|
| V1.1.1 / V1.1.2 | 2014 / 2015 | WCAG 2.0, como anexo |
| V2.1.2 | agosto de 2018 | WCAG 2.1 |
| V3.1.1 | noviembre de 2019 | WCAG 2.1 |
| V3.2.1 | marzo de 2021 | WCAG 2.1 nivel AA |
| V4.1.1 | septiembre de 2026 | WCAG 2.2, con el texto incorporado íntegro |
Datos verificados en octubre de 2026. Esta sección depende de una decisión de la Comisión Europea y conviene comprobarla antes de usarla como referencia: la situación estaba previsto que cambiara a finales de 2026.
La versión con valor jurídico es la V3.2.1, de marzo de 2021, que incorpora las WCAG 2.1 de nivel AA. Su referencia está citada en el Diario Oficial mediante la Decisión de Ejecución (UE) 2018/2048, modificada por la Decisión de Ejecución (UE) 2021/1339, en agosto de 2021, en apoyo de la Directiva (UE) 2016/2102 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.
La V4.1.1 existe pero todavía no otorga presunción de conformidad. Se publicó el 2 de septiembre de 2026 e incorpora las WCAG 2.2 —seis criterios nuevos de nivel A y AA—, rehace los requisitos de preferencias de usuario, actualiza la comunicación en tiempo real y añade en sus anexos los mapeos con la legislación europea de accesibilidad. Pero una norma armonizada no produce efectos hasta que su referencia se cita en el Diario Oficial, y en el momento de redactar esta entrada esa cita no se había publicado. Se esperaba en torno al 30 de noviembre de 2026, con un plazo para la retirada de normas nacionales en conflicto que se extiende hasta mayo de 2028.
Qué hacer mientras tanto. Lo razonable es tratar la V3.2.1 como el mínimo exigible y diseñar contra la V4.1.1. La diferencia entre ambas son los criterios añadidos por las WCAG 2.2, que serán obligatorios en algún momento; incorporarlos ahora evita rehacer el trabajo, y ninguno de ellos empeora la accesibilidad de un curso que ya cumple la versión anterior.
Aquí hay un matiz que casi ningún contenido divulgativo recoge y que puede tener consecuencias prácticas si se da por supuesto. La pregunta es si cumplir la EN 301 549 basta para acreditar la conformidad con la Ley Europea de Accesibilidad —la Directiva (UE) 2019/882—, aplicable desde junio de 2025 y que afecta a productos y servicios dirigidos a consumidores. Las fuentes no coinciden, y conviene conocer las dos posiciones.
El argumento de que no basta se apoya en el artículo 15.1 de esa directiva, que concede presunción de conformidad únicamente a las normas armonizadas cuya referencia se publique en el Diario Oficial en apoyo de esa directiva concreta. La EN 301 549 está citada en apoyo de otra —la de webs del sector público—, de modo que, siguiendo esa lectura, no produce presunción para la EAA y la conformidad debe acreditarse directamente contra los requisitos de su Anexo I. Quienes sostienen esta posición señalan además que, aunque el mandato de normalización correspondiente se adoptó en 2022, a mediados de 2026 no constaba ninguna norma armonizada citada para esa directiva.
El argumento de que sí basta es el que asume buena parte del sector, apoyándose en que la Comisión encargó expresamente la actualización de la norma para dar soporte a la EAA y en que la V4.1.1 incorpora anexos que mapean sus requisitos esenciales. Es una posición razonable, pero descansa en una expectativa: la de que la cita acabe produciéndose.
Qué se deduce de todo esto en la práctica. Mientras la situación no se aclare, lo prudente es:
Esta entrada es divulgativa y no constituye asesoramiento jurídico. Para una decisión concreta sobre el ámbito de aplicación y las obligaciones de tu organización, consulta con asesoría especializada.
En el ordenamiento español la norma aparece por dos vías distintas, y conviene no mezclarlas porque afectan a sujetos diferentes.
Sector público. El Real Decreto 1112/2018 traspuso la Directiva (UE) 2016/2102 y obliga a que los sitios web y las aplicaciones móviles de las entidades del sector público sean accesibles. La referencia técnica es la UNE-EN 301 549, la versión española de la norma, que funciona como criterio de conformidad y aparece de forma sistemática en los pliegos de contratación. Si vendes una plataforma de formación a una administración, esta es la norma por la que te van a preguntar.
Productos y servicios de consumo. El Título I de la Ley 11/2023, de 8 de mayo traspuso la Directiva (UE) 2019/882 y está en vigor desde el 28 de junio de 2025. Afecta a determinados productos y servicios dirigidos a consumidores, con una exención relevante: las microempresas no están sujetas a los requisitos de accesibilidad de esa norma. La determinación de las autoridades de vigilancia corresponde a las comunidades autónomas.
La consecuencia para un equipo de formación es que el nivel de exigencia depende menos del tipo de contenido que de a quién va dirigido: la formación interna de una empresa privada, la que se vende como servicio a consumidores y la que se presta a una administración pública se mueven en tres marcos distintos.
Traducido a decisiones concretas, la norma se materializa en tres sitios: lo que exiges a tus proveedores, cómo produces el contenido y qué declaras públicamente.
La exigencia práctica es que la herramienta genere salida accesible por defecto —HTML semántico, etiquetas ARIA correctas, orden de foco coherente, exportación legible por lectores de pantalla—, porque si cada curso requiere intervención manual en el código después de publicar, el cumplimiento no se sostiene en el tiempo. Tienes el detalle en nuestra guía sobre cómo crear contenido accesible y en el artículo de diseño e-learning accesible, y la visión general en accesibilidad en e-learning.
Una declaración de accesibilidad útil es la que distingue entre lo conforme, lo no conforme y lo exento, con fecha de evaluación y método. Decir «plenamente conforme» cuando no se ha auditado cláusula por cláusula es el error con más riesgo de los tres, porque convierte una laguna técnica en una afirmación falsa. Si quieres una primera medición del estado de tus cursos, puedes empezar por el test de accesibilidad.
Las WCAG son pautas técnicas internacionales que publica el W3C y que se aplican al contenido web. La EN 301 549 es una norma europea que cubre un terreno mucho más amplio —productos y servicios TIC en su conjunto: hardware, software, documentos, comunicación en tiempo real y documentación de soporte— y que, para la parte web, incorpora las WCAG por referencia. Dicho de otro modo: las WCAG dicen cómo tiene que ser un contenido accesible y la EN 301 549 dice qué partes de un producto o servicio TIC deben cumplirlas y qué más hace falta además. La segunda diferencia es jurídica y es la que suele importar: las WCAG no son exigibles por sí mismas en la Unión Europea, mientras que la EN 301 549, al ser una norma armonizada citada en el Diario Oficial, sí funciona como referencia de conformidad.
A fecha de redacción de esta entrada, la versión con valor jurídico es la V3.2.1 (marzo de 2021), que incorpora las WCAG 2.1 de nivel AA y está citada en el Diario Oficial de la Unión Europea mediante la Decisión de Ejecución (UE) 2018/2048, modificada por la (UE) 2021/1339. La V4.1.1, publicada el 2 de septiembre de 2026 e incorporando ya las WCAG 2.2, existe pero todavía no está citada, y hasta que lo esté no otorga presunción de conformidad. La cita depende de una decisión de la Comisión Europea y se esperaba en torno al 30 de noviembre de 2026. La recomendación práctica: cumplir la V3.2.1 como mínimo exigible y diseñar contra la V4.1.1, porque la diferencia entre ambas son seis criterios de las WCAG 2.2 que tarde o temprano serán obligatorios.
No automáticamente, y conviene saberlo porque es una confusión extendida. El artículo 15.1 de la Directiva (UE) 2019/882 concede presunción de conformidad únicamente a las normas armonizadas cuya referencia se publique en el Diario Oficial para esa directiva, y la EN 301 549 está citada bajo otra: la Directiva (UE) 2016/2102, de accesibilidad de los sitios web del sector público. Hay análisis jurídicos que sostienen que, por tanto, no otorga esa presunción para la EAA y que la conformidad debe acreditarse directamente contra los requisitos de su Anexo I; y hay fuentes del sector que dan por hecho lo contrario. La lectura prudente es tratar las pruebas contra la EN 301 549 como evidencia de soporte y no como certificado, y no afirmar «plenamente conforme» en una declaración de accesibilidad. Esta entrada es divulgativa y no sustituye al asesoramiento jurídico.
Tres cosas concretas. La primera, documentación de conformidad: un informe que indique versión de la norma evaluada, fecha, alcance y resultado cláusula por cláusula, no una declaración genérica de «somos accesibles». La segunda, que cubra las tres cláusulas que te afectan: la 9 para el contenido web del curso y del campus, la 10 para los materiales descargables —PDF, presentaciones— y la 11 para la aplicación móvil, porque es habitual cumplir la 9 e incumplir las otras dos. Y la tercera, que la herramienta genere salida accesible por defecto: HTML semántico, etiquetas ARIA correctas, orden de foco coherente y exportación SCORM legible por lectores de pantalla. Si corregir la accesibilidad exige tocar el código a mano después de publicar, el cumplimiento no es sostenible en un equipo de L&D.
Conoce la herramienta de autor nº1 del mercado
Pruébalo gratis Solicita una demo
