Inizia con una scelta utente e un sistema di token
Usa la preferenza di sistema come default con prefers-color-scheme. Se offri un interruttore, rendilo controllabile da tastiera, con un nome accessibile ed espone la scelta attiva programmaticamente. Dai precedenza alla selezione manuale nel contesto del browser; non promettere che segua l’utente su un altro dispositivo o in una sessione privata.
Nomina i colori per ruolo, non per aspetto: canvas, surface, text, muted text, border, link, accent, error, success, focus e disabled. Mappa ogni ruolo in entrambi i temi. Questo evita che un grigio pensato per il tema chiaro venga usato in quello scuro e rende le correzioni riutilizzabili. Il dark non è intrinsecamente più accessibile né universalmente preferito; è un’altra esperienza da rendere utilizzabile.
Documenta un ordine, ad esempio scelta salvata prima e preferenza di sistema dopo, così i team testano lo stesso risultato.
Includi hover, focus, selected, invalid, disabled, loading, empty e visited-link, non solo gli stati di default.
Misura il contrasto nel tema renderizzato
La Success Criterion 1.4.3 di WCAG 2.2 stabilisce un minimo di 4.5:1 per il testo normale e le immagini di testo, e 3:1 per il testo grande. Non arrotondare: 4.499:1 non soddisfa 4.5:1. I caratteri sottili possono apparire più deboli rispetto al loro colore calcolato, quindi usa una famiglia più solida o un margine visivo aggiuntivo.
Controlla ogni primo piano renderizzato e lo sfondo adiacente. Il testo su foto, gradienti, pannelli traslucidi o video ha sfondi variabili, quindi un singolo calcolo token non può provare la leggibilità. Usa un retro opaco, un overlay adeguato o un posizionamento diverso, quindi ispeziona ai viewport realistici.
Sotto la Success Criterion 1.4.11 di WCAG 2.1, le informazioni visive necessarie per identificare un controllo attivo, uno stato obbligatorio o una grafica significativa richiedono 3:1 rispetto ai colori adiacenti.
Abbina le modifiche cromatiche con testo, un’icona, un motivo, posizione o un altro indizio chiaro; stati di errore e selezione non dovrebbero dipendere da una tinta sottile.
Proteggi il focus da tastiera, i moduli e le variazioni di stato
Naviga con Tab in entrambi i temi. Il focus deve essere visibile su link, pulsanti, input, menu, dialog, widget personalizzati e sul controllo del tema. Non rimuovere l’outline del browser a meno che la sua sostituzione non sia stata testata su ogni superficie e stato. Un outline offset è spesso più chiaro di un alone che si fonde.
La Focus Appearance di WCAG 2.2 è un criterio AAA, non prova che un sito soddisfi AA. È però un obiettivo utile: un’area indicatrice almeno grande quanto un perimetro di 2 CSS-pixel e contrasto 3:1 tra pixel focalizzati e non focalizzati. Verifica inoltre che stati di errore, obbligatorietà, selezione e non disponibile mantengano significato.
Testa separatamente hint dell’input, valore inserito, label, testo di aiuto, testo di errore, bordo invalido, segno delle checkbox, selezione radio e stato di submit.
Per checkout o altri flussi regolamentati, usa una sandbox del provider e ottieni una revisione qualificata di accessibilità e sicurezza quando opportuno. Questa è una guida educativa, non una valutazione di conformità o sicurezza.
Gestisci immagini, asset incorporati e UI fornite dal browser
Revisiona loghi, illustrazioni, screenshot, grafici, icone e testo incorporato nelle immagini in entrambi i temi. Un logo chiaro riutilizzato può svanire e la legenda di un grafico può fallire anche quando l’HTML circostante è a posto. Fornisci un asset adatto allo scopo o uno sfondo stabile. Le immagini che trasmettono istruzioni, stato o dati devono restare comprensibili.
Dichiara il supporto per light e dark schemes, quindi stila il contenuto della pagina per il tema selezionato. La proprietà color-scheme allinea canvas del browser, barre di scorrimento, controlli di form e altra UI del browser. Inserisci i metadati corrispondenti nelle prime parti del documento. L’SVG incorporato può rispondere allo scheme del parent; testa end-to-end iframe e widget di terze parti.
Preferisci controlli HTML semantici. Il comportamento forced-color usa semantica nativa, non un ruolo ARIA aggiunto a un elemento generico.
Ispeziona stati di download, cache, caricamento lento e immagini fallite, specialmente dove testo o indizi di azione stanno sopra i media.
Rispetta forced-colors e testa il rilascio come sistema
La modalità forced-colors applica una palette limitata scelta dall’utente, come l’High Contrast di Windows. I browser possono sostituire colori, rimuovere ombre e aggiungere backplate al testo. Non bloccare l’override. Applica correzioni mirate dove un componente perde confine o significato, per esempio un bordo reale dove un’ombra forniva affordance. L’emulazione non rappresenta ogni dispositivo, browser, estensione, livello di zoom o combinazione di tecnologie assistive.
Esegui la matrice di rotte e interazioni in impostazioni light, dark e forced-colors prima del rilascio. Chrome DevTools può emulare entrambe le condizioni; usalo per accelerare la revisione, poi naviga manualmente i flussi prioritari. Gli scanner trovano candidati ma non possono determinare l’accessibilità da soli. SIU preflight dei asset e delle interazioni tematiche critiche, registra una soglia di rilascio e mantiene una strada di rollback testata per regressioni di presentazione gravi; non è monitoraggio di downtime.
Includi landing, navigazione, ricerca, accesso account, moduli, pagine di errore, schermate autenticate e flussi di conversione materiale.
Salva URL testati, versioni del browser, impostazioni, eccezioni, owner e trigger di rollback così la rimedio parte dai fatti.