WCAG 1.4.1: Uso del colore

Cosa Significa Questa Regola

WCAG 1.4.1 Uso del colore è un criterio di Livello A sotto il principio Percettibile. Stabilisce che il colore non deve essere usato come unico mezzo visivo per trasmettere informazioni, indicare un’azione, sollecitare una risposta o distinguere un elemento visivo. La parola chiave qui è "unico": il colore non è vietato, ma deve sempre essere accompagnato da almeno un ulteriore segnale visivo, come etichette testuali, pattern, forme, bordi, icone o trattamenti tipografici, in modo che le stesse informazioni siano disponibili indipendentemente dal fatto che l’utente possa percepire le differenze di colore.

Questo criterio copre un’ampia gamma di elementi dell’interfaccia. I campi di un modulo che diventano rossi per indicare un errore non soddisfano questo criterio se il rosso è l’unico indicatore. Grafici e diagrammi che usano solo il colore per distinguere le serie di dati non soddisfano questo criterio. I link stilizzati solo con un colore diverso (senza sottolineatura, grassetto o un altro elemento distintivo non basato sul colore) non soddisfano questo criterio quando compaiono all’interno di un blocco di testo principale. Stati di navigazione, badge di stato, indicatori di avanzamento, marcatori di campi obbligatori e affordance interattive rientrano tutti nell’ambito di applicazione.

Una implementazione conforme fornisce almeno un meccanismo non basato sul colore insieme al colore. Per esempio: un campo di errore contornato in rosso e accompagnato da un’icona di errore e da un’etichetta testuale descrittiva; un grafico a torta che utilizza sia colori distinti sia riempimenti a pattern; link nel testo principale che sono sia di un colore diverso sia sottolineati. Una implementazione non conforme si affida esclusivamente al cambiamento di colore: non esiste alcuna differenza di forma, bordo, pattern, etichetta o testo che trasmetta lo stesso significato.

C’è un’importante precisazione di ambito nella specifica WCAG: questo criterio si applica specificamente al colore come mezzo visivo per trasmettere informazioni. Non richiede che tutti i colori vengano rimossi, né affronta i rapporti di contrasto, che sono gestiti da 1.4.3 e 1.4.11. Non si applica nemmeno a loghi o immagini decorative in cui il colore non ha alcun significato informativo. Il criterio riguarda esclusivamente le situazioni in cui un utente che non può distinguere tra due o più colori perderebbe l’accesso a informazioni o funzionalità.

Perché È Importante

Circa 300 milioni di persone nel mondo vivono con una qualche forma di deficit della visione dei colori (daltonismo) e 2,2 miliardi di persone a livello globale hanno un’ipovisione da vicino o da lontano secondo l’Organizzazione Mondiale della Sanità. Il daltonismo colpisce circa 1 uomo su 12 e 1 donna su 200 di discendenza nordeuropea, il che significa che in un pubblico tipico di 100 persone, circa 5–8 di loro non possono distinguere in modo affidabile il rosso dal verde, una delle combinazioni di colore più comuni usate nelle interfacce per segnalare successo rispetto a fallimento.

Per gli utenti con deuteranopia o protanopia (daltonismo rosso-verde), un modulo che evidenzia i campi non validi solo in rosso è, di fatto, invisibile come indicatore di errore. Invieranno il modulo, non vedranno alcun cambiamento evidente e concluderanno che il sistema è guasto o che l’invio è stato accettato. Questo non è un semplice inconveniente: può comportare transazioni finanziarie non riuscite, appuntamenti medici mancati, domande per servizi governativi non andate a buon fine o impossibilità di completare acquisti di e-commerce.

Gli utenti ipovedenti che si affidano a display ad alto contrasto o a combinazioni di colori personalizzate possono avere attivi override di colore a livello di sistema. In tali ambienti, i colori specificati dall’autore possono essere completamente sostituiti, rendendo qualsiasi segnale basato solo sul colore privo di significato, indipendentemente dalla capacità dell’utente di percepire il colore. Allo stesso modo, gli utenti che stampano documenti in bianco e nero o accedono ai contenuti su display e-ink monocromatici perdono ogni differenziazione basata sul colore.

