Errori di accessibilità comuni da evitare

Perché continuano a comparire gli stessi problemi di accessibilità

La maggior parte delle barriere non è esotica. Anno dopo anno, gli audit automatici e manuali fanno emergere la stessa breve lista di errori: testo alternativo mancante, contrasto basso, campi di modulo senza etichetta, trappole da tastiera e struttura difettosa. Si ripresentano perché vengono introdotti in modo silenzioso — uno sviluppatore pubblica un nuovo componente, un addetto al marketing carica un’immagine, un designer sceglie un colore del marchio — e nulla nel normale flusso di lavoro segnala il problema. Il risultato visivo sembra a posto per chi usa un mouse e una vista acuta, quindi la barriera va in produzione.

Questo catalogo passa in rassegna le violazioni di WCAG 2.2 più frequenti che riscontriamo negli audit reali. Per ciascuna troverai perché è importante, chi colpisce, il criterio di successo pertinente e una correzione concreta del prima e del dopo. Insieme, questi problemi rappresentano la stragrande maggioranza delle barriere che escludono le persone con disabilità — e la stragrande maggioranza dei reclami legali presentati ai sensi dello European Accessibility Act, dell’ADA e della Section 508.

Una cosa da chiarire prima della lista: gli strumenti automatici non possono trovare tutti questi problemi. La ricerca indipendente dimostra costantemente che anche i migliori scanner rilevano in modo affidabile solo il 30–40 % dei problemi WCAG. Sono eccellenti nell’individuare attributi alt mancanti, errori di contrasto programmatici ed etichette di modulo assenti, ma non possono giudicare se un testo alternativo è accurato, se l’ordine di focus è logico o se un widget personalizzato funziona davvero con uno screen reader. Ecco perché ogni programma credibile abbina la scansione alla revisione manuale. Il nostro software di scansione dell’accessibilità gestisce il livello automatizzabile; gli audit manuali e gli audit eseguiti da persone con disabilità coprono il resto.

Un modo rapido per trovare il tuo punto di partenza prima di proseguire: visualizza la pagina con le immagini disattivate, leggi ogni parola come un unico paragrafo non strutturato e prova a completare ogni attività usando solo la tastiera. Ovunque l’esperienza crolli, hai trovato una barriera.

Percepibile: contenuti che le persone non possono vedere o leggere

Testo alternativo mancante o impreciso per le immagini

Chi colpisce: persone cieche o ipovedenti che usano screen reader; chiunque abbia una connessione lenta in cui le immagini non si caricano.

Criterio WCAG: 1.1.1 Contenuto non testuale (Livello A).

Le immagini senza un attributo alt sono invisibili alla tecnologia assistiva — l’utente potrebbe non sapere nemmeno che l’immagine esiste. Peggio di un attributo mancante è uno impreciso: nomi di file come IMG_4821.jpg, parole generiche come «immagine» o stringhe piene di parole chiave fuorviano attivamente chi ascolta.

La regola è semplice ma legata al contesto. Le immagini informative necessitano di una descrizione concisa del loro significato, non del loro aspetto. Le immagini decorative che non aggiungono nulla dovrebbero avere un alt="" vuoto, così gli screen reader le saltano. Le immagini funzionali — un’icona che funge da pulsante — devono descrivere l’azione, non l’immagine. Gli elementi visivi complessi come i grafici necessitano di un alt breve più un equivalente testuale più lungo nelle vicinanze.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Gli strumenti automatici rilevano all’istante l’assenza di testo alternativo. Non possono dirti se il testo è corretto: questo richiede una persona che legga la pagina nel suo contesto.

Contrasto del colore insufficiente

Chi colpisce: persone ipovedenti, daltoniche o con perdita della vista legata all’età; chiunque usi uno schermo sotto la luce intensa del sole.

Criterio WCAG: 1.4.3 Contrasto (minimo), Livello AA; oltre a 1.4.11 Contrasto non testuale per i componenti dell’interfaccia.

