/* Theme Name: Divi Enfant — La Ferme du Petit Sud Theme URI: https://lafermedupetitsud.fr Description: Thème enfant de Divi. Reçoit le code et le CSS propres au site, pour qu'ils survivent aux mises à jour du thème parent. Author: Ferreiro Studio Template: Divi Version: 1.1.0 Text Domain: divi-child */ /* -------------------------------------------------------------------------- Compteur du panier dans le menu — 21/08/2026 Divi rend : Articles 2 Le mot et le nombre sont dans le MÊME nœud de texte : le CSS ne peut pas garder l'un sans l'autre. On l'assagit donc au lieu de le réécrire — pas de JavaScript, rien qui puisse casser au rafraîchissement du panier. Aucune couleur n'est modifiée : règle du chantier (tailles, espacements, rayons). -------------------------------------------------------------------------- */ .et_pb_menu__cart-count{ font-size: .72em; /* nettement plus petit que les entrées du menu */ font-weight: 400; /* ne concurrence plus les liens */ margin-left: .3em; /* collé à l'icône, plutôt que flottant */ white-space: nowrap; /* « Articles 2 » ne se coupe jamais en deux lignes */ vertical-align: middle; } /* Témoin de contrôle : sa présence dans le CSS servi prouve que la feuille du thème enfant est bien chargée — vérification impossible autrement, CSS Combine fusionnant toutes les feuilles. Ne pas retirer sans le remplacer par une autre preuve. */ .lfps-temoin-theme-enfant{--lfps-enfant:"actif"} /* ============================================================================= VIGNETTES PRODUIT — surface cliquable et anneau de focus Accompagne le BLOC 5 de functions.php (23/08/2026, revu le meme jour). 🔴 CE QUE LA PREMIERE VERSION AVAIT FAUX Elle posait position:relative sur le module et comptait sur ::after{inset:0} pour couvrir la vignette. Mesure : sur 89 liens poses sur 89, le pseudo-element se calait en realite sur une enveloppe INTERNE de Divi (.et_pb_blurb_content, .et_pb_heading_container), qui porte deja position:relative dans la feuille du theme. La zone etendue etait donc reduite a la ligne du titre, tandis que l anneau de focus, lui, se dessinait autour du module entier : l indication annoncait une zone cliquable plus grande que la vraie. Une indication qui ment est pire que pas d indication. ➜ Le JS neutralise desormais ces enveloppes lui-meme (data-lfps-statique), et SEULEMENT quand aucun enfant absolu ne s y appuie. Quand il ne peut pas le faire sans risque, il ne pose pas data-lfps-etendu : la vignette reste cliquable au clavier par son titre, sans zone etendue et sans anneau menteur. C est la limite, elle est ecrite plutot que masquee. ========================================================================== */ /* Enveloppes que le JS a juge sûr de neutraliser. ⚠️ CETTE REGLE NE SUFFIT PAS, et c est mesure : .et_pb_blurb_content porte position:relative depuis la feuille DYNAMIQUE de Divi (et-divi-dynamic-*.css), qui a la meme specificite (0,1,0) mais est chargee APRES celle du theme enfant. Elle gagne donc. Le JS pose en plus un style EN LIGNE, qui bat toute feuille, puis RELIT le resultat : s il n est pas static, il annule tout et renonce a etendre. Cette regle-ci ne subsiste que comme trace lisible dans l inspecteur. Ne pas la supprimer, ne pas s y fier seule. */ [data-lfps-statique] { position: static; } [data-lfps-lien="pose"][data-lfps-etendu] { /* Contexte de positionnement de la zone etendue. Pose UNIQUEMENT sur les modules ou l extension a ete jugee sans danger. */ position: relative; } .lfps-lien-vignette { /* Le lien ne doit pas se voir : il remplace le contenu du titre, qui garde son apparence. On herite au lieu d imposer, pour que les presets Divi continuent de gouverner la typographie. */ color: inherit; font: inherit; text-decoration: inherit; } [data-lfps-etendu] .lfps-lien-vignette::after { /* Etend la zone de clic a toute la vignette. Sur du contenu sans autre element interactif — garanti par la garde 1 du BLOC 5 — cette zone ne peut masquer aucun lien concurrent. */ content: ""; position: absolute; inset: 0; } /* L ANNEAU DE FOCUS EPOUSE LA ZONE REELLEMENT CLIQUABLE, jamais une autre. Vignette etendue -> anneau sur la vignette. Vignette non etendue -> anneau sur le texte du lien, qui est alors la seule zone cliquable au clavier. */ [data-lfps-lien="pose"][data-lfps-etendu]:has(.lfps-lien-vignette:focus-visible) { outline: 2px solid currentColor; outline-offset: 4px; } [data-lfps-lien="pose"]:not([data-lfps-etendu]) .lfps-lien-vignette:focus-visible { outline: 2px solid currentColor; outline-offset: 4px; } /* Repli pour les navigateurs sans :has() — l anneau se dessine alors autour du texte seul. Moins bon, mais present : un focus imparfait vaut infiniment mieux qu un focus absent. */ @supports not (selector(:has(*))) { .lfps-lien-vignette:focus-visible { outline: 2px solid currentColor; outline-offset: 4px; } } /* currentColor suit la couleur du texte du titre : l anneau reste contraste sur toute surface ou le titre l est deja. A verifier neanmoins en navigateur reel sur les sections a fond image — la revue du 23/08 ne l a pas exerce. */ /* Le curseur indiquait deja la cliquabilite via .et_clickable de Divi ; on ne le redeclare pas, pour ne pas entrer en concurrence avec ses regles. */ /* ============================================================================= ANNEAU DE FOCUS GLOBAL — le repere clavier sur TOUT le site 23/08/2026 LE DEFAUT, MESURE DANS LE CSS SERVI EN PRODUCTION Divi pose `:focus{outline:0}` — une regle globale qui supprime l anneau du navigateur sur tous les elements, et ne le remplace pas. Consequence : une personne qui navigue au clavier ne sait jamais ou elle se trouve. C est un manquement au critere WCAG 2.4.7 (Focus Visible), niveau AA. Constate le 23/08 sur ce site : seuls les champs de la lettre d information montraient un repere, parce qu ils portent leur propre style ; et les vignettes produit, parce que le BLOC 5 le redeclare explicitement. Tout le reste — menu, boutons, liens, panier, fil d Ariane — n en avait aucun. POURQUOI :focus-visible ET NON :focus `:focus` s applique aussi au clic de souris : un anneau apparaitrait sur chaque bouton clique. Personne ne supporte ca, et la regle finit desactivee dans la semaine — le standard le dit. `:focus-visible` ne se declenche que quand le navigateur juge le repere utile : clavier, navigation vocale, pas la souris. POURQUOI CETTE SPECIFICITE, ET PAS :where() `:focus{outline:0}` vaut (0,1,0). Une regle en `:where()` vaut (0,0,0) et PERDRAIT — d autant que la feuille du theme enfant est chargee AVANT celle de Divi (mesure du 23/08). On nomme donc les elements interactifs, ce qui donne (0,1,1) ou (0,2,0) : suffisant pour gagner, sans surenchere ni !important. POURQUOI DEUX COUCHES DE COULEUR Un anneau d une seule couleur disparait des qu il rencontre un fond de la meme teinte, et ce site a des sections claires, sombres et des images de fond. Le trait est double d un halo clair, ce qui couvre la grande majorite des surfaces : 602 elements sur 632 mesures obtiennent l anneau. LA COULEUR EST CELLE DE LA CHARTE — #675122, la variable primaire du site (--gcid-primary-color). Choisie le 23/08 apres mesure : elle donne 7,56:1 sur blanc et 6,12:1 sur les gris clairs, tres au-dessus du seuil de 3:1 exige pour un indicateur de focus (WCAG 1.4.11). L orange envisage d abord a ete ecarte par la mesure, pas par gout : l orange vif tombe a 2,90:1 sur les gris clairs et 1,19:1 sur le vert de la charte — invisible la ou il faut le voir. ⚠️ CE N EST PAS UNE GARANTIE UNIVERSELLE — LA LIMITE, ECRITE PLUTOT QUE TUE. Une premiere version de ce commentaire affirmait que « l un des deux contraste toujours ». C est FAUX, et mesure : dans la visionneuse d images de WooCommerce (PhotoSwipe), le plugin impose son propre box-shadow en !important, le halo disparait, et le trait #675122 sur fond noir tombe a 1,12:1 — invisible, sur 24 boutons. Ce n est pas une regression (il n y avait rien avant), mais la promesse ne tient pas la. Corriger cela demanderait de lutter contre le !important d une extension tierce dans un composant qu on ne maitrise pas : le remede serait plus fragile que le mal. La limite est donc bornee ici. ========================================================================== */ :is(a, button, input, select, textarea, summary, [tabindex], [role="button"], [role="link"], [role="tab"], [role="menuitem"]):not(.lfps-lien-vignette):focus-visible { /* 2px : le minimum que WCAG 2.4.13 (AAA) juge encore perceptible. On ne descend pas en dessous — un trait d 1px disparait sur un ecran dense et sur les bordures deja presentes. Affine le 23/08 a la demande de Ramon : 3px etait juste, mais lourd sur les petits elements de menu. 🔴 LE DECALAGE, PAS DU PADDING. Sur un lien de menu, la boite epouse le texte : le trait arrivait collé en haut. La tentation est d ajouter du padding — ce serait une FAUTE : le padding agrandit reellement l element, donc decale le menu et tout ce qui l entoure, en permanence, pour un effet qui ne doit apparaitre qu au focus. outline-offset ecarte le trait sans toucher a la mise en page : rien ne bouge jamais. */ outline: 2px solid #675122; outline-offset: 4px; /* Halo clair : garantit la visibilite du trait sur fond sombre. */ box-shadow: 0 0 0 4px rgba(255, 255, 255, 0.95); /* L anneau ne doit pas passer sous un element voisin. */ position: relative; z-index: 10; } /* Les vignettes du BLOC 5 sont EXCLUES a la source par le :not() de la regle ci-dessus, et non annulees apres coup. 🔴 La version du 23/08 n annulait que box-shadow : le trait, lui, restait, et chaque vignette recevait DEUX anneaux imbriques — 400x602 pour le module, 183x25 autour du titre. Mesure par tabulations reelles sur /produits/epicerie/sucre/, ~89 liens concernes en production. Annuler apres coup obligeait a deviner tout ce que la regle avait pose ; exclure a la source ne laisse rien a oublier. */ /* Repli pour les navigateurs sans :focus-visible — l anneau apparait alors aussi au clic. Moins confortable, mais present. Aucun navigateur courant n est concerne depuis 2022 ; la regle est la pour les anciens. */ @supports not (selector(:focus-visible)) { :is(a, button, input, select, textarea, summary, [tabindex]):focus { outline: 2px solid #675122; outline-offset: 4px; } } /* ============================================================================= TEXTES DESTINES AUX LECTEURS D ECRAN — masques a l oeil, PAS a l oreille 24/08/2026 LE DEFAUT, MESURE SUR LES 137 PAGES Deux fautes bloquantes remontaient de l audit : · champ de recherche sans etiquette 9 occurrences, 9 pages (regle « label ») · lien sans intitule 14 occurrences, 7 pages (regle « link-name ») MEME CAUSE POUR LES DEUX, trouvee dans la feuille servie : .wp-block-search__label { display:none } l etiquette « Rechercher » .et-pb-arrow-prev span { display:none } le mot « Precedent » des fleches Le texte EXISTE dans le HTML — l etiquette est meme correctement reliee au champ par son attribut for. Mais `display:none` ne masque pas seulement a l oeil : il retire l element de l ARBRE D ACCESSIBILITE. Pour un lecteur d ecran, ce texte n existe plus du tout. Le champ n a donc plus de nom, et le lien non plus. 🔴 LA CLASSE, ET NON LES DEUX OCCURRENCES Cinq selecteurs de la feuille servie font la meme chose, plus les fleches de Divi. Les corriger un a un ferait revenir le defaut par la porte suivante : on nomme donc la famille — « du texte de service masque par display:none » — et on la traite d un bloc. LA TECHNIQUE : masquage VISUEL, pas suppression. L element garde une surface d un pixel, hors flux, decoupee a zero. Il reste dans l arbre d accessibilite, donc annonce, mais invisible et sans effet sur la mise en page. C est la methode standard, celle que WordPress lui-meme emploie sous le nom « screen-reader-text ». ⚠️ CE QU IL NE FAUT PAS FAIRE A LA PLACE Ni `visibility:hidden` ni `opacity:0` : le premier retire aussi de l arbre d accessibilite, le second laisse l element occuper sa place et capter les clics. Ni `font-size:0` : le texte reste selectionnable et le rendu varie selon les navigateurs. ========================================================================== */ .et_pb_widget .wp-block-search__label, .widget_search .screen-reader-text, .et_password_protected_form label, .et-pb-arrow-prev span, .et-pb-arrow-next span, .tinv-wishlist .tinv-lists-nav a.tinv-prev > span, .tinv-wishlist .tinv-lists-nav a.tinv-next > span { /* !important — ⚠️ RECTIFICATION. J avais ecrit que les feuilles de Divi etaient chargees APRES celle du theme enfant. C est FAUX, et mesure le 24/08 : l enfant charge en 448k contre Divi 179k/252k/374k, et en 201k contre Divi en ligne 16k/44k sur les pages non optimisees. L enfant passe donc APRES et gagnerait sans !important dans ces cas. Il est neanmoins conserve : la feuille « wp-block-search-inline-css » du coeur de WordPress, elle, est bien chargee apres nous. Mesure, pas suppose. */ position: absolute !important; display: block !important; width: 1px !important; height: 1px !important; padding: 0 !important; margin: -1px !important; overflow: hidden !important; clip: rect(0, 0, 0, 0) !important; clip-path: inset(50%) !important; white-space: nowrap !important; border: 0 !important; } /* Si l un de ces textes peut recevoir le focus au clavier, il doit REDEVENIR visible a ce moment-la : sinon le curseur disparait sur un element invisible. Aucun des selecteurs ci-dessus n est focalisable aujourd hui (176 tabulations mesurees, aucune n y tombe), mais la regle protege les ajouts futurs — et elle remet TOUTES les proprietes, pas seulement la position : une revelation a moitie faite laisserait un texte tronque et illisible. ⚠️ Elle couvre aussi le cas du lien d evitement : WordPress prevoit `.screen-reader-text:focus{clip:auto}` pour le reveler, et notre !important le battrait sans cette regle. */ .et_pb_widget .wp-block-search__label:focus, .et_password_protected_form label:focus { position: static !important; display: inline-block !important; width: auto !important; height: auto !important; padding: .25em .5em !important; margin: 0 !important; overflow: visible !important; clip: auto !important; clip-path: none !important; white-space: normal !important; border: 1px solid currentColor !important; } /* ============================================================================= BOUTON « RECHERCHER » DU WIDGET — contraste 25/08/2026 LE DEFAUT, MESURE SUR 9 PAGES Le bouton du bloc de recherche de WordPress, place dans la barre laterale des articles, affiche du gris #666 sur un fond #ddd : **4,23:1**, sous le seuil de 4,5:1 exige pour un texte courant (WCAG 1.4.3, niveau AA). La couleur vient d une regle de Divi : .widget_search input#s, .widget_search input#searchsubmit, .et_pb_widget … { color:#666 } Le bloc de recherche, lui, est du coeur de WordPress : aucun reglage de Divi ni de Rank Math ne permet de le corriger. C est donc du CSS, faute de mieux. POURQUOI LE BRUN DE LA CHARTE #675122 est la couleur primaire du site (--gcid-primary-color), celle des liens et des titres. Elle donne **5,57:1** sur ce fond — conforme avec de la marge — et le bouton cesse d etre un gris anonyme pour rejoindre l identite du site. Un gris plus fonce (#444, 7,17:1) aurait aussi marche, mais sans rien apporter. ⚠️ PORTEE VOLONTAIREMENT ETROITE : seulement le bouton du bloc de recherche, dans un widget. Ni les champs, ni les autres boutons du site ne sont touches. ========================================================================== */ .et_pb_widget .wp-block-search__button, .widget_block .wp-block-search__button { color: #675122; }