Mascota Jacar — leyendo contigo Un portátil cuyos ojos siguen el cursor mientras lees.
Experiencia de Usuario

European Accessibility Act: preparando junio de 2025

European Accessibility Act: preparando junio de 2025

Actualizado: 2026-05-03

La European Accessibility Act[1] (EAA, Directiva 2019/882) entra en vigor el 28 de junio de 2025. Aprobada en 2019 y traspuesta por los estados miembros en los últimos años, es ya una realidad inminente. Muchas empresas la tienen identificada pero no trabajada. Otras ni saben que les aplica. Este artículo es un resumen práctico: quién está obligado, qué exige técnicamente y cómo planificar para llegar a tiempo.

Qué es la EAA

La EAA armoniza los requisitos de accesibilidad de productos y servicios en toda la UE. Su objetivo es que personas con discapacidad puedan acceder a productos y servicios digitales y físicos sin barreras desproporcionadas.

No es nueva en espíritu — ya existía normativa sobre sector público (WAD, Directiva 2016/2102). La EAA extiende esas obligaciones al sector privado con plazos vinculantes. En España, el Real Decreto 193/2023 articula la transposición.

Qué productos y servicios cubre

La lista es extensa y a veces sorprende:

Productos:

  • Ordenadores, smartphones, tabletas y sus sistemas operativos.
  • Terminales de autoservicio: cajeros automáticos, máquinas de billetes, totems de check-in.
  • Routers, decodificadores, smart TVs.
  • Lectores de libros electrónicos.

Servicios:

  • Comercio electrónico (e-commerce).
  • Servicios bancarios electrónicos.
  • Telecomunicaciones (llamadas, mensajería, acceso a emergencias 112).
  • Transporte (reserva online, pantallas de información, billetes electrónicos).
  • Libros electrónicos y software para leerlos.
  • Servicios de medios audiovisuales — interfaces de Netflix, Prime Video, plataformas similares.

Si tu empresa tiene e-commerce consumer en Europa, la EAA te afecta. Si tienes una app bancaria, te afecta. Si vendes un SaaS que los usuarios consumen en sus navegadores, probablemente también.

Excepciones importantes

No todas las empresas están igual expuestas:

  • Microempresas (menos de 10 empleados y menos de 2M€ de facturación) están exentas en servicios — no en productos.
  • Carga desproporcionada: ajustes que sean injustificadamente costosos respecto al beneficio pueden exceptuarse, pero con análisis documentado. “Desproporcionado” no equivale a “no quiero hacerlo”.
  • Infraestructura legacy con alcance limitado puede estar parcialmente excepcionada con justificación sólida.

Qué exige técnicamente

Los requisitos técnicos específicos están en la EN 301 549, el estándar europeo que incorpora WCAG 2.1 AA[2] como referencia base. Los cuatro pilares:

  • Perceptible: contenido accesible a distintos sentidos — alt text, subtítulos, contraste mínimo.
  • Operable: navegación por teclado, sin tiempos forzados, sin contenido que cause convulsiones.
  • Entendible: lenguaje claro, comportamiento predecible, ayuda a errores.
  • Robusto: compatible con tecnologías asistivas presentes y futuras.

Para la mayoría de productos digitales esto significa: HTML semántico, roles ARIA correctos, contraste mínimo 4.5:1 para texto normal, focus-visible en navegación por teclado, subtítulos en vídeo y formularios con labels y mensajes de error claros. Ver el artículo sobre accesibilidad WCAG básica para el punto de partida técnico.

Sanciones en España

Las sanciones dependen del estado miembro. En España, Real Decreto 193/2023:

  • Infracciones leves: hasta 50.000€.
  • Graves: entre 50.001€ y 400.000€.
  • Muy graves: entre 400.001€ y 1.000.000€.

A eso se suma el riesgo reputacional de auditorías públicas. Ya se producen denuncias de asociaciones de consumidores por accesibilidad — el volumen crecerá tras junio de 2025.