Oltre alla disabilità, questo criterio avvantaggia una vasta popolazione: utenti mobili all’aperto in piena luce solare, utenti con schermi di bassa qualità con scarsa resa cromatica e persone anziane la cui percezione del colore diminuisce naturalmente con l’età. Un uso accessibile del colore migliora anche la SEO in modo indiretto: le etichette testuali descrittive aggiunte per soddisfare questo criterio forniscono contenuto semantico aggiuntivo che i motori di ricerca possono indicizzare. Dal punto di vista dell’usabilità, etichette testuali esplicite e segnali visivi insieme al colore riducono il carico cognitivo per tutti gli utenti rendendo il significato dell’interfaccia ridondante e rafforzato.

Regole Axe-core Correlate

WCAG 1.4.1 richiede test manuali perché gli strumenti automatici non possono determinare in modo affidabile se il colore viene usato come unico mezzo per trasmettere informazioni. Si tratta di un giudizio semantico e visivo: uno strumento automatico può rilevare che due elementi hanno colori diversi, ma non può determinare se quei colori sono l’unico fattore distintivo o se le informazioni veicolate da quella differenza di colore sono trasmesse anche da un altro meccanismo. Lo strumento dovrebbe comprendere l’intento progettuale e l’intero contesto di resa visiva per poterlo determinare.

• Test manuale richiesto — Distinzione del colore dei link: Axe-core non può verificare automaticamente se i link all’interno del testo principale sono distinguibili dal testo non collegato circostante con mezzi diversi dal solo colore. Un tester umano deve ispezionare visivamente la pagina e confermare che i link abbiano un ulteriore segnale non basato sul colore (come sottolineatura, grassetto o un’icona visibile) quando compaiono in linea all’interno di paragrafi di testo. Gli strumenti automatici possono rilevare che esiste un link, ma non se la sua presentazione visiva si basa esclusivamente su una differenza di tonalità.
• Test manuale richiesto — Stati di errore dei moduli: Quando un campo di un modulo entra in stato di errore, gli strumenti automatici non possono determinare se il cambiamento visivo (come un bordo o uno sfondo rosso) sia l’unica indicazione dell’errore o se sia accompagnato da un’icona di errore, un messaggio testuale o un altro segnale non basato sul colore. Un tester deve interagire con il modulo, generare errori di validazione e ispezionare come l’errore viene comunicato visivamente.
• Test manuale richiesto — Visualizzazioni di dati: Grafici, diagrammi, mappe e schemi che usano il colore per distinguere categorie, serie di dati o regioni non possono essere valutati automaticamente per la conformità con 1.4.1. Un tester umano deve valutare se siano presenti anche pattern, etichette o texture per differenziare gli elementi codificati a colori.
• Test manuale richiesto — Indicatori di stato: Badge, tag e indicatori di stato (come indicatori online/offline o etichette di stato degli ordini) che si affidano al colore per comunicare lo stato non possono essere segnalati automaticamente. Il tester deve confermare che ogni stato sia comunicato anche da un’etichetta testuale, un’icona o un cambiamento di forma.

Come Eseguire i Test

