Aureon
Demo gratuita
← Blog

Accessibilità sito web: obblighi normativi e primi passi pratici

Illustrazione decorativa sull'accessibilità del web

Se gestisci un sito web professionale o aziendale, oggi hai un obbligo misurabile, non un’opzione da valutare in futuro. La Direttiva UE 2016/2102, recepita in Italia e affiancata dalla norma tecnica EN 301 549, impone requisiti precisi di accessibilità; per molti soggetti scatta anche l’obbligo di pubblicare la Dichiarazione di accessibilità tramite form.agid.gov.it. Il primo passo concreto è verificare se questa dichiarazione esiste già sul tuo sito o avviare un audit rapido delle pagine principali.

In breve:

  • La conformità richiede di verificare se si possiede già una Dichiarazione di accessibilità e di aggiornarla ogni anno entro il 23 settembre.
  • La norma EN 301 549, basata sulle WCAG 2.2, è il principale riferimento tecnico con obiettivi pratici di livello AA per garantire l’accessibilità.
  • La dichiarazione di accessibilità deve essere pubblicata in modo visibile nel footer del sito, includendo stato di conformità, limitazioni e contatti, e essere aggiornata annualmente.
  • La principale verifica tecnica si ottiene attraverso scanner automatici, test con screen reader e navigazione da tastiera, documentando ogni risultato con screenshot e note tecniche.
  • Per un sito ben strutturato sin dall’inizio, è fondamentale progettare in modo inclusivo, scegliendo colori, form e componenti secondo i principi del design accessibile.
Aureonweb
Dai forma al tuo sito accessibile
Aureon crea una demo realistica del tuo sito in 12 ore, con design personalizzato e ottimizzato per i motori di ricerca.

Indice

Chi deve adeguarsi all’accessibilità sito web e quale normativa si applica

L’obbligo nasce dalla Direttiva (UE) 2016/2102, che ha imposto agli Stati membri di rendere accessibili i siti e le app mobili della pubblica amministrazione, fissando anche i quattro principi cardine dell’accessibilità digitale che riprenderemo più avanti. In Italia questo quadro si è progressivamente allargato: il decreto legislativo 82/2022 recepisce parte dell’European Accessibility Act (EAA) e introduce requisiti di accessibilità per prodotti e servizi immessi sul mercato, applicabili dal 28 giugno 2025. Non riguarda più solo gli enti pubblici.

Le linee guida AGID dedicate ai soggetti privati chiariscono che l’obbligo si estende anche a imprese private che erogano servizi al pubblico, con criteri legati a fatturato e tipologia di attività. Se vendi online, gestisci prenotazioni o offri servizi digitali a clienti finali, è molto probabile che tu rientri in una di queste categorie, anche se non sei un ente pubblico.

I punti da tenere sotto controllo sono:

  • Verificare se la propria attività rientra tra i soggetti privati obbligati secondo i criteri AGID.
  • Controllare se esiste già una Dichiarazione di accessibilità pubblicata sul sito.
  • Monitorare l’evoluzione normativa legata all’EAA, che negli anni recenti ha ampliato il perimetro di applicazione.
  • Segnare in agenda la scadenza di aggiornamento annuale della dichiarazione, che va aggiornata ogni anno entro il 23 settembre.

Ignorare questi passaggi non è più un rischio teorico: gli enti di vigilanza possono richiedere verifiche, e un sito non conforme espone l’azienda a segnalazioni e richieste di adeguamento.

Standard tecnici e criteri di conformità: EN 301 549 e WCAG

Lo standard tecnico che fa da riferimento operativo per l’accessibilità sito web è la norma EN 301 549. Quando è armonizzata, offre la presunzione di conformità ai requisiti della Direttiva UE 2016/2102, come chiarisce la Commissione europea nella sua pagina dedicata a norme e armonizzazione. In pratica, EN 301 549 si basa in larga misura sulle Web Content Accessibility Guidelines (WCAG), ma aggiunge requisiti che vanno oltre i criteri del W3C, in particolare per software, hardware e documenti non web.

