Ley de accesibilidad: cumplirla y descubrir por qué convertías menos
Caso real · E-commerce de electrónica ante la fecha de la EAA, con un checkout que no se podía terminar con el teclado
La Ley Europea de Accesibilidad (EAA) puso una fecha en el calendario, y con ella llegó la conversación equivocada. Cuando la accesibilidad entra por la puerta del miedo a la sanción, el proyecto acaba siendo un certificado de conformidad que se archiva y un widget que promete arreglarlo todo con una línea de código. Ninguna de las dos cosas cumple, y las dos cuestan dinero.
Hay otra forma de mirarlo. Los fallos de accesibilidad son, casi siempre, fricción que ya estabas pagando con todos tus usuarios —no solo con los que tienen una discapacidad reconocida—. Arreglarlos es la manera más barata de encontrar esa fricción. Este es el caso de un e-commerce que empezó por obligación y terminó con un checkout que convertía más.
De dónde partíamos
«No sé si mi web cumple la nueva normativa de accesibilidad, y puedo estar dejando fuera —y perdiendo— a parte de mis clientes.»
Un e-commerce de electrónica de tamaño medio, con la fecha de la EAA encima y un correo de un cliente que no había podido completar una compra con su lector de pantalla. La dirección quería dos cosas, en este orden: no exponerse a una sanción y no volver a recibir ese correo.
La primera auditoría automática devolvió 47 incidencias en las rutas de compra. Pero lo que decidió el proyecto no salió de ninguna herramienta automática: salió de sentar a tres personas que navegan a diario con tecnología asistiva delante del checkout. Ninguna de las tres pudo terminar una compra sin ayuda.
Antes de llamarnos, la empresa ya había recibido varias propuestas. Casi todas coincidían en lo mismo: instalar una capa de accesibilidad en la web, emitir un certificado y dar el asunto por cerrado. Sonaba rápido y barato. Por eso desconfiaban.
Lo que costaba una web que no era accesible
La factura legal. Con la ley de accesibilidad ya en vigor, cada barrera en la ruta de compra era una exposición a reclamaciones y a expedientes que la empresa no sabía dimensionar.
La factura de ventas. Las personas que no podían terminar una compra no escribían todas un correo. La mayoría simplemente se iba a otra tienda. Entre ellas había clientes con discapacidad, personas mayores y cualquiera que comprara desde el móvil en condiciones poco cómodas.
La factura de soporte. Parte de los contactos al servicio de atención eran variantes de la misma frase: no puedo terminar la compra. Cada uno costaba tiempo del equipo y, a menudo, acababa en un pedido perdido igualmente.
Lo que descartamos, y por qué
El widget de accesibilidad (overlay). Es la oferta más tentadora del mercado: una capa que se superpone a la web y dice hacerla accesible sin tocar el código. No cumple —los propios colectivos de usuarios de lectores de pantalla los rechazan—, da una falsa sensación de seguridad jurídica y, a menudo, añade una barrera nueva encima de las que ya había.
El informe de conformidad que se archiva. Auditar, entregar un PDF con la lista de fallos y cobrar. El documento no arregla nada; solo traslada el problema al equipo que ya no sabía por dónde empezar.
Rehacer la web entera «ya que estamos». La tentación de convertir un requisito acotado en un rediseño de seis meses. La accesibilidad se prioriza como todo lo demás: primero, lo que toca el dinero y el riesgo —las rutas de compra—; el resto, después.
Lo que buscábamos era que una persona con lector de pantalla pudiera comprar sin ayuda, y que eso quedara resuelto en el código de la web y no en una capa encima.
Qué exige la ley de accesibilidad a un e-commerce
La Ley Europea de Accesibilidad obliga a que determinados productos y servicios sean accesibles desde el 28 de junio de 2025. El comercio electrónico dirigido a consumidores está entre ellos. En España, la directiva se incorporó al ordenamiento a través de la Ley 11/2023.
En la práctica, para una tienda online eso se traduce en tres cosas:
| Qué pide la norma | Qué significa en una tienda online | Referencia técnica |
| Que el servicio se pueda usar con tecnologías de apoyo | Buscar, elegir, pagar y recibir confirmación sin depender del ratón ni de la vista | Norma EN 301 549, que remite a las pautas WCAG nivel AA |
| Que la información sea perceptible y comprensible | Textos alternativos, contraste suficiente, errores explicados junto al campo que falla | WCAG |
| Que se informe de cómo se cumple | Explicar en la web el grado de accesibilidad del servicio y cómo contactar si algo falla | Información de accesibilidad del servicio |
Trabajamos con WCAG 2.2, la versión más reciente de las pautas, porque cubre los criterios de las anteriores y añade varios que afectan directamente a formularios y a la navegación con teclado. El detalle jurídico de cada caso, como las exenciones o el régimen sancionador, conviene revisarlo con asesoría legal.
El método: cinco fases
Fase 1. Auditoría WCAG 2.2, automática y manual
Lo automático detecta lo evidente (contrastes, etiquetas ausentes, textos alternativos). Pero la mayoría de los fallos que bloquean de verdad solo aparecen probando a mano: navegar toda la compra únicamente con el teclado, con el lector de pantalla encendido, con el zoom al 200%.
La auditoría de accesibilidad web se centró en las rutas que generan ingresos: buscador, listado, ficha de producto, carrito y pago. Una herramienta automática puede comprobar la accesibilidad de cientos de páginas en minutos, pero no sabe si una persona real consigue terminar una tarea.
Fase 2. Pruebas con usuarios de tecnología asistiva
Tres personas que usan lector de pantalla y navegación por teclado a diario, comprando de verdad. Aquí apareció el hallazgo que ninguna herramienta había marcado como crítico: al enviar el formulario de pago con un error, el foco saltaba al principio de la página y el mensaje de error no estaba asociado al campo. El usuario sabía que algo fallaba, pero no qué ni dónde.
Salieron otros bloqueos menos visibles: botones de cantidad que el lector anunciaba sin nombre, un selector de fecha de entrega imposible de manejar con el teclado y una ventana de cookies que atrapaba el foco al cargar la página.
Fase 3. Priorización por impacto
Las 47 incidencias, ordenadas por dos criterios: cuántos usuarios afecta y cuánto pesa en la ruta de compra. Primero el checkout y la ficha de producto; después el resto. No todo es igual de urgente, y tratarlo como si lo fuera es la forma más rápida de no terminar nada.
Fase 4. Rediseño accesible de componentes y plantillas, con guía
No se parchearon páginas sueltas: se corrigieron los componentes (botones, campos, mensajes de error, foco visible) y las plantillas que los usan, de modo que el arreglo se propaga y lo nuevo nace accesible. Y se dejó una guía breve para que el equipo lo mantenga sin depender de nosotros.
Fase 5. Declaración de accesibilidad y revisión continua
Con las rutas de compra conformes, se publicó la declaración de accesibilidad: qué nivel se cumple, qué partes están pendientes y cómo avisar de una barrera. Y se incorporó una comprobación de accesibilidad a cada nueva versión de la web, para que el trabajo no se deshiciera en la siguiente campaña.
Por qué esto no era solo cumplimiento
El error que bloqueaba al usuario con lector de pantalla —el foco perdido, el mensaje de error huérfano— no era exclusivo de él. Cualquiera que rellena rápido con el teclado, con el móvil a pleno sol o con una mano ocupada se comporta como un usuario con capacidad reducida. Arreglar el checkout para el caso más exigente lo arregló para todos.
Resultados
| Indicador | Antes → después |
| Incidencias WCAG críticas en rutas de compra | 47 → 0 |
| Conversión de checkout | +11% (todos los usuarios, no solo tecnología asistiva) |
| Contactos de soporte «no puedo terminar la compra» | −64% |
| Rutas de compra | Conformes con WCAG 2.2 AA en la auditoría final |
Cumplir la ley era el motivo. El +11% de conversión fue el efecto secundario —y pagó el proyecto varias veces—. La accesibilidad, bien entendida, no es un coste de cumplimiento: es un diagnóstico de fricción que llevabas tiempo pagando sin verlo.
El equipo de desarrollo trabaja ahora con componentes que ya nacen accesibles. Las nuevas páginas de campaña se montan sobre ellos, y la accesibilidad dejó de ser una revisión al final para ser una propiedad de la web.
Y el correo que abrió el proyecto no ha vuelto a repetirse. La persona que lo envió volvió a comprar, esta vez sin ayuda.
Datos ilustrativos de un caso real anonimizado. Tu punto de partida y tus cifras variarán según la web y el sector.
Por qué lo hacemos así
La accesibilidad digital se suele contratar como un trámite: un informe, un sello o una capa de código. Ninguno de los tres consigue que una persona con lector de pantalla termine una compra, que es lo único que de verdad importa, a la ley y al negocio.
Por eso trabajamos con tres principios:
- Probar con personas reales que usan tecnología asistiva, además de las herramientas automáticas.
- Priorizar por impacto en las rutas que generan ingresos, no por el orden de un listado de incidencias.
- Corregir en componentes y plantillas, para que la accesibilidad se mantenga sola en cada cambio de la web.
Dónde no aplica: si tu web es informativa y no vende ni presta servicios a consumidores, la obligación legal puede ser distinta, aunque las barreras siguen costando usuarios. Y si la plataforma de tu tienda es cerrada y no permite modificar componentes, parte del trabajo dependerá de tu proveedor, y conviene saberlo antes de empezar.
Preguntas frecuentes
¿Qué es la Ley Europea de Accesibilidad y a quién afecta?
Es una directiva europea que obliga a que determinados productos y servicios sean accesibles para personas con discapacidad desde el 28 de junio de 2025. Afecta, entre otros, al comercio electrónico dirigido a consumidores, la banca, el transporte y los libros electrónicos. En España se incorporó mediante la Ley 11/2023. Las microempresas que prestan servicios tienen exenciones, que conviene revisar con asesoría legal.
¿Es obligatoria la accesibilidad web para un e-commerce?
Para la mayoría de tiendas online que venden a consumidores en la Unión Europea, sí, desde junio de 2025. La obligación alcanza a todo el proceso de compra: buscar productos, consultar la ficha, añadir al carrito, pagar y recibir la confirmación. Además, la tienda debe informar de cómo cumple los requisitos de accesibilidad. El alcance exacto depende del tamaño de la empresa y del tipo de servicio.
¿Qué nivel de WCAG hay que cumplir?
La referencia técnica habitual es la norma europea EN 301 549, que remite a las pautas WCAG en su nivel AA. En la práctica, eso significa cumplir los criterios de nivel A y AA: textos alternativos, contraste suficiente, navegación completa con teclado, formularios con errores bien explicados y contenidos compatibles con lectores de pantalla. Trabajar ya con WCAG 2.2 cubre esos criterios y los más recientes.
¿Sirve un widget de accesibilidad para cumplir la ley?
No. Un widget o overlay de accesibilidad añade una capa sobre la web sin corregir el código de fondo, y los problemas estructurales, como un foco que se pierde o un formulario mal etiquetado, siguen ahí. Muchos usuarios de lectores de pantalla los desactivan porque interfieren con su tecnología. Además, transmiten una seguridad jurídica que no tienen: la conformidad se evalúa sobre la web, no sobre el widget.
¿Cómo comprobar la accesibilidad de una web?
Combinando tres pruebas. Una herramienta automática detecta errores evidentes como contrastes insuficientes o imágenes sin texto alternativo. Una revisión manual comprueba si todo el recorrido se puede completar solo con el teclado, con lector de pantalla y con zoom. Y las pruebas con usuarios de tecnología asistiva revelan los bloqueos reales. Solo con las tres se obtiene una auditoría de accesibilidad web fiable.
¿La accesibilidad web mejora la conversión?
En muchos casos, sí. Los fallos que bloquean a una persona con discapacidad, como errores mal explicados o botones difíciles de usar, también frenan a cualquiera que compra desde el móvil, con prisa o en malas condiciones. Corregirlos reduce la fricción para todos los usuarios. Por eso un proyecto de accesibilidad bien planteado suele mejorar la conversión además de reducir el riesgo legal.
¿Podría una persona con lector de pantalla terminar hoy una compra en tu tienda sin pedir ayuda? Si no lo has probado, no lo sabes, y ninguna herramienta automática te lo va a decir.
Cuéntanos cómo es tu tienda y dónde crees que están las barreras, y en la primera conversación sabremos qué partes de tu ruta de compra conviene revisar primero.
Otros casos de uso
Otros proyectos donde resolvimos el mismo tipo de problema.