La direttiva stessa non fissa un termine preciso per "rendere accessibile" un negozio online. Ciò che è definito con certezza è la data in cui l'obbligo diventa applicabile: dal 28 giugno 2025 il requisito è vincolante per i servizi che rientrano nell'ambito di applicazione. La durata effettiva del percorso per passare da un sito web attuale a un sito conforme a EN 301 549 (in pratica WCAG 2.1 livello AA) dipende dalle dimensioni del sito, dal numero di problemi e dalla velocità con cui un'organizzazione può coordinare i propri sforzi internamente.
In pratica, un percorso si articola in quattro fasi: inventariazione, prioritizzazione, correzione tecnica e documentazione. Un piccolo negozio online con un tema cms standard e una procedura di pagamento limitata di solito completa queste fasi più velocemente di una piattaforma con un proprio ambiente di accesso, un checkout personalizzato e più lingue. Non esiste un numero che valga per ogni organizzazione; tuttavia esiste un modello sui punti in cui i percorsi tendono a rallentare.
Cosa regola la legge e cosa no
Il regolamento descrive quali servizi rientrano nell'ambito di applicazione, quale norma tecnica si applica e quali informazioni deve contenere una dichiarazione di accessibilità. Un termine concreto del tipo "scansionare prima, poi migliorare entro X settimane" non è presente. Le autorità di controllo esaminano lo stato attuale di un servizio e se un'organizzazione sta dimostrabilmente e sistematicamente lavorando al rispetto dei requisiti, non un tempo fisso che sarebbe lo stesso per tutti. Per i requisiti precisi di ogni parte di un sito è consigliabile consultare direttamente il testo; per ogni argomento è stato chiarito esattamente cosa prescrivono le regole e dove si trovano nel testo ufficiale.
Dove i percorsi si arenano nella pratica
Il primo rallentamento spesso non avviene a livello tecnico ma a livello di chiarezza: le aziende non sanno quali pagine, moduli e flussi rientrano nell'ambito di applicazione e quali no. Un secondo problema è il passaggio di pagamento e l'ambiente di accesso; questi sono spesso componenti personalizzate che non si trovano in un tema standard e quindi non beneficiano automaticamente di un aggiornamento del cms. Un terzo problema è la dipendenza da un fornitore esterno per il cms o il modulo di pagamento, dove una modifica a volte deve attendere un rilascio di quella parte. E un quarto problema è interno: un elenco di risultati in linguaggio tecnico rimane fermo perché nessuno sa chi dovrebbe affrontare quale problema.
Quattro fasi e dove si bloccano
La fase di inventariazione riguarda l'identificazione di ciò che non funziona, su quali pagine, e quanto grave sia per qualcuno che utilizza un lettore di schermo o solo una tastiera. Questa è la fase in cui una scansione automatizzata fa il maggior lavoro, ma è anche la fase in cui deve essere chiaro ciò che tale scansione non può rilevare; non ogni criterio WCAG può essere verificato automaticamente.
La fase di prioritizzazione trasforma i risultati in un ordine: cosa blocca completamente un ordine e cosa è un ostacolo minore. Questo spesso si blocca perché un elenco tecnico di risultati non dice chi all'interno dell'organizzazione è responsabile di quale parte.
La fase di correzione è la fase con il tempo di esecuzione più lungo, e la sua durata dipende molto dal fatto che gli adeguamenti possono essere effettuati internamente o devono passare attraverso un fornitore. Le etichette dei moduli e il contrasto dei colori sono spesso facili da risolvere; una procedura di pagamento che tecnicamente non è utilizzabile con la sola tastiera richiede più lavoro di sviluppo.
L'ultima fase è la documentazione: preparare la dichiarazione di accessibilità, stabilire un piano di miglioramento con scadenze e provare che è stata effettuata una valutazione indipendente. Questa non è una fase che si salta una volta che la tecnica è corretta; la dichiarazione deve riflettere lo stato attuale, anche se quello stato non è ancora perfetto.
Cosa influenza effettivamente la durata del percorso
Un'organizzazione che sa in anticipo quali pagine rientrano nell'ambito di applicazione e quali sono i punti critici più rilevanti perde meno tempo negli scambi tra team tecnico e decisionale. In poche domande è possibile vedere gratuitamente dove si trova attualmente un sito, senza necessità di un account. Per il proseguimento, cioè la scansione completa della fase di checkout e del flusso di accesso più un elenco di azioni prioritizzato in linguaggio semplice, lo sviluppo per ogni obbligo con i relativi termini fa parte del percorso a pagamento; ciò che vi è contenuto è presentato in modo chiaro.
Un ultimo fattore che influisce sui tempi di completamento: l'accessibilità non è un progetto con una data di scadenza ma uno stato che vale di nuovo dopo ogni modifica al sito. Un nuovo step di checkout o un modulo di contatto rinnovato può reintrodurre un problema che era già stato risolto. Chi vuole sapere da dove provengono le informazioni in un rapporto e con quale frequenza vengono aggiornate, le ritrova su la pagina che spiega come funziona il processo.
Per la propria situazione, con il proprio CMS, fornitore e pianificazione interna, rimane difficile stabilire in anticipo una scadenza fissa. Chi è incerto se un progetto è realistico da pianificare, farebbe bene a chiarire prima con precisione cosa deve esattamente accadere prima di costruire una pianificazione attorno ad esso. La scansione rapida gratuita è un punto di partenza logico per questo, senza che sia necessario un account o un pagamento immediato.