La directiva en sí no menciona un plazo fijo para «hacer accesible» una tienda online. Lo que sí está establecido es la fecha en que entra en vigor la obligación: desde el 28 de junio de 2025, el requisito es exigible para los servicios que se incluyen en su ámbito de aplicación. El tiempo que tarda el proceso real para pasar de un sitio web actual a uno que cumpla con EN 301 549 (en la práctica, WCAG 2.1 nivel AA) depende del tamaño del sitio, del número de problemas y de la velocidad con que una organización pueda actuar internamente.
En la práctica, un proceso se divide en cuatro fases: inventariar, priorizar, reparar técnicamente y documentar. Una tienda online pequeña con un tema cms estándar y un proceso de compra limitado suele pasar por esas fases más rápidamente que una plataforma con su propio entorno de acceso, una experiencia de pago personalizada y múltiples idiomas. No existe una cifra que se aplique a todas las organizaciones; sin embargo, hay un patrón en los lugares donde los procesos se retrasan.
Qué regula la ley y qué no
El reglamento describe qué servicios se incluyen en el ámbito de aplicación, qué norma técnica se aplica y qué información debe contener una declaración de accesibilidad. No hay un plazo concreto del tipo «primero escanee, luego mejore dentro de X semanas». Las autoridades supervisoras observan el estado actual de un servicio y si una organización está trabajando de manera demostrable y estructurada en el cumplimiento, no un plazo fijo que fuera igual para todos. Para los requisitos específicos de cada parte de un sitio, se recomienda consultar el propio texto; por tema se ha investigado qué dicen exactamente los requisitos y dónde se encuentran en el texto oficial.
Dónde se atascan los procesos en la práctica
El primer retraso a menudo no surge de la técnica sino de la falta de claridad: las empresas no saben qué páginas, formularios y flujos se incluyen en el ámbito de aplicación y cuáles no. Un segundo problema es el paso de pago y el entorno de acceso; a menudo son componentes personalizados que no están en un tema estándar y, por lo tanto, no se actualizan automáticamente con una actualización del cms. Un tercer problema es la dependencia de un proveedor externo para el cms o el módulo de pago, donde a veces un cambio espera el lanzamiento de ese tercero. Y un cuarto problema es interno: una lista de hallazgos en lenguaje técnico queda sin resolver porque nadie sabe quién se hace cargo de cada regla.
Cuatro fases y dónde se atascan
La fase de inventario consiste en determinar qué no funciona, en qué páginas y cuán grave es para alguien que utiliza un lector de pantalla o solo un teclado. Esta es la fase en la que un escaneo automatizado realiza la mayor parte del trabajo, pero también la fase en la que debe quedar claro qué no puede ver ese escaneo; no todos los criterios WCAG pueden probarse de forma automática.
La fase de priorización convierte los hallazgos en un orden: qué bloquea completamente una compra y qué es solo una molestia menor. Esto a menudo se detiene porque una lista técnica de hallazgos no indica quién dentro de la organización es responsable de qué parte.
La fase de reparación es la fase con más tiempo de duración, y su duración depende en gran medida de si los ajustes se pueden hacer internamente o deben realizarse a través de un proveedor. Las etiquetas de formulario y el contraste de color suelen ser rápidos de resolver; un paso de compra que técnicamente no se puede usar solo con el teclado requiere más trabajo de desarrollo.
La última fase es documentar: preparar la declaración de accesibilidad, establecer un plan de mejora con plazos y demostrar que se ha realizado una evaluación propia. Esta no es una fase que se omita una vez que la técnica es correcta; la declaración debe reflejar el estado actual, incluso si ese estado aún no es perfecto.
Qué factores sí afectan el tiempo de duración
Una organización que sabe de antemano qué páginas se incluyen en el ámbito de aplicación y qué problemas tienen mayor peso pierde menos tiempo en ir y venir entre técnica y toma de decisiones. Con algunas pocas preguntas es posible ver de forma gratuita dónde se encuentra un sitio ahora, sin necesidad de una cuenta. Para continuar, es decir, el análisis completo del proceso de pago y flujo de inicio de sesión, más una lista de acciones priorizada en lenguaje sencillo, está incluido en la ruta de pago; lo que contiene está claramente organizado.
Un último factor que afecta el tiempo de ejecución: la accesibilidad no es un proyecto con fecha de finalización, sino un estado que se aplica nuevamente después de cada cambio en el sitio. Un nuevo paso de pago o un formulario de contacto renovado puede traer de vuelta un problema que ya se había resuelto. Quien quiera saber de dónde proviene la información en un informe y con qué frecuencia se actualiza, lo encontrará en la página que explica cómo funciona el proceso.
Para la situación propia, con el propio CMS, proveedor y planificación interna, sigue siendo difícil mencionar de antemano un plazo fijo. Quien dude si un proceso es realista de planificar, haría bien en aclarar primero exactamente qué debe suceder antes de construir un plan alrededor. El análisis rápido gratuito es un punto de partida lógico para eso, sin necesidad de una cuenta inmediata o pago.