Rapporto di contrasto WCAG: AA, AAA e APCA — la guida completa 2026

Pubblichi un pulsante. Arancione brand, testo bianco, sembra perfetto sul tuo monitor 4K. Poi torna l’audit di accessibilità in rosso: il rapporto di contrasto WCAG è 1.97:1, ben lontano dalla soglia AA di 4.5:1 richiesta per il testo del corpo. Il pulsante che a te sembrava a posto risulta illeggibile per circa 220 milioni di persone con ipovisione nel mondo. Questa guida copre ogni numero che ti serve per sistemarlo: i rapporti WCAG 2, il livello AAA, il nuovo algoritmo APCA Lc, otto categorie di deficienze della visione cromatica e un’implementazione JavaScript funzionante che puoi integrare nella tua build.

Riferimento rapido: soglie WCAG e APCA a colpo d’occhio

Standard	Testo normale	Testo grande	UI / icone	Note
WCAG AA	≥ 4.5:1	≥ 3:1	≥ 3:1	Baseline legale
WCAG AAA	≥ 7:1	≥ 4.5:1	≥ 3:1	Obiettivo avanzato
APCA body	Lc 75+	Lc 60+	Lc 45+ (icone)	Bozza, percettivo

Per “testo grande” si intende ≥ 18pt regular oppure ≥ 14pt bold (circa 24px e 18.66px in CSS). “UI” comprende i bordi dei form, i ring di focus e qualsiasi oggetto grafico che l’utente deve percepire per operare sulla pagina. Loghi e grafiche puramente decorative sono esentati dai requisiti di contrasto.

Cos’è il contrasto cromatico WCAG?

Il rapporto di contrasto WCAG è una misura numerica che va da 1:1 (nessun contrasto) a 21:1 (massimo) e confronta la luminanza relativa del testo rispetto allo sfondo. Le Web Content Accessibility Guidelines richiedono ≥ 4.5:1 (AA) per il testo del corpo o ≥ 7:1 (AAA) per la conformità avanzata.

Quel singolo rapporto governa la maggior parte degli audit di accessibilità nel mondo. Il W3C lo ha pubblicato in WCAG 2.0 nel 2008, l’ha rifinito nella 2.1 (2018) e nella 2.2 (2023), e oggi ogni grande regolatore lo cita. L’ADA negli Stati Uniti, l’European Accessibility Act (entrato in vigore a giugno 2025), la Section 508 per le agenzie federali statunitensi e l’AODA canadese usano tutti WCAG 2.x AA come riferimento di fatto.

Perché conta tutto questo, al di là dell’aspetto legale? Circa 220 milioni di persone nel mondo soffrono di ipovisione senza essere cieche: leggono gli schermi, ma soltanto quando il contrasto tra testo e sfondo è sufficientemente alto. Circa l’8% degli uomini e lo 0.5% delle donne presentano una deficienza della visione cromatica. I lettori più anziani sperimentano l’ingiallimento del cristallino e una riduzione dell’apertura pupillare, che dopo i 60 anni abbassa funzionalmente il contrasto percepito del 20-30%. L’uso dello smartphone all’aperto fa perdere un altro 20-40% per via dei riflessi. Una pagina che sulla tua scrivania segna 4.5:1 è il limite minimo perché tutti questi utenti riescano comunque a leggerla.

Sono problemi quotidiani per chi spedisce UI in produzione, per chi sceglie le palette brand, per chi conduce audit di accessibilità e per i team compliance che rispondono dell’esposizione legale. La matematica è breve, ma le decisioni che ne derivano richiedono compromessi reali.

Rapporto di contrasto WCAG 2.x: la matematica, le soglie

Il W3C definisce il contrasto in tre brevi passaggi. Per calcolare il rapporto di contrasto WCAG: (1) converti ogni colore da sRGB gamma-encoded a valori linear-light, (2) calcola la luminanza relativa usando coefficienti fissi che rispecchiano la sensibilità dell’occhio umano al rosso, verde e blu, e (3) dividi le due luminanze con una piccola costante di offset per gestire i valori vicini al nero.

