Come scegliere combinazioni di colori accessibili

Le scelte di colore sembrano una decisione estetica e si comportano come una decisione legale. Circa 4.000 cause sull'accessibilità web all'anno colpiscono i convenuti statunitensi dal 2021, e un contrasto cromatico inadeguato è uno dei tre problemi più citati nelle denunce basate su WCAG (insieme al testo alt mancante e ai campi modulo senza etichetta). La buona notizia è che il contrasto è il più semplice dei tre da correggere: un rapporto di contrasto è un numero, la soglia WCAG è un numero, e puoi calcolare l'uno rispetto all'altro in pochi secondi. La cattiva notizia è che "accessibile" va oltre il rapporto in copertina: cecità ai colori, indicatori di focus, modalità scura e tokenizzazione contano tutti, e una palette che ottiene 4,5:1 in ogni stile di testo può comunque fallire con gli utenti reali.

Una breve storia dell'accessibilità cromatica digitale

Il contrasto cromatico come standard scritto risale al primo lavoro della Web Accessibility Initiative del W3C nel 1997. Le originali Web Content Accessibility Guidelines 1.0 (maggio 1999) raccomandavano un contrasto sufficiente in termini qualitativi senza un numero rigido. WCAG 2.0 (dicembre 2008) ha introdotto la formula di luminanza relativa ora familiare e il rapporto 4,5:1 a Livello AA, tratto dalla ricerca della Lighthouse International su ciò che gli utenti più anziani con occhiali da lettura potevano leggere comodamente sugli schermi.

Il peso legale è arrivato dopo. La Section 508 dell'U.S. Rehabilitation Act ha referenziato WCAG 2.0 nel 2018; l'Americans with Disabilities Act, dopo la decisione del Ninth Circuit Robles v. Domino's del 15 gennaio 2019 (la Corte Suprema ha rifiutato di ascoltare l'appello a ottobre 2019), è ora interpretato dai tribunali statunitensi come copertura dell'accessibilità digitale sotto il Titolo III. L'European Accessibility Act è entrato in vigore il 28 giugno 2025, richiedendo WCAG 2.1 AA sui servizi digitali rivolti ai consumatori per il settore pubblico e molte aziende private. In pratica, 4,5:1 testo normale + 3:1 testo grande + 3:1 componenti UI è il pavimento de facto per qualsiasi sito web pubblico che venga costruito oggi.

La scienza ha continuato a evolversi. WCAG 2.1 (2018) ha aggiunto la regola del contrasto non-testo 3:1. L'algoritmo APCA, sviluppato da Andrew Somers per WCAG 3, modella la percezione della luminosità in modo più accurato e dà numeri diversi per combinazioni molto scure e molto chiare; è una Editor's Draft al 2026, non ancora uno standard, quindi la maggior parte delle normative cita ancora WCAG 2.x. OKLAB e OKLCH di Bjorn Ottosson (2020) hanno dato ai designer uno spazio cromatico percettivamente uniforme che rende molto più facile generare scale di colori accessibili rispetto a lavorare in HSL o RGB.

Cosa significa davvero "colore accessibile"

Contano quattro cose, non solo il rapporto:

1. Contrasto primo piano vs sfondo. Il numero in copertina. Il testo del corpo necessita di 4,5:1, il testo grande 3:1, i controlli UI e gli indicatori di focus 3:1 rispetto ai colori adiacenti. Calcola il rapporto con la formula WCAG 2 in qualsiasi color contrast checker.
2. Daltonismo. Circa l'8% degli uomini e lo 0,5% delle donne vedono meno colori di quanto il design assuma. I tre tipi principali sono la protanopia e la deuteranopia (rosso-verde, le più comuni) e la tritanopia (blu-giallo). Un'etichetta di errore rossa su un'etichetta di successo verde può essere invisibile per un osservatore protanopico.
3. Il colore non è mai l'unico segnale. WCAG 1.4.1 vieta di affidarsi al solo colore per trasmettere significato. Un bordo "errore" rosso ha bisogno anche di un'icona o di un'etichetta. Un toast "successo" verde ha bisogno di un segno di spunta.
4. Indicatori di focus. Gli utenti da tastiera devono vedere dove si trova il focus. La regola WCAG 2.4.7 richiede un indicatore di focus visibile, e l'aggiornamento 2.4.11 (WCAG 2.2) richiede che sia spesso almeno 2 pixel CSS e contrasto 3:1 rispetto al colore adiacente.

Una palette che azzecca il rapporto ma ignora le altre tre fallisce comunque con gli utenti reali.

Come scegliere colori accessibili, passo dopo passo