Le WCAG 2.2 restano il testo di riferimento per capire cosa significa “accessibile” a livello di contenuti web. Definiscono tre livelli di conformità:

  • Livello A: requisiti minimi, spesso insufficienti per un sito professionale.
  • Livello AA: lo standard raccomandato dalla maggior parte delle normative europee, incluso il contesto italiano.
  • Livello AAA: il livello più rigoroso, difficile da raggiungere su tutte le pagine di un sito complesso.

Un dato da ricordare: rispettare solo le WCAG non basta automaticamente a garantire la presunzione di conformità alla norma armonizzata, perché EN 301 549 include requisiti aggiuntivi che vanno oltre il perimetro coperto dalle sole linee guida W3C.

Per un’impresa che punta alla conformità concreta, il livello AA delle WCAG 2.2 rappresenta oggi l’obiettivo più realistico e difendibile.

Dichiarazione di accessibilità: contenuti, pubblicazione e scadenze

Per le pubbliche amministrazioni, la dichiarazione va compilata esclusivamente tramite l’applicazione ufficiale Form, che richiede credenziali RTD per procedere. I soggetti privati obbligati seguono un modello analogo, basato sulle linee guida AGID.

Una dichiarazione completa deve includere:

  1. Lo stato di conformità dichiarato: conforme, parzialmente conforme o non conforme, secondo il modello di autovalutazione AGID.
  2. Le eventuali limitazioni di accessibilità riscontrate, descritte in modo specifico e non generico.
  3. Le alternative accessibili offerte al pubblico, quando alcune sezioni non sono pienamente conformi.
  4. I contatti a cui rivolgere segnalazioni o richieste di supporto.

La dichiarazione va pubblicata in una posizione facilmente raggiungibile dal sito, tipicamente nel footer, e aggiornata ogni anno entro il 23 settembre. Il meccanismo di feedback previsto non è un dettaglio formale: raccogliere e gestire le segnalazioni degli utenti è parte integrante dell’obbligo, non un’aggiunta facoltativa.

Come verificare l’accessibilità: checklist operativa e strumenti

Il flusso più efficace combina tre livelli di verifica: scansione automatica, controllo manuale tecnico e test con utenti reali. Le linee guida AGID per la pubblica amministrazione sottolineano che unire test automatici e verifica manuale riduce sensibilmente il rischio di errori che gli scanner da soli non intercettano.

Gli strumenti da usare in sequenza:

  • Validatori HTML e scanner automatici per individuare errori strutturali evidenti (contrasto colore, alt mancanti, markup non semantico).
  • Screen reader come NVDA per verificare come il sito viene letto da chi non usa il mouse.
  • Test di navigazione da tastiera, verificando che ogni elemento interattivo sia raggiungibile con Tab e utilizzabile senza puntatore.
  • Controlli specifici sui documenti scaricabili (PDF, moduli) per verificare che siano leggibili da tecnologie assistive.

Un consiglio: documenta ogni test con screenshot e note tecniche: questo materiale ti servirà sia per compilare la dichiarazione sia per rispondere rapidamente a eventuali segnalazioni di utenti o controlli esterni.

Se dopo lo scan automatico emergono decine di errori critici o il sito gestisce funzioni complesse come pagamenti e prenotazioni, è il momento di coinvolgere un fornitore esterno specializzato in audit di accessibilità.

Strategie pratiche per l’implementazione: priorità tecniche e contenutistiche

Non tutti gli interventi hanno lo stesso peso. Alcuni elementi tecnici incidono immediatamente sull’esperienza di chi usa tecnologie assistive, altri sono raffinamenti da affrontare in seconda battuta.

Le priorità operative, in ordine:

  1. Markup semantico corretto: usare heading in ordine gerarchico, landmark HTML5 (header, nav, main, footer) e liste vere invece di paragrafi impaginati con spazi.
  2. Testi alternativi per le immagini: ogni immagine informativa deve avere un attributo alt descrittivo; le immagini decorative vanno marcate come tali.
  3. Etichette (label) per ogni campo dei form: un campo senza label associata è invisibile per uno screen reader, anche se visivamente chiaro.
  4. Navigazione da tastiera completa: ogni link, pulsante e menu deve essere raggiungibile e attivabile senza mouse, con un focus visibile in ogni momento.
  5. Gestione dei documenti non web: i PDF scaricabili vanno resi accessibili o sostituiti con pagine HTML equivalenti, più semplici da verificare e mantenere.

