Errori di accessibilità nei siti web: quali sono i più comuni e come correggerli

Aggiornato il: 21/07/2026

Quasi una persona su cinque nel mondo vive con una disabilità. Eppure solo il 4% circa dei siti web è progettato per essere usabile da tutti. Chi non riesce a completare un acquisto, leggere un documento o navigare un servizio bancario online, non è escluso per propria scelta ma, comunque, si trasforma in un utente perso.

In questo articolo

• Perché l'accessibilità web riguarda anche la tua azienda

• I 13 principali errori di accessibilità nei siti web

• Cosa dice la normativa: EAA, WCAG e Legge Stanca

• Quali strumenti e tecniche usare per migliorare l'accessibilità del tuo sito?

• Come fare un audit di accessibilità efficace

• Domande frequenti

Secondo il report WebAIM Million 2026, il 95,9% del milione di homepage più visitate al mondo presenta errori rispetto alle Web Content Accessibility Guidelines (WCAG), con una media di 56,1 problemi per pagina.

I numeri peggiorano rispetto all'anno precedente, nonostante anni di attenzione al tema. Il che significa che le barriere digitali sono il risultato di processi di sviluppo che non includono l'accessibilità fin dalle fasi di progettazione.

Perché l'accessibilità web riguarda anche la tua azienda

L'accessibilità è un obbligo di legge, oltre ad essere un obbligo etico.

Dal 28 giugno 2025, l'European Accessibility Act (EAA) è pienamente in vigore in Italia, con obblighi concreti per e-commerce, banche, trasporti, media e piattaforme digitali. Le Linee Guida AgID operative dal marzo 2026 hanno aggiunto strumenti di vigilanza e sanzionatori che rendono il rischio normativo reale, non teorico.

Ma c'è anche un argomento di mercato. Una ricerca di Accenture mostra che le aziende più inclusive dal punto di vista della disabilità generano 1,6 volte più ricavi rispetto alla media. Il 69% delle persone con disabilità abbandona i siti che trova difficili da usare.

Ogni barriera digitale irrisolta è un potenziale cliente perso.

I 13 principali errori di accessibilità nei siti web

Questi sono gli errori che compaiono più spesso nelle scansioni automatizzate e nelle verifiche manuali.

Immagini senza testo alternativo

Il problema: Un'immagine senza attributo alt è invisibile per chi usa uno screen reader. La tecnologia assistiva legge "immagine" e si ferma, senza trasmettere alcun contenuto informativo.

Le Web Content Accessibility Guidelines (WCAG) 2.1 richiedono che ogni immagine informativa abbia un testo alternativo descrittivo. Se l'immagine è decorativa, l'attributo alt va lasciato vuoto (alt=""), in modo che lo screen reader la salti.

Errori frequenti:

• Testo alternativo generico tipo "immagine" o "foto prodotto"

• Attributo alt assente del tutto per immagini informative

• Banner con testo incorporato nell'immagine ma assenza del testo equivalente nell'alt

Contrasto cromatico insufficiente

Il problema: Testo grigio chiaro su sfondo bianco, sovrapposizioni tra testo e immagine di sfondo senza overlay. Sono problemi che riguardano non solo le persone con ipovisione, ma chiunque legga in condizioni di luce difficile o su uno schermo di bassa qualità.

Le WCAG richiedono un rapporto di contrasto minimo di 4,5:1 per il testo normale e 3:1 per il testo grande.

Moduli senza etichette

Il problema: Un campo di inserimento senza etichetta leggibile da un lettore di schermo è inutilizzabile per chi naviga senza mouse. L'utente arriva al campo ma non sa cosa deve inserire.

Le etichette devono essere associate programmaticamente al campo tramite for/id o aria-label. Il placeholder non è un'alternativa valida: scompare nel momento in cui l'utente inizia a digitare.

Questo errore è particolarmente frequente in:

• Form di contatto

• Checkout e pagamento

• Form di registrazione e login

• Campi di ricerca

Navigazione da tastiera inaccessibile

Il problema: Moltissimi siti permettono la navigazione tramite tasto Tab, ma lo fanno in modo parziale. Un menu a discesa si apre con Tab, ma non si chiude con Esc. I ruoli ARIA non sono implementati correttamente. Gli elementi interattivi non hanno un focus visibile.

Per una persona che non usa il mouse (chi ha disabilità motorie, chi usa tecnologie di switch access, chi preferisce navigare da tastiera per efficienza), un'interfaccia così è bloccante.

WCAG 2.1 richiede:

• Focus visibile su tutti gli elementi interattivi

• Ordine logico e navigabile di tutti i componenti

• Chiusura dei menu con Esc

• Compatibilità con le tecnologie assistive tramite ruoli ARIA corretti

