Durante años, la accesibilidad web fue en la mayoría de las empresas una casilla de «buenas prácticas»: algo que estaba bien tener, que quedaba bonito en la propuesta de diseño y que se recortaba en cuanto apretaba el calendario. Desde el 28 de junio de 2025 eso ha dejado de ser cierto. La European Accessibility Act (EAA) —la Directiva 2019/882, transpuesta en España a través de la Ley 11/2023— convierte la accesibilidad digital en una obligación legal exigible, con régimen sancionador incluido, para una parte enorme del comercio y los servicios digitales que operan en la Unión Europea.
Si tienes un ecommerce, una app, un servicio de banca, telecomunicaciones o transporte, o simplemente vendes a consumidores dentro de la UE, esto te afecta aunque tu empresa esté fuera de Europa. Y no es una cuestión de marketing ni de imagen: hablamos de multas, de retirada de productos del mercado y, en 2026, de las primeras demandas que ya están llegando a los tribunales europeos. En este artículo lo desmenuzamos desde el punto de vista de quien tiene que implementarlo: qué obliga la ley exactamente, a quién, qué exige a nivel técnico (WCAG 2.1 AA y la norma EN 301 549) y cómo montar un plan de cumplimiento realista sin frenar tu roadmap.
1. Qué es la EAA y por qué 2025 lo cambia todo
La European Accessibility Act es la Directiva (UE) 2019/882 sobre los requisitos de accesibilidad de determinados productos y servicios. Su objetivo es armonizar las reglas de accesibilidad en los 27 Estados miembros para que un producto o servicio digital accesible en un país lo sea en todos, evitando el laberinto de normativas nacionales que existía antes. Los 27 países han transpuesto ya la directiva a su legislación nacional, y la aplicación efectiva arrancó el 28 de junio de 2025.
1.1 De directiva europea a ley española
Una directiva europea no se aplica directamente: cada Estado la incorpora a su ordenamiento. En España, la transposición se ha hecho principalmente a través de la Ley 11/2023, de 8 de mayo, que traslada la Directiva 2019/882 en materia de accesibilidad de determinados productos y servicios. A su lado convive el Real Decreto 193/2023, de 21 de marzo, que regula las condiciones básicas de accesibilidad y no discriminación de las personas con discapacidad para el acceso y utilización de los bienes y servicios a disposición del público.
La distinción importa porque marcan calendarios distintos. La obligación central que nace de la EAA —la que afecta a ecommerce, banca electrónica, comercio de servicios digitales, e-books o billetaje de transporte— es exigible desde el 28 de junio de 2025. El Real Decreto 193/2023, más amplio en su ámbito de «bienes y servicios a disposición del público», fija plazos propios para determinados portales y aplicaciones del sector privado: 1 de enero de 2029 para los nuevos y 1 de enero de 2030 para los ya existentes. No mezcles ambos calendarios: si vendes online a consumidores, tu fecha de referencia es junio de 2025, no 2029.
1.2 Fechas clave que debes tener en el calendario
Hay tres hitos que conviene fijar. Primero, el 28 de junio de 2025: entra en vigor la obligación. Todo producto nuevo puesto en el mercado y todo servicio nuevo prestado a consumidores debe cumplir desde ese día. Segundo, el 28 de junio de 2030: es el fin del periodo transitorio para los servicios que ya se venían prestando antes de junio de 2025; hasta esa fecha se les da margen para adaptarse, pero no es una barra libre indefinida. Tercero, los contratos de servicio firmados antes de junio de 2025 pueden mantenerse sin cambios como muy tarde hasta junio de 2030. En la práctica, para cualquier proyecto que estés arrancando hoy no existe periodo de gracia: nace con la obligación puesta.
2. A quién obliga la EAA (y quién queda exento)
El error más común que vemos es pensar «esto es como la accesibilidad del sector público, a mi empresa privada no le aplica». Es justo al revés respecto a la normativa anterior: a diferencia de directivas previas centradas en administraciones, la EAA apunta directamente a empresas privadas que venden a consumidores.
2.1 Sectores y productos dentro del ámbito
Entre los servicios afectados están el comercio electrónico, los servicios bancarios para consumidores, las comunicaciones electrónicas, el acceso a servicios de medios audiovisuales, elementos de transporte de pasajeros (webs, apps, billetaje y terminales), y los libros electrónicos. En productos, la lista incluye ordenadores y sistemas operativos de consumo, terminales de autoservicio como cajeros y máquinas expendedoras de billetes, lectores de libros electrónicos y equipos terminales de telecomunicaciones. Si tu negocio encaja en cualquiera de estos ámbitos, la accesibilidad de tu web, tu app y tus canales de atención al cliente deja de ser opcional.
2.2 El alcance es extraterritorial
Aquí está uno de los puntos que más sorprende a los equipos técnicos: la EAA no se limita a organizaciones con sede en la UE. Si ofreces productos o servicios a consumidores dentro de la Unión, se espera que cumplas, aunque tu central esté en Estados Unidos, Reino Unido o cualquier otro sitio. El criterio es el mercado al que vendes, no dónde tienes registrada la sociedad. Es exactamente la misma lógica de alcance que ya conocemos del RGPD, y de hecho hay quien llama a la EAA «el nuevo RGPD de la accesibilidad».
2.3 La exención de microempresas: pequeña y con matices
Existe una exención, pero es limitada y conviene entenderla bien. Las microempresas que prestan servicios —definidas como aquellas con menos de 10 empleados y un volumen de negocio o balance anual inferior a 2 millones de euros— quedan exentas de las obligaciones de la EAA para los servicios. Sin embargo, esa exención no se aplica a los productos: una microempresa que fabrica o distribuye un producto cubierto sigue obligada. Y ojo con confiar tu estrategia a este umbral: en cuanto superas los 10 empleados o los 2 millones de euros, la exención desaparece y la obligación es plena. Diseñar tu plataforma para ser accesible desde el principio es mucho más barato que reconstruirla cuando cruzas el umbral.
3. Qué exige técnicamente: WCAG 2.1 AA y EN 301 549
La ley habla de «requisitos de accesibilidad», pero no reinventa la rueda técnica. El estándar de referencia bajo la EAA es WCAG 2.1 en su nivel AA, las Web Content Accessibility Guidelines del W3C. En el plano europeo, la norma armonizada es la EN 301 549 —en su versión actual v3.2.1— que incorpora íntegramente WCAG 2.1 nivel AA y añade requisitos para un abanico más amplio de tecnologías (hardware, apps móviles, documentación, reproductores de vídeo o contenido de terceros integrado). Cumplir con EN 301 549 es el camino más directo para demostrar conformidad con la EAA.
3.1 Los cuatro principios POUR
WCAG se organiza en torno a cuatro principios que se recuerdan por el acrónimo POUR: Perceptible (la información y los componentes deben poder percibirse: texto alternativo en imágenes, subtítulos, contraste suficiente), Operable (la interfaz debe poder manejarse: todo accesible por teclado, sin trampas de foco, con tiempos suficientes), Comprensible (contenido e interfaz legibles y predecibles: lenguaje claro, mensajes de error explicados) y Robusto (el código debe ser válido y compatible con tecnologías de asistencia presentes y futuras, como los lectores de pantalla). Cada criterio de conformidad de WCAG cuelga de uno de estos cuatro principios.
3.2 Los criterios que más se incumplen
En nuestras auditorías, el 80% de los problemas se concentra en un puñado de fallos repetidos. El contraste insuficiente entre texto y fondo (WCAG exige un ratio mínimo de 4.5:1 para texto normal) es el más habitual y, a la vez, el más barato de corregir. Le siguen la falta de texto alternativo en imágenes informativas, los formularios sin etiquetas asociadas ni mensajes de error accesibles, la imposibilidad de navegar con teclado (menús que solo responden al ratón, focos que se pierden), la ausencia de un foco visible al tabular, y una jerarquía de encabezados rota o inexistente que desorienta a quien usa un lector de pantalla. La buena noticia es que ninguno de estos exige rehacer la plataforma: son ajustes de plantilla, de CSS y de marcado semántico.
Si tu negocio es una tienda online, este territorio no te resultará ajeno: ya lo tocamos en detalle al analizar cómo PrestaShop 9 cumple con WCAG 2.1 AA, donde se ve el impacto concreto de estos criterios sobre fichas de producto, filtros y checkout.
4. La declaración de accesibilidad y el canal de feedback
Cumplir técnicamente no basta: la EAA obliga a comunicar el estado de accesibilidad de tus servicios. Esto se materializa en una declaración de accesibilidad pública, un documento que debe explicar con qué estándar cumples (típicamente WCAG 2.1 AA vía EN 301 549), el grado de conformidad de tu servicio, las limitaciones conocidas y las excepciones, y con qué navegadores, sistemas operativos y tecnologías de asistencia has probado el producto (por ejemplo: última versión de Chrome, Edge, Firefox y Safari, y lectores como NVDA y VoiceOver).
El segundo pilar obligatorio es un mecanismo de feedback accesible: una vía —correo, formulario, teléfono— por la que cualquier usuario pueda reportar una barrera de accesibilidad y recibir respuesta. Ese canal tiene que ser, él mismo, accesible. Piensa en la declaración de accesibilidad como el equivalente a la política de privacidad que popularizó el RGPD: un artefacto vivo que refleja el estado real y que debes mantener actualizado cada vez que cambias tu plataforma.
5. Cómo auditar tu web: herramientas y método
La pregunta que todo CTO se hace es «¿cómo sé si cumplo?». La respuesta corta: con una combinación de herramientas automáticas y pruebas manuales. La respuesta larga es importante, porque aquí es donde muchos equipos se confían de más.
5.1 Herramientas automáticas
El motor de referencia es axe-core, la librería que hay debajo de axe DevTools y que alimenta a Google Lighthouse, Accessibility Insights y decenas de herramientas más. Para el día a día del desarrollador, axe DevTools (extensión de navegador) y Lighthouse (integrado en Chrome DevTools) permiten detectar fallos en segundos. WAVE es excelente para revisión visual de diseño y contenido, y Pa11y encaja bien para automatizar chequeos en tu pipeline de CI/CD y bloquear despliegues que introduzcan regresiones de accesibilidad. Integrar estas comprobaciones en el CI es la forma más eficiente de no volver a caer: cada pull request se valida solo.
5.2 El límite de lo automático
Aquí está el matiz crítico: las herramientas automáticas detectan aproximadamente entre el 30% y el 40% de los problemas de WCAG. Ni axe ni Lighthouse pueden evaluar si el texto alternativo de una imagen es útil, si el orden de lectura tiene sentido o si un patrón de interacción funciona de verdad con teclado. Una puntuación de 100 en Lighthouse no significa que tu página sea accesible. El resto —la mayoría— exige prueba manual: navegar toda la web solo con teclado, comprobar que el foco es visible y lógico, y recorrerla con un lector de pantalla real (NVDA en Windows, VoiceOver en Mac/iOS, TalkBack en Android). La combinación que recomendamos a nuestros clientes es axe DevTools para el código, WAVE para diseño y contenido, y un lector de pantalla para cazar la mitad que ninguna máquina ve. Las tres primeras son gratuitas.
Esta filosofía de «lo automático detecta, lo manual confirma» es la misma que aplicamos en cualquier auditoría técnica seria y en la auditoría de seguridad de APIs: las herramientas te dan el mapa, pero el criterio humano encuentra los agujeros que importan.
¿Tu plataforma cumple ya con la EAA?
En Keliam auditamos tu web o ecommerce contra WCAG 2.1 AA y EN 301 549, priorizamos los fallos por riesgo legal e impacto de usuario, y los corregimos sin frenar tu roadmap. Te entregamos también la declaración de accesibilidad y el canal de feedback listos para publicar.
6. Errores frecuentes en ecommerce (checkout, fichas y pagos)
El comercio electrónico es, junto con la banca, el sector donde más se está mirando el cumplimiento, y no por casualidad: es donde la barrera de accesibilidad se traduce directamente en una compra que no se completa. Los puntos calientes son claros. En las fichas de producto, la información no puede depender solo de la imagen: precio, tallas, disponibilidad y variantes deben ser texto perceptible por un lector de pantalla. El checkout es el eslabón más crítico: cada paso, cada campo y cada mensaje de error tiene que ser operable con teclado y comprensible para tecnologías de asistencia. Las interfaces de pago —incluidas las de terceros que integras— también entran en el ámbito, así que no basta con que tu web sea accesible si la pasarela no lo es.
Hay además una intersección jugosa con la conversión: casi todo lo que hace una web más accesible la hace también más usable y más rápida para todos. Un checkout accesible es un checkout con menos fricción, y ya vimos cuánto pesa eso al hablar de cómo optimizar la fricción, los pagos y la confianza en tu ecommerce. Del mismo modo, la accesibilidad comparte terreno con el rendimiento: los mismos hábitos de marcado semántico y de carga eficiente que mejoran tus Core Web Vitals y la métrica INP ayudan a que lectores de pantalla y navegación por teclado funcionen mejor.
7. Sanciones y riesgo real
Llega la parte que hace que dirección preste atención. El incumplimiento de la EAA no es una recomendación desatendida: tiene consecuencias económicas. En España, el régimen sancionador se coordina con la normativa general de derechos de las personas con discapacidad, clasificando las infracciones en leves, graves y muy graves según el daño causado y la intencionalidad. Las cuantías que citan las fuentes especializadas alcanzan cifras muy relevantes —del orden de hasta 100.000 € por infracción en el régimen sancionador, con techos superiores en los casos más graves— y pueden acompañarse de medidas complementarias: retirada de productos no conformes del mercado, prohibición de comercialización en toda la UE, retirada de licencias o inhabilitaciones temporales. A escala europea, las sanciones oscilan según el país y algunos marcos las vinculan incluso a un porcentaje de la facturación anual.
Y no es teoría: la aplicación efectiva arrancó el 28 de junio de 2025, las primeras demandas por incumplimiento de la EAA se presentaron en Francia en noviembre de 2025, y otros Estados miembros como Países Bajos tienen planificadas actividades de vigilancia a lo largo de 2026. El patrón recuerda de nuevo al RGPD: un arranque tranquilo seguido de una fase de aplicación cada vez más activa. Añade a esto el riesgo reputacional y el hecho de que una web inaccesible te cierra la puerta a un porcentaje nada despreciable de clientes potenciales, y el cálculo de coste-beneficio se inclina solo.
Conviene recordar que este contenido es informativo y no constituye asesoramiento legal: para la aplicación concreta a tu caso —umbrales, plazos y régimen sancionador exacto— es recomendable contrastar con un profesional jurídico. Si te interesa cómo se conectan estas obligaciones europeas con otras que ya estás gestionando, el análisis de la directiva NIS2 y sus obligaciones para empresas tecnológicas muestra un patrón regulatorio muy parecido.
8. Plan de cumplimiento en 90 días
Cerramos con lo accionable. Este es el plan que seguimos con nuestros clientes para pasar de «no sé si cumplo» a «cumplo y puedo demostrarlo», sin paralizar el desarrollo de producto.
8.1 Semanas 1-3: diagnóstico
Auditoría inicial combinando herramientas automáticas (axe, Lighthouse, WAVE en las plantillas y flujos clave) con una prueba manual de los recorridos críticos: home, listado, ficha, carrito, checkout, login y área de cliente. El entregable es un inventario de fallos priorizado por gravedad WCAG, riesgo legal e impacto en usuario.
8.2 Semanas 4-9: corrección
Se atacan primero los quick wins transversales que arreglan cientos de incidencias de golpe: contraste de la paleta, foco visible global, etiquetado de formularios y jerarquía de encabezados en las plantillas. Después, los flujos de negocio críticos, empezando por el checkout. En paralelo, se integra Pa11y o axe en el CI/CD para que ningún despliegue futuro reintroduzca regresiones.
8.3 Semanas 10-12: verificación y documentación
Nueva pasada de auditoría (automática + manual con lector de pantalla) para confirmar la conformidad, redacción y publicación de la declaración de accesibilidad, y puesta en marcha del canal de feedback. A partir de aquí, la accesibilidad deja de ser un proyecto y pasa a ser mantenimiento: revisiones periódicas y validación automática en cada cambio. Es exactamente el modelo de mejora continua que aplicamos en el mantenimiento de plataformas y que conecta con marcos como el Esquema Nacional de Seguridad, donde el cumplimiento tampoco es una foto fija sino un proceso vivo.
Conclusión
La European Accessibility Act ha convertido la accesibilidad web de una buena intención en una obligación legal con fecha, estándar y sanciones. La fecha ya pasó —28 de junio de 2025—, el estándar es conocido y estable —WCAG 2.1 AA a través de EN 301 549— y las sanciones han empezado a materializarse en demandas reales. La buena noticia para cualquier equipo técnico es que cumplir no exige reconstruir la plataforma: exige método. Un diagnóstico honesto que no se conforme con el 30% que ven las herramientas, una tanda de correcciones priorizadas que empiezan por el contraste, el teclado y los formularios, y un proceso de mantenimiento que impida las regresiones. Hecho con cabeza, el cumplimiento de la EAA no solo te evita multas: te deja una web más rápida, más usable y abierta a más clientes. Y eso, al final, es un buen negocio.
Preguntas frecuentes
¿Desde cuándo es obligatoria la EAA?
Desde el 28 de junio de 2025 para los productos y servicios nuevos dentro de su ámbito. Los servicios que ya se prestaban antes de esa fecha disponen de un periodo transitorio hasta el 28 de junio de 2030.
¿Mi empresa está fuera de la UE, me afecta igual?
Sí. La EAA aplica a cualquier empresa que ofrezca productos o servicios a consumidores dentro de la UE, con independencia de dónde tenga su sede, igual que ocurre con el RGPD.
¿Qué estándar técnico tengo que cumplir exactamente?
WCAG 2.1 en nivel AA, que en el marco europeo se demuestra a través de la norma armonizada EN 301 549 (versión v3.2.1), la cual incorpora WCAG 2.1 AA en su totalidad.
¿Basta con pasar Lighthouse o axe para cumplir?
No. Las herramientas automáticas detectan solo entre el 30% y el 40% de los problemas. El cumplimiento real exige además prueba manual: navegación por teclado y verificación con lector de pantalla.
