Imagina un flujo de compra normal: carrito, datos de envío, pago, confirmación. Lo han diseñado con cuidado, se ve bien, convierte razonablemente. Ahora intenta completarlo sin ratón, solo con el teclado. Después, con un lector de pantalla. Es un ejercicio de unos minutos y suele enseñar más que cualquier informe. Este caso es hipotético, pero los fallos que aparecen son de los más repetidos en productos digitales, y desde el 28 de junio de 2025 la accesibilidad web es obligatoria en muchos servicios, así que tienen también una parte legal.
En corto: Desde el 28 de junio de 2025 la accesibilidad web es obligatoria para muchos servicios digitales dirigidos a consumidores en España (Ley 11/2023, que traslada la Directiva europea 2019/882). Es más barato diseñarla desde el principio que corregirla al final.
Dónde se rompe, paso a paso
El carrito. El botón de «Eliminar» es un icono sin texto. Con lector de pantalla se oye «botón», sin más. Con teclado, no se llega.
El formulario de envío. Los campos tienen texto de ejemplo en lugar de etiqueta. Al escribir, la etiqueta desaparece. Quien usa lector de pantalla no sabe qué campo es, y quien tiene dificultad para recordar tampoco.
El error. Te has equivocado en el código postal. El campo se pone rojo y ya. Nada dice qué ha pasado ni dónde. Si no distingues el rojo, no ves ni que hay error.
El pago. Un desplegable personalizado para elegir el método que solo responde al clic. El teclado se queda atrapado.
La confirmación. Un mensaje que aparece unos segundos y desaparece. Si no lo has visto, no sabes si has comprado.
Ninguno de estos fallos es un error de código. El desarrollador implementó lo que le pidieron. El fallo está en la pantalla, en la historia de usuario o en el criterio de aceptación, es decir, en una decisión anterior.
Cuánto cuesta cada momento
No pongo cifras, porque dependen de cada producto, pero el orden siempre es el mismo:
| Cuándo se detecta | Qué obliga a hacer |
|---|---|
| En el primer boceto | Cambiar una etiqueta, un color, un orden |
| En el diseño de componentes | Redefinir un componente que aún no usa nadie |
| En desarrollo | Rehacer piezas y volver a revisar |
| Con el producto en producción | Rediseñar, desarrollar, probar y desplegar, con usuarios usándolo mientras tanto |
Ese escalón de coste es para mí el argumento más sólido, más que la ley. Y en equipos con varios proveedores sube otro escalón, porque cada vuelta exige coordinación.
Por qué se deja siempre para el final
Tiene una explicación bastante humana. La accesibilidad web no se ve en una demo, no lleva a nadie a decir «qué bien se ve», y cuando hay prisa es lo primero que se aparca. Además, quien decide el diseño rara vez es quien después prueba con teclado o con lector de pantalla, así que el fallo no se ve hasta tarde. Es un requisito invisible mientras funciona y muy visible cuando falla.
Por eso me parece que no es cuestión de concienciar a nadie, sino de ponerla donde ya se toman las decisiones: en el sistema de componentes, en los criterios de aceptación y en la revisión de cada entrega. Si depende de la buena voluntad de alguien, se cae el día que hay prisa.
Accesibilidad web obligatoria: qué dice la norma, sin hacer de abogado
La Directiva (UE) 2019/882, European Accessibility Act, se trasladó a la ley española con la Ley 11/2023. Establece requisitos de accesibilidad web para determinados productos y servicios, y su aplicación efectiva llegó hasta el 28 de junio de 2025. Entre los servicios afectados está el comercio electrónico dirigido a consumidores, además de otros que fija la propia ley.
La Directiva exime a las microempresas que prestan servicios: menos de 10 personas y un volumen de negocio o balance que no supere los 2 millones de euros. La exención no cubre los productos, así que conviene comprobar cada caso.
Cómo evitar el recorrido de arriba
He trabajado organizando equipos de UX, desarrollo y SEO, y la accesibilidad web se parece a cualquier requisito de calidad: funciona si alguien es responsable y si está escrita. Sobre la parte de experiencia de usuario ya escribí en reglas de diseño para una aplicación móvil y en crear una buena app gracias a UX.
- Una vez, en el sistema de diseño. Contraste, tamaños, foco, mensajes de error y áreas táctiles definidos en los componentes. Si el componente nace accesible, todo lo que lo usa lo hereda.
- En la definición de «hecho». Cada historia incluye que se puede usar con teclado y que se entiende con lector de pantalla.
- En la demo. Probar con teclado y lector forma parte de cada entrega, cinco minutos y sin auditoría aparte.
- En el acuerdo con proveedores. Si no está escrito, cada uno entenderá algo distinto. Como referencia técnica suele usarse WCAG nivel AA.
- Con el producto vivo. Un portal accesible el día del lanzamiento deja de serlo si cada contenido nuevo entra sin criterio.
Qué cambia cuando hay varios equipos o proveedores
Con un solo equipo, la accesibilidad depende de que ese equipo la tenga clara. Con varios, depende de que todos entiendan lo mismo. Un proveedor construye los componentes, otro las plantillas, otro integra el contenido, y el fallo puede aparecer en la unión. Lo que suele funcionar es que haya un único documento de criterios, que lo vea todo el mundo el primer día, y una persona que pueda parar una entrega si no se cumple. Sin ese documento, cada pieza cumple por separado y el conjunto falla.
También ayuda que las pruebas sean compartidas. Si cada proveedor prueba a su manera, nadie puede comparar. Un guion común de cinco o seis comprobaciones, con teclado y lector, es suficiente para empezar.
Lo que gana el producto, más allá de la ley
Lo accesible suele ser lo más fácil de usar para todos. Un error explicado se agradece siempre. Un buen contraste, en un móvil a pleno sol. Una navegación que no depende de un gesto sirve con una mano ocupada. Creo que en bastantes casos mejorar la accesibilidad web mejora la conversión sin que nadie se lo proponga. No lo prometo con cifras: tiene lógica, porque quitar obstáculos hace que más gente llegue al final.
Cómo se lo cuento a un cliente
Al cliente no le interesa la directiva. Le interesa si puede tener un problema, cuánto va a costar y qué tiene que decidir. Le diría qué servicios suyos entran en el ámbito, qué cumple hoy el producto y qué no, y le propondría un plan por fases con fechas. No prometería cumplimiento total sin haber probado con personas reales: una declaración de accesibilidad sin comprobación detrás es peor que una lista de pendientes honesta.
Si quieres que miremos tu producto, tienes mi página de diseño de producto. Y si tienes un producto vivo, empieza hoy: elige el flujo que da dinero y recórrelo con el teclado. La lista de bloqueos que salga es el primer plan de trabajo.
Preguntas frecuentes
¿Desde cuándo es obligatoria la accesibilidad en servicios digitales en España?
Desde el 28 de junio de 2025, con la Ley 11/2023 que traslada la Directiva (UE) 2019/882.
¿A qué servicios afecta?
A servicios dirigidos a consumidores, como el comercio electrónico y otros que fija la ley. La Directiva exime a las microempresas que prestan servicios, algo que conviene comprobar caso a caso.
¿Cuándo es mejor tener en cuenta la accesibilidad en un proyecto?
En el diseño y en la definición de cada historia, no en una revisión final.