Mancanza di struttura semantica

Il problema: Un sito visivamente ben organizzato può essere completamente piatto dal punto di vista semantico. Se i titoli sono simulati tramite CSS anziché marcati con <h1>, <h2>, <h3>, uno screen reader non può creare una struttura di navigazione. L'utente non può saltare da sezione a sezione, né capire la gerarchia dei contenuti.

Lo stesso vale per liste, tabelle, bottoni e link. Un <div> che sembra un pulsante non è un pulsante. Un <span> che sembra un titolo non è un titolo.

Contenuti multimediali senza alternative

Il problema: Video senza sottotitoli, audio senza trascrizione, presentazioni senza descrizioni. Chi ha una disabilità uditiva è escluso dal contenuto. Chi ha una disabilità cognitiva può beneficiare di trascrizioni e descrizioni accurate.

Le WCAG richiedono sottotitoli sincronizzati per i video preregistrati (livello A) e per i contenuti in diretta (livello AA). Le trascrizioni testuali per i soli contenuti audio sono anch'esse obbligatorie a livello A.

Link e bottoni senza testo descrittivo

Il problema: Link come "clicca qui" o "leggi di più", e bottoni-icona senza etichetta accessibile, non dicono nulla fuori dal contesto visivo. Molti screen reader permettono di navigare scorrendo la sola lista dei link: se sono tutti uguali, l'utente non ha modo di capire dove portano.

Le WCAG richiedono che lo scopo di ogni link sia comprensibile dal testo stesso o dal contesto programmatico. Per i bottoni-icona serve un'etichetta accessibile tramite aria-label o testo visivamente nascosto.

Errori frequenti:

• Serie di link "leggi di più" identici lungo tutta la pagina

• Bottoni con sola icona (cestino, lente, hamburger) senza etichetta

• Link che si appoggiano a "qui" o "questo" invece di descrivere la destinazione

Lingua della pagina non dichiarata

Il problema: Senza l'attributo lang sull'elemento <html>, lo screen reader non sa in quale lingua leggere e applica la pronuncia predefinita del sistema. Un testo italiano letto con regole fonetiche inglesi diventa incomprensibile.

Le WCAG richiedono che la lingua predefinita della pagina sia dichiarata programmaticamente (livello A) e che i cambi di lingua all'interno del contenuto siano segnalati con l'attributo lang sulla porzione interessata (livello AA).

Errori frequenti:

• Attributo lang assente sull'elemento <html>

• Lingua dichiarata errata (es. lang="en" su un sito italiano)

• Citazioni o termini in altra lingua senza lang sul frammento

Ridimensionamento del testo e zoom bloccati

Il problema: Testo definito in unità fisse che non si adatta all'ingrandimento, oppure user-scalable=no nel meta viewport che disattiva lo zoom su mobile. Chi ha bisogno di un corpo più grande per leggere si trova bloccato.

Le WCAG richiedono che il testo possa essere ingrandito fino al 200% senza perdita di contenuto o funzionalità (livello AA) e che il contenuto resti utilizzabile in reflow a 400% di zoom.

Errori frequenti:

• maximum-scale=1 o user-scalable=no nel viewport

• Layout che taglia o sovrappone il testo all'aumentare dello zoom

• Dimensioni in px fissi che ignorano le impostazioni dell'utente

Contenuti che dipendono solo dal colore

Il problema: Quando il colore è l'unico veicolo di un'informazione, chi non lo percepisce resta escluso. Un errore di form segnalato solo in rosso, o un link distinguibile dal testo circostante solo per la tinta, non arrivano a chi ha una disabilità visiva o un deficit nella percezione dei colori.

Le WCAG richiedono che il colore non sia l'unico mezzo per trasmettere informazioni, indicare un'azione o distinguere un elemento (livello A). Serve sempre un secondo segnale: un'icona, un testo, una sottolineatura.

Errori frequenti:

• Campi in errore evidenziati solo con bordo o testo rosso

• Link nel corpo del testo riconoscibili solo dal colore, senza sottolineatura

• Grafici e legende che distinguono le serie unicamente per tinta

Tabelle dati senza intestazioni marcate

Il problema: Una tabella che contiene dati reali ma usa solo celle generiche, senza intestazioni marcate, diventa una griglia piatta per chi usa uno screen reader. L'utente legge i valori ma perde il collegamento con la riga e la colonna a cui appartengono.

Le WCAG richiedono che le relazioni tra dati e intestazioni siano espresse programmaticamente: intestazioni marcate con <th> e, nelle tabelle complesse, l'attributo scope o gli abbinamenti headers/id.

Errori frequenti:

• Tabelle dati costruite con soli <td>, senza alcun <th>

• Tabelle usate per impaginare il layout anziché per dati reali

