/* ==================================================================== SOCLE — la source unique des jetons et des éléments présents partout. POURQUOI CE FICHIER EXISTE Décidé le 27/08, appliqué le 28/08. Les mêmes polices, les mêmes jetons, le même pied et la même bulle WhatsApp étaient écrits SEPT fois : dans article.css et dans les six pages qui portent leur style en ligne. Le 27/08, l'un de ces jetons, --gold-deep, était déjà documenté par deux mesures contradictoires selon le fichier. Les valeurs ont été réalignées les 27 et 28, et la mesure du 28/08 ne trouve plus AUCUN écart entre les sept copies. Ce fichier ne répare donc pas une dérive : il empêche la prochaine. Un jeton qui change dans une page et pas dans les six autres ne produit aucune erreur, aucune page cassée, aucun avertissement. Il produit deux nuances d'or sur le même site, ce que personne ne remarque avant de les voir côte à côte. C'est exactement le genre de défaut que ce projet a déjà rencontré trois fois : l'empreinte de cache oubliée, le favicon fabriqué à la main, la tuile de partage tronquée. CE QU'IL NE CONTIENT PAS, ET POURQUOI Le site a TROIS familles de mise en page, mesurées le 28/08, et c'est délibéré : l'accueil (en-tête fixe transparent, conteneur à 1240 px), les pages de conseils (en-tête collant sombre, 820 px, article.css), et les pages légales (en-tête crème, 900 px). Leurs .entete, .wrap et h1 diffèrent volontairement et ne sont donc PAS ici. On a parlé un temps de « six copies quasi identiques d'un socle » : la mesure dit cinq copies identiques dans une famille, et deux mises en page assumées à côté. ORDRE DE CHARGEMENT Ce fichier se charge EN PREMIER, avant article.css et avant le style en ligne de chaque page. À spécificité égale, la dernière règle gagne : une page peut donc surcharger ce socle, jamais l'inverse. GARDE-FOU outils/verifier.py refuse la publication si un jeton porte deux valeurs différentes selon le fichier. Le contrôle a été testé sur une copie désalignée volontairement. ==================================================================== */ /* -------------------------------------------------------------------- LES SEPT POINTS DE RUPTURE DU SITE, et pourquoi ils ne sont pas unifiés. Relevé du 27/08. Ils sont bien sept, mesurés le 28/08 : les paires 700/701 et 900/901 sont des compléments, pas des doublons. 560 le bloc de preuve passe en colonne article.css 600 la bulle WhatsApp rétrécit socle.css 640 la grille des modules passe à une colonne modules.html 700 le pied passe en colonne (et 701 le complète) 760 vitrines, ressources et étapes à une colonne index.html 800 la section « qui » passe à une colonne index.html 900 la navigation bascule en menu mobile (et 901 le complète) Chacun est attaché à un contenu précis, et bascule quand CE contenu ne tient plus, pas quand un appareil théorique change de taille. Les deux seuls candidats à une fusion, 760 et 800, ne diffèrent que de 40 px : les unifier changerait le rendu entre ces deux largeurs pour retirer un nombre d'une liste. Le 28/08 a fourni le contre-exemple qui tranche : .titre-page portait 12 px sur cgv.html contre 44 ailleurs, ce qui ressemblait à une dérive. La mesure a montré que cgv est la seule page à porter une date de mise à jour sous son titre, laquelle fournit déjà les 44 px. Unifier aurait ajouté 32 px d'espace mort. Toute divergence n'est pas un défaut. -------------------------------------------------------------------- */ @font-face{font-family:'Sora';font-style:normal;font-weight:400 700;font-display:swap; src:url('polices/sora-variable.woff2') format('woff2-variations'), url('polices/sora-variable.woff2') format('woff2');} @font-face{font-family:'Source Serif 4';font-style:normal;font-weight:400 600;font-display:swap; src:url('polices/source-serif4-variable.woff2') format('woff2-variations'), url('polices/source-serif4-variable.woff2') format('woff2');} @font-face{font-family:'IBM Plex Mono';font-style:normal;font-weight:500;font-display:swap; src:url('polices/ibm-plex-mono-500.woff2') format('woff2');} :root{ --ink:#1C3548; --ink-deep:#101D27; --gold:#BE9020; --gold-dark:#CC9422; /* --gold-deep : le SEUL or admis comme couleur de texte sur fond clair. Mesure RECALCULEE le 27/08 : 4,74:1 sur creme, 5,14:1 sur off-white, 5,48:1 sur blanc. Les trois valeurs precedentes (5,43 / 5,09 / 4,70) etaient FAUSSES, surevaluees d'environ 0,45 chacune. La troisieme a servi de garantie a un lien dore sur creme qui etait en realite a 4,28:1, sous le seuil de 4,5. Teinte assombrie de #8D6B18 a #856416 pour que la regle ci-dessus redevienne vraie sur les trois fonds, plutot que d'ouvrir une exception par fond. --gold reste reserve aux aplats, filets et icones. Palette resserree le 28/08 : elle portait QUATRE ors, un de trop. Le quatrieme, --gold-text (#E8AC33), servait le texte sur fond sombre. Mesure : ses 17 emplois textuels et ses 5 emplois decoratifs tombaient TOUS sur l'encre profonde, ou --gold-dark vaut 6,38:1 pour 4,5 exige, sur un plus petit texte a 11,5 px. Il ne couvrait donc aucun cas que --gold-dark ne couvre. Supprime, avec ses trois derives rgba ecrits en dur : sans eux, l'or retire aurait survecu en douce, ce qui est exactement la derive que ce resserrement visait. Une justification a circule, et elle etait fausse : elle annoncait que l'or SOMBRE tenait le role sur les deux fonds, or --gold-deep ne vaut que 2,32:1 sur l'encre. C'est --gold-dark qui absorbe le role, et sur fond sombre seul. */ --gold-deep:#856416; --cream:#EBEFF3; --white:#FFFFFF; --off-white:#F5F8FA; --slate:#57636E; --text:#3D3A37; /* Bordure des CONTROLES de saisie, distincte de --border qui cerne les cartes. Un champ blanc dans une carte blanche separe par --border (#DBE0E5) ne donnait que 1,33:1 : sur un telephone au soleil, rien ne disait ou toucher. #7E8B96 vaut 3,49 sur blanc, 3,27 sur off-white et 3,02 sur creme, donc au-dessus du seuil de 3:1 des composants d'interface (WCAG 1.4.11) sur les trois fonds clairs du site. */ --border-fort:#7E8B96; --border:#DBE0E5; --radius-ui:3px; --radius-card:4px; --font-display:'Sora',Helvetica,Arial,sans-serif; --font-serif:'Source Serif 4',Georgia,serif; --font-mono:'IBM Plex Mono',monospace; } *{box-sizing:border-box;} a:hover{color:var(--ink);} /* ---------- Les liens dans le texte courant se soulignent ---------- */ /* Soulignement des liens en ligne, WCAG 1.4.1 niveau A, 28/08. Un lien que SEULE la couleur distingue de son voisinage doit s'en ecarter de 3:1, ou porter un second indice. MESURE AVANT CORRECTION, recalculee ici et non reprise d'un releve anterieur : --gold-deep #856416 contre --slate #57636E (le bloc RGPD du formulaire de l'accueil) : 1,12:1 ; --gold-deep contre --text #3D3A37 (le corps des pages legales) : 2,06:1. Les deux sont sous 3:1, et a:hover ne fait que changer de couleur : il n'y avait donc ni l'un ni l'autre des deux indices admis. Un lien a 1,12:1 de son voisinage n'est pas un lien, c'est du texte, et le plus couteux de tous est celui qui mene a la politique de confidentialite depuis le point de collecte. PERIMETRE MESURE, recompte dans le navigateur le 28/08 au soir sur `main p a` : accueil 4, mentions-legales 11, politique-confidentialite 4, cgv 2, merci 2, 404 2, soit 25 liens en ligne sur six pages. Le releve precedent en annoncait dix-sept sur six pages tout en n'en enumerant que cinq : les mentions legales ont gagne six liens dans la journee (licences de polices, stockage des donnees) et 404.html est nee le meme jour. La regle les couvre sans etre touchee, c'est le chiffre ecrit qui avait vieilli. Les cinq pages de conseils le faisaient deja correctement via article.css, cette regle leur donne exactement le meme rendu. POURQUOI main p a ET PAS li a Un premier releve comptait sept liens en ligne sur l'accueil. La mesure en trouve quatre : les trois autres sont les de .ressources__liste, qui sont des CARTES (display:flex, fond blanc, bordure, padding 18/20). Elles ne se distinguent pas par la couleur seule, donc 1.4.1 ne s'y applique pas, et les souligner aurait barre trois cartes. Meme cas pour ul.liste de plan-du-site et pour .liees des pages de conseils. Le critere vise le lien NOYE DANS UNE PHRASE, et c'est ce que ce selecteur designe. POURQUOI CETTE REGLE GAGNE, ALORS QUE LE SOCLE SE CHARGE EN PREMIER C'est le seul endroit du fichier ou le socle doit l'emporter sur une page. Il l'emporte par SPECIFICITE et non par ordre : main p a vaut (0,0,3) contre (0,0,1) pour le a{text-decoration:none} ecrit dans le style en ligne de l'accueil et dans legales.css. Toute regle de page portant une classe (0,1,1) reprend la main, ce qui laisse .ressources__liste a, .liees a et .retour-accueil a intacts : verifie sur toutes les pages. */ main p a{text-decoration:underline;text-underline-offset:3px;} /* ---------- La case a cocher du menu sort du parcours en bureau ---------- */ /* La case a cocher du menu prenait le focus en bureau. WCAG 2.4.7, niveau AA, 28/08. MESURE AVANT CORRECTION, sur conseils.html a 1280 px : #menu-ouvert est display:block, 1 x 1 px, opacity 0, tabIndex 0, et c'est le TROISIEME element focusable de la page, apres le lien d'evitement et le logo. Il prend le focus, et son style calcule donne alors outline-style:none et box-shadow:none. Sa seule compensation visuelle, la regle .bascule-menu:focus-visible ~ .bouton-menu, est enfermee dans @media (max-width:900px), la ou .bouton-menu est justement display:none en bureau. L'utilisateur au clavier tabulait donc vers un controle qu'AUCUN pixel ne representait, sur les cinq pages de conseils. ICI ET PAS DANS article.css, QUI EST POURTANT LE SEUL FICHIER FAUTIF La regle existait deja dans le style en ligne de l'accueil depuis le 27/08, et elle n'avait pas suivi dans article.css : c'est la regression R2 du rapport, et le mecanisme exact que ce fichier a ete ecrit pour eteindre. La reecrire dans article.css aurait recree deux copies d'une regle d'accessibilite. Ici, elle ne peut plus diverger. La copie du style en ligne de l'accueil devient redondante et pourra disparaitre avec le deplacement complet du menu dans ce fichier. */ @media (min-width:901px){.bascule-menu{display:none;}} /* R10 : le lien du logo mesurait 40 px de haut, sous les 44 px de cible tactile de la charte (section 05). Le padding agrandit la zone touchable, la marge negative annule son effet sur la mise en page : le logo ne bouge pas d'un pixel. */ .logo-lien{display:block;padding:2px 0;margin:-2px 0;} /* ---------- Lien d'evitement, identique sur toutes les pages ---------- */ /* Lien d'evitement, WCAG 2.4.1, niveau A, 28/08. Mesure AVANT correction, dans le navigateur : NEUF elements focusables a traverser sur l'accueil avant d'atteindre le h1, ONZE sur une page de conseils ouverte depuis Google (logo, case du menu, les deux boutons or de l'en-tete, cinq entrees de menu, deux liens de fil d'ariane), et cela a chaque chargement. Ces deux nombres comptent des elements focusables, pas des pages, et ont ete recomptes au navigateur le 28/08 au soir. Ici et pas dans les trois feuilles de mise en page, pour la raison qui a fait naitre ce fichier : une regle recopiee trois fois diverge un jour sans que rien ne le signale. MESURES QUI JUSTIFIENT LES VALEURS - #FFFFFF sur --ink-deep (#101D27) vaut 17,4:1, pour 4,5 exiges. - 44 px de haut : la cible tactile de la charte (section 05). Obtenus par min-height plus centrage flex, pas par un padding vertical, pour que la valeur reste vraie quelle que soit la taille de police heritee. POURQUOI UN DEPLACEMENT ET NON display:none display:none et visibility:hidden retirent l'element du parcours clavier. Un lien d'evitement ainsi cache serait inatteignable, donc exactement inverse de son but. Il est donc pousse hors du cadre et revient au focus. POURQUOI position:fixed Sur l'accueil, l'en-tete est lui-meme en position:fixed avec z-index:50. Un lien en position:absolute passerait dessous. z-index:100 le met devant sur toutes les pages. */ .evitement{position:fixed;top:0;left:0;z-index:100; display:inline-flex;align-items:center;min-height:44px;padding:0 20px; transform:translateY(-110%); background:var(--ink-deep);color:#FFFFFF;text-decoration:none; font-family:var(--font-display);font-size:15px;font-weight:500; border-radius:0 0 var(--radius-ui) 0;} .evitement:focus{transform:translateY(0);} /* Le a:hover global de ce fichier repeindrait le lien en --ink sur son propre fond d'encre profonde, soit 1,4:1. */ .evitement:hover,.evitement:focus{color:#FFFFFF;} /* Le contenu principal porte tabindex="-1" : sans lui, Safari deplace la vue mais laisse le focus clavier sur le lien, et la tabulation suivante repart du haut de l'en-tete. L'anneau est retire parce que la cible n'est pas une commande mais une region entiere : un cadre autour de toute la page se lirait comme un defaut d'affichage, pas comme une indication. */ main[tabindex="-1"]:focus{outline:none;} /* ---------- Pied de page, identique sur toutes les pages ---------- */ .pied__logo{height:26px;width:auto;opacity:.85;} .pied__liens{display:flex;flex-wrap:wrap;gap:20px;} /* R10, exception assumee et ecrite le 28/08. Ces quatre liens font 17 px de haut, sous les 44 px de cible tactile de la charte (section 05). Mesure : le pas vertical est de 25 px sur mobile (17 de hauteur, 8 de gouttiere), donc le critere WCAG 2.5.8 de niveau AA, qui demande 24 px ou un espacement equivalent, est tenu. Les porter a 44 px allongeait le pied de 84 px sur mobile, sur toutes les pages, pour des liens legaux que personne n'ouvre dans l'urgence. Le prix a payer est nomme : la charte porte desormais une exception a la regle des 44 px, la deuxieme apres celle de l'or du logotype. Toute cible qui sert a AGIR (bouton, appel a l'action, menu, logo) reste tenue aux 44 px. UN SEUL CAS Y ECHAPPE ENCORE, mesure le 28/08 dans le navigateur a 1280 px : le bouton « Me contacter » de l'en-tete de l'accueil, a 38,4 px. Il tient WCAG 2.5.8 par l'exception d'espacement. Le porter a 44 px change la hauteur visible du bouton principal de l'en-tete : c'est un choix de mise en page, pas une correction, et il reste a trancher. */ .pied__liens a{font-size:13px;color:rgba(244,248,251,.55);} .pied__liens a:hover{color:#FFFFFF;} .pied__copyright{font-size:12px;color:rgba(244,248,251,.62);} /* ---------- Bulle WhatsApp flottante ---------- */ /* Portee sur toutes les pages le 27/08, et 404.html l'a recue a sa creation le lendemain : la bulle est bien sur les douze. Elle n'existait que sur l'accueil, alors que c'est le seul canal qui ne depend ni du formulaire ni de l'hebergeur, et qu'une page de conseils ou les CGV se lisent autant que l'accueil. */ .whatsapp-flottant{position:fixed;right:22px;bottom:22px;width:58px;height:58px;border-radius:50%; background:#25D366;display:flex;align-items:center;justify-content:center; box-shadow:0 10px 28px -8px rgba(16,29,39,.45);z-index:40;} .whatsapp-flottant:hover{background:#1EBE59;} .whatsapp-flottant svg{width:28px;height:28px;color:#FFFFFF;} @media (max-width:600px){ .whatsapp-flottant{right:16px;bottom:16px;width:52px;height:52px;} .whatsapp-flottant svg{width:25px;height:25px;} } /* ---------- Bandeau de consentement a la mesure d'audience ---------- */ /* Pose le 28/08 avec Google Analytics. Le mecanisme est dans mesure.js, qui est le seul a construire ces elements : ils n'existent dans aucune des douze pages, et rien ne s'affiche sans JavaScript. POURQUOI ICI ET PAS DANS LES PAGES Le bandeau vit sur les DOUZE pages, donc dans le seul fichier que les douze chargent. Le recopier dans les trois familles de mise en page (accueil, conseils, legales) aurait fabrique trois bandeaux qui divergeraient : c'est le motif meme de l'existence de ce fichier. MESURES DE CONTRASTE, CALCULEES LE 28/08 SUR LES COUPLES REELS - #F4F8FB sur --ink-deep (#101D27), le texte du bandeau : 16,03:1. - --ink-deep sur --gold (#BE9020), le texte des deux boutons : 5,87:1, pour 4,5 exiges. Le meme couple est deja celui de tous les boutons or du site. - --gold sur --ink-deep, le bouton contre son fond : 5,87:1 aussi, donc au-dessus des 3:1 que WCAG 1.4.11 demande a un composant d'interface. - --gold-dark (#CC9422) sur --ink-deep, le lien du texte : 6,38:1, la valeur deja retenue pour l'or de texte sur fond sombre. L'anneau de focus est BLANC avec outline-offset:3px : mesure a 2,92:1 contre l'or, ce qui serait insuffisant, mais le decalage de 3 px le pose sur l'encre profonde, ou il vaut 17:1. C'est le decalage qui rend le contraste, pas la couleur : ne pas retirer l'offset. */ .bandeau-mesure{position:fixed;left:0;right:0;bottom:0;z-index:60; background:var(--ink-deep);border-top:3px solid var(--gold); box-shadow:0 -12px 30px -14px rgba(16,29,39,.65);} /* 1240 px : la largeur du conteneur de l'accueil. Le bandeau traverse trois familles de mise en page dont les conteneurs valent 1240, 900 et 820 px ; il prend la plus large, sinon il paraitrait etrangle sur l'accueil. */ .bandeau-mesure__inner{max-width:1240px;margin:0 auto; padding:18px clamp(24px,5vw,72px); display:flex;flex-wrap:wrap;align-items:center; justify-content:space-between;gap:14px 32px;} .bandeau-mesure__dire{flex:1 1 380px;display:flex;flex-direction:column;gap:6px;} .bandeau-mesure__titre{margin:0;font-family:var(--font-display); font-size:15px;font-weight:700;color:#FFFFFF;} .bandeau-mesure__texte{margin:0;font-family:var(--font-serif); font-size:14.5px;line-height:1.6;color:#F4F8FB;} /* Souligne, et pas seulement colore : c'est le critere WCAG 1.4.1 deja applique aux liens du texte courant plus haut dans ce fichier. */ .bandeau-mesure__texte a{color:var(--gold-dark); text-decoration:underline;text-underline-offset:3px;} .bandeau-mesure__texte a:hover{color:#FFFFFF;} .bandeau-mesure__actions{display:flex;flex-wrap:wrap;gap:12px;} /* LES DEUX BOUTONS PARTAGENT CETTE SEULE REGLE, ET C'EST DELIBERE. La CNIL demande que refuser soit aussi simple qu'accepter : meme niveau, meme visibilite. Une seule classe pour les deux rend la divergence impossible, y compris par une retouche distraite. Ne jamais ajouter de variante --secondaire ici : ce serait le defaut que la CNIL sanctionne. 44 px de haut et 150 px de large : la cible tactile de la charte (section 05), tenue par min-height plutot que par un padding vertical, pour rester vraie quelle que soit la taille de police heritee. */ .bandeau-mesure__bouton{flex:1 1 150px;min-width:150px;min-height:44px; display:inline-flex;align-items:center;justify-content:center; padding:0 24px;border:0;border-radius:var(--radius-ui); background:var(--gold);color:var(--ink-deep); font-family:var(--font-display);font-size:15px;font-weight:500; cursor:pointer;} .bandeau-mesure__bouton:hover{background:var(--gold-dark);color:var(--ink-deep);} .bandeau-mesure__bouton:focus-visible{outline:2px solid #FFFFFF;outline-offset:3px;} /* Visible des lecteurs d'ecran, invisible a l'oeil. Redeclaree ici et non reprise de .sr-only : cette regle doit vivre dans le fichier que les douze pages chargent, or .sr-only n'est ecrite que dans article.css et dans le style en ligne de trois pages legales. */ .bandeau-mesure__annonce{position:absolute;width:1px;height:1px;padding:0; margin:-1px;overflow:hidden;clip:rect(0 0 0 0);white-space:nowrap;border:0;} /* La bulle WhatsApp remonte de la hauteur exacte du bandeau, publiee par mesure.js en variable CSS. Sans cette regle, le bandeau (z-index 60) recouvrait la bulle (z-index 40) sur les douze pages tant qu'aucun choix n'etait fait : le seul canal de contact qui ne depende ni du formulaire ni de l'hebergeur devenait inatteignable pour qui ignore le bandeau. Le repli a 0px sert au cas ou la variable n'est pas encore posee. */ .a-bandeau .whatsapp-flottant{bottom:calc(22px + var(--hauteur-bandeau,0px));} /* ---------- Retour sur le choix, dans la politique de confidentialite ---------- */ /* Meme fichier que le bandeau parce que c'est le meme mecanisme : le bouton qui retire le consentement et celui qui le donne doivent se ressembler, sinon le retrait a l'air d'un parent pauvre. Il n'existe que sur une page, mais le separer de son bandeau les ferait diverger. */ .reglage-mesure{display:inline-flex;align-items:center;justify-content:center; min-height:44px;padding:0 24px;border:0;border-radius:var(--radius-ui); background:var(--gold);color:var(--ink-deep); font-family:var(--font-display);font-size:15px;font-weight:500; cursor:pointer;margin-top:6px;} .reglage-mesure:hover{background:var(--gold-dark);color:var(--ink-deep);} .reglage-mesure:focus-visible{outline:2px solid var(--gold-deep);outline-offset:3px;} @media (max-width:600px){ .bandeau-mesure__inner{padding:16px;} /* Les deux boutons prennent toute la largeur et restent cote a cote, a largeur egale. Les empiler donnerait au premier une position dominante que la CNIL lit comme une inegalite entre accepter et refuser. ROW-REVERSE, POSE LE 29/08 : sur telephone, « Accepter » passe A DROITE, dans la zone que le pouce atteint sans deplacer la main. C'est aussi la convention des deux systemes mobiles, qui placent l'action de confirmation a droite. Sur ecran large la regle ne s'applique pas et « Accepter » reste a gauche, ou aucune zone de pouce n'existe. CE QUE CETTE INVERSION COUTE, et le sens choisi n'est pas indifferent : l'ordre visuel cesse de suivre l'ordre du document, donc la tabulation atteint « Accepter » alors que l'oeil voit « Refuser » en premier. Le document porte [Accepter, Refuser] et c'est ici qu'on inverse, PLUTOT que l'inverse, pour que ce decalage tombe sur telephone, ou la navigation au clavier est rare, et non sur ordinateur ou elle est courante. Les deux boutons restant identiques en taille, en couleur et en niveau, la position ne cree aucune inegalite au sens de la CNIL. */ .bandeau-mesure__actions{width:100%;flex-direction:row-reverse;} .bandeau-mesure__bouton{flex:1 1 0;min-width:0;padding:0 12px;} .a-bandeau .whatsapp-flottant{bottom:calc(16px + var(--hauteur-bandeau,0px));} }