/*
 * Zarboutan Matériaux — palette claire premium.
 *
 * Migration du fond noir dominant vers une identité claire, chaleureuse,
 * inspirée des showrooms bois haut de gamme. Chargée globalement (toutes
 * les pages), après le CSS dynamique de Blocksy (voir functions.php,
 * priorité d'enqueue) : les variables --theme-* redéfinies ci-dessous
 * cascadent automatiquement vers la plupart des composants du thème
 * parent et de WooCommerce qui les utilisent déjà — vérifié en direct
 * avant modification (bouton WooCommerce = --theme-palette-color-1, prix
 * = --theme-text-color) — sans qu'il soit nécessaire de réécrire ces
 * composants un par un ni de toucher au thème parent.
 *
 * Contrastes mesurés (WCAG AA, formule de luminance relative W3C, calculés
 * précisément avant intégration — voir rapport de livraison) :
 *   - Titres #23261F sur les 3 fonds clairs : 13.0 à 15.4:1
 *   - Paragraphes #40433C sur les 3 fonds clairs : 8.6 à 10.1:1
 *   - Texte secondaire #5F6259 sur les 3 fonds clairs : 5.3 à 6.2:1
 *   - Liens #237A3D sur les 3 fonds clairs : 4.55 à 5.37:1 (AA texte normal)
 *   - Hover liens #277F42 : 5.00/4.68:1 sur carte blanche et fond général
 *     (AA texte normal), 4.25:1 sur le fond de section alterné le plus
 *     sombre (AA grand texte seulement — signalé en anomalie connue)
 * Le vert de marque #39A751 seul (3.08:1 sur blanc) ne passait pas le
 * seuil AA TEXTE (4.5:1) — la justification d'origine ("conservé pour les
 * boutons, seuil non-texte 3:1 respecté") confondait à tort le critère
 * WCAG 1.4.11 (contraste non-texte : bordures/icônes contre leur fond
 * adjacent) avec le 1.4.3 (contraste de texte : le texte BLANC posé PAR-
 * DESSUS ce fond vert, sur les boutons, reste bien soumis au seuil texte
 * 4.5:1, quel que soit l'usage du fond). Corrigé (audit accessibilité,
 * 27/07/2026) : --zb-accent assombri à #2E8541, même teinte/saturation
 * HSL (même vert reconnaissable), luminosité réduite jusqu'à obtenir
 * 4.62:1 texte blanc dessus (calcul exact, formule de luminance relative
 * W3C — valeur choisie avec une marge de sécurité au-dessus du minimum
 * 4.5:1, pas au plus juste). Icônes et bordures (seuil non-texte 3:1)
 * restent conformes, cette valeur plus sombre ne fait que renforcer leur
 * contraste. --zb-accent-deep ci-dessous reste la nuance dédiée aux liens
 * texte courant, inchangée par ce correctif.
 */

