Venti domande, con le risposte per esteso.

La mia azienda è obbligata a rendere accessibile il sito?

Dipende da cosa fa il tuo sito e da quanto è grande la tua azienda, non dal settore in cui operi.

Il D.Lgs. 82/2022, che recepisce la direttiva europea 2019/882, si applica dal 28 giugno 2025 agli operatori economici che offrono al pubblico una lista precisa di prodotti e servizi: commercio elettronico, servizi bancari al consumatore, trasporto passeggeri, libri digitali, comunicazioni elettroniche. Se il tuo sito vende o permette di prenotare, con ogni probabilità rientri. Se è una vetrina che non consente nessuna transazione, l’obbligo diretto non scatta.

Restano escluse le microimprese che forniscono servizi: meno di dieci persone occupate e un fatturato annuo o un totale di bilancio non superiore a due milioni di euro. I due criteri valgono insieme, non in alternativa. Separatamente, la Legge 4/2004 impone obblighi ai soggetti privati con fatturato medio superiore a cinquecento milioni di euro negli ultimi tre anni.

Nel dubbio, la domanda utile non è «sono obbligato» ma «cosa succede se qualcuno non riesce a comprare».

Cosa rischio se il mio sito non è accessibile?

Due cose diverse, e la seconda pesa più della prima.

La sanzione è prevista dal D.Lgs. 82/2022: sanzioni amministrative pecuniarie che nei casi più gravi arrivano al cinque per cento del fatturato. Le commina l’AgID al termine di un accertamento, che di norma parte da una segnalazione e non da un controllo a tappeto.

L’altra conseguenza è più concreta e succede già adesso: perdi clienti senza accorgertene. Chi non riesce a completare un acquisto non scrive per protestare, va altrove. Non compare in nessun rapporto, perché nei dati di navigazione una persona che rinuncia è indistinguibile da una che ha cambiato idea.

Vale la pena sapere che l’accertamento non guarda solo com’è il sito, ma anche cosa hai fatto. Una dichiarazione di accessibilità aggiornata, un canale di segnalazione che funziona e un piano di intervento documentato mettono in una posizione diversa rispetto al non avere niente.

Cos’è l’European Accessibility Act in parole semplici?

È la legge europea che dice: se vendi qualcosa al pubblico, deve poterlo comprare anche chi ha una disabilità. Formalmente è la Direttiva (UE) 2019/882, recepita in Italia con il D.Lgs. 82/2022 e applicabile dal 28 giugno 2025.

Prima l’accessibilità obbligatoria riguardava soprattutto la pubblica amministrazione. L’European Accessibility Act la estende a una lista di prodotti e servizi privati: commercio elettronico, servizi bancari, trasporto passeggeri, libri digitali, comunicazioni elettroniche.

La direttiva non contiene regole tecniche. Rinvia allo standard europeo EN 301 549, che a sua volta recepisce le WCAG, le linee guida internazionali per l’accessibilità dei contenuti web. In pratica il riferimento da rispettare sono le WCAG di livello AA.

La logica non è burocratica ma di mercato. In Italia le persone con disabilità sono circa tre milioni: un servizio che una parte di loro non può usare è un servizio incompleto, prima ancora che irregolare.

I widget di accessibilità bastano?

No, e su questo preferiamo essere netti anche se costa un cliente.

I widget sono le barre laterali che promettono la conformità in un clic: cambiano il contrasto, ingrandiscono il testo, leggono la pagina ad alta voce. Il problema è che lavorano sopra il codice, non lo correggono. Se un’immagine non ha testo alternativo il widget non può inventarlo. Se un modulo non ha etichette, restano assenti. Se il sito non si naviga da tastiera, continua a non navigarsi.

Le WCAG e la EN 301 549 chiedono che sia il contenuto a essere accessibile, non che esista uno strumento sovrapposto che tenta di rimediare.