La formula della luminanza relativa da WCAG 2.1 §1.4.3 è:

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_lin, G_lin, B_lin sono i valori linear-light di canale dopo aver invertito la curva gamma sRGB. Il peso 0.7152 sul verde riflette la forte sensibilità al verde dell’occhio umano: il verde è circa 7 volte più “rumoroso” visivamente del blu a parità di energia luminosa.

La formula del rapporto è:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

Lo +0.05 evita la divisione per zero per il nero puro (L = 0) e produce un massimo di (1 + 0.05) / (0 + 0.05) = 21:1 per bianco puro su nero puro. Il minimo è 1:1, ovvero colori identici.

Ecco l’implementazione completa in circa trenta righe di JavaScript vanilla. Nessuna dipendenza, gira ovunque:

// sRGB hex → canale linear-light
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → luminanza relativa [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// Rapporto di contrasto WCAG 2.x fra due colori hex
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// Esempio: testo slate scuro su bianco
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" — comodamente sopra AA 4.5:1 e appena oltre AAA 7:1

Incolla due codici hex nel Convertitore di colori e ottieni gli stessi numeri, affiancati da un valore APCA Lc, una classificazione di gamut e un’anteprima CVD su otto canali. Le soglie in sé sono concrete:

Elemento	AA min	AAA min	Note
Testo del corpo normale	4.5:1	7:1	Sotto 18pt regular / sotto 14pt bold
Testo grande	3:1	4.5:1	≥ 18pt regular OPPURE ≥ 14pt bold
Componenti UI / icone	3:1	—	WCAG 2.1 §1.4.11, introdotto nel 2018
Loghi e decorativi	esente	esente	Nessun requisito di contrasto

Le conversioni di unità CSS confondono spesso i team. 18pt = 24px al default del browser, 14pt = 18.66px. Un body a 16px — il default moderno — è sotto la soglia di “testo grande”, quindi ricade nella regola AA più stringente di 4.5:1. Un heading a 20px con font-weight: 700 si qualifica come grande e ottiene il più permissivo 3:1.

Una sottigliezza che coglie i team di sorpresa: l’esenzione “testo grande” di WCAG riguarda la leggibilità per l’utente alle dimensioni di rendering, non la semantica degli heading. Un <h2> da 14px non è testo grande: ha comunque bisogno di 4.5:1. Un paragrafo da 24px di copy marketing è testo grande e ottiene il floor a 3:1. La regola si basa sulla dimensione in pixel renderizzata e sul peso, mai sul nome del tag. Gli auditor segnaleranno i mismatch; il tuo CSS è la fonte di verità, non la semantica HTML.

La costante +0.05 nella formula del rapporto ha un’origine precisa: rappresenta il flare term, ovvero la luce ambientale riflessa dalla superficie dello schermo che alza la luminanza apparente del nero puro fino a un floor minimo. Senza questa costante, un pixel OLED che renderizza nero vero contro bianco puro produrrebbe una divisione per zero. Con la costante, il rapporto massimo raggiungibile è 21:1, un numero che vedrai citato in ogni strumento di accessibilità. Non esiste schermo fisico che possa superare 21:1 una volta tenuto conto del flare, ed è il motivo per cui la scala WCAG si ferma lì.

AA vs AAA: a quale livello puntare?

AA è il floor legale; AAA è il livello aspirazionale. La maggior parte dei siti commerciali punta ad AA perché AAA spinge i colori brand verso la scala di grigi per essere superato, cosa che i team marketing rifiutano. La scelta giusta dipende dal compromesso fra portata utente ed espressione del brand.

Contesto	Livello consigliato	Perché
Sito commerciale generico	AA	Baseline ADA / EAA; i tribunali citano WCAG 2 AA
Servizi pubblici / governativi	AAA	Section 508 e statuti UE equivalenti raccomandano AAA
Sanità / istruzione	AAA	Base utenti orientata a esigenze di accessibilità più alte
Dashboard interno	AA	Pubblico noto, ROI accettabile
Landing page marketing	AA + deroga brand	Colori brand ammessi su hero/CTA, il body resta AA

Il costo nascosto di AAA emerge la prima volta che cerchi di far passare a 7:1 contro il bianco un arancione brand saturo. Non ce la fa. O scurisci l’arancione finché smette di essere il tuo brand, oppure accetti AA e usi l’arancione su sfondi scuri, dove può centrare AAA con facilità. Molte aziende — incluse alcune delle più attente all’accessibilità — puntano esplicitamente ad AA sul contenuto del corpo e spingono per AAA solo su testi critici come messaggi di errore o disclosure legali.

I regolatori non hanno aspettato la diffusione di AAA. Il regolamento web-accessibility ADA del 2024 cita WCAG 2.1 AA. L’European Accessibility Act, in vigore da giugno 2025, richiede WCAG 2.1 AA su tutti i servizi digitali coperti. La Section 508 del governo federale statunitense usa WCAG 2.0 AA come baseline (con AAA raccomandato dove fattibile). L’AODA canadese, lo statuto sull’accessibilità dell’Ontario, punta a WCAG 2.0 AA. Lo schema è coerente: AA è l’asticella, AAA è l’obiettivo.

APCA: il nuovo algoritmo percettivo

APCA — Advanced Perceptual Contrast Algorithm, progettato da Andrew Somers sotto l’etichetta Myndex — è un algoritmo candidato per WCAG 3. Sostituisce il rapporto simmetrico di WCAG 2 con un punteggio Lc con segno di polarità da -108 a +108, dove il segno indica la direzione in cui corre il contrasto (testo scuro su chiaro vs testo chiaro su scuro) e la magnitudine riflette il contrasto percepito su un display emissivo reale.

APCA conta perché la formula simmetrica di WCAG 2 ignora due effetti reali:

Asimmetria di polarità. Testo chiaro su sfondo scuro si legge diversamente da testo scuro su sfondo chiaro, anche allo stesso rapporto WCAG. WCAG 2 restituisce lo stesso numero per entrambe le direzioni; APCA no.
Modellazione del display. La formula di WCAG 2 è stata derivata da modelli di luminanza per stampa su carta. APCA è stato tarato su display sRGB in illuminazione ufficio tipica, più vicino a ciò che i tuoi utenti vedono davvero.

Il compromesso: APCA è più complesso (coinvolge esponenti polarity-aware e aggiustamenti per il peso del font) e non è ancora uno standard regolatorio. L’analisi di Adrian Roselli di aprile 2026 resta il riassunto più chiaro sullo stato di APCA: è tecnicamente promettente, ma WCAG 3 in sé è ancora in early-draft nel Silver-track, e APCA non è stato ratificato come algoritmo ufficiale.

Le soglie APCA Bronze-level (il floor pratico a cui puntano i team) sono queste:

Caso d’uso	Lc consigliato	Lc minimo
Testo del corpo (16px, weight 400)	90+	75
Testo grande (24px, weight 400)	75+	60
Elementi UI e icone non testuali	60+	45
Spot text / placeholder	30+	30

Il motivo per cui APCA è interessante — e il motivo per cui il Convertitore di colori mostra entrambe le metriche affiancate — sono i casi in cui diverge da WCAG 2:

#FFA500 (arancione) su #FFFFFF: WCAG 2 restituisce 1.97:1, una bocciatura netta ad AA. APCA è d’accordo, con un punteggio intorno a Lc 38, anch’esso fail. Entrambi gli algoritmi dicono di no, eppure molti designer che ho visto continuano a spedire questa combinazione perché “sembra a posto”.
#767676 (grigio medio) su #FFFFFF: WCAG 2 restituisce 4.54:1, appena sopra AA 4.5:1, tecnicamente promosso. APCA assegna a questa coppia circa Lc 60, sotto la soglia di 75 di APCA Bronze per il testo del corpo. WCAG promuove; APCA boccia. L’esperienza vissuta dall’utente è più vicina al verdetto di APCA: quel grigio su bianco è più difficile da leggere alle dimensioni del corpo di quanto il rapporto suggerisca.
#3b82f6 (Tailwind blue-500) su #000000: WCAG 2 restituisce 5.71:1, un comodo pass AA. APCA assegna circa Lc 65, sotto il minimo Lc 75 per il testo del corpo. Testo azzurro su sfondo scuro, un pattern adorato nel dark mode, è il caso canonico “WCAG promuove, APCA segnala”.

Non serve scegliere fra i due. Molti team di produzione adottano un approccio pragmatico: tengono WCAG 2 AA come baseline regolatoria perché è ciò che gli audit di conformità verificano, e fanno girare APCA in parallelo come gut check “è davvero leggibile?”, soprattutto per design in dark mode e colori brand saturi. Il Convertitore di colori mostra entrambi i numeri sulla stessa riga, così non devi cambiare contesto fra checker diversi.

Daltonismo e oltre il contrasto

I rapporti di contrasto sono solo metà dell’accessibilità cromatica. Circa l’8% degli uomini e lo 0.5% delle donne vedono i colori diversamente dal tricromata da manuale, e la variante più comune, la deuteranomalia, si colloca al centro della coppia rosso/verde che usiamo ovunque per gli stati success/error. WCAG 1.4.1 (“Uso del colore”) vieta esplicitamente il colore come unico veicolo di informazione; è la regola che esiste proprio per imporlo.

La tassonomia completa delle differenze nella visione cromatica si divide in tre gruppi: dicromia (un cono mancante), tricromia anomala (un cono spostato) e le rare monocromie.

Tipo	Nome comune	Canale interessato	Prevalenza (M / F)
Protanopia	Cecità al rosso	Cono L assente	1.0% / 0.01%
Deuteranopia	Cecità al verde	Cono M assente	1.1% / 0.01%
Tritanopia	Cecità al blu	Cono S assente	0.003% / 0.003%
Protanomalia	Debolezza al rosso	Cono L spostato	1.3% / 0.02%
Deuteranomalia	Debolezza al verde	Cono M spostato	5.0% / 0.4%
Tritanomalia	Debolezza al blu	Cono S spostato	0.01% / 0.01%
Acromatopsia	Nessun colore	Tutti i coni assenti	0.003% (rarissima)
Monocromia conica	Grigio parziale	Solo un cono	0.001%

La deuteranomalia da sola è il 5% degli uomini, uno su venti. È quella fetta di popolazione che vede un indicatore di errore rosso e uno di successo verde come una sfumatura quasi identica color oliva-marrone. Per sistemarlo basta aggiungere un secondo canale, senza dover ridisegnare l’intero sistema di colori. Un’icona di errore rossa abbinata a una forma ”×” e alla parola “Errore” sopravvive a ogni variante della tabella. Un semplice punto rosso no.

Simulare i CVD nel codice si appoggia a due insiemi standard di matrici: Brettel-Viénot-Mollon (1997) per le dicromie e Machado-Oliveira-Fernandes (2009) per le tricromie anomale. L’approccio Brettel proietta il colore di input dell’utente su un piano definito dalle due risposte coniche residue; Machado parametrizza lo spostamento del cono in base alla gravità. Entrambi sono implementabili come filtri SVG o matrici CSS. Il Convertitore di colori include tutte e otto le varianti come anteprima a un click, così puoi scansionare un colore brand lungo tutto lo spettro senza lasciare la pagina.

Un breve filtro SVG — incollalo nella tua pagina e referenzialo per ID — ti dà la simulazione di protanopia in-browser per test ad-hoc:

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

Applica .preview-protanopia al wrapper della pagina per vedere ciò che vede un protanope. Ripeti con le matrici di deuteranopia e tritanopia (i loro coefficienti sono documentati nel paper di Brettel e inclusi nella maggior parte delle librerie di simulazione CVD). Il pannello Rendering di Chrome DevTools ha gli stessi simulatori incorporati sotto “Emula deficienze visive”: utile per controlli rapidi, meno per catturare screenshot in CI.

Oltre la simulazione, vale una regola di fondo: non lasciare mai che il colore sia l’unica differenza fra due stati. Le icone devono differire nella forma (× vs ✓), gli stati nell’etichetta testuale (“Errore” vs “Successo”), le categorie nel pattern (tinta unita vs tratteggiato). Il colore amplifica questi altri segnali; non li sostituisce.

C’è una classe di errori che i checker di contrasto non rilevano ma i simulatori CVD sì. Segmenti di grafico a torta distinti solo per tinta, legende di mappe che color-codificano i paesi, pill di stato che si affidano a un gradiente verde/giallo/rosso: tutti possono superare il contrasto WCAG 2 contro lo sfondo pur risultando illeggibili a un deuteranope che li confronta fra loro. La regola è verificare la leggibilità fra colori adiacenti nel design, non solo contro il canvas circostante. Due segmenti slate-500 affiancati alla stessa luminosità sono indistinguibili a prescindere dalla rotazione di tinta. Aggiungi uno step di luminanza fra regioni adiacenti e il grafico sopravvive a ogni variante CVD.

L’acromatopsia e la monocromia conica sono rare ma vale la pena progettare esplicitamente per loro, perché collassano ogni distinzione di tinta. Un utente con acromatopsia percepisce solo la luminanza: la tua UI color-coded gli appare come una foto in scala di grigi. Se il tuo design regge quando applichi filter: grayscale(1) all’intera pagina (prova in DevTools), hai superato la versione più stringente della regola “il colore non è l’unico segnale”. È il test di accessibilità più economico che puoi eseguire, e fa emergere molti fallimenti non appena lo attivi.

Audit delle palette Tailwind e Material

Gran parte del lavoro front-end usa una palette preconfezionata: Tailwind v4, Material 3, Radix o shadcn. La domanda di accessibilità diventa “a quale stop di questa rampa il testo diventa leggibile?”, e la risposta è più approssimativa di quanto i docs ammettano.

Per la rampa slate di Tailwind v4 contro il bianco puro, i numeri WCAG e APCA cadono così:

Classe Tailwind	Hex circa	WCAG vs bianco	AA body	AAA body	APCA Lc (circa)
slate-400	`#94a3b8`	2.56:1	✗	✗	~38 ✗
slate-500	`#64748b`	4.76:1	✓	✗	~60 ✗ body
slate-600	`#475569`	7.58:1	✓	✓	~78 ✓ body
slate-700	`#334155`	10.35:1	✓	✓	~90 ✓ body

Le regole pratiche che ne discendono:

Il testo del corpo richiede slate-600 o più scuro. Slate-500 supera WCAG AA ma fallisce la soglia APCA per il testo del corpo: è conforme ma scomodo. Slate-600 è il floor sicuro.
Le label UI e il testo secondario possono usare slate-500. I componenti UI hanno bisogno solo di 3:1; il 4.76:1 di slate-500 è comodo, e il testo di solito porta con sé un contesto visivo di supporto.
I placeholder dovrebbero usare slate-400 o tonalità più chiare. Il testo placeholder è esente da WCAG 1.4.3 come decorativo soltanto se tieni una label visibile sopra il campo. I pattern inline-label-as-placeholder devono raggiungere la soglia del testo del corpo.
Nero puro su slate-100 / slate-200 è inchiostro sprecato. Sei a 17:1+; valuta slate-700 o slate-800 come colore del testo per un effetto più morbido senza perdere leggibilità.

Material 3 usa una struttura di palette tonale simile. Il suo surface-container-high vive intorno al tono 92 (molto chiaro); il suo on-surface vive intorno al tono 10 (vicino al nero). Il contrasto fra qualsiasi on-surface e qualsiasi token surface-* nella stessa famiglia è garantito dallo spec Material come superamento di AA. Non accoppiare on-surface-variant (tono 30) contro surface-container (tono 94) senza verificare: è un errore reale che ho visto andare in produzione.

Se hai una palette esistente che non passa il contrasto, OKLCH è il percorso di fix più pulito. Invece di ritoccare codici hex alla cieca, converti il colore in OKLCH, tieni C (chroma) e H (hue) fissi, e riduci L (lightness) finché il contrasto passa. Dato che il canale L di OKLCH è davvero percettivo, il riconoscimento del brand resta intatto mentre il contrasto si stringe. Lo strumento HEX a OKLCH esegue questa conversione in un singolo passaggio; l’articolo gemello OKLCH spiegato copre la matematica in profondità.

Il dark mode richiede un trattamento a parte. Il rapporto simmetrico di WCAG 2 promuove per definizione le stesse combinazioni in light e dark mode. APCA, essendo polarity-aware, segnala spesso il testo del corpo in dark mode come più difficile da leggere rispetto alla stessa coppia hex in light mode. Il testo chiaro su scuro perde sempre un po’ di contrasto percepito rispetto a scuro-su-chiaro a parità di rapporto numerico: è un effetto noto di come l’occhio si adatta. Ri-esegui APCA su ogni coppia dark mode prima di spedire.

Checker di contrasto e workflow CI

Designer e ingegneri hanno ciascuno il proprio checker preferito; la domanda pratica è quale combinazione di strumenti cucire insieme in un workflow reale. Ecco il panorama al 2026:

Strumento	WCAG 2	APCA	Sim. CVD	Audit palette
WebAIM Contrast Checker	✓	✗	✗	✗
Adobe Color	✓	✗	✓	✓
Stark (plugin Figma)	✓	✓	✓	✓
Polypane (browser)	✓	✓	✓	✓
Color picker di Chrome DevTools	✓	✓ (exp.)	✗	✗
axe DevTools	✓	✗	✗	✓ (page-level)
Go Tools Color Converter	✓	✓	✓ (8 tipi)	✓ (Tints/Shades)

Un workflow che regge sotto la pressione di prodotto reale è fatto così:

In Figma, i designer fanno girare Stark su ogni frame per far emergere presto le coppie non conformi. Stark intercetta i colpevoli più ovvi prima che qualunque codice hex entri nel codebase.
Al handoff del codice hex, gli ingegneri incollano il valore nel Convertitore di colori per ottenere rapporto WCAG + APCA Lc + classificazione di gamut + anteprima CVD in una sola riga. Se la coppia è dark-mode o brand saturo, la doppia metrica intercetta i casi WCAG-promuove-APCA-boccia che Stark potrebbe mancare.
Al momento della PR, axe-core/playwright scansiona le pagine buildate per qualsiasi violazione di contrasto sul DOM renderizzato, inclusi stati dinamici. Questo intercetta ring di focus, stati hover e affordance disabilitate che i file di design statici mancano.
In QA, la scheda Rendering di Chrome DevTools simula protanopia/deuteranopia/tritanopia per controlli a campione sui flow critici. Il Color Picker in DevTools mostra inoltre un rapporto WCAG inline quando passi sopra un qualsiasi elemento.

Pa11y, Lighthouse CI e @axe-core/playwright espongono tutti assertion sul contrasto come parte dei loro audit di accessibilità più ampi. Nessuno di loro verifica APCA oggi; verificano tutti WCAG 2. Il compromesso realistico è “imponi WCAG 2 AA in CI, controlla APCA Lc manualmente per i colori brand e il dark mode”.

Un pattern utile preso in prestito dai team di design system più grandi: integra il check del contrasto nel passaggio di validazione dei token, non solo nel QA a livello di pagina. Se i tuoi design token si compilano da un file sorgente (JSON, YAML o un modulo TypeScript), aggiungi uno script che enumera ogni accoppiamento --text-* × --surface-* che il sistema consente e impone un rapporto WCAG minimo. Lo script gira in millisecondi, intercetta le regressioni quando qualcuno ritocca un valore di token e produce una matrice di contrasto che funge da documentazione per il team di design. Il check è indipendente da qualsiasi pagina renderizzata: opera puramente sui token, quindi intercetta il fallimento prima che qualunque UI venga spedita.

Per conversioni ad-hoc durante questo workflow — passaggi fra hex, RGB, HSL e OKLCH mentre fai debug — gli spoke HEX a RGB, HEX a HSL, HEX a OKLCH e RGB a HEX coprono i round-trip da e verso qualsiasi formato di colore richiesto dalla tua toolchain.

Errori comuni e come correggerli

Dopo anni di audit di accessibilità, continuano a presentarsi gli stessi sei errori. Ognuno ha una correzione pulita:

Testo placeholder in grigio chiaro. #999999 su bianco è 2.85:1, fallisce AA. O scurisci a #666666 (5.74:1, passa AA) oppure — meglio ancora — sostituisci i pattern placeholder-as-label con una label visibile e persistente sopra il campo. I placeholder non dovrebbero veicolare informazioni.
Pulsante arancione brand con testo bianco. #FFA500 su bianco è 1.97:1, fallisce AA pesantemente. La correzione che preserva il brand è invertire la direzione del contrasto: testo scuro (es. #451a03) sullo sfondo arancione, oppure tieni il testo bianco e scurisci il pulsante verso un marrone-arancio profondo e saturo. Verifica nel Convertitore di colori prima di spedire.
Link blu acceso in dark mode. #3b82f6 su #000000 è 5.71:1, WCAG AA pass, ma APCA Lc ~65, sotto la soglia Lc 75 per il corpo. Passa a OKLCH e alza L da circa 0.63 a 0.75, mantenendo C e H fissi; atterri vicino a #7aa5f8 con un comodo APCA Lc 80+ e la stessa tinta.
Testo disabilitato in #CCCCCC. 1.61:1 contro il bianco. WCAG 1.4.3 esenta il testo puramente decorativo dalla regola del rapporto, ma i controlli UI disabilitati non sono decorativi: comunicano “questo è attualmente non disponibile”. Abbina il colore attenuato a un indizio non cromatico (barrato, icona di lucchetto, tooltip “Disabilitato”) in modo che un utente CVD o ipovedente capisca comunque lo stato.
Icone di stato che differiscono solo per tinta. Una × rossa e una ✓ verde vanno bene perché la forma già le distingue. Un punto rosso vs un punto verde no. Usa forma e colore insieme: l’anteprima CVD del Convertitore di colori rende ovvio il caso di fallimento in un secondo.
Testo su uno sfondo a gradiente. Un gradiente che va da #3b82f6 a #a78bfa contro testo bianco passa il contrasto al centro e fallisce vicino all’estremità lavanda. La correzione è imporre il contrasto contro il punto peggiore del gradiente, oppure sovrapporre uno scrim semi-trasparente scuro così che la luminanza effettiva di sfondo resti sempre sotto una soglia nota.

Ogni correzione richiede minuti, mentre il ciclo di audit che evita ognuna di esse pesa intere settimane.

FAQ

Cos’è il rapporto di contrasto WCAG AA?

WCAG AA richiede ≥ 4.5:1 fra testo del corpo e sfondo, oppure ≥ 3:1 per testo grande (≥ 18pt regular o ≥ 14pt bold) e componenti UI come i bordi dei form. AA è la baseline legale sotto ADA, EAA e Section 508: la maggior parte dei siti commerciali punta ad AA perché copre l’asticella regolatoria senza spingere i colori brand verso la scala di grigi.

Quale rapporto di contrasto mi serve per AAA?

WCAG AAA richiede ≥ 7:1 per il testo del corpo normale e ≥ 4.5:1 per il testo grande. AAA è raccomandato per siti medici, formativi e governativi dove la base utenti è orientata a esigenze di accessibilità più alte. I colori brand spesso devono essere appiattiti verso valori vicini alla scala di grigi per superare AAA, motivo per cui molti prodotti commerciali si fermano ad AA.

Cos’è APCA ed è WCAG 3.0?

APCA (Advanced Perceptual Contrast Algorithm), progettato da Andrew Somers / Myndex, è un algoritmo candidato nel progetto WCAG 3 Silver. Usa punteggi Lc con polarità da -108 a +108 invece di rapporti simmetrici. Al 2026, WCAG 3 è ancora in early draft e APCA non è stato ratificato formalmente: WCAG 2.1 / 2.2 AA resta lo standard regolatorio da centrare oggi.

Il dark mode aiuta l’accessibilità del contrasto?

A volte, ma non automaticamente. Il rapporto simmetrico di WCAG 2 promuove le stesse combinazioni in light e dark mode, ma APCA (polarity-sensitive) segnala spesso il testo del corpo in dark mode come più difficile da leggere rispetto alla stessa coppia hex in light mode. Ri-testa sempre il dark mode contro sia WCAG sia APCA prima di spedire; testo chiaro su scuro perde contrasto percepito in modi che il rapporto simmetrico non vede.

Perché il mio colore brand non passa WCAG AA?

I colori saturi a luminanza media — la maggior parte di arancioni, gialli, verdi lime, azzurri — hanno valori di luminanza relativa troppo vicini al bianco per superare 4.5:1. La soluzione: tieni la tinta brand per accent e titoli grandi, ma abbina il testo del corpo a un tono più scuro della stessa famiglia di tinta. Usa OKLCH per abbassare il canale L senza spostare la tinta: il Convertitore di colori trova la sfumatura conforme più vicina in un solo passaggio.

I rapporti WCAG 2 e i punteggi APCA sono compatibili?

No. WCAG 2 restituisce un rapporto simmetrico (1-21); APCA restituisce un punteggio Lc con polarità (-108 a +108). La relazione non è lineare: una coppia che è 4.5:1 in WCAG potrebbe segnare Lc 60 o Lc 75 in APCA a seconda di quale colore stia sopra. Trattali come due verifiche indipendenti, non come traduzioni l’una dell’altra.

Posso usare il contrasto cromatico per icone UI piccole?

Sì, con qualche distinguo. WCAG 2.1 §1.4.11 richiede ≥ 3:1 per componenti UI e oggetti grafici. Per le icone decorative abbinate a una label di testo visibile, i requisiti di contrasto si rilassano: la label porta il significato. Per le icone stand-alone (es. una lente d’ingrandimento di ricerca senza label), imponi il pieno 3:1 contro lo sfondo circostante.

Come testo il daltonismo senza simulare?

Usa Chrome DevTools → Rendering → “Emula deficienze visive” per protanopia, deuteranopia, tritanopia e acromatopsia. Combina con l’anteprima CVD a 8 tipi del Convertitore di colori per le varianti di tricromia anomala (la deuteranomalia è la più comune, al 5% degli uomini). Per la reportistica di audit, cattura screenshot sotto ogni simulazione così che chi revisiona possa vedere i modi di fallimento inline.

Conclusione

Cinque punti reggono l’intera guida:

AA 4.5:1 è il floor legale. Centralo per tutto il testo del corpo o aspettati rumore di conformità.
AAA 7:1 è per sanità, istruzione e settore pubblico. La maggior parte dei brand commerciali si ferma ad AA per scelta progettuale.
APCA Lc è il sanity check sulla leggibilità reale. Eseguilo in parallelo a WCAG 2, soprattutto per dark mode e colori brand saturi.
Il colore non è mai l’unico segnale. Abbina ogni indizio cromatico a forma, testo o pattern: la deuteranomalia da sola è il 5% degli utenti maschi.
L di OKLCH è la leva giusta. Quando un colore non passa il contrasto, riduci L (non S, non B) per correggerlo senza spostare la tinta.

Incolla due codici hex qualsiasi nel Convertitore di colori per vedere rapporto WCAG, APCA Lc, classificazione di gamut e anteprima CVD a 8 tipi affiancati. Quella singola vista sostituisce sei strumenti separati ed è il modo più rapido per chiudere gli audit descritti in questa guida.

Guida online al contrasto WCAG: rapporti AA, AAA e algoritmo APCA