:root {
	/* --- Surfaces --- */
	--zb-surface-page: #faf7f1; /* fond général, blanc cassé chaud */
	--zb-surface-alt: #f1ece3; /* sections alternées, gris-beige très clair */
	--zb-surface-card: #ffffff; /* cartes, blanc pur */
	--zb-surface-dark: #121519; /* header/footer, anthracite très foncé — identique à la couleur déjà en place sur le header (réglage Header Builder Blocksy, non modifié) */

	/* --- Textes --- */
	--zb-text-heading: #23261f; /* titres H1/H2/H3 */
	--zb-text-body: #40433c; /* paragraphes */
	--zb-text-secondary: #5f6259; /* texte secondaire / métadonnées */

	/* --- Bordures --- */
	--zb-border-subtle: #e6e0d3; /* décoratif — cartes, séparateurs (pas de seuil de contraste requis, non porteur d'information à lui seul) */
	--zb-border-strong: #8a867f; /* composant d'interface (ex. contour de bouton) : 3.39:1 sur --zb-surface-page (#faf7f1), conforme au seuil non-texte WCAG 1.4.11. Version assombrie de --zb-border-subtle (mêmes proportions R/G/B, luminosité réduite) — audit boutons, correctif contraste bordure, 27/07/2026. Ne remplace pas --zb-border-subtle, qui reste inchangé sur ses ~15 usages décoratifs existants (cartes, séparateurs) : à réserver aux bordures qui servent seules à délimiter un contrôle interactif. */

	/* --- Accent --- */
	--zb-accent: #2e8541; /* vert Zarboutan — boutons (texte blanc dessus, 4.62:1 AA), icônes, bordures. Assombri depuis #39a751 (3.08:1, non conforme) — audit accessibilité 27/07/2026, voir commentaire d'en-tête */
	--zb-accent-deep: #237a3d; /* vert lien (texte courant, seuil AA 4.5:1) */
	--zb-accent-bright: #277f42; /* vert hover lien, plus lumineux que --zb-accent-deep */

	/* --- CTA fort (bloc d'action, ex. fin de guide) --- */
	--zb-cta-bg: #163d22;
	--zb-cta-text: #ffffff;

	/* --- Redéfinition des variables Blocksy : cascade automatique vers les
	   composants (WooCommerce compris) qui les utilisent déjà, sans toucher
	   au thème parent. Le header garde ses propres réglages (rgba(18,21,25,
	   .98)), plus spécifiques que ce bloc :root et donc non affectés. --- */
	--theme-palette-color-8: var(--zb-surface-page);
	--theme-text-color: var(--zb-text-body);
	--theme-headings-color: var(--zb-text-heading);
	--theme-link-initial-color: var(--zb-accent-deep);
	--theme-link-hover-color: var(--zb-accent-bright);
	--theme-border-color: var(--zb-border-subtle);

	/* Fond des boutons génériques Blocksy/WooCommerce/Fluent Forms
	   (.button, .woocommerce button.button, .wp-element-button,
	   .fluentform .ff-el-group button.ff-btn, etc. — sélecteur natif
	   Blocksy, vérifié via l'inspecteur de styles). Non défini par défaut
	   dans ce thème enfant jusqu'ici (valeur venant du CSS compilé de
	   Blocksy, #39a751 en dur) ; réutilise --zb-accent pour que "Ajouter
	   au panier" bénéficie du même correctif de contraste que
	   .zb-cta__button--primary, depuis une seule source. Aucun style
	   Customizer live ne redéfinit cette variable en <head> (vérifié) :
	   pas de !important nécessaire, l'ordre de chargement suffit. */
	--theme-button-background-initial-color: var(--zb-accent);

	/* Vérifié via CDP (getComputedStyle) : Blocksy fixe cette variable à
	   #39A751 en dur (même vert, même problème de contraste). Elle pilote
	   deux choses à la fois dans le CSS compilé de Blocksy : (1) le contour
	   de focus clavier générique `a:focus-visible,button:focus-visible`
	   (natif à Blocksy, actif par défaut sur tout lien/bouton du site — pas
	   un correctif ajouté ici, seulement sa couleur assombrie) et (2) le
	   fond du numéro de page courant en pagination WooCommerce (texte
	   blanc dessus, même paire de contraste que les boutons CTA). La
	   redéfinir ici corrige les deux d'un coup depuis --zb-accent, sans
	   dupliquer une liste de sélecteurs. */
	--theme-palette-color-1: var(--zb-accent);
}

