Come correggere i 6 errori WCAG più comuni su qualsiasi sito web

Apri uno qualsiasi dei primi un milione di siti web in questo momento e c’è una probabilità di 96 su 100 di trovare una violazione WCAG che uno scanner automatico può individuare in pochi secondi. Su un milione di home page, sono stati rilevati 56.114.377 errori di accessibilità distinti — una media di 56,1 errori per pagina. Ciò che rende questo dato particolarmente sorprendente è che il 96% di tutti gli errori rilevati rientra in sole sei categorie, e questi sei tipi di errore più comuni sono rimasti gli stessi negli ultimi sette anni. Questo significa che correggere una manciata di problemi ben compresi migliorerebbe in modo drastico l’accessibilità dell’intero web — e tutto inizia dal tuo sito.

Perché gli stessi sei errori continuano a ripresentarsi

Potresti chiederti come sia possibile che, in un’epoca di strumenti di sviluppo sofisticati e di crescente attenzione legale, gli stessi errori persistano su larga scala anno dopo anno. La risposta è sistemica. Questa densità di errori riflette quanto profondamente l’inaccessibilità sia stata incorporata nelle pratiche di sviluppo web. I problemi nei template si moltiplicano su ogni pagina. I malfunzionamenti dei componenti si ripetono in tutto il sito. Senza un’attenzione deliberata all’accessibilità, i flussi di lavoro di sviluppo standard producono risultati sistematicamente inaccessibili.

Esiste anche un falso senso di progresso alimentato dall’automazione. I test automatici intercettano solo il 30–40% dei potenziali errori WCAG. I siti che superano i test automatici possono comunque presentare problemi significativi di navigazione da tastiera, di utilizzo con screen reader o di accessibilità cognitiva. Questo significa che persino la piccola percentuale di siti che sembrano conformi sulla carta probabilmente non lo è nella pratica.

Le implicazioni legali sono concrete e in crescita. Secondo Seyfarth Shaw, nel 2024 sono state intentate 8.800 cause federali ai sensi del Titolo III dell’ADA, con circa 2.452 che prendevano di mira specificamente l’accessibilità web. I siti di e-commerce affrontano un rischio sproporzionato — il 77% delle cause relative all’accessibilità web riguarda il retail online. La conformità non è più un “nice-to-have”. È una questione di continuità operativa.

Il lato positivo? Questa concentrazione ha implicazioni pratiche. Le organizzazioni possono affrontare la maggior parte dei loro problemi di accessibilità concentrandosi su una manciata di tipologie di problemi. Una conformità WCAG completa richiede attenzione a tutti i 78 criteri, ma i miglioramenti a maggior impatto derivano dalla correzione di questi errori comuni. Quindi analizziamoli uno per uno, con soluzioni pratiche che puoi implementare oggi.

Errore n. 1 — Testo a basso contrasto (WCAG 1.4.3)

Il testo a basso contrasto — testo che non presenta una sufficiente differenziazione di colore rispetto allo sfondo — compare nell’83,6% delle home page analizzate. È l’errore WCAG più comune, che colpisce più di quattro siti su cinque. WCAG 1.4.3 (Contrasto minimo) è brutalmente diretto: il testo normale deve raggiungere un rapporto di contrasto di almeno 4,5:1 rispetto allo sfondo, e il testo grande (18pt o 14pt grassetto) deve raggiungere almeno 3:1.

I problemi di contrasto derivano spesso da decisioni di design che privilegiano l’estetica rispetto alla leggibilità. Il testo grigio chiaro su sfondo bianco appare sofisticato ai designer con una vista perfetta. Per le persone con ipovisione, le persone anziane o chiunque legga su uno schermo con riflessi, è illeggibile. Etichette secondarie, placeholder dei form, testo nel footer e stati disabilitati dei pulsanti sono i colpevoli abituali — vengono stilizzati per apparire discreti e finiscono per essere invisibili a una parte significativa del tuo pubblico.

La correzione è quasi sempre un aggiustamento CSS. Passa le tue coppie di colori attraverso un contrast checker come lo strumento di WebAIM o il pannello di accessibilità dei DevTools del browser, quindi modifica leggermente il valore del primo piano o dello sfondo finché non supera il test. Ecco uno schema comune che fallisce e come correggerlo:

