Accesibilidad para tiendas online: qué significa para ti la Ley Europea de Accesibilidad
Revisado en junio de 2026. La EAA se aplica desde el 28 de junio de 2025 y se ejecuta mediante transposiciones nacionales (la BFSG alemana y equivalentes en otros países), que pueden variar en detalles y umbrales; las cifras de este artículo son los criterios de referencia publicados por la UE, no una resolución sobre tu caso. Las vías técnicas se aplican a PrestaShop 1.7, 8 y 9 con el tema classic. Esto no es asesoramiento jurídico: confirma tu alcance, tu posible exención y tus obligaciones nacionales con un abogado de tu país, y ten en cuenta que ningún módulo ni tema hace que una tienda sea "conforme" por sí solo.
Este es el dato que muchos comerciantes de PrestaShop solo han asimilado a medias: desde el 28 de junio de 2025, la Ley Europea de Accesibilidad (EAA) convierte la accesibilidad web en una obligación legal para la mayoría de las tiendas online que venden a consumidores de la UE; no es un extra deseable ni un problema para 2030. Se aplica a nivel de cada Estado miembro (BFSG en Alemania, la directiva transpuesta en cada país), y la obligación recae en el comerciante, no en PrestaShop ni en el proveedor de tu tema. Si tu proceso de pago no puede completarse con el teclado, ahora tienes una brecha de cumplimiento con tu nombre.
Esta guía trata específicamente de qué significa la EAA para una tienda PrestaShop y cómo cerrar las brechas dentro del software que realmente usas: el tema, el back office y los módulos. Es el capítulo de accesibilidad de nuestro bloque de cumplimiento, así que cuando un tema pertenezca a un artículo hermano (banners de cookies, GDPR, condiciones) encontrarás una referencia breve en lugar de repetirlo todo. Para una visión legal más amplia sobre vender en la UE, empieza por la legislación de comercio electrónico en la UE.
A quién cubre realmente la EAA (y quién está exento)
Antes de dedicar un fin de semana al texto alternativo, comprueba si la ley se te aplica por completo, porque la respuesta cambia lo que tienes que hacer.
- Vendes B2C a consumidores de la UE: estás dentro del ámbito de aplicación. Los "servicios de comercio electrónico" se mencionan expresamente en la Ley.
- Eres una microempresa que vende servicios: menos de 10 empleados y menos de 2 millones de euros de facturación anual o de balance total; los proveedores de servicios de este tamaño están exentos de las obligaciones de servicio. Esta es la excepción en la que encajan muchas tiendas pequeñas, pero lee el punto siguiente antes de relajarte.
- Vendes productos (la lista de productos regulados por la EAA: lectores electrónicos, hardware, terminales): la exención de microempresa para servicios no cubre los productos. La mayoría de tiendas de ropa, cosmética o artículos para el hogar no venden productos regulados, así que rara vez es la trampa principal; aun así, verifícalo en lugar de asumirlo.
- B2B puro: por lo general queda fuera del ámbito orientado al consumidor, aunque la accesibilidad sigue siendo una buena práctica y puede ser un requisito contractual de compradores de mayor tamaño.
¿Y qué implica? Una boutique polaca de dos personas por debajo del umbral de facturación probablemente esté exenta de la presión legal directa, pero la accesibilidad aun así amplía su mercado y ayuda a su SEO, por lo que el trabajo compensa igualmente. Una tienda en crecimiento pierde la exención cuando deja de cumplir los requisitos de microempresa según las normas nacionales aplicables. Trata el umbral como un plazo hacia el que avanzas, no como un escudo permanente. Esta guía no ofrece deliberadamente asesoramiento jurídico sobre tu situación concreta: confírmala con un abogado de tu país; las cifras aquí indicadas son los umbrales publicados por la UE, no una resolución sobre tu caso.
El estándar detrás de la ley: WCAG 2.1 AA, en términos claros
La propia EAA no enumera ratios de píxeles. Remite al estándar armonizado EN 301 549, que a su vez adopta WCAG 2.1 Nivel AA como base para la web. Ese es el listón que debe superar el front office de tu PrestaShop. Los criterios de éxito que afectan a una tienda típica son una lista breve, y cada uno se corresponde con algo concreto de tu tema:
| Criterio WCAG | Qué significa en tu tienda | Dónde suele romperse en PrestaShop |
|---|---|---|
| 1.1.1 Contenido no textual | Las imágenes tienen texto alternativo significativo | Imágenes de producto importadas con el nombre de archivo como alt; iconos decorativos sin alt vacío |
| 1.4.3 Contraste (mínimo) | 4.5:1 para texto normal, 3:1 para texto grande | Precios/"precio anterior" en gris claro, etiquetas de marcador de posición atenuadas, insignias de oferta con bajo contraste |
| 2.1.1 Teclado | Todo se puede operar sin ratón | Megamenú que solo aparece al pasar el cursor, flechas de carrusel que nunca reciben el foco |
| 2.4.7 Foco visible | El elemento enfocado se distingue claramente | CSS del tema con outline: none en enlaces/botones |
| 3.3.1 / 3.3.2 Etiquetas & errores | Los campos tienen etiquetas reales; los errores nombran el campo | Campos del proceso de pago solo con marcador de posición; banner genérico de "Hay 1 error" |
| 4.1.3 Mensajes de estado | Los cambios AJAX se anuncian | Total del carrito / actualizaciones del filtro por facetas silenciosas para lectores de pantalla |
Fíjate en el patrón: casi nada de esto son fallos del núcleo de PrestaShop. Son decisiones integradas en tu tema y en tus módulos. Es una buena noticia: significa que las correcciones viven en archivos que controlas.
Dónde te ayuda PrestaShop y dónde te deja expuesto

