Le han pedido que se asegure de que un sitio web o una aplicación cumpla con las WCAG. Luego, otro documento menciona la norma EN 301 549. El equipo técnico empieza a intentar averiguar qué estándar deben utilizar y qué es lo que realmente hay que probar.
La confusión es comprensible. Ambos están estrechamente relacionados, pero tienen funciones y ámbitos de aplicación diferentes.
Para los equipos que crean o gestionan productos digitales, esa distinción es importante, especialmente cuando la accesibilidad debe incorporarse a los procesos de diseño, desarrollo, control de calidad y cumplimiento normativo.
¿Qué es la norma EN 301 549?
La norma EN 301 549 es el estándar europeo de requisitos de accesibilidad para productos y servicios de Tecnologías de la Información y la Comunicación (TIC).
Su alcance es más amplio que el de los sitios web. La norma abarca requisitos para tecnologías como sitios web y documentos no web, software y aplicaciones móviles, hardware y otros productos y servicios TIC.
Esto cambia la perspectiva para un equipo de producto.
Si su organización gestiona un servicio digital complejo, la accesibilidad debe tenerse en cuenta en todos los componentes relevantes de dicho servicio, no solo en la página web principal.
Para los equipos técnicos, la norma EN 301 549 proporciona requisitos que pueden incorporarse a las especificaciones, los procesos de adquisición, el desarrollo y las pruebas.
La Comisión Europea explica que esta norma va más allá de los requisitos de las WCAG. Por lo tanto, cumplir con todos los criterios de éxito pertinentes de las WCAG no garantiza automáticamente que se hayan cubierto todos los requisitos de la norma EN 301 549.
¿Qué lugar ocupan las WCAG?
Las WCAG (Pautas de Accesibilidad para el Contenido Web) son el estándar internacional desarrollado por el W3C para la accesibilidad del contenido web.
Los criterios de éxito de las WCAG se organizan en torno a cuatro principios:
- Perceptible
- Operable
- Comprensible
- Robusto
Bajo estos principios se encuentran criterios de éxito evaluables, organizados en tres niveles de conformidad: A, AA y AAA.
En la práctica, estos criterios se traducen en requisitos muy concretos.
Una imagen informativa requiere una alternativa textual adecuada.
El contenido debe tener suficiente contraste.
La funcionalidad debe poder operarse mediante los métodos requeridos por los criterios de éxito aplicables.
Los formularios deben implementarse de manera que la información y las relaciones que los usuarios necesitan puedan determinarse mediante programación cuando así lo exija el criterio pertinente.
El foco del teclado debe ser visible y rastreable.
Los componentes interactivos deben implementarse de modo que las tecnologías de asistencia puedan recibir la información necesaria sobre ellos.
De repente, la "accesibilidad" se convierte en un conjunto de requisitos que un diseñador, un desarrollador y un especialista en control de calidad pueden debatir y probar realmente.
EN 301 549 y WCAG no son lo mismo
Esta es una de las distinciones más importantes que hay que entender.
Las WCAG se centran en la accesibilidad del contenido web. La norma EN 301 549 tiene un alcance más amplio en las TIC e incorpora los requisitos de las WCAG para el contenido web dentro de su estructura, junto con otros requisitos adicionales.
La versión de la norma EN 301 549 actualmente relevante para los requisitos europeos de accesibilidad armonizados utiliza las WCAG 2.1. La Comisión Europea declara que las WCAG 2.2 aún no se utilizan en una norma EN 301 549 armonizada mediante la publicación de su referencia en el Diario Oficial de la Unión Europea.
Esta distinción es importante en 2026.
Pero las WCAG 2.2 ya existen
Las WCAG 2.2 son la versión final más reciente de la familia WCAG, y el W3C recomienda utilizar la última versión cuando las organizaciones desarrollen o actualicen sus políticas y prácticas de accesibilidad.
Las WCAG 2.2 añaden nueve criterios de éxito nuevos en comparación con las WCAG 2.1. Estos incluyen requisitos relacionados con la apariencia del foco, el tamaño mínimo de los objetivos, alternativas a las interacciones de arrastrar, autenticación accesible y evitar la entrada redundante de información en determinadas situaciones.
Desde 2025, las WCAG 2.2 también son una norma internacional ISO: ISO/IEC 40500:2025.
Para un equipo técnico, esto crea una distinción entre la norma europea utilizada para el marco normativo pertinente y la versión de las WCAG recomendada por el W3C para el desarrollo actual de accesibilidad.
El W3C también explica que el contenido que cumple con las WCAG 2.2 también cumple con las WCAG 2.1 y las WCAG 2.0 debido a la forma en que se diseñaron las versiones sucesivas.
¿Qué significa esto para los equipos de producto?
La accesibilidad funciona mejor cuando se integra en los requisitos del producto antes de comenzar el desarrollo.
Tomemos como ejemplo un formulario sencillo de creación de cuenta.
El equipo define los campos y las reglas de validación. UX define la interacción. Diseño prepara los componentes y sus estados. Desarrollo los implementa. QA verifica el resultado.
Si la accesibilidad solo se incorpora al proceso después del lanzamiento, los problemas detectados pueden requerir cambios en varias de estas áreas.
Si los requisitos se definen durante la planificación, el equipo puede discutir las etiquetas, el enfoque, los mensajes de error, el contraste y el comportamiento del teclado desde el principio.
Esto también reduce las situaciones en las que la accesibilidad se convierte en una lista independiente de errores que corregir tras el lanzamiento.
¿Qué deben tener en cuenta los equipos de UX y Diseño?
Un buen sistema de diseño puede evitar que el mismo problema de accesibilidad se repita en decenas de páginas.
Los botones, formularios, ventanas modales, la navegación, los componentes interactivos y los estados de enfoque deben definirse incluyendo los requisitos de accesibilidad en sus especificaciones.
El contraste es un ejemplo evidente.
Pero la accesibilidad no se limita al color.
Los diseñadores también deben considerar cómo los usuarios comprenden la jerarquía de la información, los estados de los componentes, los mensajes de error y las interacciones que no dependen de un único método de entrada.
Un componente puede verse perfecto en un archivo de diseño y aun así generar problemas de accesibilidad tras su implementación.
Por eso, las pruebas de accesibilidad deben continuar en el producto funcional.
¿Qué deben tener en cuenta los equipos de desarrollo?
El HTML semántico y la implementación correcta de los componentes desempeñan un papel directo en la accesibilidad.
Los desarrolladores deben entender qué sucede cuando un usuario deja de lado el ratón e intenta navegar por la interfaz utilizando únicamente el teclado.
Igual de importante es lo que reciben las tecnologías de asistencia.
¿Cuál es el nombre accesible del componente?
¿Qué función tiene?
¿En qué estado se encuentra?
¿Qué sucede con el foco cuando se abre o cierra un modal?
¿Se puede completar el formulario realmente?
Estas preguntas son mucho más útiles durante el desarrollo que el requisito vago de que “la página debe ser accesible”.
¿Qué deben tener en cuenta los equipos de control de calidad?
Las pruebas automatizadas son útiles, pero no pueden evaluar todos los requisitos de accesibilidad por sí solas.
El W3C explica que las WCAG están diseñadas para que la conformidad pueda evaluarse mediante una combinación de evaluación automatizada y criterio humano.
Ahí es donde las pruebas manuales siguen siendo importantes.
El control de calidad puede probar la navegación por teclado, el orden de enfoque y el comportamiento de los componentes. Las pruebas con tecnologías de asistencia añaden otra capa de validación.
Mientras tanto, las pruebas automatizadas pueden identificar rápidamente ciertos problemas repetibles en muchas páginas.
Combinar estos métodos ofrece una imagen mucho más útil que depender de una única puntuación.
Una puntuación de accesibilidad no cuenta toda la historia
El panel muestra 92/100. Suena bien.
Pero, ¿qué sucede si el problema restante está en el botón que completa un pago?
El impacto en el usuario no es necesariamente proporcional al número total de errores.
Es por eso que los equipos también deberían considerar el la gravedad de un problema, el componente afectado y dónde aparece dentro de un recorrido crítico del usuario.
El proceso de pago, la autenticación, la creación de cuentas, los pagos y las reservas son ejemplos donde una sola barrera de accesibilidad puede impedir que un usuario complete una acción.
Las prioridades de corrección deben tener en cuenta este contexto.
La accesibilidad continúa después del lanzamiento
Un producto digital cambia.
Se añaden nuevas páginas, componentes e integraciones. El equipo de marketing publica contenido nuevo. Se modifica un formulario. La experiencia de pago recibe una actualización.
Una prueba realizada hace seis meses describe el producto tal como existía hace seis meses.
Es por eso que su proceso debe incluir pruebas después de cambios relevantes y el monitoreo de problemas que puedan surgir a medida que el producto evoluciona.
Wawsome puede ayudar a identificar problemas de accesibilidad detectables automáticamente y monitorear la accesibilidad del sitio web a lo largo del tiempo.
¿Cómo debería ser un proceso interno de accesibilidad?
Para un equipo que gestiona continuamente un producto digital, la accesibilidad debe estar presente en múltiples puntos del proceso.
En los requisitos, cuando se define la funcionalidad.
En el sistema de diseño, para los componentes reutilizables.
En el desarrollo y la revisión de código, cuando se implementan dichos componentes.
En el control de calidad (QA), mediante pruebas automatizadas y manuales.
Tras el lanzamiento, mediante el seguimiento y la reevaluación de las áreas que han cambiado.
Esto convierte las normas EN 301 549 y WCAG de estándares abstractos en requisitos concretos, tareas de desarrollo y casos de prueba con las que los equipos realmente pueden trabajar.
Preguntas frecuentes
¿Debo usar WCAG 2.1 o WCAG 2.2?
La norma EN 301 549 utiliza actualmente las WCAG 2.1 en la versión armonizada pertinente a nivel europeo. El W3C recomienda utilizar la versión más reciente de las WCAG y señala que el contenido que cumple con las WCAG 2.2 también cumple con las WCAG 2.1.
Para cumplir con las obligaciones legales, debe verificar la norma específica y el marco regulatorio aplicable al producto o servicio en cuestión.
Si cumplo con las WCAG, ¿significa eso automáticamente que cumplo con la norma EN 301 549?
No. La norma EN 301 549 tiene un alcance más amplio. La Comisión Europea establece explícitamente que cumplir únicamente con todos los criterios de conformidad de las WCAG 2.1 no garantiza la presunción de conformidad con todos los requisitos pertinentes basados en la norma EN 301 549.
¿Puedo probar automáticamente todos los criterios de conformidad de las WCAG?
No. La evaluación de la accesibilidad también requiere comprobaciones que implican el juicio humano. Las pruebas automatizadas son útiles para detectar problemas de forma técnica y coherente, pero no pueden sustituir a la evaluación manual.
¿Cuándo debo evaluar la accesibilidad?
Durante el desarrollo y antes del lanzamiento, y de nuevo tras realizar cambios que puedan afectar a la experiencia del usuario. En el caso de productos que se actualizan con frecuencia, el seguimiento continuo ayuda a los equipos a identificar nuevos problemas a medida que surgen.
¿Por dónde empezar?
Si su equipo gestiona un sitio web existente, comience por comprender qué problemas de accesibilidad se pueden identificar ahora mismo. Los resultados de un análisis inicial pueden servir como punto de partida para priorizar las pruebas y las correcciones posteriores.
Para una evaluación completa, los resultados automatizados deben complementarse con las comprobaciones manuales necesarias para los criterios que no pueden evaluarse de forma automática.