/* ============================================================================= scatole.com — DIREZIONE "BIANCO CANDIDO" · 05 · QUALITA' TRASVERSALE ----------------------------------------------------------------------------- Si carica PER ULTIMO, dopo 00/01/02/03/04. Non ha una zona del sito da vestire: raccoglie quello che vale ovunque e i difetti che non appartengono a nessuna delle altre tre zone. 1 lo scorrimento appiccicato, sbloccato (difetto del TEMA) 2 il contrasto, misurato e corretto dove non arriva alla soglia 3 l'anello di messa a fuoco, visibile su fondo chiaro E su fondo scuro 4 i bersagli da toccare col dito 5 la voce "sei qui" nel filtro delle categorie 6 una toppa a scadenza (il titolo in italiano) 7 movimento 8 immagini che spostano il layout, e i 16 px di scorrimento orizzontale 9 cosa ho guardato e NON ho fatto, e perche' REGOLA CHE MI SONO DATO Nessun colore letterale: solo gettoni di 00-fondamenta. Dove un gettone non bastava l'ho scritto nel commento invece di inventarne uno. COME SONO STATI PRESI I NUMERI — conta, perche' tre volte mi hanno mentito. Ogni rapporto di contrasto e' calcolato sul colore effettivamente reso in pagina, ricostruendo il fondo risalendo la catena degli antenati e componendo le trasparenze. Tre trappole, tutte incontrate davvero: 1. LA SCHEDA IN SECONDO PIANO. Se la finestra del browser non e' in primo piano, Chrome smette di ricalcolare gli stili e `getComputedStyle` restituisce valori vecchi. Mi ha fatto vedere il prezzo scelto "bianco su bianco" per mezz'ora. Cura: ogni pagina letta due volte a distanza, e i casi gravi riconfermati con uno scatto dello schermo. 2. IL CONTENUTO CHE ARRIVA DOPO. La matrice dei prezzi si disegna da sola via AJAX: letta troppo presto, da' numeri che non esistono. Tenuto solo cio' che si confermava in entrambe le letture. 3. I VELI CHE IL CALCOLO NON VEDE. Il fondo di un testo puo' essere una fotografia o uno pseudo-elemento semitrasparente sopra il colore. Il calcolo legge solo `background-color` e non li vede: su /about-us/ mi ha dato 1,05:1 su un titolo che in realta' fa 4,8:1. Ogni correzione di questo foglio e' stata ricontrollata una per una contro questa trappola (capitolo 2c del vecchio impianto, ora documentato nel capitolo 2). ========================================================================== */ /* ============================================================================= 1 · LO SCORRIMENTO APPICCICATO, SBLOCCATO ----------------------------------------------------------------------------- IL DIFETTO Sulla scheda prodotto il tema carica wp-content/themes/porto/css/theme/shop/single-product/sticky_info.css che comincia esattamente cosi': div#main { overflow: hidden } Su quelle pagine `#main` E' `div.column1.boxed` (misurato: 2545 x 6827 px). Un elemento con `overflow: hidden` diventa il contenitore di scorrimento di riferimento per tutto quello che ha dentro: da quel momento nessun discendente puo' piu' usare `position: sticky`, perche' il riferimento rispetto a cui dovrebbe appiccicarsi non scorre mai. Il file si chiama sticky_info.css. Sono queste le cose che nessuno trova. PERCHE' IL TEMA L'HA MESSO — non e' un capriccio Nello stesso file, poche righe piu' sotto: .woocommerce-tabs::after, .woocommerce-tabs::before { width: 30vw } .woocommerce-tabs::before { right: 100% } .woocommerce-tabs::after { left: 100% } due fasce larghe 30vw che sporgono di proposito a destra e a sinistra del contenuto. Senza un ritaglio la pagina scorrerebbe in orizzontale. Il ritaglio serve davvero: non si puo' togliere e basta. LA CORREZIONE, E PERCHE' SONO DUE PROPRIETA' E NON UNA `overflow: clip` ritaglia esattamente come `hidden` ma NON crea un contenitore di scorrimento: le fasce restano tagliate e `sticky` torna a vivere. Pero' `clip` — a differenza di `hidden` — non stabilisce un contesto di formattazione a blocchi, e il margine inferiore dell'ultimo figlio smette di essere contenuto. MISURATO: con `hidden` la colonna e' alta 6827 px; con il solo `clip` diventa 6779 px, 48 px in meno. L'altezza totale della pagina non cambia (7387 px in entrambi i casi: il margine si limita a uscire dalla scatola), ma la scatola dipinge il proprio fondo bianco e sarebbe 48 px piu' corta. `display: flow-root` ristabilisce il contesto a blocchi senza creare un contenitore di scorrimento. E' la meta' mancante, e con lei il conto torna. VERIFICATO PRIMA DI LASCIARLO, sulla scheda prodotto: altezza colonna 6827 px -> 6827 px identica altezza pagina 7387 px -> 7387 px identica larghezza pagina 2545 px = larghezza visibile 2545 px (nessuno scorrimento orizzontale nuovo) antenato che bloccava lo sticky: nessuno `.column1` e' `display: block` di suo, quindi `flow-root` e' un cambio neutro. `.column1.boxed` esiste SOLO sulle schede prodotto: controllate a una a una home, categoria, prodotto, carrello, cassa, area cliente, faq, chi siamo, contatti, negozio — tutte le altre hanno `.column1 wide clearfix` con `overflow: visible`. Nessun'altra parte del sito viene toccata. ========================================================================== */ #main.column1.boxed { overflow: clip; /* stesso ritaglio di `hidden`, senza il contenitore di scorrimento che disattivava `sticky` */ display: flow-root; /* restituisce il contenimento dei margini che `hidden` dava e `clip` da solo non da' */ } /* --- IL RIEPILOGO CHE SEGUE LO SCORRIMENTO: NON VA TOCCATO ----------------- Avevo scritto qui una regola che rendeva appiccicata da CSS la colonna del riepilogo, e l'avevo pure vista funzionare nel banco di prova. L'ho tolta, e questo e' il motivo — leggerlo prima di riscriverla. QUELLA COLONNA E' GIA' APPICCICATA, e non da CSS. Misurato sulla pagina vera: la colonna porta le classi elementor-sticky elementor-sticky--active elementor-sticky--effects e uno stile in linea `position: fixed; top: 0`. E' l'effetto "Sticky" di Elementor Pro, che lavora in JavaScript con `position: fixed`. Il `position: fixed` NON e' toccato da `overflow: hidden` di un antenato: ecco perche' funzionava anche prima della correzione qui sopra. COME LAVORA ELEMENTOR, e perche' la mia regola gli faceva male. Quando pinza la colonna, Elementor lascia al suo posto un CLONE invisibile (`elementor-sticky__spacer`, `visibility: hidden`) che tiene occupato lo spazio e, soprattutto, dice all'effetto DOVE FINIRE. Misurato: quel clone e' alto 6.228 px. La mia regola gli applicava `align-self: start` e `max-height`, e lo faceva crollare a **716 px**: 5.512 px in meno. Il riepilogo si sarebbe staccato cinquemila pixel prima del dovuto, cioe' avrei rotto una cosa che funziona per "aggiustarla". spacer senza la mia regola 6228 px spacer con la mia regola 716 px (-5512) Numeri presi sulla pagina, non dedotti. DI CONSEGUENZA — e vale anche per chi legge dopo di me: sulla scheda prodotto NON si aggiunge `position: sticky` da CSS a quella colonna. Se il comportamento va cambiato (per esempio dare un margine dal bordo alto invece di `top: 0`), si cambia nell'impostazione Sticky del widget dentro Elementor, non qui. E ALLORA A COSA SERVE `overflow: clip` QUI SOPRA? Serve lo stesso, ma per una ragione piu' onesta di quella che credevo: toglie una trappola. Oggi sulla scheda prodotto nessuno usa `position: sticky` da CSS — e se qualcuno provasse, non funzionerebbe e non capirebbe perche'. Costa zero (geometria identica al pixel, verificata qui sopra) e disinnesca il problema per chiunque venga dopo. ========================================================================== */ /* ============================================================================= 2 · CONTRASTO ----------------------------------------------------------------------------- Soglie: 4,5:1 per il testo normale, 3:1 per il testo grande (>= 24 px, oppure >= 18,7 px con peso >= 700). WCAG 2.1 AA. ========================================================================== */ /* --- 2a · --sc-ink-4 SUI GRIGI CHIARI: 4,37:1 ------------------------------- PICCOLA CRONACA, perche' spiega perche' questo capitolo e' cosi' corto. Quando ho cominciato, 00-fondamenta dichiarava --sc-ink-4: #79828D; etichette circa 4,5:1 AA (min 14px) e la misura vera era **3,90:1** su bianco: sotto soglia dappertutto, con una ventina di occorrenze bocciate per pagina prodotto. Avevo scritto sei regole per promuoverle a --sc-ink-3. Mentre lavoravo, chi possiede 00-fondamenta ha corretto il gettone a **#6B747F**. Rimisurato: **4,74:1** su bianco. Passa. Quelle sei regole sono diventate inutili e le ho tolte tutte: un foglio pieno di correzioni che non correggono piu' niente e' peggio di un foglio corto, perche' il giorno in cui qualcuno cambia il disegno se le trova contro senza capire da dove arrivano. COSA RESTA DAVVERO FUORI SOGLIA #6B747F non ce la fa sui grigi chiari della tavolozza, che non sono bianco: su --sc-fondo #FFFFFF 4,74:1 passa su --sc-pannello #FBFBFC 4,62:1 passa su --sc-incasso #F4F6F7 **4,37:1** BOCCIA su --sc-rilievo #EDF0F2 **4,19:1** BOCCIA Il CSS non puo' sapere su che fondo si posera' un colore, quindi correggo i due punti misurati e passo il resto a chi possiede il gettone. --sc-ink-3 (#616A75) misurato: 5,49:1 su bianco, 5,07:1 su --sc-incasso, 4,85:1 su --sc-rilievo. Sta sopra soglia su tutti e quattro. DA PORTARE IN 00-fondamenta: --sc-ink-4 va bene sul bianco e non va bene sui due grigi; o si scurisce ancora, o si scrive nel commento che sotto --sc-incasso e --sc-rilievo va usato --sc-ink-3. Non e' una decisione mia. (Nella stessa riga: --sc-ink-3 e' dato per "circa 6,0:1" ma misura 5,49:1. Passa comunque, quindi e' solo il commento a essere impreciso.) */ /* "26 AGOSTO" nelle celle non scelte della matrice consegne: --sc-ink-4 su --sc-incasso, 4,37:1 -> 5,07:1. La forma del selettore ricalca quella di 02-prodotto (`thead`, `span:last-child`) perche' la prima stesura, piu' corta, perdeva: valeva 1-5-3 contro 1-5-5 e il colore non cambiava. Verificato in pagina. */ body.single-product #main .dd_quantity_table thead th.dd_date div.dd_col:not(.selected) span:last-child { color: var(--sc-ink-3); } /* --- 2b · IL SELETTORE DI LINGUA — quattro pastiglie, due problemi diversi -- Sono `EN FR IT ES`, 41x25 px l'una, a 10,5 px, nella barra alta di ogni pagina. Misurate una per una: EN (`.gt-current-lang`) bianco su --sc-mar (#2F8C98) **3,94:1** FR IT ES --sc-ink-4 su --sc-incasso **4,37:1** La prima e' la violazione che 00-fondamenta ha gia' previsto e battezzato: --sc-mar-pieno-ok-da: 19px; sotto questa misura, niente fondo pieno perche' il bianco su --sc-mar fa 3,94:1 — basta per il testo grande (soglia 3:1), non per il testo normale (4,5:1). A 10,5 px siamo lontanissimi dai 19 px. Su --sc-mar-vivo (#226E78) il bianco fa **5,88:1**: cambio il FONDO, non il testo, cosi' la pastiglia resta una pastiglia petrolio e il disegno non si muove. Le altre tre sono il caso 2a: --sc-ink-4 su un grigio. ERRORE CHE AVEVO FATTO E CHE HO CORRETTO — vale la pena leggerlo. La prima stesura diceva `.gtranslate_wrapper a.glink { color: bianco }` senza distinguere. Avrebbe reso bianche anche FR, IT ed ES, che stanno su fondo CHIARO: da 4,37:1 a 1,08:1, cioe' tre pastiglie invisibili al posto di una poco leggibile. Un peggioramento netto, spacciato per correzione. Le due condizioni vanno separate, e ogni riga qui dentro ha accanto la sua misura proprio per non ricascarci. `#header` all'inizio non e' decorazione: 04-rifiniture scrive `#header .gtranslate_wrapper a.glink`, che vale 1-2-1. Senza l'id le mie regole valevano 0-3-1 e perdevano — provate, misurate, e infatti non cambiavano niente. */ #header .gtranslate_wrapper a.glink.gt-current-lang { background-color: var(--sc-mar-vivo); /* col bianco sopra: 5,88:1 */ color: var(--sc-mar-ombra); } #header .gtranslate_wrapper a.glink:not(.gt-current-lang) { color: var(--sc-ink-3); /* su --sc-incasso: 5,07:1 */ } /* gli dentro le pastiglie non devono decidere per conto loro */ #header .gtranslate_wrapper a.glink * { color: inherit; } /* --- 2c · COSE CHE ERANO ROTTE E SI SONO SISTEMATE DA SOLE ------------------ Le lascio scritte perche' chi rilegge sappia che sono state misurate e non dimenticate, e perche' se tornano si sa gia' dove guardare. Tutte misurate di nuovo alla fine, senza il mio foglio caricato: "Configure a box" (eroe home) era 3,94:1 -> ora 8,38:1 (fondo passato a --sc-mar-scuro da chi possiede l'eroe) "FAQ - HELP CENTRE" (barra alta) era 3,94:1 -> ora 8,38:1 (idem) span.wcpa_option_price, 20 per pagina prodotto era 3,90:1 -> ora 4,74:1 (gettone --sc-ink-4 corretto in 00-fondamenta) "Quantity" (matrice) era 3,90:1 -> ora 4,74:1 (idem) .sc-eroe__prova, le tre prove era 3,90:1 -> ora 4,74:1 (idem) voci del menu del telefono erano 1,03:1 (bianco su bianco!) -> ora 5,88:1 (corretto in 01-base) pannello dati aziendali nel piede erano 1,12:1 (scuro su scuro) -> ora leggibile (corretto in 01-base) Avevo una regola pronta per ognuna. Nessuna e' rimasta: se il proprietario della zona ha gia' sistemato, il mio compito e' togliere la mia, non lasciarla li' a litigare. */ /* --- 2f · LA BARRA "PROJECT QUOTATION": 1,49:1 ------------------------------ Sulla scheda prodotto la seconda fisarmonica del riepilogo ha la barra del titolo a fondo petrolio pieno con sopra il testo petrolio scuro: **1,49:1**, praticamente illeggibile. Si vede a occhio nudo, ed e' il riquadro del PREVENTIVO: il numero che il cliente e' venuto a cercare. NON E' COLPA DI UN FILE SOLO — e' il punto d'incontro fra due: 04-rifiniture: details.e-n-accordion-item + details.e-n-accordion-item > summary { background-color: var(--sc-mar) } (la seconda fisarmonica viene messa in evidenza col pieno) 02-prodotto: .e-n-accordion-item-title-text { color: var(--sc-mar-testo) } (il titolo e' petrolio scuro, giusto sul fondo BIANCO che quel foglio si aspettava) Ognuna delle due, da sola, e' sensata. Insieme fanno petrolio su petrolio. E' esattamente il tipo di difetto che non appartiene a nessuno dei due proprietari, quindi lo chiudo qui, dove i due fogli sono gia' passati entrambi. Fondo a --sc-mar-vivo e testo bianco: **5,88:1**. L'evidenza voluta da 04-rifiniture resta — la barra e' ancora piena e ancora petrolio — cambia solo di un tono, quanto basta perche' si legga. */ body.single-product #main details.e-n-accordion-item + details.e-n-accordion-item > summary { background-color: var(--sc-mar-vivo); } body.single-product #main details.e-n-accordion-item + details.e-n-accordion-item > summary .e-n-accordion-item-title-text, body.single-product #main details.e-n-accordion-item + details.e-n-accordion-item > summary .e-n-accordion-item-title-icon { color: var(--sc-mar-ombra); } /* l'icona a sinistra del titolo e' disegnata con una maschera: si colora col fondo, non col testo. Senza questa riga resterebbe petrolio su petrolio mentre la scritta accanto e' gia' diventata bianca. */ body.single-product #main details.e-n-accordion-item + details.e-n-accordion-item > summary .e-n-accordion-item-title-text::before { background-color: var(--sc-mar-ombra); } /* --- 2d · IL TITOLONE DI /about-us/ — REGOLA SCRITTA E POI TOLTA ------------ Lascio il buco documentato perche' e' il pezzo piu' istruttivo di questo foglio, e perche' se un domani qualcuno rifa' la stessa misura arrivi qui invece di rifare l'errore. "Great BRANDS deserve great PACKAGING!" su /about-us/ e' bianco, 37 px, grassetto 900, e il mio calcolo dava **1,05:1**: bianco su --sc-carta (#FAFAF8). Avevo gia' scritto la regola che lo riportava a --sc-ink. E' UN FALSO POSITIVO DEL MIO METODO DI MISURA. Il mio calcolo ricostruisce il fondo risalendo gli antenati e leggendo `background-color`. Non vede due cose: le immagini di sfondo e i veli messi su uno pseudo-elemento. Qui c'e' un velo: 01-base mette su `.elementor-element-909827f::after` un gradiente di --sc-ink al 62% -> 42% con `inset: 0` e `z-index: -1`, cioe' fra il fondo della fascia e il contenuto. Il bianco non sta su #FAFAF8: sta su #FAFAF8 gia' scurito dal velo. RIMISURATO tenendo conto del velo: nel punto dove il titolo finisce davvero — misurato: occupa il 21% iniziale della larghezza della fascia a 1400 px — il velo e' fra il 62% e il 52% di opacita', e il bianco fa **4,8:1**. Passa AA, e passa con margine anche per il testo normale. A 390 px il velo diventa uniforme (58% -> 50%): bianco a 4,8:1 - 3,7:1 su un titolo di 28 px in grassetto 900, cioe' testo grande, soglia 3:1. Passa anche li'. Chi ha scritto 01-base l'aveva previsto e l'aveva scritto nel commento: "nessuno strumento di contrasto lo vede, perche' il fondo e' un'immagine e non un colore". Aveva ragione, e la mia regola avrebbe messo un titolo nero su un fondo scuro — cioe' avrebbe rotto una cosa che funzionava. Niente regola. Per gli altri punti corretti in questo capitolo ho ripetuto la verifica dei veli uno per uno: nessuno ne aveva. */ /* --- 2e · a.template — ASSICURAZIONE, oggi non colpisce nessuno ------------- Il kit Elementor (post-2168.css: e' il "Default Kit", non il CSS di un'altra pagina, ed e' caricato su OGNI pagina perche' e' il kit globale) contiene nel suo CSS personalizzato: .template { background-color: var(--e-global-color-9dba6b6); ... } a.template { color: #FFF !important } Cercata su tutte le pagine pubbliche: **oggi quella classe non e' su nessun elemento**, quindi il difetto e' dormiente, non attivo. Ma la coppia e' fragile in due modi: se il fondo non arriva resta bianco su bianco, e anche quando arriva, il bianco su #2F8C98 a 15 px fa 3,94:1, sotto soglia. Due righe perche' se qualcuno rimette quella classe nasca gia' leggibile. */ a.template, .template { background-color: var(--sc-mar-vivo); color: var(--sc-mar-ombra); } /* ============================================================================= 3 · L'ANELLO DI MESSA A FUOCO ----------------------------------------------------------------------------- 00-fondamenta ne dichiara gia' uno: :where(a, button, input, select, textarea, summary, [tabindex]):focus-visible ma `:where()` azzera la specificita', quindi quella regola vale (0,1,0) ed e' l'ultima della fila in ogni discussione. Nel sito ci sono **86 regole** che spengono l'outline (Instagram feed, plyr, photoswipe, wcpa, page-scroll, tippy). Verificato sulla scheda prodotto: nessuna di quelle 86 combacia con i 104 elementi raggiungibili col tabulatore di QUELLA pagina, quindi oggi l'anello regge. Regge per fortuna, pero', non per costruzione: basta che qualcuno metta un carosello Instagram in una pagina e sparisce. MA IL PROBLEMA VERO NON ERA QUELLO, ED E' MOLTO PEGGIO. Provando con il tasto Tab vero — non con `.focus()` da script, che in Chrome non attiva `:focus-visible` — sono finito su un collegamento e ho letto: :focus-visible = true outline-style = none Cercando chi lo spegneva, in `wp-content/themes/porto/css/theme.css`: body a { outline: none !important } Non e' dentro `:focus`, non e' dentro un widget: e' su OGNI collegamento del sito, sempre, con `!important`. Batte la regola di 00-fondamenta, batte la mia scritta normalmente, batte qualunque cosa non abbia `!important`. Risultato misurato: **chi naviga da tastiera non vede dove si trova su nessun collegamento di nessuna pagina del sito**. E' una violazione secca del criterio 2.4.7 di WCAG, ed e' anche il motivo per cui la mia prima analisi non l'aveva trovata: cercavo regole che contenessero `:focus`, e questa non ne ha. Per questo — e SOLO per questo blocco — uso `!important`. Non e' un modo di scrivere che mi piace, ma qui l'alternativa e' modificare il tema, che non e' mio, oppure lasciare il sito senza indicatore di messa a fuoco. Riscrivo anche con specificita' vera (`:is()` invece di `:where()`) e su un elenco piu' largo: mancavano [role=button], [role=link], [role=tab], details, [contenteditable] e i tabindex positivi. L'ALTRA META' DEL PROBLEMA E' IL COLORE L'anello di 00-fondamenta e' --sc-mar-testo (#226E78). Su bianco fa 5,88:1 ed e' ottimo; sulla fascia petrolio della barra alta (#2F8C98) fa 1,49:1 e sulla fascia scura del piede (#1A555E) fa 1,40:1 — cioe' proprio sui fondi colorati sparisce l'unico indicatore che ha chi naviga da tastiera. Soluzione a due tinte, che non ha bisogno di sapere in anticipo cosa c'e' sotto: - un anello scuro (--sc-ink) staccato di 2 px - un anello chiaro (--sc-mar-ombra) di 2 px che riempie lo stacco Su fondo chiaro si legge quello scuro (19:1); su fondo scuro si legge quello chiaro (8,4:1 sul piede, 5,3:1 sulla barra alta). Uno dei due c'e' sempre. NON metto `position: relative` per far uscire l'anello dai contenitori che ritagliano: ci avevo pensato, ma su un elemento gia' `position: absolute` quel `relative` lo rimetterebbe nel flusso e spaccherebbe il layout proprio nel momento in cui viene messo a fuoco. Meglio un anello ogni tanto tagliato che una pagina che salta. ========================================================================== */ :is( a[href], area[href], button, input:not([type="hidden"]), select, textarea, summary, details, iframe, [tabindex]:not([tabindex^="-"]), [role="button"], [role="link"], [role="tab"], [role="menuitem"], [role="checkbox"], [role="radio"], [role="switch"], [role="option"], [contenteditable="true"] ):focus-visible { /* `!important` malvolentieri, e solo qui: vedi il riquadro qui sopra. E' l'unico modo di battere `body a { outline: none !important }` del tema senza modificare il tema. */ outline: 3px solid var(--sc-ink) !important; outline-offset: 2px !important; box-shadow: 0 0 0 2px var(--sc-mar-ombra) !important; } /* Le 86 regole che spengono l'outline lo fanno quasi sempre su `:focus`, che comprende anche `:focus-visible`. Le riaccendo dove riguardano elementi veri. Non tocco `:focus` da solo: il click col mouse NON deve disegnare l'anello, ed e' esattamente il motivo per cui esiste `:focus-visible`. */ #sb_instagram :is(a, button):focus-visible, .plyr :is(button, input, a):focus-visible, .pswp :is(button, a):focus-visible, .wcpa_wrap :is(input, select, textarea):focus-visible, .dce-scrollify-pagination .nav__item:focus-visible { outline: 3px solid var(--sc-ink) !important; outline-offset: 2px !important; box-shadow: 0 0 0 2px var(--sc-mar-ombra) !important; } /* I radio e le caselle del configuratore sono 18x18 px e stanno dentro una