El tema classic predeterminado de PrestaShop 1.7 a 9 está construido sobre Bootstrap y es un punto de partida razonable: los campos de formulario usan elementos <label> reales, el proceso de pago tiene un orden lógico de encabezados y la mayoría de controles nativos son accesibles mediante teclado. Si trabajas bastante cerca del classic original, vas más avanzado de lo que crees.
La exposición viene de tres lugares previsibles:
- Tu tema personalizado o comprado. La mayoría de temas de pago eliminan visualmente el contorno de foco, añaden menús que solo funcionan al pasar el cursor y usan tipografías grises finas que no cumplen 1.4.3. Esta es la mayor fuente de fallos reales.
- Módulos que inyectan marcado en el front office. Sliders, ventanas emergentes de vista rápida, banners de cookies, corazones de lista de deseos, desplegables de búsqueda en vivo: cada uno añade DOM interactivo que quizá no sea operable por teclado o no se anuncie. Cada módulo que instalas es una nueva superficie de accesibilidad que hay que probar.
- Contenido que redactas. Descripciones de producto con imágenes insertadas desde el editor enriquecido (sin alt), páginas CMS con niveles de encabezado saltados, PDF enlazados como "haz clic aquí". PrestaShop no puede corregir lo que escribes.
Lista de corrección específica para PrestaShop
El consejo genérico de "añade texto alternativo" no sirve de nada si no sabes dónde. Aquí tienes el mapa de back office y código, aproximadamente en orden de relación entre esfuerzo y beneficio.
1. Texto alternativo de las imágenes de producto: corrígelo en origen y en bloque
En el editor de producto, la pestaña Catálogo → Productos → [producto] → Imágenes tiene un campo Leyenda por imagen; ese valor se convierte en el atributo alt en el front office. Rellenarlo producto a producto en un catálogo real es donde mueren las buenas intenciones. Hay dos vías más rápidas:
- SQL/en bloque: el texto alternativo de las imágenes vive en ps_image_lang.legend (indexado por id_image e id_lang). Una actualización controlada ahí, o una importación, supera a editar a mano cientos de filas; haz primero una copia de seguridad.
- Deja de crear deuda: incorpora una leyenda útil a tu rutina de alta de productos para que las imágenes nuevas nunca queden en blanco. Un buen texto alternativo también lo lee Google Images, así que es accesibilidad y visibilidad en un solo movimiento; nuestra suite Smart SEO Revolution existe para mantener limpio ese tipo de metadatos on-page a escala de catálogo, no producto por producto.
2. Visibilidad del foco: normalmente una corrección de una línea en el tema
Si el CSS de tu tema contiene outline: none u outline: 0 en enlaces, botones o campos sin un sustituto igual de visible, los usuarios de teclado pierden por completo su ubicación. Búscalo en assets/css/ de tu tema (y en cualquier custom.css). La corrección adecuada no es borrar la regla a ciegas, sino proporcionar un estilo :focus-visible claro: un contorno de 2px con alto contraste. Es el cambio de mayor impacto y menor esfuerzo de toda la lista.
Añade esto al custom.css de tu tema (o a una hoja de estilo de un tema hijo, para que una actualización del tema no lo borre) y restaurará un anillo de foco visible en los elementos interactivos sin reactivar los contornos al hacer clic con el ratón:
/* Restore a visible keyboard focus indicator (WCAG 2.4.7) */
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible {
outline: 2px solid #1a1a1a; /* pick a colour that hits 3:1 against its background */
outline-offset: 2px;
}
El color del contorno debe alcanzar un contraste de 3:1 frente a lo que tenga detrás, así que ajusta el hexadecimal a tu paleta en lugar de copiarlo sin más. Si el tema estableció outline: none con !important, quizá necesites igualar esa especificidad, pero es preferible eliminar la regla problemática en su origen antes que apilar otro !important encima.
3. Proceso de pago y formularios: la parte donde hay dinero en juego
El proceso de pago es tanto la página más sensible jurídicamente como la más sensible comercialmente de tu tienda. Recorre con la tecla Tab todo el flujo de pedido en el controlador order de PrestaShop: información personal, direcciones, entrega y pago, usando solo el teclado. Confirma que cada campo tenga una etiqueta visible (no solo marcador de posición), que los botones de opción del transportista sean alcanzables y que los errores de validación nombren el campo afectado en lugar de mostrar un banner genérico. Los iframes de pago de terceros (Stripe, PayPal, Adyen) tienen su propia accesibilidad: prueba el envío real de principio a fin, no solo la carga de la página. Como un proceso de pago accesible y uno que convierte bien son, en gran medida, el mismo proceso, esto se solapa con todo lo que explicamos en nuestra guía de seguridad en pagos sobre cómo dejar ese flujo bien resuelto.
4. Mensajes de estado AJAX: el punto ciego de los lectores de pantalla
PrestaShop actualiza el total del carrito y la cuadrícula de productos de ps_facetedsearch sin recargar la página. Un usuario con visión ve cambiar el número; un usuario de lector de pantalla no oye nada salvo que la región actualizada esté marcada como aria-live="polite". Esto es WCAG 4.1.3, y es el criterio que las herramientas automáticas suelen pasar por alto. Comprueba que el bloque de subtotal del carrito y el contenedor de resultados de búsqueda por facetas anuncien sus actualizaciones; si un módulo sustituyó el carrito o la búsqueda nativos, la responsabilidad de esa afirmación recae en ese módulo.
5. Jerarquía de encabezados y contraste: auditables en minutos
Confirma que cada página tenga exactamente un <h1> y que no haya saltos de nivel (una página de categoría que pasa de H1 a H3 confunde la navegación con lector de pantalla). Para el contraste, los culpables habituales son el color atenuado del precio/precio anterior, las insignias de oferta y el texto de marcador de posición; pásalos por cualquier comprobador de contraste frente a 4.5:1.
Probar tu tienda como lo harán los reguladores
Los escáneres automáticos detectan una minoría de los problemas, a menudo se habla de aproximadamente un tercio, aunque las estimaciones varían según la herramienta y el sitio. , Así que son una línea de salida, no la meta. Superpón tus pruebas:
- Primera pasada automática: Lighthouse (Chrome DevTools → auditoría de accesibilidad), la extensión WAVE y axe DevTools. Ejecútalas en la página de inicio, una categoría, un producto, el carrito y cada paso del proceso de pago; no solo en la página de inicio.
- Recorrido solo con teclado: desconecta el ratón. Usa Tab desde el logotipo hasta completar un pedido. Cualquier cosa que no puedas alcanzar o activar es un fallo, sin matices.
- Recorrido con lector de pantalla: NVDA (Windows, gratuito) o VoiceOver (Mac, integrado). Escucha una página de producto y un proceso de pago. Esto revela problemas de texto alternativo, etiquetas y aria-live que ningún escáner marcará con plena confianza.
- Zoom al 200%: verifica que no se recorte contenido y que nada exija desplazamiento horizontal.
La declaración de accesibilidad: el documento que se olvida
Varias transposiciones de Estados miembros esperan una declaración de accesibilidad publicada: el estándar al que apuntas (EN 301 549 / WCAG 2.1 AA), las limitaciones conocidas y un canal de contacto para comentarios sobre accesibilidad. En PrestaShop lo más sencillo es crear una página CMS (Diseño → Páginas) enlazada desde el pie de página, junto a tus demás páginas legales. Va en el mismo estante que tus términos y condiciones y, como ellos, es un documento vivo que actualizas cuando corriges o descubres un problema.
Dónde se solapa la accesibilidad con el resto de tu pila de cumplimiento
Dos partes del trabajo de accesibilidad son en realidad terreno compartido con temas hermanos, así que trátalas donde viven en lugar de duplicarlas:
- El banner de consentimiento de cookies. Un banner que atrapa a usuarios de teclado o no puede cerrarse sin ratón incumple tanto la accesibilidad como la normativa de consentimiento. Haz bien el banner una vez; lo que debe hacer legalmente está en consentimiento de cookies para PrestaShop y GDPR y cumplimiento de cookies para PrestaShop; después prueba ese mismo banner para confirmar que se puede manejar con teclado.
- Datos y formularios. El trabajo de formularios accesibles en las páginas de cuenta y contacto está justo al lado de tus obligaciones de tratamiento de datos; la parte de privacidad está cubierta en GDPR para tiendas online.
El argumento de negocio más allá de la multa
Conviene resistirse a presentar la accesibilidad como un simple impuesto. Una parte significativa de la población, se suele citar alrededor de una de cada siete personas en el mundo, con cifras nacionales variables, tiene alguna discapacidad, y muchas más usan funciones de accesibilidad de forma situacional: reflejos en el móvil bajo el sol, una muñeca lesionada, un bebé dormido que descarta el audio. Cada una de esas personas es un cliente al que ahora mismo le estás poniendo un proceso de pago más difícil de lo necesario.
La conexión con la buena ingeniería también es real. Una estructura correcta de encabezados y el texto alternativo son las mismas señales que premian los buscadores; las etiquetas claras y el foco visible reducen errores de formulario y abandono para todo el mundo, no solo para usuarios de tecnologías de asistencia. Es poco probable que puedas separar del todo "hicimos esto por la EAA" de "esto simplemente mejoró la tienda". Esa es la razón honesta para hacer el trabajo aunque hoy mantengas la exención de microempresa.
Hacer que perdure: la accesibilidad como rutina, no como proyecto
Las tiendas que se mantienen conformes no hacen una auditoría heroica de una sola vez para luego olvidarla; incorporan unas pocas comprobaciones a hábitos ya existentes:
- Al añadir un producto: pon leyenda a cada imagen, mantén las descripciones con encabezados/listas reales en lugar de falsos encabezados en negrita.
- Al instalar un módulo: recorre con Tab cualquier elemento de front office que añada antes de publicarlo; un slider o una ventana emergente inaccesible es una regresión que has introducido.
- Al cambiar tema o diseño: repite las pruebas de teclado y contraste; los rediseños son el lugar donde los contornos de foco y el contraste suelen desaparecer en silencio.
- Cada trimestre: una revisión de 30 minutos con Lighthouse + teclado del embudo principal (inicio → categoría → producto → carrito → proceso de pago).
Preguntas frecuentes
¿La EAA se aplica a mi pequeña tienda PrestaShop?
Depende del tamaño y de lo que vendas. Una microempresa que presta servicios, menos de 10 empleados y menos de 2 millones de euros de facturación o de balance total, suele estar exenta de las obligaciones de servicio, lo que cubre muchas tiendas B2C pequeñas. Pero la exención no se extiende a la lista de productos regulados por la EAA, y el B2B puro queda en gran parte fuera del ámbito de consumidores. Estos son los umbrales publicados por la UE, no una resolución sobre tu caso; confirma tu situación con un abogado de tu país, porque las transposiciones nacionales varían.
¿Qué estándar de accesibilidad tengo que cumplir realmente?
La EAA remite al estándar armonizado EN 301 549, que adopta WCAG 2.1 Nivel AA como base web. Ese es el listón que debe superar tu tienda. Los criterios que afectan a una tienda PrestaShop típica son una lista breve: texto alternativo, contraste, operabilidad con teclado, foco visible, etiquetas reales en formularios y actualizaciones AJAX anunciadas; casi todos dependen del tema o de los módulos, no de fallos del núcleo.
¿El tema classic predeterminado de PrestaShop es accesible de serie?
Es un punto de partida razonable, no una garantía. Classic usa elementos <label> reales, un orden lógico de encabezados en el proceso de pago y controles en su mayoría alcanzables con teclado. Los fallos suelen llegar con un tema personalizado o comprado que eliminó el contorno de foco y usa texto gris fino, con módulos que inyectan marcado interactivo y con contenido que redactas sin texto alternativo. Cuanto más cerca estés del classic original, menos corrección tendrás por delante.
¿Un escáner automático me dirá si cumplo?
No. Las herramientas automáticas (Lighthouse, WAVE, axe) detectan solo una minoría de problemas, se suele citar alrededor de un tercio, aunque varía según la herramienta y el sitio. , Así que son un punto de partida. Aún necesitas una prueba solo con teclado (desconecta el ratón, usa Tab desde el logotipo hasta completar el pedido), una pasada con lector de pantalla (NVDA o VoiceOver) y una comprobación con zoom al 200%. Los criterios que más se les escapan a los escáneres son exactamente los que encuentran reguladores y usuarios reales: anuncios aria-live, calidad de las etiquetas y trampas de teclado.
¿Necesito una declaración de accesibilidad y dónde va en PrestaShop?
Varias transposiciones de Estados miembros esperan una: el estándar al que apuntas (EN 301 549 / WCAG 2.1 AA), las limitaciones conocidas y un canal de contacto para comentarios sobre accesibilidad. El lugar más sencillo en PrestaShop es una página CMS en Diseño → Páginas, enlazada desde el pie de página junto a tus demás páginas legales. Trátala como un documento vivo que actualizas cada vez que corriges o descubres un problema.
La EAA no inventó un nuevo tipo de trabajo; puso una fecha límite legal a trabajo de UX que te beneficia de todos modos. En PrestaShop, en concreto, ese trabajo es especialmente abordable porque los fallos se concentran en tu tema, tus módulos y el contenido que redactas: todo lo puedes ver y cambiar desde tu propio back office. Empieza por el proceso de pago (la página donde inaccesibilidad e ingresos perdidos son el mismo problema), corrige el contorno de foco que tu tema eliminó, controla el texto alternativo desde el origen y habrás superado buena parte del listón antes de tocar nada exótico.
Comentarios
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.