Un consiglio: inserisci un controllo di accessibilità in ogni sprint di sviluppo, non solo a fine progetto: correggere un heading fuori ordine costa pochi minuti durante la costruzione, ma diventa un intervento oneroso su un sito già in produzione.

Integrare questi controlli nel processo di sviluppo, invece di trattarli come un’attività separata, è ciò che distingue un sito realmente mantenibile da uno che richiede un audit costoso ogni volta che cambia qualcosa.

Un esempio pratico: verificare l’accessibilità prima del lancio

Una demo realistica del sito, disponibile prima di qualsiasi pagamento, permette di testare soluzioni accessibili quando i costi di modifica sono ancora bassi. È molto più semplice correggere la struttura dei heading o il contrasto dei colori su una demo che intervenire su un sito già pubblicato e indicizzato.

Alcuni elementi utili in questa fase:

  • Una demo consegnata entro 12 ore consente di verificare rapidamente markup, navigazione da tastiera e leggibilità dei contenuti.
  • I pacchetti Sito Vetrina e Sito E-commerce di Aureonweb includono un’area amministrativa che permette di intervenire su testi e immagini senza competenze tecniche, utile per mantenere gli standard nel tempo.
  • Il supporto tecnico incluso per tre mesi dopo il lancio dà margine per sistemare eventuali criticità emerse dai primi test reali.

Resta un punto fermo: la responsabilità di redigere e aggiornare la Dichiarazione di accessibilità è sempre del titolare del sito, indipendentemente da chi lo ha realizzato.

I quattro principi POUR delle WCAG

Le WCAG si costruiscono attorno a quattro principi, spesso indicati con l’acronimo POUR: percepibilità, utilizzabilità, comprensibilità, robustezza. Sono i criteri con cui il W3C valuta ogni requisito tecnico, e capirli aiuta a interpretare correttamente checklist e strumenti di test.

I quattro principi POUR delle WCAG

La percepibilità riguarda la possibilità di percepire un contenuto attraverso almeno un senso: un video senza sottotitoli non è percepibile per chi non sente, un’immagine senza testo alternativo non lo è per chi usa uno screen reader. L’utilizzabilità riguarda l’interazione: ogni funzione deve essere raggiungibile da tastiera, senza limiti di tempo troppo stretti e senza elementi che inducono crisi epilettiche per lampeggiamenti eccessivi.

La comprensibilità richiede che testo e funzionamento del sito siano prevedibili e chiari, con messaggi di errore comprensibili nei form. La robustezza garantisce che il contenuto funzioni con tecnologie assistive attuali e future, il che significa scrivere codice HTML valido e semanticamente corretto.

Questi quattro principi non sono un esercizio teorico da manuale: ogni criterio di successo delle WCAG, dal livello A al AAA, si ricollega a uno di essi. Quando un test di accessibilità segnala un errore, capire a quale principio appartiene aiuta a decidere quanto sia urgente intervenire.

I benefici dell’accessibilità web per utenti e aziende

Un sito accessibile non serve solo a chi ha una disabilità dichiarata. Sottotitoli, contrasto adeguato e navigazione da tastiera migliorano l’esperienza anche per chi usa lo smartphone sotto il sole, per chi ha una connessione lenta o per chi semplicemente preferisce muoversi con la tastiera invece del mouse.

Per le aziende, i vantaggi si vedono su più fronti. Un pubblico più ampio può effettivamente completare acquisti e prenotazioni, invece di abbandonare il sito per frustrazione. La reputazione del brand ne beneficia, soprattutto in settori dove il servizio al cliente è un fattore competitivo diretto. E la conformità normativa riduce il rischio di segnalazioni, richieste di adeguamento o contenziosi legati alla Direttiva UE 2016/2102.

