Prova a navigare il tuo sito senza mouse, solo con il tasto Tab. Se dopo tre o quattro pressioni il focus sparisce, o finisce dentro un menu da cui non si esce più, hai appena trovato un problema di accessibilità. Non serve un software costoso per accorgersene. Serve farlo davvero. Una volta.
L’accessibilità di un sito web è la capacità di un sito di essere usato da chiunque, incluse le persone che non vedono bene, non sentono, non usano il mouse o navigano con uno screen reader. Non è un plugin. Non è una spunta da mettere una volta sola. È una caratteristica tecnica del sito, misurabile, che si perde ogni volta che si aggiunge un elemento senza pensarci.
Cosa significa davvero che un sito web è accessibile
Lo standard tecnico di riferimento è il WCAG (Web Content Accessibility Guidelines), pubblicato dal W3C, il consorzio internazionale che definisce gli standard del web. La versione più citata oggi è la WCAG 2.1, con il livello AA come riferimento pratico per la maggior parte dei siti — il livello AAA esiste ma è più stringente e spesso non applicabile a un intero sito commerciale.
Le WCAG si organizzano intorno a quattro principi, noti con l’acronimo POUR: percepibile (le informazioni devono arrivare anche senza vista o udito), utilizzabile (l’interfaccia deve funzionare anche da tastiera), comprensibile (testo e navigazione devono avere senso logico) e robusto (il codice deve funzionare con tecnologie assistive diverse, non solo con l’ultimo Chrome). Da qui derivano le regole concrete: contrasto colore minimo, testo alternativo per le immagini, struttura dei titoli coerente, form con etichette collegate ai campi.
Un sito web accessibile e inclusivo non è un sito minimalista o “per disabili”. È un sito costruito con HTML semantico corretto — heading in ordine, landmark ARIA dove servono, link con un testo che ha senso anche fuori contesto — più un po’ di attenzione al contrasto e alle immagini. Gran parte del lavoro è invisibile a chi vede e sente bene, ma cambia tutto per chi non può.
Perché conta anche per il business, non solo come obbligo
In Italia l’accessibilità digitale è un obbligo di legge per gli enti pubblici dalla Legge Stanca (Legge 4/2004), poi aggiornata con il D.Lgs. 106/2018 per recepire la direttiva UE 2016/2102. AGID sovrintende il tema e ha definito il modello di dichiarazione di accessibilità che i siti pubblici devono pubblicare. Con l’European Accessibility Act, l’obbligo si estende gradualmente anche a una parte del settore privato — e-commerce, servizi bancari, trasporti — con un’applicazione che parte dal 2025. Se lavori con la Pubblica Amministrazione, anche solo come fornitore, l’accessibilità del tuo sito diventa un requisito che qualcuno ti chiederà di dimostrare. Lo standard tecnico europeo EN 301 549 traduce questi principi in requisiti verificabili per prodotti e servizi digitali, ed è il riferimento a cui la conformità normativa fa capo sia per gli enti pubblici sia, sempre di più, per le applicazioni mobili delle imprese private.
Ma ridurla a un obbligo è miope. Le stime dell’Organizzazione Mondiale della Sanità parlano di circa una persona su sei nel mondo che convive con una qualche forma di disabilità — motoria, visiva, uditiva o cognitiva. Un sito che quella persona non riesce a usare è un sito che perde clienti. Non solo un rischio legale. E c’è un terzo effetto, meno ovvio: molte pratiche di accessibilità coincidono con le buone pratiche SEO. Alt text descrittivo, struttura dei titoli pulita, HTML semantico, form etichettati correttamente — sono esattamente le cose che aiutano Google a capire una pagina. Non è un caso. Entrambi i sistemi, motore di ricerca e screen reader, leggono il codice, non il colore dello sfondo.
Gli errori più comuni che si trovano in giro
Abbiamo verificato decine di siti con gli strumenti gratuiti descritti più sotto. Gli errori che tornano sono pochi. Sempre gli stessi.
Contrasto colore insufficiente. Testo grigio chiaro su sfondo bianco, o bottoni pastello con scritta bianca: leggibili per chi vede bene con lo schermo al massimo, illeggibili per chiunque altro. La soglia WCAG AA è 4,5:1 per il testo normale.
Alt text mancante o inutile. Immagini senza attributo alt, oppure con alt=”immagine1.jpg”: per uno screen reader è come se l’immagine non esistesse. O peggio: come se leggesse un nome di file a voce alta.
Form senza label collegate. Un campo “Nome” che si vede bene ma non è tecnicamente associato al suo input: chi usa la tastiera o uno screen reader non sa cosa deve scrivere lì dentro. Zero indizi.
Navigazione da tastiera impossibile. Menu che si aprono solo al passaggio del mouse, focus che sparisce, pulsanti che si attivano solo al click e non al tasto Invio. Prova tu stesso il test del Tab descritto in apertura: è il modo più rapido per trovarli.
Link generici. Una pagina piena di “clicca qui” o “leggi di più” senza contesto è inutile per chi naviga a salti tra i link con uno screen reader, funzione che quasi tutti usano davvero.
Come fare una prima verifica gratuita
Non serve comprare niente. Bastano tre controlli, in un pomeriggio, per capire a che punto è il tuo sito.
WAVE. Lo strumento gratuito di WebAIM analizza una URL e segnala errori di contrasto, alt text mancante, struttura dei titoli scorretta, direttamente sovrapposti alla pagina. È il punto di partenza più immediato: nessuna installazione, si incolla l’indirizzo e si guarda cosa si accende in rosso.
Google Lighthouse. Integrato nei DevTools di Chrome (tasto destro, Ispeziona, scheda Lighthouse), genera un punteggio di accessibilità 0-100 con l’elenco puntuale di cosa lo abbassa. Utile per avere un numero da monitorare nel tempo, non solo un elenco di errori.
Test manuale da tastiera e screen reader. Nessuno strumento automatico trova tutto. Mai. Le stime comuni dicono che copre circa un terzo dei problemi reali. Il resto si trova navigando: solo Tab, senza mouse, e con uno screen reader gratuito come NVDA su Windows o VoiceOver, già incluso su Mac.
Nella nostra esperienza questi tre controlli insieme coprono la maggior parte dei problemi bloccanti. Quello che restano sono i dettagli fini — ordine di lettura logico, testo dei link nel contesto — che si trovano solo usando il sito come lo userebbe qualcun altro.
Come lavoriamo noi su un progetto di accessibilità
Il primo passo è un audit: strumenti automatici più test manuale da tastiera e screen reader, per avere sia i numeri che i casi concreti che gli strumenti non vedono.
Il secondo passo è la prioritizzazione. Sempre. Non tutti gli errori pesano uguale: un form di contatto inaccessibile blocca una conversione, un attributo alt mancante su un’immagine decorativa quasi no. Si parte da quello che impedisce a qualcuno di completare un’azione. Non dalla lista più lunga.
Il terzo passo è intervenire sui template e sui componenti ricorrenti — header, footer, form, menu — invece che pagina per pagina: un errore nel componente si ripete su tutto il sito, e correggerlo una volta lo risolve ovunque.
Il quarto passo è la riverifica con gli stessi strumenti dell’audit iniziale, per avere un prima e un dopo misurabile e non un “adesso è meglio” a sensazione. Se il sito è di un ente pubblico o lavora con la PA, l’ultimo passo è la dichiarazione di accessibilità nel modello richiesto da AGID.
Domande frequenti sull’accessibilità dei siti web
Un sito accessibile è obbligatorio per legge?
Per gli enti pubblici sì, dalla Legge Stanca e dal D.Lgs. 106/2018. Per i privati l’obbligo si sta estendendo con l’European Accessibility Act, in modo graduale a partire dal 2025 e limitato ad alcuni settori. Ma anche dove non è obbligo, resta una scelta utile. Allarga il pubblico raggiunto.
L’accessibilità di un sito aiuta anche la SEO?
Sì. In modo indiretto ma concreto. Alt text descrittivo, struttura dei titoli coerente, HTML semantico e form etichettati sono elementi che sia gli screen reader sia i motori di ricerca leggono nello stesso modo: dal codice, non dall’aspetto visivo della pagina.
Quanto costa rendere accessibile un sito web?
Dipende da quanti errori ha il sito e se sono concentrati nei template o sparsi pagina per pagina: un preventivo serio arriva solo dopo un audit reale. Non a occhio. Se vuoi una valutazione sul tuo sito, la pagina richiedi un preventivo è il punto di partenza.
Gli strumenti gratuiti come WAVE e Lighthouse bastano per essere sicuri di essere conformi?
Bastano per un primo controllo. Non per una conformità certificata. Coprono bene gli errori tecnici — contrasto, alt text, struttura — ma non tutto quello che riguarda l’uso reale con tastiera e screen reader. Per quello serve un test manuale, e per una dichiarazione di accessibilità nel modello AGID serve una verifica più strutturata.
Da dove si comincia se il sito è online da anni ed è pieno di contenuti?
Dai template. Non dalle singole pagine. Header, footer, menu e form si ripetono ovunque: sistemarli una volta risolve l’errore su centinaia di pagine insieme. Le pagine con più traffico o più conversioni vengono dopo, il resto del sito segue via via.
Un sito accessibile non si ottiene con una spunta o un plugin che promette la conformità automatica — questi strumenti, nella nostra esperienza, spesso aggiungono più problemi di quanti ne risolvano. Si ottiene con attenzione al codice e verifiche reali, fatte con costanza. Se stai valutando una creazione o revisione del sito web e vuoi che l’accessibilità sia parte del progetto fin dall’inizio invece che una correzione a posteriori, scriveteci: siamo Tuscan Solutions, Via Tevere 10 a Pisa, telefono 392 872 2682. Trovate tutti i recapiti nella pagina contatti.
Gli approfondimenti su cui si appoggia questa guida
Sull’accessibilità abbiamo scritto negli anni schede più ristrette, che qui restano utili come letture di dettaglio: come si struttura il testo per i lettori di schermo, tre correzioni che valgono più di un restyling, perché il WCAG è diventato lo standard di fatto, la differenza fra accessibilità e usabilità, quando l’accessibilità smette di essere un obbligo e diventa qualità e le regole minime da rispettare in fase di progetto.