WCAG 2.2 richiede un rapporto di contrasto di almeno 4,5:1 per il testo normale e 3:1 per il testo grande (circa 18 pt, o 14 pt in grassetto). I componenti dell’interfaccia e la grafica significativa — bordi dei campi di input, indicatori di focus, icone che trasmettono uno stato — devono raggiungere 3:1 rispetto al loro contesto. Gli errori di contrasto sono tra i problemi più comuni riscontrati in ogni audit su larga scala e vengono quasi sempre introdotti in fase di progettazione.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testa l’intera tavolozza, non solo il corpo del testo: il testo segnaposto, gli stati disabilitati che devono comunque essere leggibili, i messaggi di errore e il testo sovrapposto alle fotografie sono trasgressori frequenti. Non affidarti mai al colore da solo per trasmettere un significato (1.4.1): un bordo rosso su un campo non valido deve essere abbinato a un testo o a un’icona.

Contenuti multimediali e movimento ad avvio automatico

Chi colpisce: persone con disturbi vestibolari, disabilità dell’attenzione o cognitive, utenti di screen reader la cui uscita audio viene coperta e chiunque si trovi in uno spazio condiviso silenzioso.

Criteri WCAG: 1.4.2 Controllo audio (Livello A), 2.2.2 Metti in pausa, ferma, nascondi (Livello A), 2.3.1 Tre lampeggiamenti (Livello A) e 2.3.3 Animazione dalle interazioni (Livello AAA).

L’audio o il video che si riproduce automaticamente per più di tre secondi deve offrire un modo evidente per metterlo in pausa o disattivarne l’audio. I contenuti in movimento, lampeggianti o che si aggiornano automaticamente per più di cinque secondi — caroselli, banner animati, scritte scorrevoli — necessitano di un controllo di pausa accessibile. I contenuti che lampeggiano più di tre volte al secondo possono provocare convulsioni e devono essere evitati del tutto. Rispetta l’impostazione prefers-reduced-motion dell’utente per attenuare le animazioni non essenziali.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Utilizzabile: cose che le persone non possono usare

Inaccessibilità da tastiera e trappole da tastiera

Chi colpisce: persone con disabilità motorie che non possono usare un mouse, utenti di screen reader (che navigano da tastiera) e persone che usano dispositivi a scansione o il controllo vocale.

Criteri WCAG: 2.1.1 Tastiera (Livello A) e 2.1.2 Nessuna trappola da tastiera (Livello A).

Ogni interazione — link, pulsanti, campi di modulo, menu, finestre modali, selettori di data, trascinamento della selezione — deve essere completamente utilizzabile con la sola tastiera. La variante più dannosa è la trappola da tastiera: il focus entra in un componente (spesso una finestra modale o un widget incorporato) e non riesce a uscirne, lasciando l’utente bloccato sulla pagina. I widget personalizzati sono i soliti colpevoli, perché gli elementi nativi come <button> e <a> sono utilizzabili da tastiera per impostazione predefinita, mentre le imitazioni basate su <div> non lo sono.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Percorri i tuoi flussi chiave usando solo Tab, Maiusc+Tab, i tasti freccia, Invio, Spazio ed Esc. Verifica che il focus possa sempre spostarsi in avanti e uscire da ogni componente, che Esc chiuda gli overlay e che nulla richieda un puntatore. Il nostro servizio di valutazione con screen reader testa esattamente questi flussi nel modo in cui li vivono gli utenti reali di tecnologia assistiva.

Indicatori di focus mancanti o invisibili e ordine di focus illogico

Chi colpisce: utenti di tastiera vedenti, utenti ipovedenti e chiunque abbia perso di vista dove si trova nella pagina.

Criteri WCAG: 2.4.7 Focus visibile (Livello A) e 2.4.3 Ordine del focus (Livello A); 2.4.11 Focus non oscurato (Livello AA) in WCAG 2.2.