C’è un aspetto che riguarda direttamente il rischio: se dichiari la conformità basandoti su un widget e arriva una segnalazione, la dichiarazione non regge, perché l’accertamento guarda il codice. Diversi contenziosi negli Stati Uniti hanno riguardato proprio siti che il widget ce l’avevano. Costano ogni mese e spostano poco.

Chi rilascia il certificato di accessibilità?

Nessuno. È il punto che quasi nessun fornitore spiega.

Per i siti web non esiste un certificato rilasciato da un organismo terzo, come avviene per esempio per la sicurezza sul lavoro. La normativa prevede l’autodichiarazione: è il titolare del sito a dichiarare lo stato di accessibilità, sotto la propria responsabilità. Il modello è quello definito dall’AgID in attuazione della Legge 4/2004 e della decisione di esecuzione (UE) 2018/1523.

Chi ti vende un «certificato di accessibilità» ti sta vendendo un documento che non ha valore legale, perché non esiste l’ente che possa rilasciarlo.

Quello che ha valore è un’altra cosa: una relazione tecnica che dica chi ha fatto la verifica, con quale metodo e in che data. In caso di contestazione è quella che esibisci. È la differenza fra un’autovalutazione prodotta da un programma in trenta secondi e una verifica che porta un nome e una firma.

Quanto costa mettere a norma un sito?

Dipende da due cose: quante pagine diverse ha il sito e quanto è complicato ciò che ci si fa dentro. Una vetrina di dieci pagine è un lavoro; un negozio online con carrello, filtri e area riservata è un altro, perché i percorsi da provare uno per uno si moltiplicano.

I nostri prezzi sono pubblicati. La Diagnosi costa 290 € + IVA, arriva in tre giorni e serve a capire a che punto sei. L’Audit completo parte da 1.400 € + IVA e produce la relazione tecnica firmata. L’Adeguamento parte da 3.900 € + IVA e comprende le correzioni. La Diagnosi viene interamente scontata se prosegui, quindi non è un costo aggiuntivo se decidi di andare avanti.

Non trattiamo sul prezzo: se il budget non basta riduciamo il perimetro — per esempio partendo dai percorsi che portano più fatturato — invece di abbassare la qualità del lavoro.

Un preventivo vero richiede di guardare il sito: a occhio la cifra cambia troppo per essere onesta.

La mia azienda ha 12 dipendenti, sono obbligato?

Con dodici dipendenti l’esenzione per le microimprese non ti copre, ma non è ancora la risposta completa. La definizione europea richiamata dal D.Lgs. 82/2022 considera microimpresa chi occupa meno di dieci persone e ha un fatturato annuo o un totale di bilancio non superiore a due milioni di euro. I due criteri vanno soddisfatti insieme, e tu sei già oltre il primo. Quell’esenzione, peraltro, riguarda le microimprese che forniscono servizi.

La domanda che decide non è quanti dipendenti hai, ma cosa fa il tuo sito. L’obbligo scatta se offri uno dei servizi elencati dalla direttiva: commercio elettronico, servizi bancari al consumatore, trasporto passeggeri, libri digitali, comunicazioni elettroniche. Se il sito permette di acquistare o prenotare, rientri. Se è una vetrina informativa senza transazioni, l’obbligo diretto non scatta.

Vale però la pena ricordare che i clienti che non riescono a leggerti li perdi comunque, obbligo o non obbligo.

Cos’è la dichiarazione di accessibilità e chi la firma?

È un documento pubblico in cui dichiari lo stato di accessibilità del tuo sito: cosa è conforme, cosa non lo è e perché, e come una persona può segnalarti una barriera. Il modello è quello dell’AgID, previsto dalla Legge 4/2004 e dalla decisione di esecuzione (UE) 2018/1523.

La firma è tua, non del fornitore. È un’autodichiarazione e la responsabilità resta del titolare del sito: nessun consulente può assumersela al posto tuo.