/* Non conforme — rapporto circa 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Conforme — rapporto circa 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Per il testo dei placeholder, ricorda che WCAG lo considera testo reale — non un suggerimento decorativo — quindi deve anch’esso rispettare la soglia di 4,5:1. Evita di fare affidamento esclusivamente sul placeholder per fornire istruzioni; abbinalo comunque a un elemento <label> visibile. Se utilizzi immagini di testo, non puoi correggere il contrasto con il CSS — devi rigenerare quelle immagini, il che è un ulteriore motivo per preferire testo HTML vivo rispetto al testo incorporato nella grafica.

Errore n. 2 — Testo alternativo mancante per le immagini (WCAG 1.1.1)

Immagini senza testo alternativo compaiono nel 58,2% delle home page. Quando le immagini non hanno alt text, le persone che usano screen reader incontrano silenzio o nomi di file privi di significato dove invece dovrebbe esserci contenuto significativo. Questo problema non è nuovo. Il testo alternativo è un requisito fondamentale di accessibilità fin da WCAG 1.0 nel 1999. Venticinque anni dopo, la maggior parte dei siti web continua a non implementarlo in modo coerente.

Il motivo per cui persiste è un problema di flusso di lavoro, non di conoscenza. Questo tasso di errore indica lacune sistematiche nei flussi di lavoro dei contenuti. Autori e redattori spesso non sanno che è necessario l’alt text. I sistemi di gestione dei contenuti non sempre lo richiedono. Il controllo qualità non ne rileva l’assenza. La soluzione ha quindi due livelli: uno tecnico e uno di processo.

Dal punto di vista tecnico, ogni immagine significativa necessita di un attributo alt che trasmetta la stessa informazione veicolata dall’immagine. Le immagini decorative — abbellimenti puramente visivi che non aggiungono informazioni — dovrebbero avere un alt="" vuoto, così che gli screen reader le saltino del tutto. Distinguere correttamente tra questi casi è importante quanto aggiungere l’attributo in sé. Una grande percentuale di immagini ha testo alternativo mancante o inaccurato. Alcune immagini significative non hanno alcuna descrizione, mentre le immagini decorative vengono spesso trattate come contenuto significativo. Entrambi i problemi compromettono la conformità WCAG per i contenuti percepibili.

<!-- Immagine significativa: descrivi ciò che comunica -->
<img src='team-photo.jpg' alt='Il team di ingegneria di Accsible al loro offsite 2024 a Lisbona' />

<!-- Immagine decorativa: alt vuoto, nessun ruolo necessario -->
<img src='wave-divider.svg' alt='' />

<!-- Immagine con link: descrivi la destinazione, non l’immagine -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='Visualizza i piani tariffari' />
</a>

Dal punto di vista del processo, aggiorna i template del tuo CMS per rendere obbligatorio il campo alt per le immagini di contenuto e forma chiunque carichi asset. Strumenti automatici come Accsible possono rilevare a livello di sito le immagini con alt text mancante o vuoto, fornendo al tuo team un elenco verificabile da gestire in modo sistematico.

Errore n. 3 — Etichette mancanti per i campi dei form (WCAG 1.3.1, 3.3.2)

Il 48,6% dei siti web presenta campi di input nei form senza etichette. Questo errore è particolarmente dannoso perché i form sono il luogo in cui le persone compiono azioni — si registrano, acquistano, contattano, inviano richieste di supporto. Molti form non hanno etichette accessibili, si affidano solo ai placeholder, non espongono istruzioni e messaggi di errore o non supportano l’uso esclusivo della tastiera. Poiché i form sono essenziali per la maggior parte delle esperienze digitali, questi errori creano barriere di usabilità gravi.

L’errore più comune è usare il testo del placeholder come sostituto di un <label>. I placeholder scompaiono non appena l’utente inizia a digitare, lasciando chi ha difficoltà di memoria a breve termine — o semplicemente chi si distrae a metà compilazione — senza più alcuna indicazione sulla funzione del campo. Gli screen reader gestiscono i placeholder in modo diverso tra loro, e nessuno di questi approcci è affidabile quanto un’associazione corretta con un’etichetta.

Lo schema corretto è usare un elemento <label> collegato al suo input tramite attributi for e id corrispondenti. Se un’etichetta visibile non è possibile per motivi di design, utilizza aria-label o aria-labelledby — ma non ricorrere ad ARIA quando potresti semplicemente usare un <label>.

<!-- Corretto: associazione esplicita dell’etichetta -->
<label for='email'>Indirizzo email</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Errato: solo placeholder -->
<input type='email' placeholder='Indirizzo email' />

<!-- Accettabile quando l’etichetta deve essere nascosta visivamente -->
<label for='search' class='visually-hidden'>Cerca nel sito</label>
<input type='search' id='search' name='q' />

I messaggi di errore devono anche essere associati in modo programmatico. Quando un form viene validato e rileva un errore, il messaggio dovrebbe essere collegato al campo tramite aria-describedby e, idealmente, il focus dovrebbe essere spostato sul primo campo non valido. Gli errori di validazione dei form devono essere efficienti, intuitivi e accessibili — l’errore deve essere chiaramente identificato, deve essere fornito un accesso rapido all’elemento problematico e l’utente deve poter correggere facilmente l’errore e inviare nuovamente il form.

Errore n. 4 — Link e pulsanti vuoti (WCAG 2.4.4, 4.1.2)

Il 44,6% dei siti web presenta hyperlink vuoti. Pulsanti vuoti sono stati trovati su quasi il 30% delle pagine, e questo numero è aumentato rispetto all’anno precedente. Ciò significa che le persone cieche o ipovedenti non comprenderanno lo scopo di pulsanti come invia, reimposta, filtra o cerca. Insieme, link e pulsanti vuoti rappresentano una delle esperienze più frustranti per chi usa screen reader — imbattersi in elementi interattivi senza nome è come premere una maniglia senza etichetta e senza sapere dove porta.

I link vuoti si verificano più spesso quando un’icona o un’immagine è l’unico elemento figlio di un tag <a> e non viene fornita alcuna alternativa testuale. I pulsanti vuoti si verificano quando i pulsanti composti solo da icone — menu hamburger, icone di chiusura, pulsanti di condivisione social — non hanno alcun nome accessibile. Entrambi i problemi sono semplici da correggere.

<!-- Link vuoto — non conforme -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Corretto con aria-label -->
<a href='/dashboard' aria-label='Vai alla dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Pulsante vuoto — non conforme -->
<button><svg>...</svg></button>

<!-- Corretto con testo nascosto visivamente -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Chiudi menu</span>
</button>

Nota l’attributo aria-hidden='true' sull’SVG in ciascun esempio corretto. Quando fornisci un’alternativa testuale tramite aria-label o testo nascosto visivamente, vuoi escludere l’SVG dall’albero di accessibilità — altrimenti gli screen reader potrebbero annunciare sia l’etichetta sia il titolo o la descrizione dell’SVG, creando una confusione con doppia lettura. Il testo del link ambiguo — frasi come “clicca qui”, “leggi di più” o “scopri di più” — è un errore correlato. Altri problemi relativi agli hyperlink, come il testo del link ambiguo, sono stati riscontrati su quasi il 14% delle home page, in aumento rispetto all’anno precedente. Hyperlink con testo adeguato sono importanti affinché le persone sappiano dove le porterà un link. Il nome accessibile di ogni link dovrebbe avere senso anche fuori contesto, perché chi usa screen reader spesso naviga richiamando un elenco di tutti i link presenti in una pagina.

Errore n. 5 — Lingua del documento mancante (WCAG 3.1.1)

Questo errore può sembrare minore rispetto al contrasto o al testo alternativo, ma circa il 16% delle pagine non ha una lingua del documento impostata — e l’impatto per chi usa screen reader è immediato e destabilizzante. Se l’utente di uno screen reader ha installato il pacchetto linguistico specifico, il contenuto verrà letto correttamente. Altrimenti suonerà come un accento pessimo e potrebbe risultare incomprensibile.

La correzione è un singolo attributo HTML — letteralmente una riga di codice — e non c’è alcuna scusa per dimenticarlo. Aggiungi l’attributo lang all’elemento <html> con il tag di lingua BCP 47 appropriato. Se sezioni della pagina sono in una lingua diversa rispetto al resto, aggiungi un attributo lang anche a quegli elementi specifici.

<!-- Mancante: nessun attributo lang -->
<html>

<!-- Corretto: pagina in inglese -->
<html lang='en'>

<!-- Corretto: pagina in francese -->
<html lang='fr'>

<!-- Cambio di lingua inline all’interno di una pagina -->
<p>L’espressione francese <span lang='fr'>joie de vivre</span> significa un gioioso gusto per la vita.</p>

Se utilizzi un CMS o uno static site generator, l’attributo lang dovrebbe essere impostato nel template di base. Controlla il template una volta, correggilo una volta, e ogni pagina del tuo sito sarà immediatamente sistemata. Questo è probabilmente l’intervento con il miglior rapporto tra risultato e sforzo in tutta questa lista — una singola modifica al template elimina il problema su tutto il tuo dominio.

Errore n. 6 — Navigazione da tastiera e gestione del focus inaccessibili (WCAG 2.1.1, 2.4.7)

L’accessibilità da tastiera è l’area in cui il divario tra test automatici e usabilità reale è più ampio. Gli strumenti automatici possono rilevare alcuni errori relativi alla tastiera — come elementi interattivi costruiti con tag non semantici — ma non possono simulare l’ordine di tabulazione, i blocchi di focus o l’esperienza di navigare in un menu a discesa usando solo i tasti freccia. I siti rimuovono frequentemente gli indicatori di focus predefiniti senza fornire alternative, rendendo la navigazione da tastiera quasi impossibile. Questo non riguarda solo le persone con disabilità motorie, ma chiunque preferisca la navigazione da tastiera, gli utenti esperti e le persone che utilizzano dispositivi a interruttore.

Gli errori più comuni relativi alla tastiera sono: componenti interattivi personalizzati costruiti con tag <div> o <span> che non ricevono mai il focus; regole CSS che eliminano l’anello di focus predefinito del browser con outline: none o outline: 0 senza sostituirlo con qualcosa di altrettanto visibile; finestre modali che non intrappolano il focus (così chi usa la tastiera può tabulare dietro l’overlay); e caroselli o accordion che non possono essere utilizzati senza mouse.

<!-- Pulsante personalizzato non accessibile da tastiera — non conforme -->
<div class='btn' onclick='doSomething()'>Invia</div>

<!-- Corretto: usa un vero pulsante -->
<button type='button' onclick='doSomething()'>Invia</button>

<!-- Rimozione degli stili di focus — non conforme a WCAG 2.4.7 -->
* {
  outline: none; /* non farlo mai globalmente */
}