/* --- Footer : jusqu'ici transparent (aucune couleur propre), visible en
 * noir uniquement parce que le fond du site (body) était lui-même noir.
 * Une fois --theme-palette-color-8 éclairci, le footer doit porter sa
 * propre couleur sombre explicite pour ne pas devenir clair.
 * !important nécessaire (bug trouvé en test visuel : sans lui, le footer
 * restait clair) : le CSS dynamique de Blocksy définit
 * `[data-footer*="type-1"] .ct-footer { background-color: rgba(0,0,0,0) }`,
 * plus spécifique (sélecteur d'attribut + classe) qu'un simple `.ct-footer`,
 * et l'emportait malgré un ordre de chargement postérieur.
 *
 * --- Correction structurelle (remonte un correctif page par page devenu
 * insuffisant, voir ressources.css / commit cdf45191) : Blocksy applique
 * une image décorative directement sur <body>, globalement, sans aucune
 * portée de page :
 *   body { background-image: url(".../footer-background.jpg");
 *          background-position: 50% 100%; background-size: contain; }
 * (CSS dynamique de Blocksy, wp-content/uploads/blocksy/css/global.css,
 * régénéré par le Personnaliser — jamais modifié directement, cause
 * documentée ici plutôt que corrigée à la source pour ne pas éditer un
 * fichier généré). Cette image, ancrée à 50% 100% (bas), n'est correctement
 * confinée près du bas de page QUE si le document est nettement plus long
 * que la fenêtre visible — dès qu'une page est courte (Centre de
 * Ressources, /nos-bois/, etc.), elle remonte derrière le contenu
 * principal. Un correctif limité à une seule page (`body.page-template-
 * page-centre-de-ressources`) ne resterait donc jamais suffisant : la
 * même image a été retrouvée, via inspection directe des styles calculés,
 * identique sur /nos-bois/ (cartes "Bois Essentiel"/"Bois Premium"
 * assombries) — un problème structurel, pas propre à une page.
 *
 * Image inspectée (aperçu visuel) : texture abstraite sombre (vert très
 * foncé sur noir), déjà pensée pour un fond sombre — exactement le
 * contexte du footer, jamais celui du corps de page (devenu clair). La
 * neutraliser sur <body> et la réappliquer uniquement ici, sur le footer
 * réel (<footer id="footer" class="ct-footer">, seule zone pour laquelle
 * elle a été conçue), restaure l'usage prévu sans dépendre de la hauteur
 * de la page ni multiplier les exceptions par gabarit.
 *
 * !important nécessaire ici aussi, pour la même raison déjà démontrée par
 * `body.home` ci-dessous (pas une supposition, un fait déjà établi dans ce
 * fichier) : sur l'accueil, `zarboutan-immersive.css`/`logo-3d.css`
 * (snippet WPCode 1436, chargés côté <head> hors de la file d'attente
 * standard des styles du thème) définissent aussi `html, body { background:
 * radial-gradient(...) }` sur ce même élément <body>, à spécificité égale
 * (0,0,1) — sans !important, cette règle resterait gagnante ici comme elle
 * l'était déjà pour background-color avant le correctif body.home. */
body {
	background-image: none !important;
}

/* --- Footer repassé en fond clair (demande explicite du propriétaire,
 * 2026-07-24, confirmée après signalement que le choix ci-dessus était
 * délibéré et déjà testé AA — pas un résidu oublié). Le header n'est PAS
 * concerné (hors périmètre demandé) : il garde son propre réglage sombre
 * (Header Builder Blocksy), non affecté par ce fichier — le résultat est
 * donc désormais un header sombre au-dessus d'un footer clair.
 * Note : `--zb-bg-primary` (mentionnée dans la demande) n'existe pas dans
 * cette palette — la variable réelle du fond clair général est
 * `--zb-surface-page` (#faf7f1, voir :root ci-dessus), utilisée ici.
 * L'image de fond `footer-background.webp` est retirée : c'est une texture
 * sombre explicitement conçue pour un fond noir (voir commentaire
 * d'origine ci-dessus) — la garder sous un fond clair (image opaque,
 * background-size:cover) aurait maintenu le footer visuellement sombre et
 * annulé l'effet demandé. */
.ct-footer {
	background-color: var(--zb-surface-page) !important;
	background-image: none;
}

/* --- Texte du footer repassé en sombre pour rester lisible sur le
 * nouveau fond clair (même logique de contraste que le reste du site,
 * jamais supposée : mêmes teintes déjà vérifiées AA en tête de fichier
 * sur les fonds clairs — #23261f titres 13.0-15.4:1, #40433c texte
 * 8.6-10.1:1). Le vert de marque brut (--zb-accent, #39a751) NE PASSE PAS
 * le seuil AA texte normal sur fond clair (documenté en tête de fichier) —
 * on réutilise donc --zb-accent-deep / --zb-accent-bright, déjà la paire
 * AA-safe du reste du site, plutôt que les teintes claires precédentes
 * (#d0d0d0/#ffffff/#4fc06a) pensées pour le fond sombre disparu. */
.ct-footer,
.ct-footer p,
.ct-footer li,
.ct-footer .widget-title {
	color: var(--zb-text-body);
}

.ct-footer h1,
.ct-footer h2,
.ct-footer h3,
.ct-footer h4,
.ct-footer h5,
.ct-footer h6 {
	color: var(--zb-text-heading);
}

.ct-footer a:not(.wp-block-button__link) {
	color: var(--zb-accent-deep);
}

.ct-footer a:not(.wp-block-button__link):hover {
	color: var(--zb-accent-bright);
}

