Depuis les premières versions du Système de Design de l'État, nous avons relevé auprès de la communauté d’utilisateurs, plusieurs axes d’amélioration pour le système de couleurs :

• Les couleurs étaient fournies brutes, sans consigne d’utilisation hors documentation
• Les indices utilisés (gris 800, bleu France 500) ne se rapportaient à aucune notion explicite, et n'étaient pas utilisés partout
• Les correspondances thème clair / thème sombre pouvaient apparaître comme arbitraires
• Les impératifs de contraste n'étaient pas toujours respectés
• Les versions “thème sombre” de couleurs déterminantes, comme le bleu France, ou la couleur d’erreur, étaient pâles et effacées
• Certaines couleurs, présentes dans la palette, n'étaient jamais utilisées
• Les couleurs illustratives étaient mal exploitées
• La couleur des composants n'était jamais personnalisable

La question de l’accessibilité

L’accessibilité étant la priorité du Système de Design de l'État, le système de couleurs devait faciliter au maximum la conception dans le respect des contraintes de contraste. Ce n'était pas le cas de la première version de la palette, surtout s’il on considère les associations de couleurs permises par le Système de Design de l'État, qui ne sont pas toutes présentées dans l’image ci-dessous (par exemple, bleu sur gris).

La première étape vers un système plus accessible était de changer le système d’indice : plutôt que d’utiliser la gamme 100-800 (introduite par Material Design), nous avons choisi de prendre l’indice de luminosité (“lightness”) de la couleur dans le modèle HSL (hue, saturation, lightness).

En savoir plus sur le modèle de couleur HSL

Pour une couleur donnée, il fallait donc obtenir les nuances de 0 (noir) à 1000 (blanc), et retrouver nos couleurs sur cette palette.

L'équipe a donc développé un outil déclinant les 40 nuances (avec un incrément de luminosité de 25 entre chaque nuance) à partir d’un code hexadécimal (HEX) donné.

Du point de vue de l’accessibilité, ce nouveau système d'indice possède un énorme avantage : il suffit d’avoir un écart de 500 entre deux couleurs pour permettre un ratio de contraste suffisant. Par exemple, le bleu France, d’indice 113, est accessible (contraste supérieur à 4,5:1) s’il est appliqué sur un fond d’indice 613 et supérieur. Plus besoin d’avoir recours à un plugin ou un outil de test, la simple lecture des indices suffit.

Considérons par exemple la palette des gris (version 1). En plaçant les nuances sur le dégradé, on observe que le gris foncé le plus clair (hors couleur disabled), le gris-600 (destiné aux mentions en thème clair), est accessible sur tous les fonds en thème clair (gris-200, gris-100 et blanc), car il y a tout juste 500 d'écart entre son indice (450) et celui du gris clair le plus foncé (951) : 951-450 = 501 > 500.

De la même manière, le gris clair le plus foncé (hors disabled), le gris-300, est largement accessible sur les fonds thème sombre (gris-700, gris-750 et gris-800), car 924-201 = 723 > 500.

On voit déjà ici qu’il y a un déséquilibre dans la répartition des gris (hors $g500 et $g400 utilisés pour les éléments inactifs) : côté sombre, ils s'étendent sur un intervalle de 400 d’indice, pour seulement 75 côté clair. C’est notamment ce déséquilibre qui est l’origine des problèmes sur les autres couleurs.

Retrouver ou choisir de nouvelles couleurs

Certes, nous avions un système plus compréhensible. Néanmoins, plutôt que de retrouver nos couleurs sur la palette HSL et de changer leur indice, nous nous sommes tournés vers les autres problèmes qu’elles posaient :

• Des tests d’accessibilité pas toujours respectés
• Des nuances pâles ou effacées
• Un manque de cohérence global dans la vivacité des couleurs (donné par le paramètre “saturation” du modèle HSL).

Pour répondre à ce problème, nous avons pris la décision de “caler” les palettes du bleu France et du rouge Marianne (et, plus tard, celles de toutes les nouvelles couleurs ajoutées à la charte) sur le comportement du gris. L’accessibilité étant garantie par le décalage de luminosité, celle-ci est indépendante des autres paramètres de l’HSL (“hue” et “saturation”). Avoir le même système pour chaque couleur est donc une garantie d’accessibilité.

Prenons par exemple la couleur d’erreur (le bleu France étant un peu particulier, nous y reviendrons par la suite), et comparons-le à la palette de gris (version 1).

