Come verificare il contrasto dei colori senza installare nulla

Le verifiche del contrasto dei colori vengono spesso trattate come un’attività specialistica di accessibilità: aprire un file di design, installare un plugin, esportare screenshot, eseguire un report, discutere sui colori del brand. Può essere utile, ma non è da lì che la maggior parte dei team dovrebbe partire.

Per un sito web in produzione, la verifica affidabile più rapida di solito si fa nel browser che hai già aperto. I moderni DevTools del browser possono ispezionare i colori calcolati, mostrare i rapporti di contrasto, rivelare gli stili di stato e aiutarti a testare i casi scomodi che i report automatizzati non rilevano.

Questa guida presuppone che tu non stia installando nulla. Nessuna estensione del browser. Nessun plugin di design. Nessuna suite di audit a pagamento. Solo la pagina, il browser e un metodo semplice.

Le regole di contrasto che ti servono davvero

Per la maggior parte del lavoro sul web, il contrasto WCAG si riduce a poche soglie:

• Testo normale: almeno 4.5:1 di contrasto rispetto allo sfondo.
• Testo grande: almeno 3:1. WCAG lo definisce come circa 24 pixel CSS, oppure circa 18,66 pixel CSS se in grassetto.
• Componenti UI e oggetti grafici: almeno 3:1 per bordi significativi, icone, stati e parti di grafici necessarie per comprendere l’interfaccia.
• Contrasto avanzato: 7:1 per il testo normale e 4.5:1 per il testo grande se punti oltre il livello di base.

Esistono eccezioni, come controlli inattivi, elementi decorativi e loghi. Usa queste eccezioni con parsimonia. “Fa parte del brand” non è un’eccezione; è un vincolo di design.

Ricorda inoltre che il contrasto è solo una parte dell’uso accessibile del colore. Se uno stato di errore rosso ha contrasto sufficiente ma non ha testo, etichetta dell’icona o indicazione programmatica, può comunque non funzionare per gli utenti che non distinguono il rosso da colori vicini.

Parti dalla pagina renderizzata, non dal file di design

I file di design sono utili, ma non includono tutte le variabili reali: override CSS, opacità, stati hover, rendering dei font nel browser, zoom utente, modalità scura, stili ereditati, contenuti CMS ed embed marketing.

Verifica la pagina così come la ricevono gli utenti.

Apri la pagina in un browser desktop aggiornato. Chrome, Edge, Firefox e Safari hanno tutti strumenti di ispezione utili. Le etichette esatte cambiano, ma il workflow è lo stesso:

1. Fai clic destro sul testo o sull’elemento UI.
2. Scegli Inspect.
3. Trova i valori calcolati di color e background-color.
4. Usa il campione colore del browser o il pannello accessibilità per leggere il rapporto di contrasto.
5. Registra esito positivo, esito negativo e incertezza.

Nei browser basati su Chromium, il selettore colore spesso mostra un rapporto di contrasto e indicazioni pass/fail WCAG per il testo. Anche Firefox DevTools espone informazioni di accessibilità e strumenti colore. Safari’s Web Inspector può mostrare stili calcolati e informazioni di accessibilità, anche se il workflow è leggermente diverso.

Il punto chiave non è il browser specifico. Il punto chiave è leggere il risultato calcolato, non il valore che qualcuno pensa venga usato dal componente.

Crea prima una piccola lista di verifica

Non ispezionare testo a caso finché non ti stanchi. Crea un breve inventario dei pattern:

• Testo del corpo sullo sfondo principale della pagina.
• Testo attenuato, didascalie, metadati e placeholder.
• Link negli stati normale, hover, visited e focus.
• Pulsanti primari, secondari e distruttivi.
• Etichette di form, testo di aiuto, errori e messaggi di successo.
• Elementi di navigazione, breadcrumb e tab.
• Card, badge, pill e tag.
• Icone che comunicano significato.
• Grafici, mappe, barre di progresso e colori di stato.
• Testo sopra immagini, video, gradienti o overlay traslucidi.

Questo basta per trovare la maggior parte dei problemi in un sito tipico. Inoltre mantiene l’audit legato ai componenti, non a pixel isolati.

Se il tuo audit include pulsanti, abbina il controllo del contrasto alle basi in la nostra checklist per pulsanti web accessibili. I problemi di contrasto dei pulsanti spesso si trovano accanto a stati di focus mancanti, etichette poco chiare o comportamento da tastiera non funzionante.

Ispeziona il contrasto del testo in DevTools