<!-- Meglio: stili di focus ben visibili che preservano l’estetica -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

La pseudo-classe :focus-visible è la tua migliore alleata. Mostra gli stili di focus quando l’utente naviga con la tastiera, ma li sopprime per i clic del mouse — offrendoti un’estetica pulita senza sacrificare l’accessibilità. Per modali e pannelli a scomparsa, utilizza una utility di focus trapping che limiti la navigazione tramite tab all’interno della finestra di dialogo mentre è aperta e riporti il focus all’elemento che l’ha attivata quando si chiude. I pop-up spesso compaiono senza una corretta gestione del focus, senza etichette o senza supporto per la navigazione da tastiera. Questo causa interruzioni significative, soprattutto nei flussi critici come registrazioni, login e processi di checkout.

Oltre ai singoli componenti, considera l’aggiunta di un link per saltare la navigazione — un link nascosto visivamente che diventa visibile al focus e consente a chi usa la tastiera di saltare la navigazione ripetitiva e passare direttamente al contenuto principale. I link per saltare la navigazione che permettono di bypassare la navigazione ripetitiva mancano sulla maggior parte dei siti. Si tratta di tre righe di HTML e un piccolo snippet CSS, e fa una differenza enorme per chiunque navighi una pagina ricca di contenuti tramite tastiera.