On constate ici que la couleur d’erreur, d’indice de luminosité 474, est certes accessible sur fond blanc et sur fond alternatif (gris-100, d’indice 975), mais elle ne l’est pas sur le fond réservé aux composants, par exemple les champs de saisie ou les mises en avant. Il n’était donc pas accessible, dans la version 1, d’appliquer des éléments en état “erreur” dans ces contextes.

Constat plus terrible encore en thème sombre : la couleur d’erreur thème sombre, d’indice 575, n’est accessible que sur le fond le plus sombre (gris-800) ! Le gris-750 étant un fond “alternatif” autorisé pour les pages, nous sommes face à un problème majeur d’accessibilité.

Deux solutions s’offraient ici à nous :

• Solution 1 : “décaler” la couleur d’erreur (et les autres couleurs posant problème) pour garantir l’accessibilité
• Solution 2 : “décaler” plutôt les couleurs de fond, pour les emmener au maximum vers les extrêmes et augmenter l’intervalle d’accessibilité de nos couleurs devant bien vivre sur ces fonds

La solution 1 évitait de toucher aux gris, et donc de revoir tout le système. Mais elle avait l’inconvénient de rendre nos couleurs plus effacées, notamment en thème sombre, où la couleur d’erreur devenait carrément rose (elle devait avoir un indice supérieur à 700 !).

La solution 2, malgré un impact fort sur tout le Système de Design (notamment un fort assombrissement visuel des écrans thème sombre, et la nécessité de revoir toutes les couleurs), nous garantissait des couleurs vives en thème clair et en thème sombre (un autre problème déjà relevé !), en supprimant le déséquilibre observé entre les fonds thème clair et les fonds thème sombre.

L’assombrissement des gris

Sans toucher aux fonds thème clair, décaler les couleurs de fond thème sombre augmente l’intervalle disponible pour choisir des couleurs de texte accessible sur tous les fonds :

Ce qui permet de choisir des rouges accessibles de la manière suivante 

Les indices finaux pour la couleur d’erreur (et les autres couleurs fonctionnelles) sont 425 et 625. Ce décalage de 25 s’explique par l’introduction d’un fond, notamment pour le bleu France, d'indice 125 / 925.

Le découplage fonds / textes

Nous avions donc de nouvelles couleurs de fond, mais comme vous l’aurez peut-être remarqué, ces couleurs s’appliquent également à d’autres contextes. Par exemple, le gris-700 est aussi la couleur de corps de texte en thème clair. Les décalages doivent-ils s’appliquer aussi à ces contextes ?

Appliquer ce décalage aux gris utilisés pour le texte efface considérablement la hiérarchie visuelle entre la couleurs de titre (gris-800), celle de corps (gris-700), et celle des mentions (gris-600) - celle-ci étant plus perceptible sur des grands aplats que sont les fonds. Sachant que ces couleurs sont très éloignées des couleurs de fond sur lesquelles elles doivent vivre (à l’autre bout du spectre), il n’est pas nécessaire de les changer d’un point de vue accessibilité.

Dans le système de couleurs version 1, les clairs et les foncés existaient en miroir : la couleur utilisée comme fond de niveau 1 en thème sombre (gris-800) était utilisée comme texte de niveau 1 en thème clair, et inversement. Une fois les fonds “décalés”, nous ne pouvions plus suivre cette règle, et avons dû découpler les couleurs de fonds des couleurs de texte :

Les bordures ne sont pas mentionnées ici. Elles ont néanmoins été traitées, mais puisqu’elles n’ont pas d’impératifs d’accessibilité, on ne s'étendra pas sur leur cas.

Il nous est apparu à ce stade que pour prolonger la réflexion, il nous fallait dépasser les indices de luminosité pour distinguer des usages (une même couleur pouvant être un texte ou un fond en fonction des contextes). C'était donc le moment de nous plonger dans un autre chantier de fond : celui des design tokens.

Des couleurs, pour quoi faire

Le travail présenté dans la première partie a permis de pallier certaines défaillances du système de couleur, mais il en a soulevé d’autres, outre celles mentionnées en début d’article :

• Les couleurs sont fournies sans consignes d’utilisation
• Certaines couleurs de la palette ne sont pas utilisées dans le Système de Design de l'État

Il était donc temps de faire entrer le Système de Design de l'État dans l'ère des design tokens.

L’objectif du déploiement des tokens est double :

• Faciliter l’utilisation des couleurs pour les utilisateurs, en documentant tous les contextes d’application d’une couleur
• Assouplir la communication entre le design et le code, en créant un langage commun

La première étape pour la formalisation des tokens a consisté en un audit du Système de Design de l'État, pour recenser tous les contextes d’application par couleur présente dans la palette, et les factoriser au maximum dans une nomenclature claire.

