Comment utiliser les tokens de couleur sémantiques

Votre marque utilise le vert. Le bouton principal est vert, le message de réussite est vert et l’élément de navigation sélectionné est vert. Tout paraît coordonné jusqu’à ce que la marque passe au violet. Une importation réussie doit-elle aussi devenir violette ? Et le contour de focus ou l’avertissement près d’un compte arrivant à expiration ?

Les tokens de couleur sémantiques rendent ces décisions explicites. Un token primitif nomme une valeur de couleur, comme green-700. Un token sémantique nomme sa fonction, comme action-primary-background ou status-success-text. Les composants font référence à cette fonction pour qu’une évolution de marque puisse changer les rôles prévus sans modifier accidentellement chaque utilisation d’une nuance similaire.

Partez de l’erreur à éviter

Imaginez un espace de travail avec un bouton « Créer un projet », une confirmation « Enregistré », un message d’erreur et un lien sélectionné dans la barre latérale. Le designer initial a choisi le même vert sombre pour le bouton, la confirmation et le lien sélectionné. Un développeur a raisonnablement stocké cette valeur une seule fois et l’a réutilisée. Une nouvelle direction de marque demande maintenant une autre couleur principale.

Modifier la variable verte commune met à jour les trois éléments. L’implémentation respecte le code initial, mais la décision est mauvaise : la confirmation était verte pour exprimer une réussite, pas pour représenter l’action principale de la marque. Cette distinction existait dans la tête du designer sans avoir atteint les règles réutilisables.

Avant d’ajouter des tokens, écrivez cette distinction simplement. « L’action principale suit la marque du produit. Les retours de réussite conservent leur sens de statut. La sélection demande un état actif clair. » Ces phrases valent davantage qu’un point de départ fondé sur une convention de nommage : elles indiquent quelles valeurs peuvent évoluer ensemble sans risque.

Comment Atlassian rend les rôles visibles dans l’interface

Les recommandations de couleur d’Atlassian associent un tableau Jira à des tokens de sélection, de texte et de fond de bouton de marque. Leur vocabulaire distingue les rôles de couleur du niveau d’accentuation et de l’état d’interaction. Il sépare aussi sélection et focus clavier : un élément sélectionné doit conserver son traitement lorsque l’indicateur de focus s’ajoute.

Remarquez pourquoi une interface annotée est plus utile qu’une palette seule. Un échantillon indique sa valeur. Le tableau montre quelle partie de l’expérience doit utiliser cette valeur et pourquoi. Vous pouvez vérifier si le libellé vise du texte, une surface ou une icône, plutôt que déduire l’usage de la saturation apparente.

Pour un petit système, reprenez cette habitude avant tout l’inventaire de noms. Placez le token proposé à côté d’un usage réel, décrivez ce qui le ferait changer et montrez un usage qu’il ne doit pas contrôler. « Action de marque » et « opération réussie » peuvent commencer avec le même vert tout en restant des décisions indépendantes. Si votre correspondance ne permet pas cette distinction, elle stocke une palette plutôt que la sémantique de l’interface.

Rendez le test de dépendance concret

Une petite table d’alias suffit à révéler l’erreur. Dans cet exemple, réussite et action principale commencent avec la même valeur, mais renvoient à des rôles distincts :

:root {
  --palette-green-700: #236646;
  --palette-purple-700: #6439a8;
  --action-primary-bg: var(--palette-green-700);
  --action-primary-fg: #fff;
  --status-success-text: var(--palette-green-700);
}
[data-brand="purple"] {
  --action-primary-bg: var(--palette-purple-700);
}

Changer l’attribut de marque doit modifier les éléments qui utilisent --action-primary-bg. Cela ne doit pas changer un libellé de réussite utilisant --status-success-text. Si les deux changent, examinez les références réelles des composants avant de choisir une autre nuance. Si aucun ne change, cherchez une couleur codée en dur ou une règle plus spécifique. C’est un test de dépendance ; les valeurs d’exemple exigent encore une vérification du contraste dans leurs contextes réels.

Testez ensuite le premier plan avec le fond. La surface d’une action et son libellé forment une paire. Modifier seulement la surface peut rendre illisible un texte auparavant lisible, surtout lorsqu’une marque claire remplace une marque sombre. Documentez le rôle associé dans la correspondance, afin que changer l’un déclenche une revue de l’autre sans compter sur la mémoire du réviseur.

Vérifiez la migration en trois passages :