• Tabelle complesse a doppia entrata senza scope né headers

Timeout e contenuti in movimento

Il problema: Sessioni che scadono senza preavviso e caroselli o animazioni che partono in automatico mettono in difficoltà chi ha bisogno di più tempo o è sensibile al movimento. Chi ha una disabilità cognitiva o motoria può non riuscire a completare un'azione prima della scadenza, o a leggere un contenuto che si sposta da solo.

Le WCAG richiedono che l'utente possa estendere o disattivare i limiti di tempo (livello A) e mettere in pausa, fermare o nascondere i contenuti in movimento o che si aggiornano automaticamente (livello A).

Errori frequenti:

• Sessioni che scadono senza avviso né possibilità di proroga

• Caroselli in autoplay senza comando di pausa

• Animazioni e contenuti lampeggianti senza controllo da parte dell'utente

Messaggi di stato non annunciati

Il problema: Conferme, errori e aggiornamenti dinamici che compaiono senza ricaricare la pagina — "elemento aggiunto al carrello", "ricerca completata, 12 risultati" — sono visibili a schermo ma silenziosi per la tecnologia assistiva, se non vengono esposti correttamente. L'utente non si accorge che qualcosa è cambiato.

Le WCAG richiedono che i messaggi di stato siano comunicati alla tecnologia assistiva senza spostare il focus (livello AA), tipicamente tramite aria-live o i ruoli ARIA appropriati (status, alert).

Errori frequenti:

• Aggiunte al carrello o conferme senza alcun annuncio sonoro

• Errori di validazione mostrati a schermo ma non collegati a una regione live

• Conteggi di risultati di ricerca aggiornati in silenzio

Cosa dice la normativa: EAA, WCAG e Legge Stanca

In Italia l'accessibilità digitale è regolata da un quadro normativo a più livelli

Legge Stanca (Legge 9 gennaio 2004, n. 4): La legge italiana storica sull'accessibilità digitale, che ha imposto gli obblighi alle pubbliche amministrazioni e agli enti pubblici. Nel tempo è stata aggiornata per includere i privati che forniscono servizi tramite internet.

European Accessibility Act (EAA): La direttiva europea recepita in Italia con il D.Lgs. 82/2022 estende gli obblighi di accessibilità ai servizi privati, con scadenza di conformità al 28 giugno 2025. Riguarda e-commerce, servizi bancari, trasporti, media audiovisivi e piattaforme di distribuzione di ebook.

WCAG 2.1 AA: Lo standard tecnico di riferimento per entrambe le normative. Le Web Content Accessibility Guidelines stabiliscono i criteri di successo che un sito deve soddisfare per essere considerato accessibile. Il livello AA è quello richiesto dalla normativa.

Linee Guida AgID (marzo 2026): Le linee guida operative che definiscono le schede di controllo per siti web, documenti e app mobile. Non sono formalmente obbligatorie, ma rappresentano lo strumento che AgID utilizzerà nelle verifiche. Avere le schede compilate e firmate digitalmente è la forma più concreta di tutela per un'azienda.

Quali strumenti e tecniche usare per migliorare l'accessibilità del tuo sito?

Non esiste uno strumento unico che risolva tutto. L'approccio più efficace combina scansione automatica, verifica manuale e test con persone con disabilità.

Scansione automatica

Gli strumenti automatici rilevano tra il 30% e il 40% degli errori di accessibilità. Sono utili per una prima diagnosi rapida, per il monitoraggio continuativo e per individuare le criticità più comuni.

Strumenti utili:

• WAVE (WebAIM): analisi visiva dell'accessibilità direttamente in browser

• axe DevTools: estensione per browser, integrata nei DevTools di Chrome

• Lighthouse (Google): report di accessibilità integrato nel browser, con punteggio e suggerimenti

• Accessibility Scan di Accessiway: scansione gratuita che verifica la conformità del sito alle WCAG 2.1

Per sapere come capire se un sito web è accessibile in modo sistematico, la scansione automatica è il punto di partenza. Non il punto di arrivo.

Verifica manuale

La verifica manuale copre quello che gli strumenti automatici non vedono: il senso di un testo alternativo, la logicità dell'ordine di focus, la comprensibilità delle istruzioni di errore, il comportamento reale con uno screen reader.

Cosa verificare manualmente:

• Navigazione completa del sito usando solo la tastiera (Tab, Shift+Tab, Enter, Esc, frecce)

• Lettura con uno screen reader (NVDA su Windows, VoiceOver su Mac e iOS, TalkBack su Android)

• Verifica del contrasto con strumenti come Colour Contrast Analyser

• Revisione dei testi alternativi: sono descrittivi? Hanno senso nel contesto?

• Test dei form: ogni campo è etichettato? I messaggi di errore sono chiari?