<!-- Inserisci questo come primissimo elemento dentro <body> -->
<a href='#main-content' class='skip-link'>Salta al contenuto principale</a>

<!-- Poi nel tuo CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Una nota su ARIA: usala con cautela

Molti team ricorrono agli attributi ARIA (Accessible Rich Internet Applications) come soluzione rapida per colmare lacune di accessibilità. I dati suggeriscono che questo approccio spesso si ritorce contro. Circa il 79% delle home page valutate utilizzava ARIA, in aumento rispetto all’anno precedente. Le home page con ARIA presentavano più del doppio degli errori rispetto alle pagine senza ARIA. Il problema non è ARIA in sé — di solito è il suo uso improprio o scorretto. Molti sviluppatori ben intenzionati pensano di rendere i contenuti più accessibili aggiungendo ARIA, quando in realtà spesso li rendono meno accessibili.

Il principio guida è semplice: usa prima l’HTML semantico. Un <button> è meglio di un <div role='button'>. Un <nav> è meglio di un <div role='navigation'>. Gli elementi HTML nativi includono comportamento da tastiera integrato, gestione del focus e ruoli ARIA impliciti che, con markup personalizzato, devi replicare manualmente — ed è proprio in quella replica manuale che si insinuano gli errori. Riserva ARIA ai casi in cui l’HTML non può davvero esprimere la semantica di cui hai bisogno, come regioni live, widget compositi complessi o cambiamenti di stato dinamici.