/* --- Ligne de copyright du footer, invisible sur le nouveau fond clair :
 * `rgba(255,255,255,.4)` — un blanc quasi transparent, pensé pour le fond
 * sombre disparu — vient du CSS dynamique de Blocksy (Personnaliser,
 * réglage propre à `[data-id="copyright"]`, jamais modifié directement,
 * voir plus haut dans ce fichier le même principe pour l'image de fond).
 * `--zb-text-secondary` (#5f6259) est la teinte déjà réservée dans ce
 * fichier au texte secondaire / métadonnées sur fond clair — exactement
 * l'usage d'une ligne de copyright. */
.ct-footer-copyright {
	color: var(--zb-text-secondary) !important;
}

/* --- Débordement horizontal mobile sitewide (Lot 7) : la ligne de widgets
 * du footer (4 colonnes, dont "Informations") passait de display:grid
 * (empilement natif Blocksy, colonne unique en dessous de 689.98px via sa
 * propre variable --grid-template-columns:initial) à display:flex en
 * flex-direction:row/flex-wrap:nowrap — à TOUTES les largeurs, y compris
 * mobile. Cause identifiée par inspection des règles CSS réellement
 * appliquées (CSSOM, `:matches`) : le snippet WPCode 1392 ("Widget Facebook
 * Footer Zarboutan") insère `<style>.ct-footer .ct-container:has(.zarboutan-
 * fb-footer-button){display:flex;...}</style>` sans le moindre point de
 * rupture mobile — seul le bouton lui-même est masqué sous 767px
 * (`.zarboutan-fb-footer-button{display:none}`), pas le display:flex de son
 * conteneur, qui persiste. Résultat : les 4 colonnes du footer restent
 * forcées sur une seule ligne et se compriment (flex-shrink) au lieu de
 * s'empiler, jusqu'à faire déborder le texte de la dernière colonne d'une
 * dizaine de pixels au-delà du viewport (confirmé à 390px via Chrome DevTools
 * Protocol, sur les 5 gabarits testés : accueil, /faq/, /bois-premium/, une
 * fiche produit, /boutique/ — le footer étant global, le bug est identique
 * partout). Ne jamais modifier le snippet WPCode sans autorisation explicite
 * (règle permanente du projet) : on restaure ici, en périphérie, le
 * display:grid natif de Blocksy au même point de rupture que Blocksy lui-
 * même (689.98px), scopé au seul conteneur contenant ce widget précis via
 * :has() — n'affecte aucun autre .ct-container du site.
 * !important nécessaire : la règle du snippet est injectée en <style> inline
 * dans le corps de page (contenu du widget), donc après les feuilles de
 * style du thème dans l'ordre du DOM ; à spécificité égale, elle l'emporterait
 * sinon malgré le point de rupture ciblé ici. */
@media (max-width: 689.98px) {
	footer .ct-container:has(.zarboutan-fb-footer-button),
	.ct-footer .ct-container:has(.zarboutan-fb-footer-button) {
		display: grid !important;
	}
}

/* --- Champ e-mail de la newsletter footer à 240px de haut sur mobile
 * (audit visuel post-Lot 7) : le snippet WPCode #1562 ("Zarboutan —
 * Newsletter footer + Brevo") définit `.zb-newsletter__row{display:flex}`
 * et bascule cette ligne en `flex-direction:column` sous 480px pour empiler
 * champ et bouton — mais ne réinitialise pas le `flex:1 1 240px` de
 * `.zb-newsletter__row input[type=email]`, pensé comme une LARGEUR de 240px
 * en disposition horizontale. Une fois l'axe principal du flex devenu
 * vertical (colonne), ce même 240px s'applique à la HAUTEUR : le champ
 * "Adresse e-mail" s'étire sur 240px au lieu d'environ 45px (confirmé par
 * getComputedStyle en CDP à 390px). Même point de rupture que le snippet
 * lui-même (480px) pour rester au plus près de son intention d'origine.
 * !important nécessaire pour la même raison que le correctif footer
 * ci-dessus : règle source injectée en <style> inline dans le corps de
 * page, donc après les feuilles de style du thème dans l'ordre du DOM. */
@media (max-width: 480px) {
	.zb-newsletter__row input[type="email"] {
		flex: none !important;
		height: 48px !important;
	}
}

/* --- Header repassé en fond clair (demande explicite du propriétaire,
 * 2026-07-24, suite au footer) : annule le choix ci-dessus (header rendu
 * "toujours sombre" pour éviter la transparence native de Blocksy sur le
 * fond noir disparu) — cohérence demandée avec le footer, déjà clair.
 * `--zb-bg-primary` (mentionnée dans la demande) n'existe pas dans cette
 * palette : `--zb-surface-page` (#faf7f1) est la variable réelle. */