Après consultation de nombreuses sources, nous nous sommes arrêtés sur une nomenclature construite autour des contextes d’application de la couleur, dans une optique d’utilisabilité. Le système devait répondre à la question suivante : en tant qu’utilisateur, quelle couleur dois-je utiliser pour mon composant ? Les étapes de réponse sont :

• Quel est le contexte visé (un fond, une bordure, un texte) ?
• Quel est l’usage fait de ce contexte ? Signifie-t-il une action, un état, un niveau d’information ?
• Quelle couleur souhaite-je utiliser ? Le bleu France (pour indiquer l’identité de l'État), les couleurs neutres (niveaux de gris), de systèmes (erreur, succès, etc.) ou d’illustrations ?

La nomenclature finale est la suivante :

THÈME - CONTEXTE - USAGE - VARIANTE - COULEUR

Par exemple, le token utilisé pour le fond d’un bouton primaire :

$background-action-high-blue-france

Ce token s’applique à tous les fonds de composants importants (comme le bouton primaire), permettant une interaction (en général au clic) et portant l’identité de l'État (le bleu France).

Il s’agit là des tokens servant dans un contexte donné, que nous nommons “Décisions”. Il nous fallait également trouver une nomenclature pour les couleurs “hors contexte”, celle des “Options” :

COULEUR - NOM - VARIANTE - INDICE - ÉTAT

Remarque

Le thème (clair ou sombre) étant une variable à part en code, il n’entre qu’en théorie dans le nom du token. Il n’est donc pas mentionné dans la nomenclature mais la distinction existe en pratique.

Par exemple, le bleu France de la charte, couleur dominante et accessible en thème clair (sun), en état de survol, s'écrira de la manière suivante :

$blue-france-sun-113-hover

Les autres variables de la nomenclature sont utiles pour les couleurs illustratives, dont nous parlerons par la suite.

Affinage des couleurs

Grâce à la base solide que fournissait le système colorimétrique fondé sur les indices (version 2), et la nomenclature des tokens, nous avons pu revoir certains usages peu rigoureux de la couleur, et fixer les correspondances thème clair / thème sombre de manière logique.

Par exemple : le composant “Barre de navigation” de la navigation principale introduisait de nombreuses correspondances thème clair / thème sombre, car les couleurs à disposition dans la palette de bleu dans les premières versions permettaient peu d’associations accessibles.

L’introduction grâce au générateur de palette développé par l'équipe d’une couleur de correspondance sombre ($blue-france-125) a permis de supprimer ces exceptions et retrouver de la cohérence.

Cependant, les nouvelles couleurs introduites par l’outil n'étaient pas à l’origine celles affichées dans l’image ci-dessus et retenue pour les couleurs définitives. Elles n'étaient pas entièrement satisfaisantes pour deux raisons :

• Les couleurs rendues par le générateur de palette étaient effacées, en particulier quand elles s’approchaient des extrêmes (du noir ou du blanc)
• En fonction de la clarté naturelle des couleurs, la luminosité perçue des couleurs à un niveau de luminosité égal (paramètre “lightness” du HSL) variait grandement. La couleur jaune, par exemple, paraît constamment plus lumineuse qu’une autre couleur.

Ces deux problèmes étaient liés au choix de l’espace colorimétrique, HSL. En faisant le choix de passer notre générateur de palette dans l’espace HSLuv, nous étions en mesure d’en régler une partie.

Comparaison entre les espaces HSL et HSLuv sur quelques couleurs illustratives, en thème clair Select an Image

Le dernier réglage effectué sur le générateur de palette était celui de la saturation : à un niveau de luminosité donné, il est possible de varier la saturation d’une couleur (son “éclat”) sans changer son indice, donc sans changer son accessibilité. Nous avons donc ajusté la saturation des différentes variations des couleurs afin de les adapter au mieux à leurs usages :

• Saturation élevée pour les aplats clairs (qui ont tendance à s’effacer en s’approchant du blanc)
• Saturation basse (inférieure à 50) pour les aplats foncés, qui ont tendance à “vibrer” sur un fond gris

Avec un tel outil à notre disposition, nous étions en mesure de concevoir et d’ajuster une nouvelle version de la palette répondant aux exigences d’accessibilité, agréable à l’œil et surtout évolutive, en prévision des chantiers suivants :

• Le système de survol (“hover”) qui sera également déployé en 1.2.0
• Le système d’accentuation, à venir en 1.2.0
• Et d’autres évolutions encore au stade de réflexion !

Article écrit par @Antoine Puig