C’è anche un beneficio meno discusso: un sito costruito con markup semantico corretto e struttura chiara tende a essere più facile da mantenere e aggiornare nel tempo, perché sviluppatori e content manager lavorano su una base più ordinata. L’accessibilità, in questo senso, non è un costo isolato ma un investimento che si ripaga nella manutenzione quotidiana del sito.

Che impatto ha l’accessibilità su usabilità e SEO

Accessibilità e usabilità condividono buona parte degli stessi principi. Un heading strutturato correttamente aiuta sia uno screen reader sia un utente che scorre velocemente la pagina in cerca di un’informazione. Un contrasto colore adeguato aiuta chi ha una lieve ipovisione e chi legge lo schermo in piena luce.

Sul fronte SEO, il legame è concreto. I motori di ricerca leggono la pagina in modo simile a uno screen reader: si affidano al markup semantico, ai testi alternativi delle immagini e alla gerarchia dei heading per capire di cosa parla un contenuto. Un sito con alt text descrittivi e struttura ordinata offre agli algoritmi di ricerca segnali più chiari, mentre un sito con markup confuso e contenuti non testuali privi di alternative rischia di perdere visibilità, indipendentemente da quanto sia valido il contenuto stesso.

Anche i tempi di caricamento entrano in questo equilibrio: un sito appesantito da elementi non ottimizzati penalizza sia l’esperienza di chi usa tecnologie assistive, spesso più sensibili ai ritardi, sia il posizionamento nei risultati di ricerca. Lavorare sull’accessibilità sito web, quindi, non è un’attività separata dall’ottimizzazione SEO: nella pratica, le due cose si sovrappongono su gran parte degli interventi tecnici.

Strumenti e risorse per l’accessibilità

Costruire un flusso di verifica efficace richiede pochi strumenti, usati con costanza più che con sofisticazione. Gli scanner automatici individuano rapidamente errori strutturali comuni: contrasto insufficiente, immagini senza alt, campi form senza label. Sono un buon punto di partenza, ma non sostituiscono la verifica manuale.

Gli screen reader come NVDA (gratuito e diffuso) permettono di ascoltare come il sito viene effettivamente presentato a chi non può vederlo. Provare a navigare l’intero sito solo con tastiera, senza mai toccare il mouse, è un test altrettanto rivelatore: capita spesso che un menu a tendina funzioni perfettamente al clic ma resti irraggiungibile con il tasto Tab.

Per chi gestisce documenti scaricabili, esistono strumenti dedicati alla verifica dei PDF, che controllano la presenza di tag semantici e l’ordine di lettura corretto. Le linee guida AGID restano il riferimento più aggiornato per il contesto italiano, mentre le WCAG del W3C offrono la base tecnica dettagliata dietro ogni criterio di successo.

Un buon approccio combina strumenti gratuiti per i controlli quotidiani con una verifica manuale periodica più approfondita, magari trimestrale, per intercettare problemi che nessuno scanner automatico riesce a individuare.

Come si progetta un sito accessibile fin dall’inizio

Il design inclusivo funziona meglio quando entra nel progetto dalla prima bozza, non come correzione finale. Pensare all’accessibilità durante la fase di wireframe, prima ancora di scrivere una riga di codice, costa molto meno che rincorrere problemi su un sito già sviluppato.

Concretamente, questo significa scegliere palette di colori con contrasto sufficiente fin dai primi mockup, progettare form con label sempre visibili invece di placeholder che scompaiono al clic, e strutturare la gerarchia dei contenuti pensando a come apparirà a uno screen reader, non solo a come apparirà visivamente.

Un altro aspetto spesso trascurato riguarda i componenti interattivi personalizzati: menu a tendina, caroselli di immagini, popup. Ogni elemento costruito su misura, invece di usare i controlli HTML nativi del browser, richiede un lavoro aggiuntivo per garantire che funzioni con tastiera e tecnologie assistive. La scelta più semplice, quando possibile, è affidarsi a componenti HTML standard: sono già accessibili di default, senza bisogno di reinventare comportamenti che il browser gestisce da solo.

Il design inclusivo non è un livello estetico aggiuntivo: è una sequenza di decisioni tecniche prese al momento giusto, quando costano poco correggerle.