Va pubblicata in un punto raggiungibile da ogni pagina, di norma dal piè di pagina, e va aggiornata a ogni cambiamento sostanziale del sito oltre che con una revisione periodica. Deve indicare la data della verifica e il metodo usato: una dichiarazione senza data è una dichiarazione che non dice niente.

Quello che facciamo noi è la parte che la sostiene: la relazione tecnica su cui la dichiarazione si appoggia. Tu la firmi, noi ti diamo di che firmarla.

Il mio sito è WordPress, cambia qualcosa?

Cambia il modo di lavorare, non l’obbligo.

WordPress di per sé non è né accessibile né inaccessibile: dipende dal tema, dai plugin e da come sono stati messi insieme. Nella pratica i problemi ricorrenti sono tre. I temi commerciali che generano codice senza una gerarchia di titoli sensata. I costruttori di pagine che producono contenitori generici al posto di elementi con un significato. I plugin di terze parti — caroselli, banner dei cookie, moduli di contatto — che introducono barriere indipendenti dal tema che hai scelto.

La notizia buona è che molto si corregge senza rifare il sito: spesso si interviene sul tema figlio e sulla configurazione dei plugin, e il grosso si risolve lì.

Quella meno buona è che alcuni costruttori di pagine producono strutture difficili da sistemare a valle. In quei casi la strada onesta è dirlo, non rattoppare. Quale dei due casi sia il tuo si capisce guardando il codice, non il pannello di amministrazione.

Quanto tempo serve per adeguarsi?

Per un sito vetrina di dieci o quindici pagine, fra verifica e correzioni si sta di norma in quattro o sei settimane. Per un negozio online con carrello, pagamento e area riservata si arriva a otto o più, perché i percorsi da provare uno per uno sono molti di più.

I nostri tempi pubblicati sono tre giorni per la Diagnosi, due settimane per l’Audit completo, da quattro a otto settimane per l’Adeguamento.

La variabile che sposta di più le date non è tecnica: è la velocità con cui arrivano risposte e accessi da parte vostra. Un audit fermo in attesa di una credenziale costa giorni che nessuno recupera.

Una cosa da mettere in conto fin dall’inizio: l’adeguamento non è un lavoro che si fa una volta sola. Ogni modifica al sito può reintrodurre una barriera, ed è il motivo per cui la dichiarazione va aggiornata a ogni cambiamento sostanziale. Conviene trattarlo come manutenzione, non come emergenza.

Chi controlla e come?

In Italia la vigilanza è dell’AgID, l’Agenzia per l’Italia Digitale, designata dal D.Lgs. 82/2022.

Il controllo non è a tappeto: parte quasi sempre da una segnalazione. Chi non riesce a usare un sito lo segnala prima al titolare, attraverso il canale che il titolare stesso è tenuto a mettere a disposizione. Se entro trenta giorni non riceve risposta, o la risposta non è soddisfacente, può rivolgersi all’AgID. Da lì può avviarsi un accertamento.

Nell’accertamento contano due cose: lo stato effettivo del sito e cosa hai fatto per migliorarlo. Una dichiarazione aggiornata, un canale di segnalazione che funziona davvero e un piano di intervento documentato raccontano una storia diversa dal silenzio.

È anche la ragione per cui il canale di segnalazione è un obbligo e non una cortesia: è il primo posto dove si guarda, ed è l’unico che puoi predisporre in un pomeriggio.

Sono in proroga fino al 2030?

Quasi certamente no, ed è l’equivoco che sentiamo più spesso.

La direttiva 2019/882 prevede due regimi transitori, entrambi più stretti di come vengono raccontati. Il primo riguarda i contratti di servizio conclusi prima del 28 giugno 2025, che possono proseguire senza modifiche fino alla scadenza e comunque non oltre il 28 giugno 2030. Il secondo riguarda i terminali self-service già in uso a quella data, utilizzabili fino a fine vita economica e comunque non oltre vent’anni.

Nessuno dei due è una proroga generale per i siti web. Un sito pubblico che offre un servizio al consumatore è soggetto agli obblighi dal 28 giugno 2025, data ormai passata.

