El 28 de junio de 2025 entró en vigor la European Accessibility Act en España (transpuesta como Ley 11/2023) y por primera vez las empresas privadas tienen la obligación legal de garantizar que sus productos digitales sean accesibles.
Probablemente llegas tarde. Yo también lo habría estado si no hubiera liderado el esfuerzo de accesibilidad en WordPress.com los meses previos.
No voy a explicarte qué es la ley ni todos los requisitos técnicos, porque eso lo encuentras en mil sitios. Voy a contarte lo que aprendimos haciendo el trabajo real.
A quién afecta
Si tu empresa, o la empresa en la que trabajas, tiene más de 10 empleados o factura más de 2 millones de euros, y ofrece servicios digitales en la Unión Europea, te afecta. Esto incluye comercio electrónico, banca y finanzas, telecomunicaciones, transporte y prácticamente cualquier servicio digital.
Las sanciones en España van de 30.000€ a 1.000.000€ por infracción, así que no es para tomárselo a broma. Pero hay algo todavía más relevante: si tu producto no es accesible, estás excluyendo al 15-20% de tus usuarios potenciales.
Qué exige la ley
La ley exige cumplir con la norma EN 301 549, que incorpora las WCAG 2.1 nivel AA. Si lo resumimos mucho, en la práctica tu producto tiene que ser:
- Perceptible: la información se puede percibir de diferentes formas (no solo visualmente).
- Operable: se puede usar con teclado, no solo ratón.
- Comprensible: navegación predecible, contenido claro.
- Robusto: funciona con lectores de pantalla y otras tecnologías de asistencia.
También exige publicar una declaración de accesibilidad explicando tu nivel de cumplimiento (así lo hace WordPress.com).
Si quieres profundizar en los principios básicos, escribí sobre ello en cómo diseñar una web y una app accesible.
Lo que aprendí liderando la accesibilidad en WordPress.com
Tras varias reuniones, se decidió que era mejor que el equipo de diseño tomase las riendas del esfuerzo de accesibilidad en WordPress.com. No se trataba solo de hacer una auditoría: fue alinear a diseño y desarrollo, priorizar qué arreglar primero, y asegurarme de que el equipo entendiera el porqué detrás de cada cambio.
Consultar con el equipo de legal
Me agobié mucho cuando empecé a pensar en cómo estructurar la tarea. WordPress.com no es un producto sencillo, y al principio me parecía una tarea enorme. Decidí hablar con el equipo de Legal para tener claro cuál era el mínimo viable, y qué podíamos hacer más tarde.
Eso me ayudó a poder comunicarlo bien con el equipo, y a priorizar adecuadamente los flujos.
Comunicar y alinear
El primer paso consistió en escribir la documentación interna explicando qué teníamos que cambiar y por qué. Ese paso fue clave para que desarrollo y diseño estuvieran alineados desde el principio, sin tener que justificar cada decisión individualmente, y poder darle prioridad al proyecto de forma clara.
Priorizar flujos críticos
Cuando los recursos y el tiempo son limitados, es momento de buscar la manera de priorizar adecuadamente. Decidimos hacerlo por impacto (volumen de usuarios), criticidad del flujo (checkout), y siguiendo las directrices de la ley. Si un usuario no puede avanzar por el flujo principal, el resto no importa.
Establecer los criterios de evaluación (success criteria)
El final del artículo interno contenía una lista que, de cumplirse, nos permitiría establecer que nuestros flujos son accesibles. En el caso concreto de WordPress.com de ese momento:
- Todas las interfaces en las que el usuario está identificado cumplen con WCAG 2.1 AA
- Todos los flujos de checkout, landing pages de alto tráfico y correos electrónicos cumplen con WCAG 2.1 AA
- Todos los componentes del sistema de diseño cumplen con los estándares de accesibilidad
- Ofrecemos guías a los usuarios para que puedan escoger opciones accesibles
- Todos los themes de Automattic en activo cumplen con WCAG 2.1 AA
- Se completan y documentan todos los tests internos
Las herramientas automáticas no son suficiente
Al principio utilizamos herramientas automáticas como axe, Lighthouse, WAVE… y no lo detectaron todo. Estas herramientas funcionan muy bien para tener una idea general de qué hay que hacer, pero siempre hay que hacer una revisión manual para poder comprobarlo todo en profundidad.
Herramientas que uso
En Figma: El infalible Stark, que es muy útil para verificar el contraste y simular problemas de visión. El A11y Annotation Kit va muy bien para poder documentar los requisitos de forma visual.
En el navegador: axe DevTools para auditorías (relativamente) completas y WAVE para identificar problemas visualmente. Recuerda que nunca te mostrarán el 100% de los problemas.
Para testing: VoiceOver (Mac) o NVDA (Windows) para probar con lectores de pantalla. Prepárate porque es una experiencia bastante interesante 👀
Si te interesa el tema, tengo un artículo más completo sobre herramientas de accesibilidad para diseñadores.
¿Y si ya voy tarde?
Vas tarde, pero no estás perdido. Los productos que existían antes del 28 de junio de 2025 tienen hasta junio de 2030 para cumplir completamente.
Lo importante es demostrar que estás trabajando en ello: tener auditoría documentada, un plan de acción con fechas, y una declaración de accesibilidad publicada.
Pero no uses 2030 como excusa, que cinco años pasan rápido 😏
