El 28 de junio de 2025 marcó la entrada en vigor del European Accessibility Act (Directiva UE 2019/882) para la mayoría de productos y servicios de e-commerce dirigidos a consumidores europeos. Un año después, la realidad sobre el terreno es nítida: la mayoría de tiendas PrestaShop que operan en España siguen sin cumplir — y la mayoría de comerciantes todavía lo ignora.
El asunto ya no es solo ético. Es un riesgo jurídico, comercial (pérdida de contratos públicos, B2B sensibles) y reputacional. Este artículo hace balance del marco legal aplicable en España en 2026, las sanciones efectivamente aplicadas desde 2025, y la hoja de ruta técnica para llevar una tienda PrestaShop 8 o 9 al cumplimiento sin rehacer la plantilla.
El marco legal aplicable a una tienda PrestaShop en España en 2026
La EAA fue transpuesta al ordenamiento jurídico español por el Real Decreto 193/2023, de 21 de marzo, sobre los requisitos de accesibilidad de los productos y servicios. Está articulado en torno a la Ley General de Derechos de las Personas con Discapacidad (Real Decreto Legislativo 1/2013). El ámbito es amplio: todo servicio de e-commerce dirigido a consumidores europeos está incluido — sitio web, aplicación móvil, proceso de compra, comunicación post-venta.
Dos exenciones estructurantes:
- Las microempresas en el sentido europeo (menos de 10 trabajadores Y volumen de negocios o balance inferior a 2 M€) están exentas para sus servicios. Atención: el umbral se aprecia a nivel de grupo.
- Los contenidos de terceros no controlados (comentarios brutos de usuarios, por ejemplo) están fuera del ámbito, pero el comerciante sigue siendo responsable de la estructura que acoge esos contenidos.
La norma técnica de referencia en España es la UNE-EN 301 549 V3.2.1, que se alinea con WCAG 2.1 nivel AA. En la práctica, la norma internacional que guía el trabajo cotidiano es WCAG 2.2, publicada en octubre de 2023, que añade nueve criterios de éxito — en particular el foco visible (2.4.11), el tamaño mínimo de objetivo (2.5.8) y la persistencia de elementos de ayuda (3.2.6). Una tienda conforme a WCAG 2.2 AA cumple con UNE-EN 301 549 y por tanto con los requisitos técnicos del RD 193/2023.
Las sanciones efectivamente aplicadas en España desde hace un año
El control está repartido entre las autoridades de vigilancia del mercado de las comunidades autónomas, el Ministerio de Consumo y la Dirección General para la Igualdad de Trato y la Diversidad Étnico-Racial. La supervisión técnica corresponde en parte al OBSAE (Observatorio de Accesibilidad Web). Un año después:
- Fase mayoritariamente pedagógica al inicio. Los primeros controles de 2025 terminaron sobre todo en requerimientos y compromisos correctivos. Pocas sanciones firmes.
- Endurecimiento desde el primer trimestre de 2026. Varias sanciones administrativas se han notificado, escalonadas entre 5 000 € y 75 000 € según el tamaño del operador y la gravedad (ausencia total de declaración de accesibilidad principalmente).
- El máximo legal es elevado. El RD 193/2023 establece sanciones graves de hasta 600 000 € y muy graves hasta 1 000 000 €, dependiendo de la calificación de la infracción.
- El riesgo indirecto es probablemente superior: exclusión de licitaciones públicas, rechazo de referenciación por centrales de compra B2B, señales negativas de clientes en comparadores.
La obligación visible más sistemáticamente controlada es la declaración de accesibilidad, que debe publicarse en el sitio, fechada, e indicar el nivel de cumplimiento alcanzado (totalmente / parcialmente / no conforme) así como un plan plurianual de adecuación. Una tienda sin esta página se identifica de inmediato.
Auditoría de campo: lo que realmente falla en PrestaShop
A partir de auditorías sobre temas Classic, Hummingbird, Warehouse y temas a medida, las no conformidades recurrentes se concentran en seis familias:
1. Contraste insuficiente (criterio WCAG 1.4.3 / 1.4.11)
El gris claro sobre fondo blanco utilizado para los precios tachados, las menciones «IVA incluido» o los pictogramas de garantía fallan casi sistemáticamente el ratio 4,5:1 (texto normal) o 3:1 (texto grande e interfaces). Una pasada de auditoría con Lighthouse o axe-core arroja por lo general 15 a 40 defectos de contraste en una ficha producto estándar.
2. Navegación por teclado rota
El menú desplegable superior, los filtros facetados a la izquierda, el selector personalizado de cantidad, el popup de newsletter — todos estos componentes son con frecuencia inaccesibles solo con teclado (Tab + Enter + Espacio). El foco visible desaparece en la mitad de los temas premium. Es un criterio bloqueante.
3. Formulario de checkout mal etiquetado
Campo sin atributo label asociado, indicación de error solo por color (rojo), sin aria-describedby para las restricciones («8 caracteres mínimo»), resumen inaccesible al lector de pantalla. El checkout one-page nativo de PrestaShop 8 ha mejorado pero sigue siendo incompleto, sobre todo cuando se añade un módulo de pago o un selector de direcciones de terceros.
4. Imágenes sin texto alternativo estructurado
El clásico problema: todas las imágenes de producto tienen un atributo alt vacío o repetido (nombre del producto copiado). La lógica correcta: alt vacío para imágenes puramente decorativas (alt=»»), alt descriptivo y diferenciado para vistas secundarias («vista trasera», «detalle de costura»). PrestaShop no lo hace automáticamente, corresponde al comerciante introducirlo en la importación del catálogo.
5. Vídeos y carruseles automáticos
Carrusel home que se desplaza solo sin botón de pausa, vídeo de producto en autoplay: violación directa del criterio 2.2.2 (Pausar, detener, ocultar). Técnicamente, para un visitante con trastorno vestibular, el desplazamiento automático puede desencadenar un malestar.
6. Captcha bloqueante y popups intrusivos
reCAPTCHA v2 «marca la casilla» sin alternativa para usuarios de lectores de pantalla, popup newsletter sin trampa de foco, modal de cookies imposible de cerrar con teclado. Tres clásicos que cualquier auditoría de control identifica en minutos.
Hoja de ruta de cumplimiento — sin rehacer la plantilla
Buena noticia: la mayoría de tiendas pueden alcanzar un cumplimiento sustancial WCAG 2.2 AA en 4 a 8 semanas de trabajo enfocado, sin reconstrucción completa. La secuencia que funciona:
Semana 1 — Auditoría cuantificada
Lanzar una auditoría automatizada (axe DevTools, WAVE, Lighthouse) sobre 10 páginas representativas: inicio, categoría, ficha producto, carrito, paso de envío, paso de pago, confirmación, blog, contacto, aviso legal. Doblar con un test manual solo con teclado y un test con lector de pantalla (NVDA gratuito en Windows, VoiceOver en Mac). Generar una matriz «criterio / página / severidad» con puntuaciones.
Semanas 2 a 3 — Correcciones de superficie de fuerte impacto
- Reajuste de la paleta de colores para alcanzar los ratios de contraste — a menudo una variable CSS por ajustar, dos o tres como mucho.
- Añadir un foco visible global y legible (outline de 2 píxeles con color contrastado).
- Corregir los textos alt en el catálogo: regla automatizable mediante un script SQL o un módulo dedicado.
- Suprimir los autoplay y añadir un control de pausa en el carrusel.
Semanas 4 a 5 — Componentes críticos
- Refactorizar el menú principal con gestión completa por teclado (Tab, Enter, Escape, flechas).
- Etiquetado ARIA correcto de los filtros facetados, el selector de cantidad, las notificaciones de carrito.
- Corregir los formularios: labels asociados, indicaciones de error en texto Y color, foco sobre el primer campo en error.
Semanas 6 a 7 — Cumplimiento editorial y declaración
- Auditar las páginas CMS y los artículos de blog (estructura de títulos, alt de imágenes).
- Redactar y publicar la declaración de accesibilidad conforme al modelo oficial (estado de cumplimiento, derogaciones justificadas, canal de retorno usuario, vía de recurso).
- Plan plurianual de adecuación publicado en la misma página.
Semana 8 — Test de usuario y documentación
Un test con un usuario real en situación de discapacidad (deficiencia visual o motora) sigue siendo el único modo de validar que no se ha pasado por alto un criterio sutil. También es un argumento en caso de control: probar una dinámica de mejora continua.
La trampa de los módulos de terceros
El gran ángulo muerto: los módulos de terceros añaden permanentemente elementos no auditados. Un popup de wishlist, un módulo de cross-sell con carrusel, un widget de reseñas de terceros — cada incorporación puede romper el cumplimiento adquirido. La regla saludable: auditar cada nuevo módulo con axe-core antes del despliegue, y exigir al desarrollador una declaración de compatibilidad WCAG 2.2 AA.
En DataFirefly, todos los módulos recientes (carrito lateral, alertas, búsqueda live, page builder) son probados con axe-core y lectores de pantalla antes de su publicación, y la declaración de conformidad técnica se proporciona bajo demanda para comerciantes en control administrativo.
Conclusión: el riesgo ya no es teórico
El argumento «nadie controla» ya no se sostiene un año después de la entrada en vigor del RD 193/2023. Las sanciones empiezan a caer, la declaración de accesibilidad se ha convertido en el mínimo visible, y la presión B2B se intensifica (centrales de compra, licitaciones públicas, grandes cuentas exigen ahora compromisos WCAG en sus contratos marco).
El ángulo estratégico adecuado para un comerciante PrestaShop no es el mínimo cosmético, sino utilizar la adecuación como una auditoría UX general: la mayoría de los correctores de accesibilidad mejoran también la conversión (legibilidad, contraste, navegación con teclado apreciada por los power users, mejor estructura semántica para SEO y AEO). Una inversión de 4 a 8 semanas que sirve a varios objetivos.
