Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
El European Accessibility Act ya es aplicable: qué deben hacer ahora los equipos de ecommerce
No es una propuesta. No es un plazo futuro. El periodo de aplicación del European Accessibility Act (EAA) comenzó el 28 de junio de 2025.
Si tu negocio de ecommerce vende a clientes europeos y tu web o tu app no cumplen los estándares WCAG 2.1 AA, ahora mismo estás en situación de incumplimiento. Las multas no son teóricas. En Alemania alcanzan los 500.000 €. En Francia, 250.000 €. España aplica hasta 300.000 €. Incluso mercados más pequeños como Irlanda imponen sanciones de 60.000 €.
No se trata de ser amable con las personas con discapacidad. Eso importa, evidentemente. Pero los consejos de administración piensan en multas, responsabilidad legal y riesgo competitivo. Por eso este artículo habla su idioma: qué significa realmente el EAA para la operativa de ecommerce, cómo es la implementación técnica y por qué supone menos carga de lo que crees si has diseñado bien la arquitectura de tu plataforma.
Qué ha cambiado y por qué importa ahora
El European Accessibility Act se publicó en 2019. Todo el mundo sabía que llegaría. Durante años se quedó en un «algún día tendremos que...» en lugar de convertirse en acción inmediata.
El 28 de junio de 2025 convirtió ese futuro deseable en una fecha límite de cumplimiento.
Este es el requisito central: cualquier web o producto digital que atienda a clientes del mercado de la UE debe cumplir los estándares WCAG 2.1 AA. Punto. Sin ambigüedades. Sin periodo de gracia.
WCAG 2.1 AA es un estándar bien definido. No es vago. Cubre la navegación por teclado, el soporte para lectores de pantalla, los ratios de contraste de color, el etiquetado de formularios, los subtítulos de vídeo y decenas de requisitos técnicos concretos más. O los cumples o no los cumples.
Las multas son lo bastante altas como para que esto sea ya un asunto de compliance a nivel de consejo, no una funcionalidad «deseable».
Pero esto es lo más importante: el EAA se aplica a cualquier empresa que venda productos o servicios digitales en el mercado de la UE, con independencia de dónde tenga su sede. Una empresa de ecommerce estadounidense que vende a clientes europeos está sujeta al EAA. Una empresa británica que vende en la UE, también. Una empresa australiana con clientes europeos, también.
Si tus ingresos europeos representan una parte relevante de tu negocio (y en la mayoría de las empresas globales de ecommerce lo hacen), esto es un requisito firme, no una opción.
A quién afecta realmente (y por qué probablemente te afecta a ti)
Seamos concretos sobre quién entra en el ámbito de aplicación del EAA.
La normativa se aplica a:
- Webs de ecommerce que atienden a clientes de la UE
- Aplicaciones móviles disponibles en las app stores de la UE
- Servicios digitales con bienes físicos (tu storefront) o bienes digitales (suscripciones, descargas)
- Servicios digitales B2C y B2B
Existen exenciones limitadas para las microempresas (menos de 10 empleados y una facturación anual inferior a 2 M€), pero se están eliminando progresivamente. Para 2030, prácticamente todas las organizaciones estarán dentro del ámbito.
Si tu negocio de ecommerce opera con cierta escala en mercados europeos, te afecta. Punto.
La cuestión geográfica es donde suele surgir la confusión. Tu empresa puede estar en California. Tus servidores pueden estar alojados en Estados Unidos. Pero si vendes a clientes de la UE desde tu web, estás sujeto al EAA. La norma sigue al mercado, no a la ubicación de la empresa.
Qué significa «accesible» en la práctica para el ecommerce
WCAG 2.1 AA es un estándar técnico detallado con requisitos concretos y medibles. Entender cómo es el cumplimiento real importa, porque determina el trabajo que tienes por delante.
Navegación por teclado
Los usuarios deben poder recorrer todo tu flujo de ecommerce usando solo el teclado. Sin ratón. Esto incluye la navegación por productos, añadir artículos al carrito, el checkout, el relleno de formularios y el pago.
Situación actual: muchas webs de ecommerce tienen agujeros en la navegación por teclado. Ventanas modales que atrapan el foco. Menús desplegables que se cierran de forma inesperada cuando alguien navega con teclado. Botones inaccesibles desde el teclado.
Situación requerida: cada elemento interactivo es alcanzable con el teclado. El orden de tabulación es lógico. Hay un indicador de foco visible. Los usuarios de teclado pueden completar el checkout sin encontrarse callejones sin salida.
Soporte para lectores de pantalla
Las personas con discapacidad visual dependen de lectores de pantalla (software que lee en voz alta el contenido de la página). Tu sitio debe estar estructurado para que los lectores de pantalla interpreten correctamente todo el contenido, incluida la información de producto, los precios, los campos de formulario y los pasos del checkout.
Situación actual: muchas webs de ecommerce dan problemas con los lectores de pantalla porque el HTML subyacente está mal estructurado. Los formularios carecen de etiquetas adecuadas. La información de producto está dentro de imágenes sin texto alternativo. Los layouts complejos usan CSS para crear relaciones visuales que los lectores de pantalla no pueden detectar.
Situación requerida: todos los elementos interactivos tienen etiquetas claras. Los campos de formulario están correctamente asociados a sus etiquetas. La información de producto está disponible como texto, no solo como imagen. Los layouts complejos están marcados semánticamente. La estructura de navegación es clara para los lectores de pantalla.
Contraste de color
El texto debe tener suficiente contraste frente a su fondo. El requisito es 4,5:1 para texto normal y 3:1 para texto grande.
Situación actual: el diseño de tendencia a veces choca con los requisitos de contraste. El texto gris claro sobre fondo blanco queda bien. Y suspende en accesibilidad.
Situación requerida: todo el texto cumple los mínimos de contraste. Esto incluye los párrafos, las etiquetas de botones, los placeholders de formulario y los mensajes de error.
Accesibilidad de formularios
Los formularios son un componente crítico del ecommerce. WCAG AA exige un etiquetado correcto, mensajes de error claros y controles de formulario accesibles.
Situación actual: muchos formularios de ecommerce carecen de etiquetas adecuadas. Los errores de validación aparecen, pero no indican con claridad qué campo falla. Los campos obligatorios no están marcados. El texto del placeholder se usa como si fuera la etiqueta.
Situación requerida: cada campo del formulario tiene una etiqueta explícita y asociada. Los campos obligatorios están marcados. Los mensajes de error identifican con claridad qué campo falla y cuál es el error. Los requisitos de contraseña se comunican con claridad.
Vídeo y multimedia
Si tu web de ecommerce incluye vídeos de producto (habituales en moda, electrónica o cosmética), deben incluir subtítulos y transcripciones.
Situación requerida: cada vídeo de producto tiene subtítulos. Se ofrecen audiodescripciones para el contenido visual que no se deduce solo de los subtítulos.
Estructura de encabezados y organización del contenido
La estructura de la página debe ser lógica y transmitirse mediante una jerarquía de encabezados correcta, no solo con el estilo visual.
Situación requerida: las páginas usan encabezados H1, H2 y H3 en orden lógico. La estructura de navegación es clara. Las secciones de contenido están bien organizadas.
El caso de negocio más allá del cumplimiento
La mayoría de los equipos de ecommerce se centra en el «tenemos que cumplir para evitar multas». Es necesario, pero incompleto. La accesibilidad tiene un retorno de negocio real.
Tamaño de mercado
Alrededor de 80 millones de personas en la UE viven con algún tipo de discapacidad. Eso no es un nicho. Es un segmento de mercado sustancial. Cuando haces accesible tu web de ecommerce no solo evitas multas. Abres tu sitio a una base de clientes mayor.
Parte de esos 80 millones tiene discapacidades permanentes. Muchas personas tienen discapacidades temporales (un brazo roto, la recuperación tras una operación) o situacionales (navegar por tu web desde el móvil a pleno sol, lo que vuelve crítico el contraste de color).
Las mejoras de accesibilidad van más allá de la comunidad con discapacidad. Mejoran la experiencia de todo el mundo.
Beneficios SEO
Los buscadores indexan las webs de ecommerce de forma parecida a como las interpretan los lectores de pantalla. Los formularios bien etiquetados, el HTML semántico, los textos de enlace descriptivos y una estructura clara benefician por igual al SEO y a la accesibilidad.
Las mejoras técnicas que haces por accesibilidad suelen mejorar también la visibilidad en buscadores. No es un beneficio colateral. Es un resultado de negocio real y medible.
Mejora de UX y conversión
Formularios simplificados, mensajes de error más claros, mejor navegación y mejor contraste no solo ayudan a las personas con discapacidad. Mejoran la conversión para todos.
La accesibilidad suele destapar problemas de UX que afectan a todos los usuarios. Cuando los corriges, normalmente ves mejoras medibles en las tasas de conversión, sobre todo en móvil.
Posicionamiento competitivo
Los competidores que esperen a que la presión sancionadora les obligue a actuar irán con prisas. Las empresas que abordan la accesibilidad de forma proactiva, documentan su cumplimiento y lo usan como diferenciador de marketing se posicionan mejor en el mercado.
Quien se mueve primero puede decir: «Cumplimos el EAA. Estamos orgullosos. Hemos diseñado para todos». Eso es una ventaja competitiva, no solo una casilla de cumplimiento.
La hoja de ruta de implementación técnica
Esta es la secuencia práctica para llegar al cumplimiento del EAA:
Fase 1: auditoría (de 4 a 6 semanas)
Haz una auditoría de accesibilidad de tu web de ecommerce actual. Puede ser automatizada (herramientas como Axe, WAVE o Lighthouse te dan una línea base) o manual (trabajar con especialistas en accesibilidad para probar la compatibilidad con lectores de pantalla, la navegación por teclado, etc.).
La auditoría revelará dos tipos de problemas:
- Correcciones fáciles: problemas de contraste de color, textos alternativos que faltan en imágenes, campos de formulario mal etiquetados. Normalmente, de 40 a 50 % de los problemas.
- Problemas estructurales: problemas de navegación por teclado, incompatibilidad con lectores de pantalla por un HTML mal estructurado, layouts complejos que no funcionan con tecnologías de apoyo. Estos exigen más trabajo.
Presupuesto: de 10.000 a 30.000 $ según la complejidad del sitio y de si contratas auditores externos.
Fase 2: priorizar
No todos los problemas de accesibilidad tienen el mismo peso en ecommerce. Prioriza por impacto y esfuerzo:
- Problemas de la ruta crítica: accesibilidad del checkout, navegación por productos, navegación en formularios. Si la gente no puede completar una compra, la accesibilidad es irrelevante.
- Correcciones de alto impacto: contraste de color (fácil), textos alternativos (medio), estructura de encabezados (medio).
- Problemas de menor impacto: etiquetado de elementos decorativos, atajos de teclado avanzados.
Fase 3: implementar
Empieza por los problemas priorizados. La mayoría requiere:
- Correcciones de HTML (etiquetado correcto, estructura semántica)
- Actualizaciones de CSS (ratios de contraste, estados de foco)
- Ajustes de JavaScript (gestión de eventos de teclado, atributos ARIA)
El calendario de implementación depende de tu arquitectura. Si tu sitio está construido sobre una plataforma Composable como Laioutr, con componentes accesibles en la librería de UI, las correcciones de accesibilidad suelen ser más rápidas. Si tu sitio es un desarrollo monolítico a medida, la implementación llevará más tiempo.
Presupuesto: de 50.000 a 150.000 $ según el estado actual y la complejidad del sitio.
Fase 4: testing
Las pruebas automatizadas detectan alrededor del 30 % de los problemas de accesibilidad. Las pruebas manuales detectan el resto.
El testing debería incluir:
- Navegación solo con teclado por todo el flujo de ecommerce
- Pruebas con lectores de pantalla (NVDA en Windows, JAWS, VoiceOver en Mac)
- Accesibilidad móvil (navegación táctil, lectores de pantalla móviles)
- Verificación del contraste de color en todo el sitio
Presupuesto: de 15.000 a 40.000 $ para pruebas y verificación de accesibilidad externas.
Fase 5: documentación
Crea y mantén documentación de tus trabajos de accesibilidad. Qué estándares cumples. Qué áreas se han probado. Cualquier problema conocido con su plan de corrección.
Esta documentación es valiosa si alguna vez te enfrentas a una acción sancionadora. Demuestra un esfuerzo de buena fe por cumplir.
Presupuesto: mínimo si es interno; de 5.000 a 10.000 $ si quieres verificación externa.
Por qué la arquitectura Composable facilita la accesibilidad
Aquí es donde la arquitectura de plataforma marca la diferencia.
Las plataformas de ecommerce monolíticas creadas hace más de 15 años no se diseñaron con la accesibilidad como principio central. Incorporar la accesibilidad a posteriori en una base de código monolítica sale caro, porque hay que cambiar la arquitectura subyacente, probar todo lo que hay aguas abajo y gestionar los efectos colaterales en todo el sistema.
La arquitectura Composable, construida sobre componentes best-of-breed, acelera la implementación y el mantenimiento de la accesibilidad.
¿Por qué? Porque:
- Los componentes accesibles son reutilizables: un componente de botón, un campo de formulario o un menú de navegación realmente accesible puede usarse en toda tu web de ecommerce. Corriges la accesibilidad una vez en la librería de componentes. Queda corregida en todas partes.
- Separación clara de responsabilidades: con una arquitectura Composable puedes auditar y corregir la accesibilidad de cada componente de forma independiente. Si el componente de botón de tu Laioutr Storefront es accesible, todos los botones de todas tus experiencias de ecommerce lo son.
- Responsabilidad del proveedor: cuando usas componentes de proveedores comprometidos con la accesibilidad (como los componentes WCAG 3.0 Ready de Laioutr), no partes de cero. El proveedor ya ha invertido en accesibilidad. Tú heredas ese trabajo.
- Testing más sencillo: las plataformas Composable suelen ofrecer una infraestructura de pruebas más limpia. Los componentes accesibles son más fáciles de probar de forma programática porque siguen los estándares. Eso significa pruebas automatizadas más eficientes y menos ciclos de prueba manual.
Si estás construyendo una nueva plataforma de ecommerce o modernizando una existente para cumplir el EAA, un enfoque Composable es bastante más eficiente que intentar incorporar la accesibilidad a un monolito heredado.
Errores habituales y cómo evitarlos
Error 1: tratar la accesibilidad como un proyecto puntual
La accesibilidad no es una casilla que marcar. Es un compromiso continuo. Nuevas funcionalidades, cambios de diseño e integraciones de terceros pueden introducir regresiones de accesibilidad.
Cómo evitarlo: integra las pruebas de accesibilidad en tu proceso de desarrollo. Exige una revisión de accesibilidad dentro de la revisión de código. Incluye la accesibilidad en tu proceso de QA, no como algo de última hora.
Error 2: confiar solo en las pruebas automatizadas
Las herramientas automatizadas detectan alrededor del 30 % de los problemas de accesibilidad. El 70 % restante exige pruebas manuales con tecnología de apoyo real.
Cómo evitarlo: combina las pruebas automatizadas (rápidas y baratas) con pruebas manuales periódicas (más lentas, pero que sacan a la luz problemas reales). Reserva presupuesto para pruebas manuales de accesibilidad al menos trimestrales.
Error 3: dar por hecho que accesibilidad solo significa lectores de pantalla
La accesibilidad abarca muchas discapacidades: visuales, motoras, cognitivas y auditivas. Probar con lector de pantalla es importante, pero no es todo el cuadro.
Cómo evitarlo: prueba con varias tecnologías de apoyo. Prueba la navegación solo con teclado (discapacidades motoras). Prueba el contraste de color (daltonismo). Prueba la estructura de encabezados (accesibilidad cognitiva). Prueba los subtítulos de vídeo (discapacidades auditivas).
Error 4: no incluir a usuarios con discapacidad en las pruebas
La mejor forma de detectar problemas de accesibilidad es probar con usuarios reales que dependen de tecnología de apoyo.
Cómo evitarlo: incluye a usuarios con discapacidad en tus pruebas de accesibilidad. Su feedback revela a menudo problemas que hasta los auditores con experiencia pasan por alto.
Error 5: ignorar las integraciones de terceros
Tu web de ecommerce probablemente se integra con proveedores de pago, plataformas de reseñas, herramientas de analytics y otros terceros. Si esas integraciones no son accesibles, tu sitio no es del todo accesible.
Cómo evitarlo: audita la accesibilidad de las integraciones de terceros. Elige proveedores que apuesten por la accesibilidad. Construye tus integraciones de forma que mantengan los estándares de accesibilidad incluso cuando las herramientas de terceros no sean perfectamente accesibles.
El panorama sancionador: multas reales, consecuencias reales
Quizá te preguntes: ¿de verdad se aplican estas multas? Sí.
Los organismos supervisores varían según el país, pero son reales:
- Alemania: multa máxima de 500.000 € (supervisa el Bundeskartellamt)
- Francia: hasta 250.000 € (supervisa la CNIL)
- España: hasta 300.000 € (diversas autoridades regionales)
- Italia: hasta 50.000 € por infracción
- Países Bajos: hasta 4,3 M€ o el 4 % de la facturación anual
- Irlanda: hasta 60.000 €
Varios Estados miembros de la UE ya han emitido advertencias o multas a webs no conformes. Esto no es especulativo. La aplicación ya está en marcha.
El foco sancionador empezó por las grandes plataformas y los sitios de mucho tráfico, pero se está ampliando. Si tu negocio de ecommerce opera con una escala relevante en Europa, tarde o temprano te auditarán.
Incorporar el cumplimiento a tu roadmap
Si tu web de ecommerce todavía no cumple el EAA, esto tiene que entrar en tu roadmap ya.
Este es un calendario razonable para la mayoría de los sitios:
- Meses 1 y 2: auditoría de accesibilidad y priorización
- Meses 2 a 4: implementación de las correcciones priorizadas
- Meses 4 a 5: pruebas y corrección
- Mes 6: verificación del cumplimiento y documentación
Son seis meses para la mayoría de las webs de ecommerce, desde la auditoría hasta el cumplimiento. Algunas irán más rápido (si partes de una base de código moderna y bien estructurada). Otras irán más despacio (si estás incorporando accesibilidad a sistemas heredados).
Empieza ya. Esperar a la presión sancionadora saldrá más caro y será más estresante que planificar de forma proactiva.
La accesibilidad es estrategia, no una carga
El relato sobre el cumplimiento del EAA en ecommerce se ha reducido muchas veces a una «carga de cumplimiento». Otra normativa. Otro requisito. Otro coste.
Cambia el enfoque: la accesibilidad es estrategia.
Cuando haces accesible tu web de ecommerce, amplías tu mercado abordable en más de 80 millones de clientes potenciales en Europa. Mejoras la UX para todos. Mejoras el SEO. Reduces el riesgo legal. Le indicas a tus clientes que tu marca valora la inclusión.
Eso no son efectos colaterales del cumplimiento. Son beneficios de negocio reales.
El trabajo técnico es real y exige inversión. Pero no es un esfuerzo imposible, sobre todo si tu arquitectura es la adecuada.
Empieza tu auditoría. Prioriza tu implementación. Integra la accesibilidad en tu proceso de desarrollo. Documenta tu cumplimiento.
Así es como se pasa de «oh no, otra normativa» a «así es como trabajamos».
¿Listo para hacer accesible tu web de ecommerce?
Si estás evaluando plataformas o modernizando tu arquitectura de ecommerce, la accesibilidad debería ser un criterio de decisión central. El Storefront y la librería de UI de Laioutr están construidos con el cumplimiento de WCAG 2.1 AA como principio fundacional. Nuestros componentes son accesibles por diseño, no por parche.
Descubre nuestra plataforma WCAG Ready, revisa nuestros componentes de UI accesibles, o profundiza en cómo la arquitectura Composable acelera la implementación de la accesibilidad.
El cumplimiento del EAA ya es una realidad. Conviértelo en una ventaja estratégica, no en una carga.
Más contenidos de la plataforma Laioutr
Lecturas relacionadas: European Accessibility Act 2025: cambios y qué significan para las empresas de ecommerce y EAA + HCL Commerce+: por qué la conformidad del backend no es suficiente.