1. Conservez les valeurs. Introduisez les alias et comparez au rendu de référence. Des différences inattendues suggèrent des erreurs d’association.
2. Changez temporairement un rôle. Examinez tous ses consommateurs prévus, y compris les éléments qui doivent rester inchangés.
3. Restaurez le thème validé. Examinez les combinaisons de survol, focus, désactivation et sélection. Consignez les valeurs brutes délibérées séparément du travail de migration inachevé.

Séparez valeurs, rôles et décisions de composants

Un petit système peut commencer par deux couches. La couche des valeurs contient les couleurs réelles. La couche des rôles les associe aux fonctions de l’interface. Une troisième couche propre aux composants est utile lorsqu’un composant doit évoluer indépendamment, mais elle n’est pas obligatoire pour chaque petit projet.

Par exemple, neutral-950 peut contenir votre neutre le plus sombre. text-primary et border-strong peuvent tous deux y faire référence au départ. Ils restent des rôles distincts, car améliorer la lisibilité du texte courant ne doit pas nécessairement assombrir toutes les bordures fortes. Des valeurs identiques aujourd’hui ne prouvent pas que deux décisions doivent partager un nom pour toujours.

L’erreur inverse consiste à créer un token unique pour chaque élément visible. Si tous les paragraphes courants remplissent le même rôle, attribuer un token de texte à chacun ajoute de la maintenance sans sens supplémentaire. Une question utile : voudrions-nous un jour modifier volontairement l’un de ces usages sans modifier l’autre ? Si oui, envisagez des rôles distincts. Sinon, réutilisez le rôle existant.

Les noms doivent aider à choisir sans ouvrir tous les composants. Un développeur cherchant une bordure d’erreur de champ ne doit pas deviner si accent-strong, special-red ou brand-secondary signifie danger. Préférez un rôle compréhensible à une abréviation astucieuse, surtout si ce contexte sert aussi à un agent de programmation.

Associez les couleurs sémantiques aux rôles de l’interface

Commencez par examiner une page représentative dans plusieurs états. Une capture statique du tableau de bord par défaut ne révélera ni actions désactivées, ni validation, ni focus clavier, ni élément de menu sélectionné. Il vous faut assez d’états pour découvrir les vraies fonctions des couleurs, pas tous les états théoriques qu’une grande organisation pourrait un jour prendre en charge.

Pour l’espace fictif, la première correspondance peut couvrir fond de page, surface surélevée, texte principal, texte secondaire, bordure ordinaire, action principale, texte sur cette action, sélection, focus, réussite, avertissement et erreur. Certains rôles demandent une paire premier plan/fond. Une surface de réussite pâle et son texte sombre sont des valeurs différentes au service d’un but commun.

La première revue est un exercice d’association. Marquez chaque couleur visible sur la page et demandez ce qu’elle communique. Si un panneau vert pâle regroupe simplement des commandes liées, il relève d’une surface ou d’un regroupement. S’il annonce une opération réussie, il relève d’un retour de statut. Ces usages peuvent se ressembler, mais leur évolution doit suivre des règles différentes.

Gardez la description écrite près du nom du token. « Fond de l’action principale : l’action disponible la plus importante d’une section » est plus utile que « vert ». Ajoutez un contre-exemple si la confusion est probable : le token ne désigne pas « tout élément que nous voulons faire remarquer ». Une erreur importante a toujours besoin du traitement de retour approprié.

Simulez un changement de marque avant de vous engager

Voici un exemple volontairement petit. L’espace commence avec une action de marque verte et un retour de réussite vert. Plus tard, la couleur d’action passe à une autre teinte de marque. Vous voulez que le bouton et le traitement de navigation sélectionnée suivent la nouvelle direction, tandis que « Enregistré » conserve son rôle reconnaissable de réussite.

Identifiez d’abord les rôles touchés par la décision de marque. Le fond du bouton et son texte de premier plan doivent être examinés ensemble. La sélection peut utiliser une surface ou un indicateur distinct dérivé de la marque. Le logo est une ressource de marque, pas un token de bouton ordinaire. Ne le recolorez pas par une règle générale d’interface sans tenir compte de ses propres exigences.

Modifiez ensuite les associations de rôles dans une copie de la page. Ne recherchez pas chaque occurrence de l’ancien code hexadécimal pour la remplacer sans distinction. Une recherche de valeur brute aide à trouver des candidats, mais ne dit pas si une occurrence représente un lien, une réussite ou un détail d’illustration.

Enfin, examinez tous les éléments qui utilisent les rôles modifiés. L’action principale peut apparaître sur une page blanche, un panneau pâle et dans une boîte de dialogue. Un nouveau fond fort dans un contexte peut disparaître dans un autre. Le changement est complet seulement si les usages prévus communiquent encore la bonne action et restent lisibles.