Un comune errore «di pulizia» è rimuovere l’anello di focus predefinito del browser con outline: none senza mai sostituirlo. Gli utenti di tastiera non hanno idea di quale elemento sia attivo. Altrettanto dannoso è un ordine di focus che non segue l’ordine di lettura visivo e logico — di solito causato da valori tabindex positivi o da un ordine del DOM che diverge dal layout renderizzato.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 aggiunge il 2.4.11: quando un elemento riceve il focus, non deve essere completamente nascosto dietro intestazioni fisse, banner dei cookie o widget di chat. Apri una finestra modale, scorrila con il tasto Tab e verifica che l’elemento con il focus non venga mai sepolto.

Link e pulsanti non descrittivi

Chi colpisce: utenti di screen reader che richiamano un elenco di tutti i link per scorrere una pagina e persone con disabilità cognitive.

Criteri WCAG: 2.4.4 Scopo del collegamento (nel contesto), Livello A; 2.5.3 Etichetta nel nome, Livello A.

Gli utenti di screen reader spesso navigano saltando tra i link fuori contesto. Una pagina piena di link «clicca qui», «leggi di più» e «scopri di più» diventa priva di significato quando viene letta come un elenco. Il testo del link dovrebbe descrivere la sua destinazione da solo. Lo stesso vale per i pulsanti con sola icona, che hanno bisogno di un nome accessibile.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Navigazione sovraccarica e nessun modo per saltarla

Chi colpisce: utenti di screen reader, utenti di tastiera e persone con disabilità cognitive.

Criterio WCAG: 2.4.1 Salto di blocchi (Livello A).

Un mega-menu con decine di link costringe gli utenti di screen reader e tastiera a scorrere l’intero elenco su ogni pagina prima di raggiungere il contenuto. Un link «Salta al contenuto principale» come primo elemento attivabile consente loro di saltare direttamente oltre i blocchi ripetuti. Raggruppa gli elementi correlati, mantieni i menu snelli e assicurati che il link di salto diventi visibile al focus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Comprensibile: contenuti che confondono

Campi di modulo senza etichetta o associati in modo errato

Chi colpisce: utenti di screen reader, persone con disabilità cognitive e utenti del controllo vocale che si rivolgono ai campi per nome.

Criteri WCAG: 1.3.1 Informazioni e correlazioni, 3.3.2 Etichette o istruzioni e 4.1.2 Nome, ruolo, valore (tutti Livello A).

Gli input senza un <label> associato a livello programmatico vengono annunciati come «modifica testo, vuoto» — l’utente non ha idea di cosa digitare. Il testo segnaposto non è un sostituto: scompare durante l’inserimento e di solito non rispetta il contrasto. Anche i campi obbligatori, le regole di formattazione e gli errori di convalida devono essere comunicati con il testo, non solo tramite colore o posizione.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Collega i messaggi di errore al loro campo con aria-describedby, contrassegna i campi non validi con aria-invalid e assicurati che l’invio di un modulo incompleto sposti il focus sul primo errore.

Lingua della pagina mancante

Chi colpisce: utenti di screen reader — la lingua sbagliata fa sì che il sintetizzatore pronunci tutto in modo errato.

Criteri WCAG: 3.1.1 Lingua della pagina (Livello A) e 3.1.2 Lingua delle parti (Livello AA).

Un singolo attributo mancante rovina la pronuncia di un’intera pagina. Dichiara la lingua principale sull’elemento radice e contrassegna i passaggi in linea in un’altra lingua con il loro lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Gerarchia dei titoli errata e punti di riferimento mancanti

Chi colpisce: utenti di screen reader che navigano per titoli e regioni e chiunque si affidi alla struttura del documento.

Criterio WCAG: 1.3.1 Informazioni e correlazioni (Livello A).

I titoli sono lo schema della pagina. Gli utenti di screen reader saltano di titolo in titolo per trovare rapidamente i contenuti; quando i livelli vengono saltati, usati solo per la dimensione del carattere o sono assenti, questa navigazione crolla. Ogni pagina dovrebbe avere un solo <h1> e una sequenza logica e ininterrotta di <h2>, <h3> e così via. Altrettanto importanti sono le regioni di riferimento — <header>, <nav>, <main>, <footer> — che consentono agli utenti di saltare tra le aree principali. Una pagina costruita interamente con elementi <div> non offre alcuna mappa di questo tipo.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robusto: codice che la tecnologia assistiva non può interpretare