Se qualcuno ti ha detto che hai tempo fino al 2030, vale la pena chiedergli su quale delle due disposizioni si basa. Nella maggior parte dei casi la risposta non arriva.

Accessibile vuol dire brutto?

No, ed è il pregiudizio che ci troviamo a smontare più spesso. Nasce da un equivoco: si confonde «accessibile» con «adattato», cioè con l’aspetto che prende un sito quando gli si sovrappone un widget che ingrandisce i caratteri e sbianca i colori.

L’accessibilità vera lavora prima, sulle decisioni di progetto: quanta distanza c’è fra un colore e il suo fondo, quanto è grande l’area su cui si può premere, se si capisce dove si trova il cursore mentre si naviga da tastiera, se un messaggio d’errore dice cosa fare invece di limitarsi a diventare rosso.

Nessuna di queste scelte impone uno stile. Impone precisione. Molti dei siti più curati che conosci superano già gran parte dei criteri, perché un progetto fatto bene e un progetto accessibile chiedono quasi sempre la stessa cosa: chiarezza.

Questo sito, per dire, rispetta i criteri e non sembra un modulo dell’ufficio anagrafe.

Il contrasto minimo mi rovina i colori del marchio?

Quasi mai, e quando succede si risolve senza toccare il marchio.

Le WCAG chiedono un rapporto di contrasto di almeno 4,5:1 fra testo e sfondo per il testo normale e 3:1 per il testo grande, oltre a 3:1 per i bordi dei controlli e le icone che veicolano informazione (criteri 1.4.3 e 1.4.11). Sono soglie sul testo, non sul logo: un marchio non è testo e non deve rispettare nessun rapporto.

Nella pratica il problema riguarda quasi sempre un solo colore, di solito quello d’accento usato per i link o per i pulsanti. La soluzione non è cambiare il colore, ma decidere dove usarlo: lo stesso fucsia che non regge come testo piccolo su bianco funziona benissimo come fondo di un pulsante con testo bianco sopra.

Il risultato è una palette con ruoli espliciti — questo colore per le superfici, questo per il testo — che di norma rende il marchio più riconoscibile, non meno.

Devo rifare il sito da capo o si può sistemare?

Nella grande maggioranza dei casi si sistema, e conviene: rifare un sito costa di più e reintroduce errori nuovi.

Si interviene sull’esistente quando la struttura del contenuto regge — c’è una gerarchia di titoli sensata, i moduli usano elementi veri, la navigazione è una lista di link — e i problemi stanno nei colori, nei testi alternativi, nelle etichette, nella visibilità del focus. Sono correzioni chirurgiche.

Rifare conviene in due casi: quando il sito è costruito con contenitori generici al posto di elementi con un significato, così che ogni correzione ne richiede altre tre; e quando il percorso stesso è il problema, per esempio un pagamento in sei passaggi che nessuno completa, disabilità o meno.

Quale dei due sia il tuo caso si vede dalla Diagnosi, che serve esattamente a questo e costa meno di una settimana di sviluppo sprecato nella direzione sbagliata.

Cosa cambia per i clienti che non hanno disabilità?

Cambia più di quanto suggerisca la parola «accessibilità», che fa pensare a una minoranza.

Le stesse correzioni migliorano l’uso per tutti in condizioni ordinarie: leggere al sole con lo schermo del telefono, riempire un modulo di fretta, capire perché un pagamento è stato rifiutato. I sottotitoli li usa chi guarda un video in treno senza cuffie. I contrasti alti servono a chi ha quarantacinque anni e non porta gli occhiali da lettura.

C’è poi una parte che riguarda direttamente i ricavi: un modulo con etichette vere, messaggi d’errore che dicono cosa correggere e campi che il browser sa compilare da solo viene completato da più persone. Non perché sia accessibile, ma perché è chiaro.