Définissez les états sans créer une couleur pour tout

L’apparence par défaut d’une action n’est qu’une partie de son comportement. Survol, pression, focus, sélection et désactivation peuvent exprimer des choses différentes. Un élément de navigation peut rester sélectionné tout en recevant le focus clavier. Un bouton peut recevoir le focus sans être pressé. Ne réduisez pas toutes ces conditions à une seule couleur « active ».

Partez de l’information à communiquer pour chaque état. Le survol indique une relation avec le pointeur. Le focus dit à la personne au clavier où l’interaction aura lieu. La sélection identifie un choix persistant. Les traitements peuvent partager des ingrédients, mais doivent rester distinguables lorsque les états coexistent. Bordure, soulignement, icône ou forme peuvent porter une partie du message.

Pour la barre latérale d’exemple, vous pouvez utiliser un fond de sélection subtil et un contour de focus clair. Le contour ne doit pas disparaître simplement parce que l’élément est déjà sélectionné. Examinez directement cette combinaison. Des échantillons isolés ne montrent pas si les traitements se gênent dans le vrai composant.

Le style désactivé mérite autant de soin. Une action désactivée demande une explication lorsque la personne ne peut pas déduire pourquoi elle est indisponible. Griser un bouton ne dit pas si un champ obligatoire manque, si un droit est absent ou si une opération est déjà en cours. Un token nomme un rôle visuel ; il ne remplace ni logique d’interaction ni texte explicatif.

Gardez les exceptions de composants visibles. Si une confirmation destructive nécessite un traitement distinct, documentez sa fonction au lieu de remplacer silencieusement le token d’action principale dans une seule boîte de dialogue. L’exception peut être légitime. Le problème commence lorsque personne ne sait si elle est intentionnelle ou issue d’un raccourci ponctuel.

Associez la couleur à un sens lisible

La couleur facilite le parcours d’une interface, mais le sens doit subsister lorsque la teinte est difficile à distinguer. Une bordure rouge seule laisse deviner le problème. Un libellé d’erreur et une correction utile rendent l’état compréhensible. De même, une icône de réussite accompagnée de « Modifications enregistrées » communique davantage qu’un point vert sans libellé.

Les recommandations du W3C sur l’utilisation de la couleur expliquent l’exigence de ne pas s’appuyer uniquement sur la couleur pour transmettre une information ou identifier une action. Appliquez-la à chaque rôle en contexte. Dans cet espace, les statuts reçoivent du texte lisible, les éléments sélectionnés conservent un traitement visible et les liens restent identifiables au-delà d’une subtile différence de teinte.

Le contraste demande une vérification distincte. Une couleur peut transmettre le bon sens et rester trop pâle pour être lue. Évaluez les paires premier plan/fond plutôt que d’attribuer une étiquette générale « accessible » à un échantillon de marque. Un texte sombre sur une surface de réussite claire constitue une autre combinaison qu’un texte blanc sur un bouton de réussite saturé.

Pour le texte normal, le critère WCAG de contraste minimal demande généralement 4,5:1, avec 3:1 pour le grand texte admissible et des exceptions définies. L’explication du contraste par le W3C en précise le périmètre. Mesurez la vraie paire et son usage rendu ; la réussite d’une paire ne certifie ni un composant, ni un thème, ni un site complet.

Les valeurs d’exemple précédentes rendent cela concret. Le calcul de luminance relative du vert #236646 et du violet #6439a8 donne des rapports de contraste de 6,86:1 et 7,80:1 avec le blanc. Avec le noir, les mêmes fonds donnent 3,06:1 et 2,69:1. Les deux conviennent donc à un libellé blanc au seuil du texte normal ; aucun ne convient au noir à ce seuil. Le nom sémantique n’établit pas ce résultat : les valeurs précises du premier plan et du fond le font. Gardez le calcul attaché à la paire afin qu’une future couleur de marque plus claire déclenche une nouvelle vérification.

Ne corrigez pas chaque échec en assombrissant toute l’interface. Examinez quel rôle échoue, sur quelle surface et dans quel état. Le texte secondaire a toujours une fonction de lecture. Qualifier de « discret » un message d’aide trop pâle ne l’améliore pas. À l’inverse, transformer chaque séparateur en ligne sombre épaisse peut effacer la hiérarchie recherchée.

Examinez un thème sombre comme une nouvelle correspondance

Un thème sombre est un bon test de résistance parce qu’il sépare fonction et apparence. Le texte principal doit rester principal, mais sa valeur change. Une surface surélevée doit rester distincte de la page. Un retour de réussite doit rester compréhensible même si ses valeurs de fond et de premier plan diffèrent de celles du thème clair.

