L’accessibilità dei siti web non è più solo una buona pratica. Dal 28 giugno 2025, per molte aziende è un obbligo di legge.
Se il sito non è conforme, la sanzione colpisce il committente. Ma il problema può diventare rapidamente tuo.
Perché quel sito non lo ha sviluppato il cliente. Lo hai fatto tu.
E se il prodotto consegnato non rispetta i requisiti di accessibilità richiesti, il tema si sposta sul piano contrattuale e professionale: se il progetto non rispetta i requisiti di accessibilità, il committente può chiedere correzioni, danni o rivalersi sul fornitore.
Per chi lavora nello sviluppo web l’accessibilità non può essere trattata come un extra da aggiungere, se avanza budget. Incide direttamente su:
- responsabilità professionale
- struttura del contratto
- perimetro dell’incarico
- gestione del cliente nel tempo.
Il punto non è se sei responsabile, ma fino a dove.
CONTENUTO DELL'ARTICOLO
- 1 Accessibilità siti web: chi è responsabile
- 2 Obblighi del committente: cosa non può delegare allo sviluppatore
- 3 Obblighi dello sviluppatore siti web in materia di accessibilità
- 4 Contratto di sviluppo sito web e accessibilità: le clausole da prevedere
- 5 Freelance, agenzia, subappalto: tre profili di rischio diversi
- 6 Legal for Digital: consulenza legale sull’accessibilità per chi sviluppa e chi commissiona siti web
Accessibilità siti web: chi è responsabile
La normativa sull’accessibilità digitale coinvolge più soggetti. Ma le responsabilità non si distribuiscono in modo simmetrico.
Committente: responsabilità verso autorità
L’accessibilità digitale è regolata da due normative: la Legge 4/2004 (Legge Stanca), aggiornata dal D.Lgs. 106/2018, e il D.Lgs. 82/2022, che recepisce l’European Accessibility Act (Direttiva UE 2019/882).
In entrambi i casi, il soggetto obbligato è chi eroga il servizio digitale al pubblico: l’azienda, l’ente o il professionista che mette a disposizione il sito web o l’app. La normativa lo definisce “soggetto erogatore”. Per te è il soggetto “committente” del progetto di sviluppo del sito.
Questo soggetto deve:
- garantire la conformità agli standard di accessibilità
- pubblicare la dichiarazione di accessibilità
- rispondere in caso di controlli.
| Categoria Aziendale | Criteri dimensionali | Normativa | Decorrenza |
| Grandi aziende private | Fatturato > 500 Mln € (media triennio) | Legge 4/2004 | Già in vigore |
| PMI | > 10 dipendenti O > 2 Mln € fatturato | D.Lgs. 82/2022 | In vigore da 28 Giugno 2025 |
| Microimprese | < 10 dipendenti E ≤ 2 Mln € fatturato | D.Lgs. 82/2022 | Esenti (solo per i servizi) |
Anche sul piano sanzionatorio, le conseguenze ricadono esclusivamente sul committente:
- D.Lgs. 82/2022 (EAA): sanzioni da 5.000 a 40.000 euro
- Legge Stanca: fino al 5% del fatturato
A questo si aggiungono diffide, obblighi di adeguamento e, nei casi più gravi, il ritiro del servizio.
Ma questa è solo una parte del problema.
Sviluppatore: responsabilità contrattuale
La sanzione amministrativa colpisce il committente, ma questo non rende lo sviluppatore estraneo alle conseguenze. La tua responsabilità si colloca su un piano diverso: quello contrattuale e professionale.
Quando il sito non è conforme, è il contratto tra committente e sviluppatore a determinare cosa succede.
Se il contratto prevede la conformità alla normativa, oppure non disciplina affatto l’accessibilità, lo sviluppatore può essere esposto a contestazioni per inadempimento.
L’assenza di clausole specifiche non ti protegge: spesso espone di più, perché lascia al giudice la valutazione su cosa fosse “ragionevole” aspettarsi dalla prestazione.
Come sottolinea il nostro cofounder, l’Avv. Vercellotti, in un’intervista, va distinta:
- la prestazione tecnica (ciò che puoi implementare)
- dalla responsabilità legale complessiva del sito.
Senza questa distinzione, le due cose si sovrappongono.
Il rischio per lo sviluppatore si traduce in:
- Richieste di correzione a tuo carico, anche a distanza di tempo dalla consegna
- Richieste di risarcimento da parte del committente che ha subito una sanzione o un danno reputazionale
- Risoluzione del contratto per inadempimento, con perdita del credito residuo
- Danno alla reputazione professionale, con impatto diretto sull’acquisizione di nuovi clienti.
Obblighi del committente: cosa non può delegare allo sviluppatore
Una parte degli obblighi di accessibilità ricade esclusivamente sul committente, indipendentemente da ciò che prevede il contratto di sviluppo.
Dichiarazione di accessibilità: chi la pubblica e chi ne risponde
La dichiarazione di accessibilità è il documento con cui il soggetto erogatore comunica al pubblico lo stato di conformità del sito.
Deve:
- indicare il livello di conformità (conforme, parzialmente conforme, non conforme)
- segnalare i contenuti non accessibili
- fornire le modalità per inviare segnalazioni
La responsabilità della dichiarazione è del committente. È lui che la pubblica, è lui che ne risponde davanti all’AgID, ed è lui che deve garantire che quanto dichiarato corrisponda allo stato reale del sito.
Lo sviluppatore non è tenuto a redigerla né a pubblicarla.
Può fornire supporto tecnico (audit, segnalazione criticità), ma l’atto formale resta in capo al committente.
👉Se il committente dichiara la piena conformità senza aver effettuato verifiche adeguate, la responsabilità non può essere trasferita allo sviluppatore.
Per un approfondimento sulla dichiarazione di accessibilità e su come va redatta, abbiamo una guida specifica.
Verifica della conformità: il committente non può affidarsi alla parola dello sviluppatore
Il committente ha l’obbligo di verificare la conformità del sito. Questo obbligo non si esaurisce nella dichiarazione del fornitore.
La verifica si articola su due livelli:
- Verifica automatizzata: strumenti come WAVE, axe DevTools, Lighthouse
- Verifica manuale: test con tecnologie assistive reali e analisi esperta
Affidarsi esclusivamente allo sviluppatore, senza un audit indipendente, significa assumersi il rischio che le non conformità emergano solo in fase di controllo o segnalazione.
👉 Se il committente non ha mai effettuato verifiche indipendenti, la sua posizione si indebolisce. Diventa evidente che ha omesso un obbligo proprio.
Scelta dello sviluppatore: perché la competenza in accessibilità è un criterio di selezione
La normativa incide anche sulla scelta dei fornitori.
Le aziende soggette all’EAA o alla Legge Stanca devono garantire la conformità dei servizi digitali.
Per farlo, devono affidarsi a fornitori competenti.
Nella Pubblica Amministrazione questo è esplicito: i contratti devono contenere clausole di accessibilità, pena la nullità.
Nel settore privato, il principio è lo stesso, anche se meno formalizzato:
sempre più aziende richiedono:
- competenze documentate
- referenze
- garanzie contrattuali
👉 Il committente che sceglie un fornitore non qualificato si assume una parte del rischio.
Non può poi imputare allo sviluppatore una carenza prevedibile fin dall’inizio.
Allo stesso tempo, lo sviluppatore che non dimostra competenze in accessibilità rischia l’esclusione da una fascia di mercato in crescita.
Per il quadro completo sugli obblighi del committente in materia di accessibilità dei siti web, rimandiamo alla nostra guida dedicata.
Obblighi dello sviluppatore siti web in materia di accessibilità
La responsabilità dello sviluppatore, come visto, si colloca sul piano contrattuale e professionale. Ma per capire fin dove arriva, serve chiarire cosa lo sviluppatore è concretamente tenuto a fare.
Gli obblighi non derivano solo dal contratto. Derivano anche dallo standard professionale atteso: ciò che un professionista del settore, nel 2026, è ragionevolmente tenuto a conoscere e applicare.
Cosa deve garantire chi sviluppa (Principi POUR)
Il riferimento tecnico per l’accessibilità dei siti web in Europa è la norma EN 301549, che richiama le Web Content Accessibility Guidelines (WCAG), nella versione 2.1, livello di conformità AA.
Questi standard si basano su quattro principi: percepibilità, operabilità, comprensibilità e robustezza.
Lo sviluppatore deve implementare:
- Percepibilità → testi alternativi, contrasto minimo 4.5:1, alternative ai media
- Operabilità → navigazione completa da tastiera, gestione del focus (WCAG 2.2)
- Comprensibilità → errori nei form gestiti correttamente, flussi prevedibili
- Robustezza → HTML semantico corretto, uso appropriato di ARIA
Questi non sono “best practice”. Sono lo standard minimo.
Uno sviluppatore che nel 2026 consegna:
❌ Heading usati solo per grafica
❌ Form senza label
❌ Menù non navigabili da tastiera
sta consegnando un prodotto non conforme ai requisiti tecnici minimi.
Questo non significa garantire la conformità totale del sito. Quella dipende anche da contenuti e scelte del committente.
Significa però che la parte tecnica sotto il controllo dello sviluppatore deve essere conforme.
Ed è su questo perimetro che si valuta la tua prestazione.
Dove lo sviluppatore si espone davvero
- Widget overlay: chi li propone si assume un rischio
I widget overlay di accessibilità sono soluzioni software che si sovrappongono al codice del sito promettendo di renderlo conforme senza interventi strutturali.
Sono spesso presentati come strumenti rapidi ed economici. Nella realtà, non garantiscono la conformità ai requisiti WCAG e possono introdurre ulteriori criticità, anche sul piano privacy. Le Linee Guida AgID 2026, ad esempio, vietano tecniche che desumono la disabilità dell’utente senza una base giuridica adeguata.
Il problema è anche contrattuale: la maggior parte dei fornitori di overlay non garantisce la conformità normativa. In altre parole, vendono una soluzione “di accessibilità” ma escludono la propria responsabilità.
Per lo sviluppatore, proporli come soluzione di adeguamento è quindi rischioso. Se il committente si affida a quella scelta e successivamente emerge una non conformità, la contestazione può ricadere su chi ha fornito quell’indicazione tecnica. Il rischio aumenta ulteriormente quando l’overlay viene integrato nell’offerta o rivenduto come servizio.
- Manutenzione e aggiornamenti
L’accessibilità non è uno stato che si raggiunge una volta per tutte: ogni modifica al sito – aggiornamenti, nuove funzionalità, interventi sul design – può introdurre nuove non conformità.
Quando esiste un contratto di manutenzione, la responsabilità dello sviluppatore può estendersi nel tempo. Se il perimetro non è chiaramente definito, il rischio è duplice: da un lato, rispondere di problemi introdotti da aggiornamenti tecnici; dall’altro, vedersi attribuire anche criticità legate ai contenuti inseriti dal committente.
Diventa quindi fondamentale distinguere tra manutenzione tecnica e responsabilità sulla conformità complessiva del sito. Senza questa distinzione, il confine si sposta facilmente a svantaggio dello sviluppatore.
- L’obbligo d’informare il committente
Molti clienti non conoscono la normativa sull’accessibilità, né sono consapevoli di essere soggetti obbligati. Questo, però, non riduce la responsabilità dello sviluppatore. Al contrario, la rafforza.
Chi sviluppa siti web ha un dovere professionale di informazione: deve segnalare i rischi legati alla mancata conformità e rendere il committente consapevole delle conseguenze delle sue scelte.
Deve quindi:
- segnalare l’esistenza dell’obbligo normativo
- chiarire i rischi della non conformità
- documentare questa comunicazione
Accettare di realizzare un sito non accessibile senza aver mai informato il cliente espone lo sviluppatore.
La difesa “non me lo hanno chiesto” è molto più debole di quanto si pensi, soprattutto quando la prestazione è resa da un professionista.
Contratto di sviluppo sito web e accessibilità: le clausole da prevedere
Il contratto è il punto in cui la distribuzione delle responsabilità tra sviluppatore e committente diventa concreta.
Finché le responsabilità restano implicite, il rischio è condiviso.
Quando vengono formalizzate, ciascuna parte sa cosa deve fare, cosa può pretendere e dove finisce il proprio perimetro.
Eppure, la maggior parte dei contratti di sviluppo oggi non contiene alcun riferimento all’accessibilità.
Né agli standard tecnici, né alla ripartizione delle responsabilità, né alle conseguenze in caso di non conformità.
È un vuoto che espone entrambe le parti, ma che nella pratica penalizza soprattutto lo sviluppatore.
Nullità del contratto senza clausole di accessibilità
Per i contratti con la Pubblica Amministrazione, la Legge 4/2004 stabilisce esplicitamente che i contratti di realizzazione o modifica di siti web devono contenere il riferimento ai requisiti di accessibilità. In assenza, il contratto è nullo.
L’art. 4 prevede inoltre che anche i contratti già in essere debbano essere adeguati in caso di rinnovo, modifica o novazione. Anche qui, a pena di nullità.
Questo implica che uno sviluppatore che firma un contratto con la PA senza clausole sull’accessibilità sta operando su un contratto potenzialmente nullo, e la nullità può essere rilevata in qualsiasi momento.
Nel settore privato non esiste una nullità espressa analoga. Ma il problema resta: se il committente è soggetto agli obblighi e il contratto non disciplina l’accessibilità, entrambe le parti operano in una zona grigia.
Separare la prestazione tecnica dalla responsabilità legale
Il contratto deve distinguere con precisione ciò che rientra nella prestazione tecnica dello sviluppatore da ciò che resta in capo al committente. È il principio che l’Avv. Vercellotti ha evidenziato parlando della distribuzione delle responsabilità dopo l’Accessibility Act: lo sviluppatore può implementare soluzioni che migliorano sensibilmente la fruibilità del sito, ma non può garantire da solo il pieno rispetto della normativa.
In pratica, un contratto ben strutturato dovrebbe prevedere:
- Perimetro tecnico della prestazione
Lo sviluppo avviene secondo WCAG 2.1 livello AA e EN 301549, limitatamente agli elementi sotto controllo diretto (struttura, navigazione, componenti, form) - Esclusione degli elementi a carico del committente
Contenuti, dichiarazione di accessibilità, gestione segnalazioni e feedback restano in capo al cliente - Obbligo di informazione reciproca
Lo sviluppatore segnala vincoli e rischi; il committente fornisce dati e contesto necessari
Questa distinzione non serve solo a proteggere lo sviluppatore. Serve a evitare equivoci e responsabilità improprie per entrambe le parti.
Clausole di manleva, collaudo e accettazione
Oltre alla definizione del perimetro, il contratto dovrebbe disciplinare tre momenti fondamentali del rapporto.
- La manleva consente allo sviluppatore di essere tenuto indenne per responsabilità legate a elementi fuori dal proprio controllo, come contenuti o scelte del committente.
- Il collaudo introduce una fase di verifica prima dell’accettazione definitiva.
Può includere test automatici e verifiche manuali, con criteri concordati. Se il committente accetta il sito senza collaudo, o senza contestazioni, la possibilità di sollevare problemi successivi si riduce, in linea con i principi dell’art. 1665 c.c. - L’accettazione, infine, segna il passaggio chiave: da quel momento, la responsabilità sulla conformità inizia a spostarsi verso il committente.
Questi tre elementi funzionano come un sistema: ciascuno rafforza gli altri. Senza collaudo, la manleva è più debole. Senza accettazione formale, il momento di passaggio della responsabilità resta indefinito.
Contratti in essere: cosa succede al rinnovo o alla modifica
La maggior parte dei rapporti tra sviluppatori e committenti non nasce oggi. Molti contratti sono stati stipulati prima dell’entrata in vigore dell’EAA, e non contengono alcun riferimento all’accessibilità.
La Legge 4/2004 disciplina espressamente questa situazione per i contratti con la PA: al rinnovo, alla modifica o alla novazione, il contratto deve essere adeguato ai requisiti di accessibilità. L’adeguamento è obbligatorio e previsto a pena di nullità.
Per i contratti con soggetti privati, il D.Lgs. 82/2022 non prevede una clausola analoga. Ma il principio operativo resta lo stesso: se il committente è oggi soggetto all’obbligo di accessibilità, e il contratto di manutenzione o sviluppo viene rinnovato senza aggiornare le clausole, entrambe le parti stanno prolungando una situazione di rischio non gestita.
Per lo sviluppatore, il rinnovo è il momento strategico per intervenire. In particolare per:
- inserire il riferimento agli standard di accessibilità
- ridefinire il perimetro della prestazione
- aggiornare le clausole di responsabilità (manleva, collaudo, accettazione)
Non adeguare il contratto al rinnovo significa continuare a operare con le stesse zone grigie. E se il committente subisce una sanzione o una contestazione durante il periodo di vigenza del contratto rinnovato, l’assenza di clausole aggiornate diventa un elemento a sfavore dello sviluppatore.
Per un approfondimento sulla struttura del contratto di realizzazione sito web e sulle clausole da prevedere, rimandiamo alla nostra guida dedicata.
Freelance, agenzia, subappalto: tre profili di rischio diversi
La qualificazione giuridica del rapporto tra sviluppatore e committente incide direttamente sul tipo e sull’entità della responsabilità.
- Il freelance opera generalmente nell’ambito del contratto d’opera, per cui il professionista si impegna a realizzare un’opera secondo le indicazioni del committente, con autonomia organizzativa. La responsabilità è personale e diretta: se il sito consegnato non rispetta gli standard di accessibilità concordati o ragionevolmente attesi, il freelance risponde in prima persona. Il profilo di rischio del freelance è amplificato da un elemento pratico: nella maggior parte dei casi, il contratto è meno strutturato rispetto a quello di un’agenzia, le clausole di limitazione della responsabilità sono assenti o generiche, e non esiste una separazione formale tra chi progetta, chi sviluppa e chi verifica la conformità.
- L’agenzia web opera spesso nell’ambito del contratto d’appalto. La differenza sostanziale è che l‘appaltatore si obbliga a un risultato, con organizzazione dei mezzi propri. Questo comporta un livello di responsabilità più strutturato: l’agenzia risponde non solo dell’esecuzione tecnica, ma anche della conformità del risultato alle specifiche concordate e alla normativa applicabile. In caso di vizi o difformità dal progetto, il committente può chiederne la correzione, la riduzione del prezzo o, se il sito è del tutto inadeguato all’uso, la risoluzione del contratto.
- Il subappalto introduce un terzo livello. Quando l’agenzia affida parte dello sviluppo a un fornitore esterno, come uno sviluppatore tecnico, un front-end specialist, un consulente UX, la responsabilità verso il committente resta in capo all’agenzia. Ma l’agenzia, a sua volta, può rivalersi sul subappaltatore se il difetto di conformità deriva dalla sua prestazione. Questo rende necessario che anche i contratti di collaborazione esterna, contengano clausole specifiche sull’accessibilità.
Legal for Digital: consulenza legale sull’accessibilità per chi sviluppa e chi commissiona siti web
Legal for Digital è la prima società di consulenza legale in Italia completamente verticalizzata sul diritto del digitale.
Lavoriamo con sviluppatori, freelance, agenzie web e con i loro committenti: e-commerce, imprese digitali, aziende che operano online, con un sistema che mira a trasformare gli obblighi normativi in strumenti di business.
Sull’accessibilità questo significa due cose.
Da un lato, aiutiamo chi sviluppa a definire il perimetro della propria responsabilità e a strutturare contratti che tutelino davvero il lavoro svolto.
Dall’altro, affianchiamo chi commissiona nella gestione della conformità, evitando che venga delegata interamente al fornitore o percepita come un semplice costo.
Il nostro team di avvocati specializzati in accessibilità supporta entrambe le parti con:
- consulenze mirate
- audit contrattuali
- percorsi di adeguamento costruiti sul singolo progetto
Perché sull’accessibilità il problema non è solo rispettare la norma,
ma capire chi risponde, per cosa e in quali limiti.
Brunella Martino
Avvocato specializzato in privacy e proprietà intellettuale con 18 anni di esperienza, DPO, arbitro in materia societaria, autrice Flaccovio Editore, formatrice aziendale, socia FederPrivacy, già componente Aiga nazionale Dipartimento Diritto delle nuove tecnologie, Founder Legal for Digital studio dell'anno per il Sole 24 Ore e Corriere della Sera
⚖️ Contratto di consulenza SEO: la guida
1 Ottobre 2019Il contratto di consulenza seo è l’accordo con cui un professionista SEO si impegna ad applicare una strategia di posizionamento organico per il sito internet di un cliente.
Leggi altro
⚖️ Contratto sviluppo app: la guida
31 Dicembre 2020Lo sviluppo di applicazioni è un’attività che per molti aspetti può essere assimilata allo sviluppo software, infatti un’applicazione è un software applicativo. Quindi ci saranno molte clausole in comune con il contratto di sviluppo software.
Tuttavia rispetto ai software, progettati per il desktop, ci sono delle particolarità che partono dal presupposto che le app devono essere compatibili con le condizioni imposte dagli app store. Da qui una serie di conseguenze.
Leggi altro
⚖️ Contratto grafici su misura per graphic designer liberi professionisti
18 Dicembre 2019Per i grafici freelance, un contratto accuratamente redatto rappresenta una dichiarazione di professionalità e serietà. Esso definisce non solo i termini dell’incarico, ma anche aspetti cruciali come la tutela della proprietà intellettuale, i termini di pagamento, le tempistiche e le responsabilità di ogni parte.
Leggi altro