.ct-header {
	background-color: var(--zb-surface-page) !important;
}

/* --- Second réglage distinct, découvert en vérifiant le rendu réel : le
 * correctif ci-dessus ne suffit pas sur la page d'accueil tant qu'on n'a
 * pas défilé. Cause exacte (CSSOM, règle réellement appliquée) : Blocksy
 * rend la ligne "middle" du header (logo + menu) via un ÉLÉMENT SÉPARÉ,
 * plus spécifique et donc prioritaire sur `.ct-header` seul —
 * `[data-transparent-row="yes"][data-row*="middle"]` — que son CSS
 * dynamique (Personnaliser, jamais modifié directement) met à
 * `rgba(255,255,255,0)` (transparent, pas sombre) tant que la page n'a pas
 * défilé, sur la seule page d'accueil (réglage "transparent_conditions:
 * front_page"). Résultat avant ce correctif : la photo du hero restait
 * visible À TRAVERS cette ligne, avec le texte de menu (déjà sombre,
 * inchangé) dessus — d'où l'impression de header "encore sombre"/peu
 * lisible signalée, alors que .ct-header lui-même était déjà bien clair. */
.ct-header [data-transparent-row="yes"] {
	background-color: var(--zb-surface-page) !important;
}

/* --- Régression trouvée en vérifiant le menu mobile (panneau hors-écran,
 * ouvert par le bouton hamburger) : `#offcanvas` porte aussi la classe
 * `.ct-header`, donc le fond est devenu clair par le même correctif
 * ci-dessus — mais ses liens (`--theme-link-initial-color`, réglage
 * Personnaliser du panneau hors-écran) restent blancs, pensés pour l'ancien
 * fond sombre du panneau : quasi invisibles sur le nouveau fond clair
 * (seul le lien actif, en vert, restait visible). Le lien actif et les
 * icônes sociales (déjà vertes) ne sont pas concernés. */
#offcanvas .ct-menu-link {
	color: var(--zb-text-heading) !important;
}

/* Exclut la page courante : elle a son propre vert de mise en évidence
   (déjà lisible, rgb(39,127,66) = --zb-accent-bright), à ne pas écraser
   par le correctif générique ci-dessus. */
#offcanvas li.current-menu-item > .ct-menu-link {
	color: var(--zb-accent-bright) !important;
}

/* --- En-tête d'archive Blocksy ("Page Header", ex. titre "Boutique" en
 * haut de la page boutique) : bug découvert en test visuel, pas anticipé
 * par l'audit — composant natif de Blocksy (`.hero-section[data-type]`,
 * réglage Personnaliser → En-têtes de page), fond sombre configuré côté
 * Customizer (theme_mod), indépendant de tout fichier CSS de ce thème
 * enfant. Les textes (titre, description, sous-titres) héritent déjà
 * correctement des couleurs sombres du nouveau fond clair via les
 * variables --theme-* redéfinies plus haut — seul le fond restait sombre.
 * Repli en surcharge ciblée plutôt qu'en modification des réglages
 * Customizer, pour rester dans le périmètre "CSS uniquement" de cette
 * tâche. Composant générique (potentiellement utilisé par d'autres
 * archives que la boutique) : portée volontairement globale. */
.hero-section {
	background-color: var(--zb-surface-alt) !important;
}

/* --- Cartes boutique (page Boutique) : anomalie rencontrée en test, non
 * résolue avec certitude — signalée telle quelle plutôt que masquée.
 * Une copie de ce même bloc de couleurs existe dans Réglages → Personnaliser
 * → CSS additionnel (post WordPress natif `custom_css`, ID 1573, lié au
 * thème enfant), avec !important sur chaque déclaration. Autorisation
 * explicite obtenue pour corriger ses couleurs (fond blanc, texte
 * anthracite, mêmes valeurs qu'ici et que functions.php) : correctif
 * appliqué en base de données. Cependant, le site continu à servir
 * l'ancienne version sombre après ce correctif (vérifié : base de données
 * confirmée à jour, alors que le HTML livré ne change pas) — cause exacte
 * non identifiée malgré vérification de plusieurs pistes courantes (cache
 * d'objets WordPress, cache de page nginx, réglages PHP-FPM, autres tables
 * de la base) : aucune n'a expliqué le phénomène, et un redémarrage de
 * PHP-FPM n'a pas résolu le problème non plus. Filet de sécurité ci-dessous
 * : sélecteur plus spécifique que celui du CSS additionnel bloqué (qui
 * n'ajoute qu'une seule classe), donc prioritaire quelle que soit la cause
 * du blocage, sans dépendre de sa résolution. */