Formare il team e coinvolgere gli stakeholder

L’accessibilità sito web smette di funzionare quando resta responsabilità di una sola persona. Sviluppatori, content manager e chi si occupa di grafica devono condividere un livello minimo di competenza: chi scrive testi alternativi per le immagini deve capire perché “immagine1.jpg” non è una descrizione utile, e chi progetta il layout deve sapere che un colore troppo simile allo sfondo esclude chi ha difficoltà visive.

Coinvolgere gli stakeholder aziendali, non solo il team tecnico, è altrettanto importante. Chi decide budget e scadenze deve sapere che un audit di accessibilità e le correzioni conseguenti richiedono tempo pianificato, non un intervento dell’ultimo minuto prima del lancio. Una checklist condivisa, integrata nel processo di sviluppo, evita che l’accessibilità diventi un’attività isolata affidata a chi ha tempo libero a fine progetto.

Anche una formazione minima, come una sessione pratica sull’uso di uno screen reader o sulla navigazione da tastiera, cambia radicalmente la sensibilità di chi lavora quotidianamente sul sito. Vedere con i propri occhi quanto sia frustrante un form senza label insegna più di qualsiasi documento normativo.

Consigli pratici per PMI e professionisti

Se il tuo sito ha meno di venti pagine e funzioni semplici, un audit interno con scanner automatici e test da tastiera può bastare. Con e-commerce, aree riservate o form complessi, conviene affidarsi a un professionista esterno per la verifica manuale. In entrambi i casi, procedi per priorità: correggi prima gli errori critici, poi rilascia e testa di nuovo. L’accessibilità ben fatta migliora quasi sempre anche SEO e esperienza utente insieme.

— Alessandro

Demo rapida e pacchetti per un sito pronto alla dichiarazione

Aureonweb ti dà quello che nessun preventivo tradizionale offre: una demo realistica del tuo sito entro 12 ore, gratuita, prima di qualsiasi pagamento. Puoi verificare struttura, contrasto colore e navigazione da tastiera direttamente sulla demo, prima ancora di decidere se procedere.

Aureonweb

I pacchetti di siti web includono design personalizzato, ottimizzazione SEO e velocità di caricamento, con un’area amministrativa che permette di gestire testi, immagini e contenuti in autonomia anche dopo il lancio. Sono previsti costi di mantenimento mensile per dominio, hosting e backup, con prezzi indicati sul sito. Inoltre, è incluso supporto tecnico per alcuni mesi dopo il lancio per sistemare eventuali criticità emerse dai primi test reali con utenti veri.

Se stai valutando come rendere accessibile il tuo prossimo sito senza sorprese sui costi, richiedi la tua demo gratuita sui pacchetti disponibili e verifica di persona come viene gestita la struttura tecnica.

Fonti

Domande frequenti

Quali sono i criteri di accessibilità per un sito web?

I criteri principali derivano dalle WCAG e dalla norma EN 301 549: markup semantico corretto, testi alternativi per le immagini, navigazione completa da tastiera e contrasto colore adeguato sono tra i più verificati.

Quali sono i quattro principi di accessibilità?

Sono percepibilità, utilizzabilità, comprensibilità e robustezza, noti con l’acronimo POUR, definiti dalle WCAG del W3C.

Cosa si intende per accessibilità di un sito web?

Significa progettare un sito utilizzabile da chiunque, incluse persone con disabilità visive, motorie, uditive o cognitive, tramite tecnologie assistive come screen reader o navigazione da tastiera.

Qual è la normativa che regola l’accessibilità dei siti web in Italia?

Il riferimento principale è la Direttiva UE 2016/2102, affiancata dal decreto legislativo 82/2022 che recepisce parte dell’European Accessibility Act, con obblighi verificabili tramite la Dichiarazione di accessibilità su form.agid.gov.it.

Quanto costa realizzare un sito accessibile con Aureonweb?

I prezzi dei pacchetti Sito Vetrina e Sito E-commerce sono disponibili sulla pagina prodotti; il mantenimento mensile parte da 15 € per il Sito Vetrina.

Raccomandati

Created with BabyLoveGrowth’s technology

← Torna al blog