1. Baseline di scansione automatizzata: Esegui axe DevTools, Lighthouse o il checker di accessibilità Accsible sulla pagina. Sebbene questi strumenti non segnaleranno direttamente violazioni di 1.4.1, possono far emergere problemi correlati come alternative testuali mancanti, contrasto insufficiente o etichette di modulo mancanti che correlano con l’uso del solo colore. Prendi nota di eventuali problemi segnalati e usali come punti di partenza per l’ispezione manuale. In axe DevTools, apri l’estensione del browser, fai clic su "Analyze" e rivedi la categoria "Needs Review" oltre all’elenco delle violazioni, poiché alcuni problemi relativi al colore possono emergere lì.
2. Simulazione in scala di grigi: Usa un’estensione del browser o una funzionalità di accessibilità del sistema operativo per visualizzare la pagina in scala di grigi (saturazione zero). Su macOS, vai su Impostazioni di sistema > Accessibilità > Schermo e abilita "Usa scala di grigi". Su Windows, vai su Impostazioni > Accessibilità > Filtri colore e seleziona "Scala di grigi". In alternativa, usa gli strumenti di sviluppo del browser: in Chrome, apri DevTools, premi Ctrl+Shift+P (o Cmd+Shift+P su Mac), digita "Emulate vision deficiencies" e seleziona "Achromatopsia". Esamina ogni elemento interattivo, indicatore di stato, campo del modulo, grafico e link in scala di grigi e conferma che tutte le informazioni restino comprensibili senza il colore.
3. Simulazione del daltonismo: Usa l’emulatore di deficit visivi di Chrome DevTools (stesso percorso di cui sopra) per simulare Deuteranopia, Protanopia e Tritanopia. Per ogni simulazione, percorri tutti i flussi utente: invio di moduli con errori, interpretazione dei dati nei grafici, navigazione tra stati attivi e inattivi, e verifica che nessuna informazione vada persa. Strumenti come Coblis Color Blindness Simulator o Colour Oracle (un’applicazione desktop) possono essere usati anche per simulare il daltonismo sull’intero schermo.
4. Link nel testo principale — verifica manuale: Identifica tutti i collegamenti ipertestuali che compaiono all’interno di paragrafi di testo principale (in contrapposizione a menu di navigazione o elenchi di link autonomi). Per ciascuno di questi link, conferma che sia visivamente distinguibile dal testo non collegato circostante tramite almeno un meccanismo non basato sul colore. Il meccanismo accettabile più comune è la sottolineatura. Se il link si basa solo su una differenza di colore, si tratta di una non conformità.
5. Validazione dei moduli — verifica manuale: Usando la navigazione da tastiera (Tab per spostare il focus, Invio o Barra spaziatrice per attivare i controlli), compila un modulo e lascia deliberatamente vuoti i campi obbligatori o inserisci dati non validi. Invia il modulo. Ispeziona visivamente come vengono comunicati gli errori. Conferma che l’indicazione di errore non sia fornita solo dal colore: ogni errore deve avere una descrizione testuale visibile, un’icona o entrambi, oltre a qualsiasi cambiamento di colore.
6. Verifica con screen reader (NVDA + Firefox): Apri la pagina in Firefox con NVDA in esecuzione. Naviga attraverso tutti i campi del modulo, i grafici e gli indicatori di stato usando il cursore virtuale. Conferma che i messaggi di errore, le etichette di stato e le descrizioni dei dati vengano annunciati dallo screen reader. Questo convalida il livello programmatico, anche se l’accesso tramite screen reader da solo non soddisfa il requisito visivo di 1.4.1 per gli utenti vedenti daltonici.
7. Revisione di grafici e diagrammi: Per ogni visualizzazione di dati, prova a interpretare i dati usando solo forma, pattern o etichette testuali, ignorando deliberatamente il colore. Se la visualizzazione diventa non interpretabile senza il colore, non è conforme. Conferma che sia disponibile un’alternativa basata su testo (tabella dati, legenda con pattern, etichette dati dirette).

Come Correggere

Link in linea nel testo principale — Non corretto

<!-- Link distinguibile dal testo circostante solo per il colore.
     Un utente daltonico non può identificarlo come link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
  before continuing.
</p>

Link in linea nel testo principale — Corretto

<!-- Il link è sottolineato oltre a essere di un colore diverso.
     La sottolineatura fornisce un segnale visivo non basato sul colore che lo identifica come link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
  before continuing.
</p>

Stato di errore del modulo — Non corretto

<!-- L'errore è comunicato solo da un bordo rosso.
     Un utente daltonico non può distinguerlo da un campo normale. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->

Stato di errore del modulo — Corretto

<!-- L'errore è comunicato da un bordo rosso E da un'icona di errore visibile E da un messaggio testuale.
     Il messaggio testuale è anche collegato tramite aria-describedby per le tecnologie assistive. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
/>
<p id='email-error' class='error-message'>
  <svg aria-hidden='true' focusable='false' class='error-icon'>
    <!-- error icon SVG path data -->
  </svg>
  Please enter a valid email address.
