L’accessibilità web AGID non è una formalità burocratica per chi lavora con clienti della pubblica amministrazione o della sanità: è un obbligo di legge con sanzioni reali, e la responsabilità tecnica ricade spesso sull’agenzia che ha sviluppato il sito. Le linee guida AGID recepiscono lo standard WCAG 2.1 a livello AA, e il loro rispetto viene verificato attraverso una dichiarazione di accessibilità pubblica che ogni ente pubblico è tenuto ad aggiornare annualmente.
Il problema pratico per le agenzie è che questo tema arriva quasi sempre tardi: o quando il cliente segnala che qualcuno ha fatto un esposto, o quando l’ente deve rinnovare la dichiarazione e si accorge che il sito non supera i controlli automatici. Noi di Blurr gestiamo sviluppo WordPress per agenzie con clienti in questi settori, e possiamo dire con certezza che la situazione più comune non è il sito fatto male, ma il sito fatto senza mai aver verificato i requisiti AGID in modo sistematico.
A chi si applica: PA, sanità e soggetti privati finanziati con fondi pubblici
L’obbligo di accessibilità AGID si applica in modo diretto a tutte le pubbliche amministrazioni italiane: comuni, province, regioni, ministeri, scuole, università, ASL, ospedali pubblici. Ma il perimetro si è allargato nel tempo. La Direttiva europea sull’accessibilità (European Accessibility Act, recepita in Italia con il D.Lgs. 82/2006 e successive modifiche) include anche i soggetti privati che ricevono finanziamenti pubblici sopra una certa soglia, e la prossima fase di applicazione porterà obblighi anche per le imprese private che offrono certi servizi al pubblico.
Per un’agenzia questo significa che avere anche un solo cliente comunale, un’ASL o una fondazione con finanziamento pubblico espone il proprio portafoglio a questo tema. Non è un mercato di nicchia: è quasi impossibile che un’agenzia italiana attiva da qualche anno non abbia mai toccato un progetto che rientra in questi criteri.
Cosa prevede la dichiarazione di accessibilità
Ogni ente pubblico deve pubblicare sul proprio sito una dichiarazione di accessibilità in un formato standardizzato, aggiornata almeno una volta l’anno. La dichiarazione non certifica che il sito è perfettamente accessibile, ma attesta lo stato attuale della conformità, indica le parti non conformi e i motivi, e descrive le alternative accessibili disponibili. Viene poi inviata tramite il portale AGID e diventa pubblica.
Il punto critico per le agenzie: la dichiarazione si basa su una verifica del sito. Se il sito non supera i test automatici di base (contrasto colori, alternative testuali alle immagini, navigabilità da tastiera, struttura degli heading), la dichiarazione non può attestare conformità. E se l’ente ha già pubblicato una dichiarazione che attesta conformità su un sito che in realtà non la rispetta, la responsabilità di quella dichiarazione errata pesa anche su chi ha sviluppato il sito.
Qualche mese fa abbiamo preso in carico un progetto per un’agenzia di Brescia: il cliente era un’azienda sanitaria locale che doveva rinnovare la dichiarazione annuale. Il sito era stato sviluppato due anni prima con un page builder commerciale, aveva una dichiarazione pubblicata con stato “parzialmente conforme”, ma la verifica effettiva mostrava problemi su contrasto cromatico in diversi componenti, assenza di alt text su circa il 40% delle immagini funzionali, e struttura degli heading completamente piatta sulle pagine di secondo livello. Abbiamo risolto in circa una settimana di lavoro, principalmente intervenendo sui template e configurando correttamente la gestione dei media. Non era un sito da rifare: era un sito da verificare sistematicamente e correggere nei punti specifici.
I requisiti WCAG che creano più problemi in pratica
Le linee guida WCAG 2.1 livello AA coprono quattro macro-principi: percepibile, utilizzabile, comprensibile, robusto. In pratica, le aree che generano più non-conformità sui siti WordPress che riceviamo riguardano sempre gli stessi punti.
Contrasto cromatico. Il rapporto minimo tra colore del testo e sfondo è 4,5:1 per testo normale e 3:1 per testo grande. I design con grigi chiari su bianco, testi colorati su sfondi pastello, o bottoni con testo bianco su colori chiari falliscono sistematicamente questo controllo. È un problema di design, non di sviluppo, ma spesso arriva in produzione senza verifica.
Alternative testuali alle immagini. Ogni immagine che porta informazioni deve avere un attributo alt descrittivo. Le immagini decorative devono avere alt vuoto. La gestione dei media in WordPress permette di impostare questi valori, ma richiede disciplina editoriale da parte di chi carica i contenuti, non solo una configurazione iniziale corretta.
Navigabilità da tastiera. Ogni elemento interattivo, link, bottone, campo form, menu, deve essere raggiungibile e utilizzabile senza mouse. I menu a tendina costruiti con CSS puro e JavaScript non ottimizzato spesso non passano questo test. I page builder moderni come Bricks, che usiamo noi di Blurr, generano markup semanticamente corretto che facilita molto la navigazione da tastiera, ma vanno comunque testati componente per componente.
Struttura degli heading. H1, H2, H3 devono seguire una gerarchia logica. Un H3 che appare prima di qualsiasi H2 sulla pagina, o una pagina con tre H1, è una non-conformità. Nei CMS dove il cliente gestisce i contenuti in autonomia, questo requisito richiede formazione specifica o limitazioni nell’editor.
Page builder e accessibilità: il problema non è lo strumento
Circola una convinzione nelle agenzie che i page builder siano incompatibili con l’accessibilità WCAG. Non è vero, o almeno non è più vero per i builder moderni. Il vero problema è che l’accessibilità richiede scelte consapevoli in fase di design e sviluppo che spesso non vengono fatte, indipendentemente dallo strumento usato.
Un sito sviluppato con HTML custom può essere completamente inaccessibile se il markup non è semantico. Un sito sviluppato con Bricks Builder, configurato correttamente, con un design che rispetta i rapporti di contrasto e una gestione dei media disciplinata, supera i controlli WCAG AA senza bisogno di interventi aggiuntivi. La variabile critica è il processo, non lo strumento.
Questo vale anche per la scelta tra sviluppo custom e page builder per clienti PA: chi esclude i page builder a priori per motivi di accessibilità sta probabilmente saltando un passaggio di verifica che sarebbe necessario comunque.
Se la tua agenzia lavora con clienti PA o sanità e non ha ancora definito un processo standard per la verifica dell’accessibilità, contattaci su blurr.it/contatti/: gestiamo sviluppo WordPress con verifica AGID inclusa nel processo per le agenzie partner di Blurr, studio white label con sede a Calliano (Trento).
Le sanzioni: cosa rischia concretamente il cliente (e indirettamente l’agenzia)
L’AGID può irrogare sanzioni agli enti pubblici inadempienti. Le sanzioni previste dal D.Lgs. 106/2018 arrivano fino a 20.000 euro per ente, con possibilità di segnalazione pubblica. Non sono sanzioni frequenti, ma esistono e vengono applicate in caso di reclami formali.
Per le agenzie il rischio diretto è diverso: un cliente che riceve una contestazione o deve affrontare un ricorso per non-conformità può rivalersi sul fornitore che ha sviluppato il sito, specialmente se nel contratto di sviluppo non era esplicitato che la conformità AGID era esclusa dallo scope dei lavori. La protezione contrattuale su questo punto è sottovalutata.
Il tema si interseca anche con i Core Web Vitals e la performance generale del sito: un sito accessibile tende ad avere markup più pulito, struttura semantica più solida, e spesso migliori performance di caricamento, perché l’accessibilità forza scelte tecniche che coincidono con le best practice di sviluppo web in generale.
FAQ
Un sito WordPress sviluppato con page builder può essere conforme AGID? Sì, purché il design rispetti i requisiti di contrasto cromatico, i contenuti vengano gestiti con attributi alt corretti, e la struttura degli heading sia gerarchicamente logica. I page builder moderni come Bricks generano markup semanticamente valido. La conformità dipende dalle scelte di design e dal processo editoriale, non dallo strumento di sviluppo.
Chi è responsabile della dichiarazione di accessibilità: l’ente o l’agenzia? La dichiarazione di accessibilità è firmata e pubblicata dall’ente pubblico, che ne assume la responsabilità formale. L’agenzia non firma nulla, ma risponde contrattualmente della qualità tecnica del sito consegnato. Se la non-conformità deriva da scelte di sviluppo, il cliente può contestare l’agenzia. Inserire nel contratto di sviluppo una clausola che specifica cosa è incluso o escluso in termini di conformità WCAG è una protezione concreta.
Con quale frequenza va verificata l’accessibilità di un sito PA? La dichiarazione di accessibilità va rinnovata almeno annualmente. Ma il sito cambia nel tempo, specialmente se il cliente gestisce contenuti in autonomia: nuove immagini senza alt text, nuove pagine con heading mal strutturati, nuovi componenti aggiunti senza verifica. Una verifica periodica ogni 6-12 mesi, integrata nel piano di manutenzione, è la soluzione più razionale.
Esistono strumenti automatici per verificare la conformità WCAG? Sì: WAVE, Axe DevTools e Lighthouse di Google eseguono controlli automatici sui criteri WCAG verificabili in modo automatico, che coprono circa il 30-40% dei requisiti totali. I criteri restanti richiedono verifica manuale, in particolare la navigazione da tastiera, la logica degli heading nel contesto della pagina e la comprensibilità dei contenuti. I tool automatici sono un punto di partenza, non un certificato di conformità.