Per testo semplice su uno sfondo pieno, il browser di solito può calcolare il contrasto per te.

Ispeziona l’elemento e cerca la proprietà color. Apri il selettore colore dal campione. Se il browser riesce a determinare lo sfondo, mostrerà un rapporto di contrasto. Alcuni strumenti disegnano anche una linea nel selettore colore per indicare dove il colore supererebbe 3:1, 4.5:1 o 7:1.

Quando il browser segnala un errore, credigli finché non puoi dimostrare il contrario. Quando segnala un passaggio, usa comunque il giudizio. Caratteri piccoli e sottili, display di bassa qualità, anti-aliasing marcato e sfondi affollati possono far sembrare debole un testo tecnicamente conforme.

Una regola pratica: se il testo del corpo passa appena a 4.55:1, non festeggiare. Dagli più margine. I requisiti di contrasto sono minimi, non obiettivi ideali.

Anche la tipografia conta. Un sistema tipografico più grande e più chiaro riduce lo sforzo prima ancora di intervenire sui colori. Se la pagina sembra difficile da leggere nonostante il contrasto sia conforme, rivedi lunghezza della riga, dimensione, peso e spaziatura con una prospettiva più ampia sulla leggibilità, come in questa guida pratica alla tipografia leggibile.

Controlla lo sfondo reale, inclusa l’opacità

Molti errori di contrasto avvengono perché lo sfondo visibile non è lo sfondo dichiarato.

Trappole comuni includono:

• Testo dentro una card semitrasparente.
• Testo su un genitore con opacity applicato.
• Overlay che usano rgba() o color-mix().
• Gradienti dietro i titoli.
• Immagini di sfondo che variano nell’area del testo.
• Variabili di tema che cambiano in modalità scura.

Se DevTools non riesce a calcolare il contrasto con sicurezza, identifica manualmente i colori di primo piano e di sfondo renderizzati. Usa il pannello degli stili calcolati, disabilita temporaneamente i livelli oppure campiona il colore visibile con il selettore colore integrato, se il tuo browser lo supporta.

Per il testo sopra le immagini, non campionare la parte più favorevole dell’immagine. Campiona l’area plausibilmente peggiore dietro il testo. Se l’immagine cambia tramite upload CMS, caroselli o ritagli responsive, non è un sistema di contrasto stabile. Aggiungi un overlay affidabile, un’ombra del testo, un contenitore pieno o un trattamento a gradiente che protegga il testo indipendentemente dall’immagine.

Un buon sistema di overlay per immagini è noioso: stessa intensità dell’overlay, area di ritaglio prevedibile, contrasto sufficiente anche con foto luminose. Noioso va bene. Gli utenti stanno cercando di leggere.

Non dimenticare gli stati

Gli screenshot statici non rilevano molti problemi di contrasto. Verifica gli stati di interazione direttamente nel browser.

In DevTools, forza pseudo-classi come:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Poi ispeziona di nuovo i colori calcolati.

Gli indicatori di focus meritano un’attenzione particolare. WCAG 2.2 ha rafforzato le aspettative sull’aspetto del focus, e un contorno azzurro pallido su una card grigio chiaro è ancora un errore comune. L’indicatore di focus deve avere abbastanza contrasto rispetto ai colori adiacenti e abbastanza area da risultare percepibile.

Per i controlli disabilitati, le regole di contrasto WCAG prevedono un’eccezione per i componenti inattivi. Questo non significa che i controlli disabilitati debbano essere illeggibili per impostazione predefinita. Se lo stato disabilitato trasmette informazioni utili, rendilo leggibile. Se non le trasmette, valuta se debba essere presente del tutto.

Usa Lighthouse, ma non delegargli il giudizio

Gli audit del browser come Lighthouse possono rilevare rapidamente alcuni problemi di contrasto. Esegui l’audit integrato se il tuo browser lo offre, poi considera i risultati come un punto di partenza.

I controlli automatizzati sono bravi a trovare nodi di testo con evidenti problemi di contrasto calcolato. Sono più deboli su:

• Testo incorporato nelle immagini.
• Etichette renderizzate su canvas.
• Casi limite SVG.
• Problemi presenti solo in hover.
• Qualità dell’indicatore di focus.
• Grafici in cui le relazioni cromatiche veicolano significato.
• Componenti nascosti dietro autenticazione, menu o passaggi di form.