È il motivo per cui non vendiamo l’adeguamento come un adempimento: nello stesso intervento sistemiamo i passaggi dove le persone si bloccano, che sono quasi sempre gli stessi.

Come faccio a sapere se un design è accessibile prima di svilupparlo?

Si controlla sul progetto, ed è molto più economico che scoprirlo dopo.

Sul file di design si verificano già parecchie cose: i rapporti di contrasto di ogni combinazione testo-fondo, la dimensione delle aree su cui si preme (il criterio 2.5.8 chiede almeno 24 per 24 pixel), il fatto che nessuna informazione sia affidata al solo colore (criterio 1.4.1), la presenza di uno stato di focus disegnato e non lasciato al caso.

Altre no: l’ordine di lettura, il comportamento da tastiera, cosa annuncia uno screen reader quando un contenuto cambia. Quelle si provano sul prototipo o sul codice.

Quello che consegniamo negli interventi di adeguamento comprende gli stati che di solito mancano nei file di design — focus, errore, campo disabilitato, caricamento — perché è lì che nasce la maggior parte delle barriere: non da una scelta sbagliata, ma da uno stato che nessuno aveva disegnato.

I nostri font e colori sono già decisi, dobbiamo cambiarli?

Il carattere quasi mai, i colori raramente, il modo di usarli spesso.

Sul carattere le WCAG non impongono nulla: nessun font è vietato. Contano la dimensione, l’interlinea e il fatto che il testo si possa ingrandire fino al 200% senza perdere contenuto o funzioni (criterio 1.4.4). Un carattere molto sottile o molto condensato può risultare problematico alle dimensioni piccole, e in quel caso si aggiusta il peso, non si cambia il carattere.

Sui colori vale quanto detto sopra: si ridefinisce dove ciascuno viene usato.

La cosa che cambia davvero è un’altra, ed è quella che le aziende non si aspettano: le dimensioni del testo e gli spazi smettono di essere decisi caso per caso e diventano una scala. Non è un vincolo estetico, è la fine delle discussioni su quanto debba essere grande un titolo.

Il sito è accessibile ma nessuno compra lo stesso: cosa guardate?

Guardiamo dove le persone si fermano, che è una domanda diversa da «il codice è conforme».

La conformità dice che una persona con disabilità può usare il sito. Non dice che il percorso abbia senso. Un modulo di pagamento può superare tutti i criteri e chiedere comunque il codice fiscale prima del nome, mostrare i costi di spedizione all’ultimo passaggio, o costringere a creare un account per comprare una volta sola.

Quello che cerchiamo sono i punti in cui l’utente deve indovinare: campi che non dicono in che formato vogliono il dato, errori che compaiono solo dopo l’invio, passaggi che non si possono tornare indietro, attese senza segnale di avanzamento.

È la parte di lavoro che chiamiamo ridisegno dei passaggi critici, ed è compresa nell’Adeguamento. Nella nostra esperienza l’accessibilità e il tasso di conversione si rompono quasi sempre negli stessi tre o quattro punti.

Di chi è il lavoro: del designer o dello sviluppatore?

Di entrambi, e la maggior parte dei problemi nasce proprio nello spazio fra i due.

Al design appartengono contrasti, dimensioni, gerarchia visiva, testi delle etichette e dei messaggi d’errore, e gli stati che di solito nessuno disegna: focus, errore, vuoto, caricamento. Allo sviluppo appartengono la scelta degli elementi giusti, l’ordine di tabulazione, gli attributi ARIA quando servono davvero, e il comportamento da tastiera.

Il guaio tipico è un progetto che non specifica come si vede il focus e uno sviluppatore che, non trovandolo nel file, lo toglie perché «sporca». Nessuno dei due ha sbagliato: mancava la consegna.

Per questo il nostro file di consegna elenca gli stati e i comportamenti attesi, non solo l’aspetto. E se preferite non gestire il passaggio, l’Adeguamento comprende anche l’implementazione: in quel caso il confine non esiste perché il lavoro è tutto nostro.