</p>

Legenda del grafico basata solo sul colore — Non corretta

<!-- Grafico a barre in cui le categorie sono differenziate solo dal colore di riempimento.
     Gli utenti daltonici non possono distinguere le categorie. -->
<svg role='img' aria-label='Quarterly sales by region'>
  <rect x='10' y='50' width='40' height='100' fill='#e63946' />
  <rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
  <rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch red'></span> North</li>
  <li><span class='swatch green'></span> South</li>
  <li><span class='swatch yellow'></span> West</li>
</ul>

Legenda del grafico basata solo sul colore — Corretta

<!-- Le barre usano sia colori distinti SIA riempimenti a pattern distinti (tramite pattern SVG).
     Gli elementi della legenda includono un'etichetta testuale. È fornita anche una tabella dati accessibile. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
  <defs>
    <pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
      <line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
    </pattern>
    <pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
      <circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
    </pattern>
    <pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
      <rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
    </pattern>
  </defs>
  <rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
  <rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
  <rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
  <li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
  <li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
  <caption>Quarterly sales by region (data table)</caption>
  <thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
  <tbody>
    <tr><td>North</td><td>100</td></tr>
    <tr><td>South</td><td>130</td></tr>
    <tr><td>West</td><td>80</td></tr>
  </tbody>
</table>

Badge di stato — Non corretto

<!-- Stato dell'ordine comunicato solo dal colore di sfondo.
     "Pending" (giallo), "Shipped" (blu) e "Delivered" (verde) sono
     visivamente identici per molti utenti daltonici. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>

Badge di stato — Corretto

<!-- Lo stato è comunicato dal colore E da un'etichetta testuale visibile.
     L'etichetta testuale è il principale veicolo di significato. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>

Errori Comuni