Coinvolgimento diretto di persone con disabilità

Nessun test automatico o manuale condotto da chi non ha disabilità può sostituire l'esperienza reale. Il coinvolgimento di persone con disabilità nelle fasi di test e progettazione porta a identificare barriere che non compaiono in nessuna checklist.

Come fare un audit di accessibilità efficace

Un audit di accessibilità professionale segue un processo strutturato. Ecco le fasi principali.

1. Definire il perimetro: Quali pagine, flussi e funzionalità saranno incluse? Un audit completo copre almeno le pagine principali, i flussi di conversione, i form critici e i contenuti multimediali.

2. Scansione automatica iniziale: Rileva gli errori meccanici, crea un inventario di partenza e identifica le aree ad alta concentrazione di problemi.

3. Verifica manuale per pagina: Segue la scansione automatica, con test di navigazione da tastiera, lettura con screen reader e verifica dei criteri WCAG non rilevabili automaticamente.

4. Classificazione per impatto e priorità: Non tutti gli errori hanno lo stesso peso. Un form di checkout inaccessibile è più urgente di un problema su una pagina di archivio raramente visitata.

5. Report con raccomandazioni azionabili: Il risultato dell'audit non è una lista di problemi. È un piano di lavoro: ogni problema con la sua posizione, il criterio WCAG violato, la priorità e le indicazioni per la correzione.

6. Verifica post-correzione: Dopo che il team di sviluppo ha implementato le correzioni, una nuova verifica conferma che i problemi siano effettivamente risolti e che non siano state introdotte nuove regressioni.

Questo è il modello che adottiamo nella nostra piattaforma per l'accessibilità digitale: audit condotti da esperti, problemi collegati direttamente a Jira, monitoraggio continuativo che non si ferma tra un audit e l'altro.

Domande frequenti

Quali sono gli errori di accessibilità più comuni nei siti web?

I sei errori più frequenti, secondo i dati WebAIM Million, sono: immagini senza testo alternativo, contrasto cromatico insufficiente, link senza testo descrittivo, moduli senza etichette, assenza di lingua della pagina dichiarata nell'HTML, e bottoni senza nome accessibile. Compaiono in oltre il 90% delle homepage analizzate.

Come si verifica l'accessibilità di un sito web gratuitamente?

Puoi usare strumenti come WAVE, Lighthouse o scanner di Accessiway per una prima analisi automatica gratuita. Questi strumenti forniscono un punteggio e una lista di problemi. Per una valutazione completa occorre affiancare la verifica manuale e, dove possibile, il test con tecnologie assistive reali.

Quali aziende sono obbligate a rispettare l'EAA in Italia?

Dal 28 giugno 2025, l'obbligo si applica alle aziende private che operano nei settori di e-commerce, servizi bancari e finanziari, trasporti, comunicazione elettronica, media audiovisivi e piattaforme di distribuzione di ebook. Le PMI con meno di dieci dipendenti e un fatturato annuo inferiore a 2 milioni di euro sono esenti, salvo abbiano ricevuto finanziamenti pubblici per l'accessibilità.

Quanto tempo ci vuole per rendere accessibile un sito web?

Dipende dallo stato di partenza e dalla complessità del sito. Un sito con decine di errori strutturali richiede un percorso pianificato di mesi, con priorità definite. Un sito con pochi problemi tecnici può raggiungere la conformità in settimane. In entrambi i casi, l'accessibilità non è un traguardo una-tantum: richiede monitoraggio continuativo, perché ogni aggiornamento può introdurre nuove barriere.

Qual è l'errore più frequente riscontrato nei siti web durante il monitoraggio semplificato?

Il contrasto cromatico insufficiente tra testo e sfondo. È l'errore che gli scanner automatici rilevano più spesso, perché a differenza di altri problemi, come un testo alternativo di scarsa qualità, si misura in modo oggettivo, senza bisogno di giudizio umano.

In un'ottica di accessibilità, quale accorgimento è bene utilizzare quando si inserisce una tabella in un documento on-line?

Marcare le intestazioni con il tag <th> invece di semplici <td>, aggiungendo l'attributo scope nelle tabelle più complesse. Solo così uno screen reader collega ogni valore alla riga e alla colonna a cui appartiene, invece di leggerlo come un dato isolato.

Rendere un sito accessibile non significa rifare tutto da zero. Nella maggior parte dei casi significa correggere errori ad alto impatto, costruire processi che mantengano l'accessibilità nel tempo e fare test con chi usa davvero le tecnologie assistive.

Se vuoi capire da dove iniziare, il primo passo è sapere dove sei. Il nostro team lavora con sviluppatori web, designer, aziende e responsabili dei contenuti digitali per trasformare i risultati di un audit in azioni concrete e misurabili