1. Inizia con token semantici, non con colori grezzi. Definisci text-primary, text-secondary, surface-default, surface-elevated, border-default, accent-primary, accent-danger, ecc. Mappa ogni token a un colore specifico e lascia che quei token portino il significato semantico ovunque nel design system.
2. Scegli la scala di luminosità. Usa valori di luminosità OKLCH per costruire una scala a 5-9 passi (50, 100, 200, ..., 900) dove ogni passo ha una differenza percettiva costante dal successivo. I numeri sembreranno insoliti in OKLCH (intorno a L = 0,97, 0,93, 0,88...) ma i passi percepiti saranno uniformi, cosa impossibile in HSL.
3. Scegli le tinte a ogni passo di luminosità. Scegli la tinta del marchio, poi scegli tinte complementari o di accento che mantengano un croma simile. Usa OKLCH così che "blu saturazione 100" e "arancione saturazione 100" appaiano della stessa luminosità.
4. Calcola i rapporti di contrasto. Ogni coppia di token che si tocca ha bisogno del rapporto giusto. Testo del corpo su superficie predefinita: 4,5:1. Testo disabilitato su superficie predefinita: ancora 3:1 se deve essere leggibile. Indicatore di focus su superficie adiacente: 3:1.
5. Esegui un simulatore di daltonismo. Prendi una schermata chiave e ri-renderizzala attraverso i simulatori di protanopia, deuteranopia e tritanopia. Conferma che le informazioni trasmesse dal colore siano ancora distinguibili.
6. Testa con vere tecnologie assistive. Mac VoiceOver, NVDA, JAWS e TalkBack dovrebbero tutti essere in grado di navigare senza dipendere da indizi cromatici.
7. Aggiungi il segnale non-cromatico ovunque il colore porti significato. Icone per errore/successo/avviso, sottolineature per i link nel corpo del testo, pattern per le serie dei grafici.
8. Documenta i token. Una libreria Figma, una pagina Storybook o un sito statico di design system. Auditor e nuovi designer dovrebbero poter scegliere il token giusto in pochi secondi.

Riferimento dei rapporti di contrasto

L'esenzione per i controlli disabilitati è una scappatoia legale, non una benedizione di usabilità; un controllo disabilitato che nessuno può leggere può tecnicamente passare WCAG ma confonderà comunque gli utenti.

Tipi di daltonismo e come controllarli

Esegui sempre il design almeno attraverso i simulatori di protanopia e deuteranopia; catturano la maggior parte degli utenti daltonici.

Insidie comuni

• Progettare in HSL o RGB. Passi numerici uguali in HSL producono passi percepiti diseguali. Un salto di luminosità del 10% nel giallo pallido sembra molto più grande dello stesso salto nel blu scuro. OKLCH risolve questo.
• Affidarsi al solo colore per trasmettere lo stato. Rosso e verde per errore e successo: l'8% degli utenti non sa distinguerli. Aggiungi un'icona o un'etichetta.
• Nero puro su bianco puro. #000 su #FFF ottiene un rapporto perfetto 21:1 ma è duro per gli occhi durante letture prolungate. Scendi a un quasi-nero (#1a1a1a) e un quasi-bianco (#f8f8f8) per il testo del corpo.
• Tirannia del colore di marca. Trattare il rosso del marchio come sacro e usarlo sul bianco del marchio a contrasto 2,1:1 solo perché "quello è il marchio". Aggiorna la palette del marchio a una che rispetti WCAG.
• Indicatore di focus che scompare su sfondi scuri. Un anello blu da 2 pixel su un pulsante blu scuro potrebbe essere invisibile. Testa l'anello di focus su ogni superficie dove potrebbe apparire.
• Testo placeholder che fallisce il contrasto. Il testo placeholder= all'interno di un input viene renderizzato dal browser a ~40% di opacità. Su un input bianco, questo scende facilmente sotto 4,5:1.
• Contorni dei campi modulo troppo deboli. Un bordo grigio-su-bianco da 1px a contrasto 1,2:1 fallisce WCAG 1.4.11 (contrasto non-testo). Aumenta a 3:1 o più spesso.
• Stati hover che cambiano solo il colore. Alcuni dispositivi di input puntatore (penne Bluetooth, eye-tracking) non producono hover; un cambio di colore solo-hover è invisibile per loro. Combina con un'ombra sottile o una trasformazione.
• Modalità scura per semplice inversione. Invertire una palette chiara produce colori scuri saturi che sembrano duri. Le palette in modalità scura necessitano del proprio passaggio di design con accenti desaturati.
• Testo auto-generato dalle immagini. Il testo renderizzato sopra un'immagine caricata dall'utente non può garantire il contrasto. Aggiungi uno sfondo traslucido o un text-shadow che riporti il contrasto locale.

Algoritmi e standard alternativi

Per il lavoro regolamentato oggi, WCAG 2.1 AA è il pavimento. APCA vale la pena tracciare man mano che WCAG 3 matura; molti team di design system già riportano entrambi i numeri.

Strumenti per scegliere colori accessibili

Per nuovi progetti, parti da una palette testata (Radix Colors e Open Props sono buoni default), scegli i token del marchio e verifica ogni coppia testo-su-superficie con un color contrast checker. Per progetti esistenti, fai un audit una tantum di ogni coppia testo/sfondo nel tuo foglio di stile, correggi i fallimenti e aggiungi un passaggio Stark o axe al tuo CI così che il prossimo fallimento sia catturato al momento del PR.

Privacy e gli strumenti

Il color contrast checker, il generatore di palette accessibile e il simulatore di daltonismo girano tutti interamente nel tuo browser. I colori che scegli o incolli vengono processati da JavaScript sul tuo dispositivo, i risultati vengono renderizzati nella pagina e nulla viene inviato a un server. Nessuna telemetria, nessuna analitica sull'input, nessuno script di terze parti. Per i colori del marchio non ancora pubblici, le palette di prodotti interni o i design sotto embargo, quel flusso solo-locale è la differenza tra fidarsi di uno strumento di design di uno sconosciuto con le tue risorse del marchio non rilasciate e non. Gli strumenti possono girare offline una volta caricata la pagina, cosa che puoi verificare spegnendo la tua rete e ricontrollando una coppia di contrasto.