• Rimuovere le sottolineature dai link in linea e affidarsi esclusivamente al colore: Impostare text-decoration: none sugli elementi ancora all’interno dei paragrafi di testo principale è uno dei fallimenti 1.4.1 più comuni. La sottolineatura è il segnale non basato sul colore predefinito per i link; rimuoverla senza aggiungere un altro elemento distintivo non basato sul colore (come un grassetto o un’icona) causa un’immediata non conformità ogni volta che quel link appare all’interno di testo circostante di un colore diverso.
• Usare coppie di colori rosso/verde per stati di pass/fail senza icone o testo aggiuntivi: Il rosso per il fallimento e il verde per il successo è culturalmente intuitivo ma inaccessibile per gli utenti con deuteranopia o protanopia, che sono proprio le forme di daltonismo più comuni. Associa sempre questi colori a icone distinte (una spunta rispetto a una X) e a etichette testuali esplicite ("Valido" rispetto a "Errore").
• Contrassegnare i campi obbligatori del modulo solo con un asterisco colorato: Un asterisco rosso (*) accanto all’etichetta di un campo comunica lo stato di obbligatorietà tramite il colore se l’asterisco stesso non ha una legenda o una spiegazione testuale visibile di accompagnamento. La correzione consiste nell’includere una nota visibile come "* indica campo obbligatorio" vicino al modulo, assicurando che l’asterisco stesso abbia un significato che va oltre il suo colore.
• Usare stati attivi/selezionati basati solo sul colore nei menu di navigazione: Evidenziare l’elemento di navigazione attualmente attivo solo cambiando il colore del testo o dello sfondo, senza cambiare anche il peso del font, aggiungere una sottolineatura o un indicatore di bordo, significa che gli utenti daltonici non possono identificare in quale pagina si trovano.
• Tooltip dei grafici che ripetono il segnale di colore senza aggiungere etichette: Alcune librerie di grafici mostrano tooltip che presentano una campionatura di colore corrispondente alla serie di dati ma nessuna etichetta testuale per il nome della serie. Se il tooltip è l’unico luogo in cui i dati vengono disambiguati e si affida solo a una campionatura di colore, si tratta di una non conformità.
• Step di avanzamento che cambiano solo di colore per indicare il completamento: I wizard di moduli multi-step spesso stilizzano gli step completati con uno sfondo verde e gli step futuri con uno sfondo grigio. Se nessun testo ("Completato", "Corrente", "Successivo") o icona (spunta) accompagna il cambiamento di colore, lo stato dello step è comunicato solo dal colore.
• Affidarsi al colore del testo segnaposto per indicare la validazione dell’input: Cambiare il colore del testo segnaposto (ad esempio, renderlo rosso in caso di errore) è sia un segnale basato solo sul colore sia inaccessibile per ulteriori motivi (il testo segnaposto non è un sostituto di etichette o messaggi di errore). Lo stato di validazione deve essere comunicato tramite un elemento di messaggio di errore persistente e visibile.
• Presumere che le etichette ARIA da sole soddisfino 1.4.1: Aggiungere aria-label o aria-describedby a un elemento rende le informazioni disponibili agli utenti di screen reader, ma 1.4.1 è un criterio visivo. Richiede un segnale visivo non basato sul colore per gli utenti vedenti daltonici, non solo un’alternativa testuale programmatica. Entrambi sono necessari, ma ARIA da sola non è sufficiente per soddisfare 1.4.1.
• Differenziare righe o celle di tabella usando solo colori di sfondo alternati: Sebbene l’alternanza dei colori di riga (zebra striping) sia generalmente decorativa e non un problema di 1.4.1 di per sé, qualsiasi tabella che usi solo il colore di sfondo per raggruppare, categorizzare o evidenziare righe o celle specifiche come distintive dal punto di vista informativo deve fornire un’etichetta testuale, un’icona o un’intestazione per trasmettere lo stesso raggruppamento o distinzione.
• Considerare i segnali basati solo sul colore come esenti perché "solo decorativi": Gli sviluppatori a volte sostengono che un pallino colorato di stato o un’etichetta di categoria colorata siano decorativi piuttosto che informativi. Se rimuovere il colore (o visualizzare in scala di grigi) farebbe sì che un utente perda l’accesso a qualsiasi informazione di cui ha bisogno per comprendere o usare l’interfaccia, allora per definizione è informativo e deve rispettare 1.4.1.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità web e mobile allineati a WCAG 2.2. WCAG 1.4.1 Uso del colore è un criterio di Livello A, il che significa che rientra nel livello di conformità di base obbligatorio previsto da questa circolare.

La circolare impone la conformità a WCAG 2.2 Livello A entro un anno per le istituzioni pubbliche e due anni per le entità del settore privato. Le seguenti categorie di organizzazioni sono esplicitamente incluse: istituzioni pubbliche e organismi governativi, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, operatori di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio autorizzate, aziende di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

Per queste entità, la mancata conformità a WCAG 1.4.1 costituisce una violazione normativa. In termini pratici, un’istituzione pubblica turca il cui portale web usa solo il colore per indicare gli errori nei moduli, o una banca la cui interfaccia di home banking usa indicatori di stato basati solo sul colore per gli stati delle transazioni, sarebbe in violazione dei requisiti della circolare. Le piattaforme di e-commerce, un settore ampio e in rapida crescita in Turchia, usano comunemente indicatori di disponibilità dei prodotti codificati a colori, badge promozionali e messaggi di errore del carrello, tutti elementi che devono fornire alternative non basate sul colore secondo i requisiti della circolare.

La conformità a 1.4.1 è particolarmente incisiva nel contesto turco, dato il numero significativo di utenti che accedono a servizi governativi, bancari e di e-commerce su dispositivi mobili, dove la qualità dello schermo e le condizioni di illuminazione ambientale riducono ulteriormente l’affidabilità del colore come unico veicolo di informazione. Le organizzazioni coperte dalla circolare sono invitate a verificare tutti gli usi del colore come meccanismo informativo nelle loro proprietà digitali, a dare priorità all’aggiunta di etichette testuali e segnali iconografici insieme agli stati codificati a colori e a includere 1.4.1 sia nelle pipeline di scansione automatizzata dell’accessibilità sia nei protocolli strutturati di test manuali come parte del loro programma di conformità.