Integrare l’accessibilità nel tuo flusso di lavoro

Correggere le violazioni esistenti è necessario, ma prevenire la comparsa di nuove è ciò che distingue i programmi di accessibilità maturi dalle corse una tantum alla conformità. L’accessibilità non è una correzione una tantum. Ogni aggiornamento di contenuto, modifica di design o rilascio di codice può introdurre nuovi problemi. Le sei categorie di errori trattate in questa guida tendono a essere problemi a livello di template — correggi header, footer e componenti condivisi e elimini il problema simultaneamente su centinaia di pagine.

Integra la scansione automatica nella tua pipeline CI/CD in modo che le violazioni vengano intercettate prima di arrivare in produzione. Strumenti come axe-core possono essere integrati nei test unitari e nelle suite di test end-to-end. Abbina questo a periodiche verifiche manuali con la tastiera e test con screen reader — VoiceOver su macOS e iOS, NVDA su Windows — perché i test automatici possono rilevare errori di accessibilità comuni, ma i test manuali aiutano a colmare le lacune. Per i team che hanno bisogno di una rampa di accesso più rapida, un widget di overlay per l’accessibilità come Accsible può evidenziare e correggere una classe significativa di problemi a livello di rendering mentre le correzioni più durature a livello di codice vengono pianificate e distribuite.

Infine, intervieni sul punto di leva più grande del tuo codebase: i template. La maggior parte dei siti web utilizza template — un header, un footer, una navigazione e un layout di pagina che si ripetono su ogni pagina. I problemi in questi template si moltiplicano su tutto il sito. Correggili per primi per ottenere il massimo impatto. Un singolo template di base corretto può trasformare 10.000 violazioni WCAG in zero con un solo deployment.

Punti chiave

• Sei tipologie di problemi dominano il panorama. Testo a basso contrasto, alt text mancante, campi dei form senza etichette, link e pulsanti vuoti, lingua del documento mancante e navigazione da tastiera difettosa rappresentano la stragrande maggioranza delle violazioni WCAG. Correggere queste sei categorie produce risultati sproporzionati rispetto allo sforzo.
• La maggior parte delle correzioni è in CSS o in una riga di HTML. Aggiungere lang='en' al tag <html>, sostituire outline: none con stili :focus-visible e associare etichette ai campi sono interventi di poche ore, non di mesi — eppure eliminano errori che colpiscono ogni persona con disabilità che visita il tuo sito.
• I template sono il punto di intervento a maggior leva. I bug di accessibilità nei componenti condivisi e nei template di pagina si replicano su tutto il sito. Verifica per primi header, footer, navigazione e form — correggerli lì significa correggerli ovunque.
• ARIA è uno strumento di ultima istanza, non la prima risposta. I siti che fanno grande affidamento su ARIA senza una solida base di HTML semantico tendono ad avere significativamente più errori di accessibilità, non meno. Preferisci gli elementi HTML nativi ogni volta che è possibile.
• La scansione automatica intercetta meno della metà dei problemi reali. Completa i tuoi strumenti con verifiche manuali tramite tastiera e test con screen reader per individuare gli errori che nessuno scanner rileverà, inclusi blocchi di focus, problemi di ordine logico di tabulazione e contenuti dinamici che non annunciano i cambiamenti.