El error más común: empezar tarde

Arreglar problemas de accesibilidad profundos cuesta meses, no semanas:

  • Auditoría completa: 2-4 semanas para un producto mediano.
  • Refactorización de componentes no accesibles: 2-6 meses.
  • Re-testing y documentación de compliance: 2-4 semanas.

Quien empieza en mayo de 2025 no llega. La única estrategia viable es empezar ahora y priorizar por severidad.

Un plan estructurado por fases

Cómo abordarlo si tienes margen:

Fase de auditoría (primer mes)

  • Herramientas automáticas: axe DevTools, WAVE, Lighthouse, pa11y.
  • Revisión manual de flujos críticos con tecnologías asistivas reales: NVDA + Firefox en Windows, VoiceOver + Safari en Mac/iOS, TalkBack en Android.
  • Output: lista priorizada de issues con estimación de esfuerzo real.

La auditoría automática cubre el 30-40% de los issues. El resto necesita revisión humana. Presupuestar ambos desde el inicio es obligatorio.

Fase de corrección de issues críticos (meses 2-5)

  • Componentes custom sin soporte ARIA correcto.
  • Navegación por teclado en toda la aplicación.
  • Contraste de texto y elementos UI.
  • Formularios con labels, errores y helpers claros.

Fase de flujos secundarios y contenido (meses 6-8)

  • Imágenes, vídeos y PDFs.
  • Documentación y centro de ayuda.
  • Emails transaccionales accesibles.

Fase final (mes 9 en adelante)

  • Re-auditoría completa.
  • Testing con usuarios reales con discapacidad — el paso más infravalorado y más útil.
  • Documentación formal de compliance para satisfacer requisitos regulatorios.
Diagrama de fases de cumplimiento EAA: auditoría, corrección crítica, flujos secundarios y verificación final

Errores típicos

Lo que vemos repetirse:

  • Añadir aria-label por todas partes sin entenderlo: mal ARIA es peor que no ARIA.
  • Depender solo de herramientas automáticas: cubren un tercio del problema.
  • Ignorar PDFs: si distribuyes PDFs comerciales, también entran en el alcance de la EAA.
  • No formar al equipo: sin sensibilización, los nuevos desarrollos re-introducen los mismos problemas.
  • “Botón de accesibilidad” como solución: los overlay widgets no cumplen la EAA y están siendo objeto de demandas en EEUU y Europa.

Impacto más allá del compliance

Accesibilidad bien hecha aporta valor real más allá de evitar sanciones:

  • SEO: la estructura semántica mejora la indexación.
  • UX general: los diseños accesibles son mejores diseños para todos.
  • Mercado: aproximadamente un 15% de los usuarios tiene alguna discapacidad relevante. Producto accesible equivale a TAM más grande.
  • Resiliencia técnica: la accesibilidad fuerza disciplina en HTML semántico y separación de presentación y estructura.

La accesibilidad es inversión con retorno, no solo coste de compliance. El contexto normativo más amplio — que incluye la NIS2 para ciberseguridad — se puede revisar en la directiva NIS2 europea.

Conclusión

La European Accessibility Act entra en vigor en junio de 2025 y afecta a más empresas de las que creen. El coste de prepararse es manejable si se empieza con margen; el coste de no prepararse escala exponencialmente cerca de la fecha. El enfoque correcto: auditar pronto, priorizar por severidad real, formar al equipo para que la accesibilidad sea parte de cómo construyen — no una capa final. Las empresas que lo hagan bien tendrán un producto mejor en todos los sentidos, no solo conforme a ley.

¿Te ha resultado útil?
[Total: 15 · Media: 4.4]
  1. European Accessibility Act
  2. WCAG 2.1 AA

Escrito por

CEO - Jacar Systems

Apasionado de la tecnología, la infraestructura cloud y la inteligencia artificial. Escribe sobre DevOps, IA, plataformas y software desde Madrid.