Per la maggior parte delle agenzie web, privacy e accessibilità vivono in compartimenti separati. La privacy viene affrontata quando un cliente chiede del GDPR. L’accessibilità viene ricordata quando qualcuno segnala un problema, o quando un bando pubblico richiede la dichiarazione di conformità. Entrambe vengono trattate come eccezioni al flusso normale di lavoro, non come parte di esso.
Questo approccio funzionava quando le normative erano vaghe e l’enforcement era raro. Oggi non funziona più. Il European Accessibility Act è in vigore, il Garante della Privacy ha intensificato i controlli sui banner cookie, e i clienti iniziano a fare domande su entrambi i temi prima della firma del contratto.
Il punto non è che siano diventate più difficili da gestire. Il punto è che continuare a gestirle separatamente — con strumenti diversi, in momenti diversi, come emergenze invece che come processo — è il modo più inefficiente e più rischioso di affrontarle.
Due problemi distinti con la stessa radice operativa
Privacy e accessibilità sono discipline diverse. La privacy riguarda come il sito raccoglie, tratta e comunica l’uso dei dati degli utenti. L’accessibilità riguarda come il sito funziona per persone con esigenze diverse — visive, motorie, cognitive, uditive.
Ma per un’agenzia web che gestisce siti WordPress per conto di clienti, creano lo stesso problema operativo: entrambe richiedono interventi che non finiscono al lancio del sito, entrambe si degradano nel tempo se non vengono manutenute, e entrambe creano responsabilità che ricadono sull’agenzia se non vengono gestite correttamente.
Come abbiamo già analizzato nell’articolo sull’accessibilità web per agenzie, l’EAA ha esteso gli obblighi di accessibilità anche alle aziende private in molti settori — non solo alla pubblica amministrazione. E come abbiamo spiegato nell’articolo su GDPR e privacy per siti web, la responsabilità dell’agenzia nella gestione della privacy del sito del cliente è più ampia di quanto molti pensino.
Trattarle separatamente significa affrontare due volte lo stesso tipo di conversazione con il cliente, due volte lo stesso tipo di audit, due volte lo stesso tipo di aggiornamento. Integrarle in un processo unico non semplifica le competenze richieste — quelle restano diverse — ma semplifica enormemente la gestione operativa.
Come si degradano nel tempo se non vengono manutenute
Il problema comune di privacy e accessibilità è che non sono statiche al momento del lancio. Evolvono con il sito.
Sul fronte della privacy: ogni nuovo plugin aggiunge potenzialmente cookie da dichiarare nel banner. Ogni integrazione con un CRM, un sistema di analytics o una piattaforma pubblicitaria cambia i soggetti con cui i dati vengono condivisi. Ogni modifica ai form di contatto può introdurre nuovi punti di raccolta dati. Un sito lanciato con un banner cookie conforme può diventare non conforme sei mesi dopo se sono stati aggiunti script di terze parti senza aggiornare la configurazione. Come abbiamo spiegato nell’articolo sui cookie di terze parti, questo è uno dei problemi più comuni e meno presidiati nei siti WordPress gestiti da agenzie.
Sul fronte dell’accessibilità: ogni nuova pagina aggiunta può introdurre immagini senza alt text, heading mal strutturati, form senza label corrette. Ogni aggiornamento del tema può alterare i contrasti o rompere la navigazione da tastiera. Come abbiamo dettagliato nell’articolo sui requisiti WCAG e AGID per WordPress, le non conformità si accumulano silenziosamente — e il cliente non lo sa finché non emerge un problema.
La manutenzione ordinaria del sito dovrebbe includere verifiche periodiche su entrambi i fronti. Il debito tecnico su WordPress si accumula anche su questi aspetti, non solo sul codice.
Cosa verificare prima della consegna di ogni sito
Integrare privacy e accessibilità nel processo di consegna non richiede di diventare esperti legali o specialisti WCAG. Richiede una checklist minima che diventi parte standard del workflow — come già avviene per la SEO tecnica o per le performance WordPress.
Sul fronte privacy, prima della consegna:
Il banner cookie è configurato con le tre opzioni visibili e il design è coerente con il sito. Tutti i cookie presenti nel sito sono dichiarati nelle categorie corrette. I form di contatto hanno le informative corrette e le caselle di consenso non sono preselezionate. Il sito è testato con i cookie analitici disabilitati. La privacy policy è accessibile con un click dal footer e dal banner. Esiste un link persistente per modificare le preferenze cookie.
Sul fronte accessibilità, prima della consegna:
Tutte le immagini significative hanno alt text descrittivo. La struttura degli heading è logica e gerarchica. I form hanno label associate correttamente a ogni campo. I pulsanti hanno testo descrittivo. Il contrasto tra testo e sfondo rispetta i requisiti minimi WCAG AA. La navigazione da tastiera funziona su tutti gli elementi interattivi. Il sito è testato su mobile con zoom al 200% senza perdita di funzionalità.
Questa checklist non garantisce la conformità legale completa — per quella servono audit specifici e consulenza specializzata — ma elimina i problemi più comuni che emergono dopo la consegna.
In Blurr abbiamo standardizzato questa doppia verifica come parte del processo di consegna di ogni progetto. Non è un’operazione aggiuntiva — è integrata nel flusso normale. Quello che abbiamo imparato nel tempo è che i problemi che emergono dopo la consegna su questi due fronti sono quasi sempre gli stessi: banner cookie con colori non allineati al sito, alt text mancanti sulle immagini caricate dal cliente nelle ultime settimane di sviluppo, link “gestisci preferenze” dimenticato nel footer. Dedicare 45 minuti a questa verifica prima di ogni consegna ha eliminato praticamente tutte le chiamate post-lancio su questi temi.
Come presentarlo ai clienti come servizio
Privacy e accessibilità sono argomenti che i clienti percepiscono come importanti ma faticano a capire nel dettaglio. Questo crea un’opportunità per le agenzie che sanno spiegarli in modo concreto.
La conversazione più efficace non parte dalle normative — parte dal rischio. Un cliente che capisce che un banner cookie mal configurato può portare a una sanzione del Garante, e che un sito non accessibile può esporre l’azienda a contestazioni formali, è un cliente motivato a investire nel farlo correttamente.
L’agenzia che include la verifica di privacy e accessibilità nel proprio processo di sviluppo — e lo comunica in modo esplicito nel preventivo — posiziona il proprio lavoro come più completo e più professionale rispetto a chi consegna solo il sito senza occuparsi di questi aspetti.
Blurr include la verifica di entrambi questi elementi nel processo di sviluppo per le agenzie partner. La configurazione del banner cookie con personalizzazione grafica completa, la verifica dei requisiti WCAG di base e la checklist pre-consegna fanno parte del servizio standard — non sono extra da richiedere separatamente. Per le agenzie che hanno siti già online con problemi non risolti su entrambi i fronti, offriamo anche interventi di messa a norma come servizio standalone. Prenota una call per capire come integrare questi aspetti nel tuo flusso di lavoro.
Il vantaggio competitivo di chi si muove prima
La direzione è chiara: privacy e accessibilità diventeranno sempre più parte delle aspettative standard per un sito web professionale, non elementi opzionali. Le agenzie che hanno già integrato questi aspetti nel proprio processo di lavoro avranno un vantaggio concreto rispetto a quelle che continuano a trattarli come eccezioni.
Non perché siano più brave tecnicamente. Ma perché sanno già cosa fare, hanno un processo rodato, e non perdono tempo ogni volta che un cliente fa una domanda su questi temi.
Se vuoi capire come integrare la gestione di privacy e accessibilità nel tuo processo di sviluppo — senza trasformarli in due progetti separati — prenota una call con Blurr per vedere come gestiamo questi aspetti nei progetti delle agenzie partner.
Domande frequenti
Dipende dai contratti e dal ruolo specifico dell’agenzia. In generale, chi sviluppa il sito ha una responsabilità tecnica sulla conformità degli elementi che ha costruito. Chi gestisce il sito nel tempo ha una responsabilità di manutenzione. I contratti dovrebbero definire chiaramente chi fa cosa — un aspetto che abbiamo approfondito nell’articolo sul contratto di sviluppo web.
La verifica completa va fatta almeno una volta l’anno, o ogni volta che vengono apportate modifiche significative al sito — nuovi plugin, nuove integrazioni, nuove sezioni. La verifica del banner cookie va fatta ogni volta che vengono aggiunti script di terze parti. La verifica dell’accessibilità va fatta ogni volta che vengono create nuove pagine o modificati elementi strutturali del sito.
Sì, dal 28 giugno 2025 il European Accessibility Act ha esteso gli obblighi di accessibilità digitale a molte categorie di aziende private nell’UE — non solo alla pubblica amministrazione. I requisiti variano in base al settore e alla dimensione dell’azienda. Per i dettagli specifici sulla normativa italiana, abbiamo pubblicato una guida completa sull’accessibilità web e i requisiti AGID.
Nella maggior parte dei casi sì. I problemi di accessibilità più comuni — alt text mancanti, heading mal strutturati, form senza label, problemi di contrasto — si risolvono con interventi mirati sul codice esistente senza alterare il design o le funzionalità del sito. I casi in cui è necessario un intervento più profondo riguardano siti con strutture tematiche non standard o costruiti con strumenti che generano codice non modificabile.