Chi colpisce: soprattutto utenti di screen reader e qualsiasi tecnologia assistiva che si affidi a un albero di accessibilità corretto.

Criterio WCAG: 4.1.2 Nome, ruolo, valore (Livello A).

I menu a discesa, le schede, gli accordion, le combobox, le finestre modali e i tooltip personalizzati costruiti con <div> e <span> non hanno ruolo, stato o comportamento da tastiera intrinseci. Gli sviluppatori ricorrono ad ARIA per rattoppare la cosa, ma ARIA si limita a descrivere — non aggiunge alcun comportamento e un ARIA errato è peggio di nessuno. La prima regola di ARIA è preferire un elemento HTML nativo ogni volta che ne esiste uno. Quando devi costruire un widget personalizzato, implementa l’interazione da tastiera completa specificata dai pattern di authoring di ARIA e mantieni aria-expanded, aria-selected e stati simili sincronizzati con la realtà.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Questi sono proprio i problemi che gli scanner automatici non rilevano più spesso. Uno scanner vede un attributo aria-expanded e lo considera valido; solo una persona (o chi esegue test con uno screen reader) può confermare che il valore cambi davvero quando il menu si apre. Consulta la nostra guida ai test con screen reader per scoprire come verificare il comportamento dei widget dall’inizio alla fine.

È allettante installare un «widget di accessibilità» o overlay di una sola riga che promette conformità istantanea. Questi strumenti non correggono i problemi sopra descritti — il testo alternativo è ancora mancante nel codice sorgente, il contrasto continua a fallire, il widget personalizzato continua a non funzionare. Gli overlay non possono rimediare al codice che causa le barriere, interferiscono frequentemente con la tecnologia assistiva degli utenti e sono comparsi in un numero crescente di cause legali sull’accessibilità. La vera accessibilità digitale deriva dalla correzione dell’HTML, del CSS e del comportamento sottostanti, non dal mascherarli.

Impedisci a questi problemi di ripresentarsi

Correggere un elenco di bug una volta è necessario ma non sufficiente; gli stessi problemi riappaiono con la versione successiva a meno che tu non cambi il modo in cui rilasci. La soluzione duratura è integrare l’accessibilità nel flusso di lavoro:

Intercetta presto il 30–40 % automatizzabile integrando le scansioni nella tua pipeline. L’integrazione dell’accessibilità in CI/CD fa fallire la build quando viene introdotta una regressione, prima che raggiunga la produzione.
Copri il resto con le persone. Pianifica audit manuali di accessibilità e audit eseguiti da persone con disabilità, che fanno emergere barriere che nessuno strumento può rilevare.
Fornisci ai team gli strumenti giusti. Il toolkit di accessibilità di QualiBooth e Agora aiutano designer e sviluppatori a testare mentre lavorano.
Rendilo un processo, non un progetto. La consulenza sull’accessibilità e il miglioramento del processo di accessibilità continui radicano le abitudini in modo che la qualità si mantenga nel tempo.

Per una roadmap di correzione passo passo, inizia con la nostra guida su come rendere il tuo sito web conforme a WCAG.

Da dove iniziare oggi

Con oltre 1,3 miliardi di persone nel mondo che vivono con una qualche forma di disabilità, le ragioni di business a favore dell’accessibilità sono chiare — e da giugno 2025 lo sono anche quelle legali ai sensi dello European Accessibility Act. I problemi di questo catalogo sono i primi a essere esaminati in qualsiasi reclamo o audit.

Il modo più rapido per capire a che punto sei è eseguire una scansione URL gratuita — senza configurazione, senza impegno. Quando sei pronto ad andare oltre ciò che l’automazione può raggiungere, richiedi una demo e ti mostreremo come un programma combinato automatico più manuale colma il divario rimanente.