Guide
Contrasto del colore per l'accessibilità: WCAG 2.1, APCA e cosa rilasciare davvero
4,5:1 WCAG è il pavimento legale. È anche una formula difettosa. Ecco il quadro moderno.
By Buğra SözeriPublished Updated
WCAG 2.1 richiede un rapporto di contrasto di 4,5:1per il testo del corpo normale e 3:1per il testo grande (18pt+ regolare o 14pt+ grassetto). La formula è lo standard legale de facto negli USA (rilevante per ADA), nell’UE (EAA) e nella maggior parte del mondo. Ha anche difetti ben documentati che hanno generato una sostituzione (APCA) che non ha superato WCAG 2.2. Questa guida spiega il quadro pratico oggi.
La formula di contrasto WCAG 2.x
Definita in WCAG 2.0 (2008) e invariata fino alla 2.2:
contrasto = (L_chiaro + 0,05) / (L_scuro + 0,05)
dove L = luminanza relativa (0-1) di ogni colore, calcolata in sRGB lineareI risultati vanno da 1:1 (colori identici) a 21:1 (bianco puro su nero puro).
Soglie WCAG (per la conformità AA, l’obiettivo standard):
- 4,5:1 — testo del corpo, icone, controlli del modulo.
- 3:1 — testo grande (≥ 18pt o ≥ 14pt grassetto), componenti UI (bordi dei pulsanti, indicatori di focus).
- Gli obiettivi AAA sono più severi: 7:1 per il corpo, 4,5:1 per il testo grande. Richiesti solo in alcuni contesti specifici (testo legale, governo).
Dove la formula è sbagliata
Tre problemi documentati:
- Insensibilità alle mezze tonalità. La formula assegna punteggi di contrasto uguali a coppie di mezze tonalità (es. grigio su grigio) che appaiono molto diverse nella percezione effettiva. Una coppia a 4,5:1 di grigi medi può essere visivamente più debole di una coppia a 3:1 di nero su grigio chiaro.
- Cieco ai colori. Le tonalità di uguale luminanza (rosso e verde alla stessa luminosità) ottengono un contrasto di 1:1, ma gli utenti dicromati potrebbero discriminarli male comunque. La formula non riesce a rilevare i problemi di daltonismo.
- Peso del carattere ignorato.I caratteri sottili hanno bisogno di più contrasto rispetto a quelli in grassetto della stessa dimensione; WCAG non dà credito al peso oltre la soglia binaria del “testo grande”.
APCA: la sostituzione che non ha superato WCAG 2.2
APCA (Accessible Perceptual Contrast Algorithm) è la metrica di contrasto di prossima generazione proposta e respinta. Sviluppata da Andrew Somers per la bozza di lavoro WCAG 3.0. Tiene conto dei problemi sopra ed è notevolmente più accurata rispetto ai dati reali degli studi sugli utenti.
I punteggi APCA vanno da −108 a +106. Positivo significa testo scuro su sfondo chiaro; negativo significa il contrario. Soglie:
- Lc 75 — testo del corpo (sostituisce il 4,5:1 di WCAG).
- Lc 60 — testo grande o titoli (sostituisce il 3:1).
- Lc 45 — testo non contenuto (decorativo, note sul copyright).
APCA fornisce soglie diverse per direzione (chiaro su scuro vs scuro su chiaro) perché gli occhi umani elaborano i due casi in modo diverso. La formula simmetrica di WCAG manca questo aspetto.
Cosa usare nel 2026
Approccio a due binari:
- Supera WCAG 2.1 AA come minimo. È lo standard legale. Usa la formula standard del rapporto, punta a 4,5:1 per il corpo / 3:1 per il testo grande. Strumenti:
npm i wcag-contrastper il programmato, DevTools del browser (Chrome e Firefox riportano entrambi il contrasto al passaggio del mouse) per l’ad-hoc. - Usa APCA come controllo di sanità. Quando WCAG supera ma il risultato appare soggettivamente debole, APCA di solito lo segnala. APCA è disponibile come
apca-w3(npm) e in strumenti dedicati (Atmos, plugin Stark).
Entrambe le metriche concordano sui casi ovvi (il testo nero su bianco va bene; il grigio chiaro su bianco no). Divergono sui casi limite delle mezze tonalità e del testo grande — esattamente dove le tendenze di design moderno amano vivere.
Raccomandazioni concrete
- Testo del corpo: puntare a
#1a1a1a(grigio scuro) su bianco dà ~17:1 — piacevole, chiaramente leggibile. Il nero puro su bianco (21:1) può sembrare duro; il quasi-nero deliberato va bene. - Testo disabilitato / segnaposto:WCAG esonera i “componenti UI inattivi” dalla regola del 4,5:1, ma gli utenti devono ancora leggere i segnaposto. Punta a un minimo di 3:1.
- Pulsanti:il testo del pulsante vs lo sfondo del pulsante deve raggiungere 4,5:1. Il bordo del pulsante vs lo sfondo della pagina deve raggiungere 3:1 (per la regola del “contrasto non testuale”).
- Indicatori di focus: il contorno del focus deve raggiungere 3:1 rispetto allo sfondo adiacente. Questa è la regola che si rompe di più quando i designer rimuovono i contorni di focus predefiniti del browser.
- Modalità scura: la formula WCAG è simmetrica; i numeri si traducono. Ma APCA è asimmetrica — la modalità scura tende a richiedere token di design leggermente diversi rispetto alla modalità chiara per la stessa qualità percepita. Non invertire semplicemente i colori.
Cosa saltare
- Non usare il contrasto come unico segnale di stato. Gli stati di errore hanno bisogno di contrasto edi un altro segnale (un’icona, del testo). Gli utenti daltonici potrebbero non distinguere gli errori rossi dai successi verdi anche ad alto contrasto.
- Non puntare ad AAA riflessivamente.Le stesse linee guida WCAG dicono che AAA “non è raccomandato come politica generale per interi siti” — è per contesti specifici. AA è il soffitto del design per la maggior parte dei prodotti.
- Non fidarti delle rampe di colore autogenerate acriticamente. Una rampa OKLCH con passi percettivi uniformi non supera automaticamente WCAG. Verifica ogni coppia adiacente.
Il flusso di lavoro pragmatico
Al momento del design: usa il controllo del contrasto WCAG nel tuo strumento di design (Figma, Sketch, Adobe XD hanno tutti plugin). Raggiungi i minimi 4,5:1 / 3:1.
Al momento del codice: lint i tuoi token di design contro WCAG conwcag-contrast o simili. Fallisci la CI sulle regressioni.
Al momento del QA: test reali con screen reader e navigazione da tastiera. Il contrasto è una piccola parte dell’accessibilità; i percorsi da tastiera e screen reader sono dove vivono la maggior parte dei bug a11y.
Esempio pratico: un colore brand che “supera”
Teal brand #3aa6a0 su sfondo bianco. Contrasto WCAG:2,99:1 — non supera AA per il testo del corpo (serve 4,5:1) e non supera di poco la soglia del 3:1 per il testo grande. Punteggio APCA: Lc 52, che APCA valuta come “usare solo per testo non contenuto o sopra i 24px.” Entrambe le metriche concordano: questo teal non supera come testo del corpo su bianco.
Scurire il teal di un passo a #2f8682: WCAG 4,52:1 (supera AA per il corpo), APCA Lc 67(supera APCA per il testo grande, marginale per il corpo). Un cambio di una cifra esadecimale sposta il componente dal fallimento al superamento — e la tonalità percepita sottostante rimane riconoscibilmente lo stesso teal. I colori brand raramente sopravvivono al contatto con l’accessibilità senza una variante per la modalità scura; costruisci la variante allo stesso tempo della palette brand, non in modo retroattivo.
Errori comuni
- Testare solo contro il bianco. Testo del corpo su un pannello colorato, testo del pulsante su un pulsante colorato, testo del link in un footer con sfondo scuro — ogni coppia ha bisogno del proprio controllo.
- Ignorare il testo sulle immagini.I titoli hero su fotografie quasi sempre falliscono da qualche parte nell’immagine. Soluzioni: una sovrapposizione scura semi-trasparente sotto il testo (abbassa l’opacità a 0,4-0,6), un’ombra di testo che crea contrasto al bordo del glifo, o il riposizionamento del testo su un pannello solido.
- Affidarsi agli stati hover per la leggibilità. Gli stili hover spesso migliorano il contrasto (più scuro all’hover) — ma lo stato di riposo è quello che l’utente legge. Se lo stato di riposo fallisce, l’hover non lo salva.
- Usare
rgba()con bassa alfa per il testo. Il testo traslucido eredita qualsiasi cosa ci sia dietro. Il contrasto calcolato dipende dallo sfondo; su uno sfondo colorato, alfa < 0,8 quasi sempre fallisce. Usa valori esadecimali opachi per il testo, riserva alfa per il chrome decorativo. - Trattare la simulazione del daltonismo come test di accessibilità. Gli strumenti di simulazione (Chrome DevTools, Stark) mostrano approssimativamente ciò che vede un utente daltonico. Non testano se il contrasto è adeguato; testano se i colori sono distinguibili. Entrambi i controlli sono necessari.
Per la meccanica dello spazio colore sottostante che la formula linearizza, vedi la nostra guida ai formati colore CSS.
Fonti: W3C WCAG 2.1 (2018) e WCAG 2.2 (2023); WCAG 3.0 Working Draft (2024); Andrew Somers, documentazione APCA-W3 e studi sugli utenti di supporto; Regola ADA Titolo III del DOJ USA sull’accessibilità web (2024); EU Accessibility Act (Direttiva 2019/882).
Frequently asked questions
- Quale rapporto di contrasto richiede WCAG 2.1 AA per il testo del corpo?
- WCAG 2.1 AA richiede un rapporto di contrasto di 4,5:1 per il testo normale (sotto 18 pt / 14 pt grassetto) e 3:1 per il testo grande (18 pt+ o 14 pt+ grassetto).
- Come calcolo il rapporto di contrasto tra due colori?
- Rapporto di contrasto = (L_chiaro + 0,05) / (L_scuro + 0,05), dove L è la luminanza relativa in sRGB lineare. Converti hex in sRGB, linearizza usando la gamma IEC 61966, poi applica la formula della luminanza prima di dividere.
- Qual è la differenza tra i livelli di contrasto WCAG AA e AAA?
- AA richiede 4,5:1 per il testo (3:1 per il testo grande) ed è il minimo legale nella maggior parte delle giurisdizioni. AAA richiede 7:1 per il testo (4,5:1 per il testo grande) ed è raccomandato per contesti di leggibilità critica come interfacce mediche o legali.
- La formula di contrasto WCAG funziona per tutti i deficit visivi?
- No — la formula WCAG 2.x è basata solo sulla luminanza e non tiene conto del daltonismo basato sulla tonalità o dei valori a basso contrasto con luminanza simile. L'algoritmo APCA (proposto per WCAG 3.0) correla meglio con la leggibilità del mondo reale.
- Esiste un colore di sfondo CSS che supera 4,5:1 sia con il testo nero che con quello bianco?
- Nessun singolo colore raggiunge 4,5:1 contro entrambi simultaneamente. Il nero (#000000) ha un rapporto di 21:1 contro il bianco e 1:1 contro sé stesso; devi scegliere un colore del primo piano per ogni sfondo e verificare con uno strumento di controllo del contrasto.
- Quando il European Accessibility Act richiede la conformità WCAG?
- Il European Accessibility Act (Direttiva 2019/882) richiedeva ai prodotti e servizi digitali coperti di soddisfare WCAG 2.1 AA entro il 28 giugno 2025, con applicazione ai nuovi contratti da quella data.
Related
Published May 16, 2026 · Last reviewed May 31, 2026