Se un report torna verde, devi comunque ispezionare componenti rappresentativi. Se un report torna rosso, evita il panico e organizza i problemi in base all’impatto sugli utenti. Lo stesso principio vale in generale per i report di performance e accessibilità: leggi l’output dello strumento come prova, non come verdetto. Usiamo questo approccio in la nostra guida per leggere un report Lighthouse senza farsi prendere dal panico, e si applica perfettamente anche qui.

Verifica anche il contrasto non testuale

Il testo riceve la maggior parte dell’attenzione, ma WCAG copre anche i contenuti non testuali necessari per comprendere o usare l’interfaccia.

Controlla almeno questi casi:

• Bordi degli input rispetto allo sfondo della pagina.
• Contorni di checkbox e radio.
• Stati dei toggle.
• Pulsanti solo icona.
• Icone di errore e simboli di avviso.
• Linee, barre ed etichette dei grafici.
• Indicatori di progresso.
• Tab selezionato o indicatori di navigazione attiva.

L’obiettivo è di solito 3:1 rispetto ai colori adiacenti. Per esempio, un bordo input grigio chiaro su sfondo bianco può essere quasi invisibile. Un grafico con cinque linee pastello può sembrare elegante e risultare comunque inutilizzabile.

Per i grafici, il contrasto da solo non basta. Usa etichette, pattern, stili di linea, annotazioni dirette o spaziatura in modo che l’informazione non dipenda solo dal colore. Questo aiuta utenti daltonici, utenti ipovedenti, persone che guardano lo schermo con riflessi e chiunque legga uno screenshot in un documento.

Registra i risultati in un formato utile agli sviluppatori

Un audit del contrasto utile non dice “alcuni grigi non passano”. Identifica componente, stato, valori attuali, soglia attesa e correzione suggerita.

Un formato compatto funziona bene:

| Componente | Stato | Primo piano | Sfondo | Rapporto | Obiettivo | Risultato | Correzione suggerita | |---|---:|---:|---:|---:|---:|---|---| | Metadati card | Default | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fail | Usa --color-text-muted-strong | | Pulsante primario | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Pass | Mantieni | | Bordo input | Default | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fail | Scurisci il token del bordo |

Collega le correzioni ai design token se il sito li usa. Non correggere venti componenti individuali se il vero problema è un token debole.

Rendi le correzioni leggermente più forti del minimo

I problemi di contrasto sono spesso facili da correggere male. I team spostano un colore finché il checker dice 4.51:1, poi passano oltre. Questo non lascia margine per rendering dei font, trasparenza, differenze tra browser, temi, variabilità delle immagini o future modifiche al brand.

Preferisci obiettivi confortevoli:

• Testo del corpo: più vicino a 7:1 quando pratico.
• Testo attenuato: comunque sopra 4.5:1 se è contenuto reale.
• Bordi e icone UI: comodamente sopra 3:1.
• Testo sopra immagini: usa un overlay controllato invece di valutare immagine per immagine.

Il web viene visto su laptop economici, telefoni con luminosità bassa, marciapiedi assolati, monitor con tinta alterata e display invecchiati. La conformità minima non è la stessa cosa di una lettura confortevole.

<!-- tool-cta:start -->

💡 Prova questo: Quando controlli le coppie di contrasto estratte da DevTools, Color Converter aiuta a convertire tra hex, RGB e HSL in modo che i valori corrispondano alle tue note di audit.

<!-- tool-cta:end -->

Una checklist per il contrasto senza installazioni

Usa questa sequenza quando ti serve un audit rapido ma credibile:

1. Apri la pagina di produzione in un browser moderno.
2. Elenca i principali pattern di testo, UI e stati.
3. Ispeziona i colori calcolati di primo piano e sfondo in DevTools.
4. Usa il selettore colore integrato o il pannello accessibilità per leggere il contrasto.
5. Forza gli stati hover, focus, active, visited e invalid.
6. Controlla il testo sopra immagini e gradienti rispetto allo sfondo plausibilmente peggiore.
7. Controlla le parti UI non testuali rispetto al requisito 3:1.
8. Esegui un audit automatizzato integrato come rete di sicurezza, non come intero audit.
9. Registra i problemi per componente e token.
10. Correggi con margine, non superando appena la soglia.

Questo basta per intercettare la maggior parte dei problemi di contrasto senza aggiungere un altro strumento al tuo stack. Gli audit più avanzati hanno comunque il loro posto, soprattutto per grandi design system, prodotti regolamentati o visualizzazioni dati complesse. Ma per molti siti web, il browser ti dà già le prove che ti servono. La parte difficile è essere abbastanza sistematici da usarle.