N’inversez pas simplement les primitives et ne réutilisez pas les valeurs du thème clair sur une page sombre. Réexaminez les relations. Une action vive qui paraissait équilibrée sur blanc peut dominer une surface sombre. Une bordure discrètement visible sur un panneau pâle peut disparaître. Images, logos et graphiques peuvent aussi demander des décisions hors de la correspondance des couleurs sémantiques.

Utilisez le même contenu dans les deux aperçus de thème. Sinon, des différences de densité ou d’images peuvent distraire des décisions de couleur. Incluez une erreur de formulaire, un message de réussite, un élément de navigation sélectionné, une commande avec focus et du texte secondaire. Ces états donnent une comparaison plus utile qu’une galerie de beaux boutons par défaut.

Les noms de rôles doivent rester stables entre les thèmes. Si vous renommez text-primary en white-text dans le thème sombre, vous remettez une valeur dans un nom censé décrire une fonction. Gardez le sens constant et modifiez l’association qui le sert.

Donnez à un agent de programmation la correspondance, pas seulement la palette

Lorsque vous demandez à un agent d’affiner une page, fournissez les décisions de rôle avec la référence visuelle. Une capture montre les couleurs présentes. Elle n’explique ni lesquelles doivent rester liées pendant un changement de marque, ni quelles combinaisons d’états doivent continuer à fonctionner. Une petite table de correspondance et un composant représentatif rendent cette intention beaucoup plus facile à examiner.

Dans les aperçus HTML OpenDesign pris en charge, vous pouvez examiner le rendu, utiliser les commandes disponibles de modification manuelle des styles et rattacher des commentaires à la zone concernée pour la conversation. Servez-vous-en pour signaler un écart concret, comme une notification de réussite utilisant le traitement de l’action principale. Le retour doit nommer le rôle prévu autant que l’emplacement visible.

Par exemple, demandez de mettre à jour l’association d’action principale en préservant les rôles de réussite et d’erreur, puis de montrer les boutons concernés dans leurs différents états. Si votre projet possède déjà des conventions de tokens, fournissez les fichiers ou le contexte de design. Évitez de demander un nouveau système de noms complet pour une petite correction de couleur.

Après une correction visuelle, examinez la référence du composant dans les fichiers générés. Le bouton peut sembler correct tout en utilisant encore le token de réussite ; le prochain changement de thème révélerait la même erreur de dépendance.

Migrez d’abord un composant représentatif

Vous pouvez introduire des rôles sémantiques sans remplacer tout le site d’un coup. Choisissez un composant à plusieurs états significatifs, comme le formulaire de création de projet. Listez ses valeurs actuelles, décidez du rôle de chacune et associez ces rôles à la palette existante. Le design visible peut initialement rester presque inchangé.

Changez ensuite l’association d’un rôle comme test contrôlé. Si les actions principales doivent changer ensemble, vérifiez que les boutons prévus le font. Si les statuts doivent rester indépendants, vérifiez qu’ils ne suivent pas la couleur d’action. Le test porte sur la dépendance, pas sur la pertinence finale de la couleur temporaire pour la marque.

Conservez une liste des éléments qui utilisent encore des valeurs brutes. Certains seront délibérés : une illustration, un logo partenaire ou une visualisation de données ne relèvent pas forcément du même rôle d’interface. D’autres appartiennent au travail de migration. Marquez la distinction pour que la personne suivante ne prenne pas une conversion inachevée pour une exception approuvée.

Une fois le composant représentatif correct, étendez aux composants liés. Examinez la page rendue après chaque groupe significatif plutôt que de faire confiance à un remplacement global. Les règles partagées peuvent affecter des contextes que vous n’aviez pas ouverts. Une petite migration permet de les trouver avant que toute l’interface devienne plus difficile à comparer.

Ce qu’une revue de tokens utile doit laisser

La revue finale doit produire une correspondance utilisable par quelqu’un d’autre : noms des rôles, fonctions prévues, valeurs actuelles par thème pris en charge et quelques composants représentatifs montrant leur comportement. Ajoutez les associations nécessaires, comme le texte sur un fond d’action. Consignez les exceptions importantes sans transformer chaque pixel en politique distincte.

Demandez à un collègue de choisir le token d’un nouveau message de réussite et celui d’une nouvelle action principale à partir de cette correspondance. S’il choisit correctement sans deviner à partir des échantillons, le système fait un travail utile. Si les deux choix conduisent encore à « utiliser le vert de marque », clarifiez les descriptions avant d’ajouter des tokens.