.zarboutan-shop-main-cats .zarboutan-shop-card,
.zarboutan-wood-family-grid .zarboutan-family-card {
	border-color: var(--zb-border-subtle, #e6e0d3) !important;
	background: var(--zb-surface-card, #ffffff) !important;
	box-shadow: 0 16px 34px rgba(35, 38, 31, 0.08) !important;
}

.zarboutan-shop-main-cats .zarboutan-shop-card.is-featured {
	border-color: var(--zb-accent, #39a751) !important;
	box-shadow: 0 18px 44px rgba(57, 167, 81, 0.16) !important;
}

.zarboutan-shop-main-cats .zarboutan-shop-card .card-image,
.zarboutan-wood-family-grid .zarboutan-family-card .card-image {
	background: var(--zb-surface-alt, #f1ece3) !important;
	color: var(--zb-text-secondary, #5f6259) !important;
}

.zarboutan-shop-main-cats .zarboutan-shop-card h3,
.zarboutan-wood-family-grid .zarboutan-family-card h3 {
	color: var(--zb-text-heading, #23261f) !important;
}

.zarboutan-shop-main-cats .zarboutan-shop-card p,
.zarboutan-wood-family-grid .zarboutan-family-card p {
	color: var(--zb-text-body, #40433c) !important;
}

/* --- Conflit identifié sur l'accueil UNIQUEMENT (audit avant écriture) :
 * wp-content/uploads/zarboutan-3d-immersive-demo/zarboutan-immersive.css
 * (fichier du Hero, chargé par le snippet WPCode 1436, jamais modifié ici
 * conformément à la consigne) contient la règle
 * `html, body { background: #0b0d0a; color: #fff; }`. Ce fichier se charge
 * après celui-ci dans le <head> et l'emporte en cascade (même
 * spécificité, ordre de source) : sans le !important ci-dessous, le fond
 * ET le texte du corps de page resteraient sombres avec du texte blanc
 * partout après le Hero — illisible sur le nouveau fond clair. Cette
 * règle-là (fond général + couleur de texte du <body>) n'a rien à voir
 * avec les scènes 3D du Hero lui-même (.zbi-*, non concernées) : c'est un
 * filet de sécurité générique du fichier immersif, pas une partie du Hero
 * à proprement parler. Portée strictement limitée à .home pour ne modifier
 * que l'accueil, seule page où ce conflit existe (vérifié : le fichier
 * n'est chargé nulle part ailleurs). */
body.home {
	background-color: var(--zb-surface-page) !important;
	color: var(--zb-text-body) !important;
}

/* --- Contraste du Hero immersif cassé par la migration claire (audit avant
 * écriture, cause exacte confirmée par inspection des règles CSS réellement
 * appliquées) : le Hero est une exception volontaire au thème clair — il
 * reste sur une photo sombre avec voile — mais deux règles globales
 * distinctes y injectent malgré tout du texte sombre :
 *
 * 1) Le H1 (scène dépôt) et le H2 (scène terrasse) n'ont aucune classe ;
 *    Blocksy les cible directement par sélecteur d'élément dans
 *    main.min.css : `h1 { color: var(--theme-headings-color) }`. Cette
 *    variable a été légitimement redéfinie plus haut pour les titres du
 *    reste du site (fond désormais clair) — mais une déclaration explicite
 *    sur l'élément l'emporte toujours sur une couleur héritée, donc ce
 *    `h1`/`h2` globaux gagnent aussi dans le Hero, sur fond sombre.
 * 2) Le sous-titre (`<p>`, sans classe) n'a lui-même AUCUNE règle de
 *    couleur : il hérite simplement de `body.home` ci-dessus
 *    (`--zb-text-body`, gris foncé) — cohérent pour le reste du site, pas
 *    pour le Hero.
 *
 * Le bouton secondaire (`.zbi-ctas .secondary`) et le repère de scroll ont
 * été vérifiés séparément : `.secondary` est déjà blanc/bordure blanche
 * translucide (non affecté, non modifié ici) ; `.zbi-scroll-hint` EST
 * affecté par le même héritage que le sous-titre (texte "Faites défiler ↓"
 * en gris foncé, invisible).
 *
 * Correctif strictement local au Hero (`.zbi-content`, `.zbi-scroll-hint`),
 * jamais sur h1/h2/p ni sur --theme-headings-color globalement. Le voile
 * sombre existant derrière le texte (zbi-scene__sticky background:#0b0d0a
 * + scrim dégradé jusqu'à 0.92 d'opacité en bas de cadre, où vivent H1 et
 * sous-titre) a déjà été vérifié conforme AA pour du texte blanc lors de
 * son intégration initiale (~11:1 même sur un pixel clair de la photo) :
 * aucun renforcement du voile n'est nécessaire, seule la couleur du texte
 * doit être restaurée. */
.home .zbi-content h1,
.home .zbi-content h2 {
	color: #ffffff !important;
}

.home .zbi-content p {
	color: rgba(255, 255, 255, 0.88) !important;
}

.home .zbi-scroll-hint {
	color: rgba(255, 255, 255, 0.82) !important;
}

/* --- Deuxième gap du même type, trouvé en test visuel approfondi (capture
 * réelle à un point de défilement précis, après correction d'un artefact de
 * script de test lié à `html { scroll-behavior: smooth }` — voir rapport).
 * wp-content/uploads/zarboutan-webgl-logo-demo/logo-3d.css (chargé par le
 * même snippet WPCode 1436, pour le logo 3D du Hero, jamais modifié ici)
 * contient un filet de sécurité générique quasi identique :
 * `html, body { background: radial-gradient(circle at 50% 40%, #10160f 0%,
 * #050704 100%); color: #fff; }`. La partie "body" de cette règle était déjà
 * neutralisée par body.home ci-dessus (spécificité supérieure), mais PAS la
 * partie "html" : l'élément <html> lui-même gardait ce dégradé sombre comme
 * fond propre, visible en transparence dès qu'une section de contenu n'a
 * elle-même aucun fond (ex. la ligne de statistiques "Matériaux premium
 * pour vos chantiers" juste après le carrousel vertical). Portée non
 * limitée à .home : sur les autres pages, <html> n'a aucune règle de fond
 * concurrente (il hérite silencieusement de <body>), donc lui donner
 * explicitement la même couleur de fond que le corps de page est sans
 * risque et sert de filet de sécurité général.
 * background-color seul ne suffit pas : `background: radial-gradient(...)`
 * (raccourci) définit un background-IMAGE (un dégradé est toujours une
 * image de fond, jamais une couleur), qui continue de s'afficher par-dessus
 * n'importe quelle background-color sans annuler explicitement l'image —
 * vérifié : background-color seul en !important laissait le dégradé
 * visible. */
html {
	background-color: var(--zb-surface-page) !important;
	background-image: none !important;
}

/* --- Menus déroulants du header : texte quasi invisible (audit avant
 * écriture, cause exacte confirmée par inspection de main.min.css et du
 * CSS dynamique de Blocksy — pas une supposition).
 *
 * Blocksy fixe la couleur des liens de sous-menu via une variable locale,
 * scopée uniquement à ce contexte :
 *   [data-header*="type-1"] .ct-header [data-id="menu"] .sub-menu
 *   .ct-menu-link { --theme-link-initial-color: var(--theme-palette-color-8); }
 * (spécificité (0,5,0) : 5 sélecteurs de classe/attribut).
 * Cette même variable --theme-palette-color-8 a été légitimement redéfinie
 * plus haut en --zb-surface-page (blanc cassé) pour éclaircir le FOND de
 * page — Blocksy réutilise malheureusement ce même slot de palette pour la
 * couleur de TEXTE des liens de sous-menu, un usage totalement différent et
 * sans rapport. Résultat : texte quasi blanc sur fond de sous-menu blanc
 * (--theme-palette-color-4, #fff, non touché par cette migration) —
 * invisible. Le survol restait lisible (var(--theme-link-hover-color),
 * redéfinie ailleurs en vert, non affectée par ce bug précis) mais sans
 * aucun fond de survol, et l'état "lien actif" retombait sur ce même vert
 * sans distinction visuelle claire. Le focus clavier, séparément, n'avait
 * *aucun* indicateur visible : Blocksy neutralise l'outline par défaut du
 * navigateur globalement (`a:focus,button:focus{outline:none}`,
 * main.min.css) sans le remplacer par un focus-visible propre au menu.
 *
 * Correctif strictement scopé à .ct-header .sub-menu (menu mobile
 * `.mobile-menu` non concerné — structure différente, vérifié : aucun
 * `.sub-menu` n'y est présent, ses liens blancs sur fond sombre sont
 * intentionnels et restent inchangés).
 *
 * !important strictement nécessaire uniquement sur la redéfinition de
 * --theme-link-initial-color : la règle Blocksy d'origine a une
 * spécificité (0,5,0) supérieure à un sélecteur de classes simple
 * (.ct-header .sub-menu .ct-menu-link = (0,3,0)) et l'emporterait sinon,
 * même sans son propre !important. Aucun !important ailleurs : hover,
 * focus-visible et l'état actif ajoutent des propriétés (background-color,
 * outline) qu'aucune règle existante ne fixe déjà à cette spécificité. */
.ct-header .sub-menu .ct-menu-link {
	--theme-link-initial-color: var(--zb-text-heading) !important;
}

.ct-header .sub-menu li:hover > .ct-menu-link {
	background-color: rgba(57, 167, 81, 0.08);
}

.ct-header .sub-menu li[class*="current-menu-"] > .ct-menu-link {
	background-color: rgba(57, 167, 81, 0.06);
}

.ct-header .sub-menu .ct-menu-link:focus-visible {
	outline: 2px solid var(--zb-accent);
	outline-offset: -2px;
	background-color: rgba(57, 167, 81, 0.08);
}

/* --- Focus clavier sur les boutons CTA ("Demander un devis",
 * "Ajouter au panier") : correction apportée, à la vérification, par
 * rapport au diagnostic initial (audit accessibilité, 27/07/2026).
 * Contrairement à ce qui avait été conclu par un test au clavier
 * simulé imparfait (focus() scripté, qui ne déclenche pas toujours
 * :focus-visible comme une vraie touche Tab) : Blocksy fournit déjà,
 * nativement, un contour de focus générique sur tout lien/bouton du
 * site (`a:focus-visible,button:focus-visible{outline:2px solid
 * var(--theme-palette-color-1)}`, main.min.css) — reverifié ici avec
 * de vraies touches Tab simulées (Input.dispatchKeyEvent), qui confirme
 * un contour déjà visible sur ces deux boutons même sans règle ajoutée
 * ici. Le seul défaut réel : --theme-palette-color-1 valait #39A751,
 * le même vert insuffisamment contrasté en non-texte (2.6-2.9:1 sur les
 * fonds clairs, sous le seuil 3:1) — corrigé juste au-dessus en
 * redéfinissant --theme-palette-color-1: var(--zb-accent), qui suffit à
 * lui seul (aucune règle :focus-visible supplémentaire nécessaire ici). */

/* --- Harmonisation bouton "Envoyer ma demande" du formulaire de devis
 * (audit boutons, 27/07/2026) : Fluent Forms (version gratuite, aucun
 * réglage global de couleur/style de bouton disponible — vérifié dans
 * les réglages du plugin et les métadonnées du formulaire) affiche par
 * défaut son bleu de marque sur .ff-btn-submit, sans lien avec la charte
 * du site.
 * Cause racine identifiée en vérification (Étape 5) : une simple règle
 * .ff-btn-submit{background:...} ne suffit pas — Fluent Forms génère, par
 * formulaire, un <style> inline `form.fluent_form_1 .ff-btn-submit:not(.ff_btn_no_style){
 * background-color:var(--fluentform-primary)}` dont la spécificité
 * (0-3-1) l'emporte sur une simple classe (0-1-0), quel que soit l'ordre
 * de chargement des feuilles de style. --fluentform-primary est défini
 * par le plugin à :root (fluentform-public-default.css) à #1a7efb et
 * n'est utilisé que pour ce fond de bouton et la bordure de focus des
 * champs — redéfinir la variable ici (chargée après la CSS du plugin)
 * est donc le correctif root-cause : le <style> inline du plugin la
 * consomme automatiquement, sans avoir à rejouer une guerre de
 * spécificité par formulaire. La règle directe .ff-btn-submit est
 * conservée en filet de sécurité pour un éventuel autre contexte Fluent
 * Forms qui n'utiliserait pas cette variable. */
:root {
	--fluentform-primary: var(--zb-accent);
}

.ff-btn-submit {
	background: var(--zb-accent);
}

.ff-btn-submit:hover {
	background: var(--zb-accent-bright);
}