Palette accessible : cessez d’utiliser HSL pour les systèmes de couleurs

 (wildbit.com)
2 points par GN⁺ 2023-08-30 | 1 commentaires | Partager sur WhatsApp
  • L’ancienne palette de couleurs de Postmark présentait une luminosité perçue très irrégulière selon les couleurs, et il était difficile de prédire les rapports de contraste entre les niveaux ; il fallait donc vérifier manuellement à chaque fois le contraste recommandé par les WCAG
  • HSL/HSV sont des modèles issus d’une simple transformation de RGB : ils ne reflètent pas la perception humaine de la luminosité et de la saturation. Ils peuvent servir à choisir une couleur isolée, mais ne conviennent pas à la construction d’un système de couleurs
  • CIELAB et LCh sont des espaces colorimétriques perceptuellement uniformes, conçus pour que les variations numériques correspondent davantage aux variations perçues ; ils permettent donc de créer des échelles de couleurs plus cohérentes à luminosité égale
  • Accessible Palette est une application qui génère une palette cohérente basée sur LCh, en ajustant la luminosité, les rapports de contraste, la correction de Hue et la prise en compte des couleurs de marque existantes
  • Il faut vérifier à la fois les rapports de contraste WCAG 2.1 et l’APCA du Working Draft de WCAG 3, afin de répondre plus facilement aux règles actuelles comme aux futurs changements d’algorithme de contraste

Le problème du système de couleurs de Postmark

  • L’ancienne palette de Postmark avait deux problèmes
    • La luminosité perçue n’était pas cohérente : les bleus et les rouges semblaient beaucoup plus sombres que les jaunes et les verts, par exemple
    • Il était difficile de prédire les rapports de contraste entre les variantes de couleurs, ce qui empêchait de savoir facilement si une paire de couleurs respectait les recommandations WCAG
  • À chaque choix d’une paire de couleurs, il fallait vérifier manuellement le rapport de contraste, avec un risque élevé que cette vérification ne soit pas faite en pratique
  • La cause venait des limites du modèle de couleur HSL lui-même, ainsi que du manque de prise en charge de meilleures alternatives dans les outils de design

Pourquoi HSL n’est pas adapté aux systèmes de couleurs

  • RGB est un modèle qui reflète le fonctionnement des écrans ; ce n’est pas un modèle intuitif pour aider les humains à choisir des couleurs
  • HSL et HSV/HSB sont des alternatives créées dans les années 1970 pour représenter RGB d’une manière plus proche de la façon dont les humains pensent les couleurs
    • HSL signifie Hue, Saturation, Lightness
    • HSV/HSB signifie Hue, Saturation, Value ou Brightness
  • À l’époque, les modèles plus sophistiqués étaient coûteux à calculer ; HSL et HSV ont donc sacrifié la précision perceptuelle au profit de la vitesse de calcul
  • En conséquence, HSL et HSV ne sont que de simples transformations mathématiques de RGB, et ne reflètent pas correctement la luminosité ou la saturation perçues par les humains
  • Par exemple, dans HSL, une échelle de couleurs réglée sur Saturation 100 et Lightness 50 a la même luminosité selon le modèle, mais en réalité le bleu #00F paraît beaucoup plus sombre que le jaune #FF0 ou le cyan #0FF
  • Dans HSL, les couleurs à saturation complète sont mappées sur la valeur maximale de RGB et placées sur le cercle des Hue à Lightness 50 ; Lightness 0 et 100 correspondent respectivement au noir et au blanc
    • Les variantes plus claires ou plus sombres sont créées comme si l’on “mélangeait” avec du blanc ou du noir
    • L’axe vertical central correspond à la plage des couleurs neutres ou grises avec Saturation 0

CIELAB et LCh

  • À l’époque où HSL et HSV ont été formalisés, une meilleure alternative existait déjà : l’espace colorimétrique CIELAB
  • La Commission internationale de l’éclairage, ou CIE, a défini en 1976 l’espace colorimétrique CIELAB, ou L*a* b*
  • CIELAB est un espace colorimétrique perceptuellement uniforme, conçu pour que les variations numériques correspondent à des variations de couleur perçues similaires
    • Contrairement à RGB, il est conçu pour couvrir l’ensemble des couleurs visibles
    • La composante L*, qui représente la Lightness, est proche de la perception humaine de la luminosité
  • CIELAB se compose de trois axes
    • La valeur L* définit le noir à 0 et le blanc à 100
    • L’axe a* est l’axe d’opposition vert-rouge : les valeurs négatives vont vers le vert, les valeurs positives vers le rouge
    • L’axe b* est l’axe d’opposition bleu-jaune : les valeurs négatives vont vers le bleu, les valeurs positives vers le jaune
  • CIELCh, LCh ou Lch(ab) est une représentation cylindrique de CIELAB
    • Au lieu de a* et b*, elle utilise Chroma et l’angle de Hue
    • La Lightness reste inchangée
  • L’angle de Hue de LCh ressemble au Hue de HSL, mais il n’est pas identique
    • HSL/HSV placent les trois couleurs primaires additives, rouge, vert et bleu, à H=0, 120 et 240°
    • LCh place le rouge, le jaune, le vert et le bleu à h=0, 90, 180 et 270°
  • Il existe aussi un espace colorimétrique similaire appelé HCL ou LCh(uv), qui, contrairement à LCh(ab), possède une échelle de Chroma uniforme de 0 à 100

Comment créer une échelle de couleurs en LCh

  • Contrairement à HSL/HSV, LCh tient dans un cylindre, mais ne remplit pas entièrement ce cylindre
  • Certaines combinaisons de Lightness, Chroma et Hue produisent des couleurs impossibles
    • Par exemple, un jaune sombre et très saturé n’existe pas
  • Sur l’échelle de Lightness, plus on se rapproche du noir et du blanc, moins il existe de couleurs que l’œil humain peut distinguer
  • Les écrans réels ne peuvent pas afficher toute la gamme des couleurs visibles
    • Le gamut sRGB représente les écrans courants et ne couvre qu’environ ⅓ de l’espace colorimétrique LCh
    • En CSS aussi, du moins pour l’instant, on est limité à cette plage
  • Si l’on observe avec LCh une échelle de couleurs en HSL avec Saturation 100 et Lightness 50, le jaune est le plus clair et le bleu le plus sombre
    • Le vert est presque trois fois plus clair que le bleu, et environ deux fois plus clair que le rouge
  • Si l’on reconstruit l’échelle en LCh avec le même niveau de Lightness, la luminosité de chaque couleur devient visuellement cohérente
    • La Chroma variant, certaines couleurs peuvent être plus saturées que d’autres
    • Dans un système de couleurs, ces différences peuvent être utiles, car on peut vouloir que les couleurs de notification et d’alerte soient plus saturées que les couleurs de texte par défaut
  • En harmonisant aussi davantage la Chroma, on peut créer des échelles fluides même dans l’espace sRGB limité

Les limites des outils de design et Accessible Palette

  • Aujourd’hui, Figma, Sketch et Adobe XD ne prennent pas en charge CIELAB ni LCh
  • Figma dispose des plugins LCH color picker et Chromatic, mais ils n’étaient pas suffisants pour créer un système de couleurs flexible
  • L’outil nécessaire devait remplir trois conditions
    • Maintenir la cohérence de luminosité lors de la création de variantes de couleurs
    • Permettre de contrôler les rapports de contraste entre les niveaux
    • Être assez flexible pour accepter les couleurs de marque existantes
  • Après avoir découvert la bibliothèque Chroma.js, qui prend bien en charge LCh, un outil simple de génération de nouvelle palette par le code a été créé
  • Après un usage interne et un partage avec quelques connaissances, cet outil a été publié sous forme d’application : Accessible Palette
  • Accessible Palette est une application permettant de créer des systèmes de couleurs avec une luminosité cohérente et des rapports de contraste prévisibles sur l’ensemble des niveaux de couleur

Fonctionnement d’Accessible Palette

  • Lorsque l’on ajuste une couleur de départ ou que l’on colle une couleur issue d’un design existant, l’outil utilise la Chroma et le Hue de cette couleur pour calculer une échelle sur plusieurs niveaux de Lightness
  • La Lightness est entièrement personnalisable et peut être utilisée aussi bien pour des palettes claires que sombres
    • Elle peut être ajustée finement pour inclure des couleurs de marque existantes
    • Chez Postmark, l’objectif était de conserver le jaune #FFDE00, le bleu #007DCC et le vert #4FC47F, qui étaient les couleurs les plus utilisées dans l’ancienne palette
    • Les valeurs de Lightness de ces couleurs, 88,6, 75,2 et 50,6, ont été utilisées respectivement comme luminosités des niveaux 200, 400 et 600
  • Le rapport de contraste varie selon la Lightness ; pour chaque niveau, il est calculé à la fois avec la méthode recommandée par WCAG 2.1 et avec le nouvel algorithme du Working Draft de WCAG 3.0
    • Par défaut, le contraste de toutes les couleurs est mesuré par rapport à un fond blanc
    • Il est possible de sélectionner l’échantillon de couleur souhaité pour mesurer le rapport de contraste par rapport à cette couleur
  • Les niveaux peuvent être générés avec l’espace colorimétrique RGB ou CIELAB
    • Les résultats pouvant varier selon les cas, cela vaut la peine d’expérimenter
    • Dans le système de couleurs de Postmark, l’usage de CIELAB a réduit la teinte violette des rouges clairs, mais l’a accentuée dans les bleus
  • Certaines couleurs peuvent nécessiter une correction de Hue sur l’ensemble de la plage
    • Les jaunes clairs prennent une nuance verdâtre lorsqu’ils s’assombrissent
    • Pour les rapprocher légèrement de l’orange, une correction de Hue négative est utilisée
  • L’application met à jour l’URL pendant l’utilisation afin d’enregistrer les modifications
    • Il est possible de la partager avec l’équipe ou de l’ajouter à une bibliothèque Figma et à un fichier de variables de couleurs CSS pour référence ultérieure
  • Parmi les palettes d’exemple figurent des palettes basées sur la nouvelle palette de couleurs Postmark, Material Design de Google et TailwindCSS
    • Ces exemples ne reproduisent pas exactement les originaux ; ce sont des alternatives inspirées des couleurs et des niveaux de luminosité d’origine

Calcul des rapports de contraste et WCAG

  • Accessible Palette affiche deux rapports de contraste parce que la méthode WCAG 2.1 a des limites
  • WCAG 2.1 calcule le rapport de contraste en divisant la luminance de la couleur de premier plan par celle de la couleur d’arrière-plan
  • Cette formule fournit une réponse linéaire, mais les humains perçoivent le contraste entre couleurs claires comme plus élevé que le contraste entre couleurs sombres
  • Dans des exemples réels, un échantillon respectant les recommandations WCAG 2.1 peut être plus difficile à lire qu’un échantillon affiché avec un rapport de contraste “insuffisant”
  • Le W3C est conscient de ce problème, et Andrew Somers a lancé une discussion publique en 2019
  • Le nouvel algorithme de travail proposé par Andrew Somers est devenu une partie du Working Draft de WCAG 3, et il a aussi créé l’APCA Contrast Calculator
  • APCA signifie Advanced Perceptual Contrast Algorithm ; il est plus précis sur le plan perceptuel et tient aussi compte de la taille et de la graisse de la police
  • Accessible Palette utilise APCA et retient un score de 60 comme niveau minimal recommandé pour un texte lisible
    • Cela correspond à un seuil similaire à la recommandation historique de rapport de contraste 4.5:1 de WCAG 2.1
  • Le rapport de contraste WCAG 2.1 n’est pas totalement inutile
    • Il reste assez précis pour les couleurs de milieu de gamme
    • Mais, globalement, le nouvel algorithme constitue une nette amélioration
  • La méthode WCAG 3 est encore un Working Draft et peut évoluer avec le temps
  • Pour respecter les directives actuelles tout en se préparant aux évolutions futures, il est préférable de construire les systèmes de couleurs en gardant les deux lignes directrices à l’esprit

À lire aussi

1 commentaires

 
GN⁺ 2023-08-30
Avis de Hacker News

  • Sur les systèmes d’affichage et d’impression courants, il faut considérer que les rouges et les bleus saturés sont en réalité plus sombres que les verts
    La formule exacte varie selon l’espace colorimétrique, mais Grayscale = 0.299R + 0.587G + 0.114B est souvent citée ; dans ce cas, le rouge pur le plus lumineux a une luminosité d’environ 30 %, et le bleu pur de 11 %, si bien que, dans la plupart des cas, rouge clair est presque une contradiction
    On peut utiliser ce genre de couleur, mais elle paraîtra forcément toujours sombre ; si appliquer simplement des règles de contraste peut suffire pour l’accessibilité, les techniques abordées dans l’article sont bien plus avantageuses si l’on veut aussi obtenir un rendu agréable
    Même lorsqu’on crée des images stéréoscopiques rouge-cyan comme https://en.wikipedia.org/wiki/Anaglyph_3D, les arbres et l’herbe sont verts, mais comme ils comportent en réalité beaucoup de composante rouge, l’équilibre des canaux est bon et le relief comme les couleurs ressortent bien
    Référence : https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • Cela me rappelle l’époque de la zone de sécurité de diffusion NTSC et les clients qui aimaient beaucoup trop le rouge
      Il était toujours difficile d’expliquer qu’une belle illustration rouge ne serait pas du tout belle à la télévision, surtout si elle était destinée à la diffusion
      Même hors diffusion, un rouge hors spécifications pouvait persister plusieurs images plus tard et donner l’impression de baver comme une gorge tranchée
    • Il y a plusieurs choses inexactes ici
      Si vous avez lu les réponses, répondez-moi et j’essaierai d’en clarifier quelques-unes

  • Cela me dérange depuis longtemps que les exemples qui satisfont effectivement aux critères recommandés WCAG 2.1 soient plus difficiles à lire que ceux dont le ratio de contraste est jugé « insuffisant »
    Je me demande pourquoi une formule de « directives d’accessibilité » qui produit plutôt l’effet inverse a été standardisée

    • C’est un peu regrettable que les algorithmes et recommandations les plus utilisés pour l’accessibilité du contraste ne reposent pas sur des preuves évaluées par les pairs
      C’est vrai pour la 2.1 comme pour la prochaine norme ; dans un domaine aussi influent, j’aimerais que l’industrie finance des recherches plus rigoureuses
    • Il me semble qu’il y a eu, au sein du W3C/WCAG, une volonté de modifier la formule d’évaluation du contraste
      Peut-être n’était-ce qu’une demande en ce sens et que cela n’a pas encore été officiellement adopté

  • Le meilleur article que j’aie vu sur ce sujet est https://www.handprint.com/HP/WCL/color1.html
    Il est extrêmement long, donc il faut être prêt à y consacrer une journée
    Cela peut surprendre, mais nous utilisons aussi certaines idées de cet article pour joliment colorer les logs dans ClickHouse : https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • Il a été difficile de trouver une méthode précise pour convertir ces couleurs ANSI en RGB ; en pratique, cela semble n’être qu’une demande de couleur et dépendre des paramètres du terminal
      Je me demande si vous pourriez partager les valeurs RGB attendues pour chaque type de message défini dans le code

  • J’ai rencontré Eugene à la conférence Config de Figma ; il a donné aux designers beaucoup de conseils pratiques similaires, et c’était quelqu’un de vraiment aimable, sincèrement engagé dans le design et l’accessibilité
    Ce que je tiens particulièrement à saluer dans cet article, c’est APCA, qui a de bonnes chances de succéder à l’algorithme de contraste des couleurs de WCAG 2
    Nous avons aussi utilisé APCA dans la refonte interne de l’accessibilité chez Figma, et le résultat final s’en est trouvé nettement amélioré
    Eugene montre bien les cas où WCAG 2 échoue, et dans les faits, nous avons nous aussi rencontré ce genre de cas en permanence
    Le conseil essentiel est qu’ajuster correctement les couleurs est vraiment difficile
    Les outils aident, mais à un moment donné, il faut faire confiance à ses yeux
    Au bout du compte, ces outils ne font qu’approximer mathématiquement la manière dont l’œil perçoit les couleurs ; le critère final, ce n’est pas l’algorithme, mais l’œil humain
    Là où un outil ou un algorithme donne un résultat qui ne convient pas, mieux vaut ajuster ou revenir aux fondamentaux

    • Je serais curieux d’en savoir plus sur le fait que vous avez utilisé APCA dans la refonte interne de l’accessibilité chez Figma
      J’aimerais savoir si cela signifie que vous avez utilisé uniquement APCA et ignoré les contenus que l’algorithme de contraste des couleurs WCAG 2 signalait comme insuffisamment contrastés
    • Je suis daltonien rouge-vert, et l’accessibilité par défaut de Figma est suffisamment bonne pour que je n’aie jamais pensé à faire des réglages d’accessibilité séparés
      Beau travail

  • Je voudrais aussi présenter HCT
    C’est un espace colorimétrique créé pour rendre Material You possible, qui combine la mesure de luminosité évoquée ici avec un espace colorimétrique issu de la science moderne de la couleur
    LAB/LCH date de 1976
    Il rend le design plus intuitif : il suffit de savoir qu’un écart de T de 40 satisfait le critère WCAG pour les boutons, et qu’un écart de 50 satisfait le critère pour le texte

    • Intéressant
      Je me demande comment HCT se compare à https://www.hsluv.org/comparison/
      Comme avec HCT, ici la différence de L facilite le choix de couleurs contrastées
      Dans le même ordre d’idées, je serais curieux d’avoir des avis sur https://www.myndex.com/APCA/ et sur l’approche à adopter quand cela deviendra un standard
      Comme la valeur de contraste entre deux couleurs dépend de celle qui est au premier plan et de celle qui est en arrière-plan, il me semble qu’il ne suffira plus de comparer uniquement l’écart de T
    • Je me demande s’il existe de bonnes ressources pour apprendre HCT
      Par exemple, supposons qu’une application ait besoin de rouge, jaune, bleu, orange, vert et violet, soit 6 couleurs correspondant aux 3 couleurs primaires et aux 3 complémentaires
      Les teintes exactes importent peu, mais si l’on veut que ces 6 couleurs soient à peu près identifiables tout en ayant une luminosité similaire, et peut-être même une saturation similaire, comment faire ?
      Comme le jaune est très clair et le bleu très sombre, il n’y a probablement pas de réponse exacte, et il faudrait parvenir à une approximation
      Je me demande s’il existe des outils ou des tutoriels pour apprendre ce genre de choses
    • Je me demande s’il existe une spécification publique quelque part
      Tout ce que j’ai trouvé, c’est le code material-color-utilities sur GitHub
      À lire le code, les calculs semblent bien plus complexes que pour OkLab, surtout dans le sens HCT vers RGB

  • L’article ne se contente pas d’omettre oklab/oklch ; l’affirmation selon laquelle le Web/CSS ne prend en charge que sRGB est également fausse
    La fonction CSS color() prend en charge plusieurs espaces colorimétriques

    • Je suis l’auteur
      Cet article a été publié il y a 2 ans, et lorsque j’ai commencé à travailler sur l’outil, la spécification OkLCH n’était pas encore sortie
      Aujourd’hui, je choisirais OkLCH plutôt que LCH, car il résout certains problèmes de LCH
    • CSS Color Module Level 4 en est encore au stade de brouillon de recommandation
      Ici, « pris en charge » signifie plus précisément « pris en charge sauf par Microsoft Edge (Chromium) et Pale Moon (Goanna) »
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • J’ai utilisé directement oklab et plusieurs espaces colorimétriques de la famille LAB, et Oklab est excellent pour être tronqué avec des calculs simples
    • Il existe aussi un modèle de couleur construit au-dessus d’Oklch
      Il utilise toutefois le contraste d’APCA, c’est-à-dire de WCAG 3, au lieu de la luminosité : https://github.com/antiflasher/apcach

  • oklab pourrait être une meilleure alternative à LCh
    https://bottosson.github.io/posts/oklab/

    • Il y a des aspects qui s’éloignent pas mal des prémisses initiales
      Le canal de luminosité est inversé par rapport à tous les autres espaces colorimétriques, et L n’a aucun rapport avec le L de LCH ou LAB
      Son succès a aussi, d’une certaine façon, accentué une pauvreté intellectuelle
      Le billet de blog initial contient énormément de choses à corriger, et la logique déraille fortement à partir du moment où il commence à revendiquer l’exactitude avec des dégradés utilisant CAM16 UCS
    • Ce playground visualise étonnamment bien 16 espaces colorimétriques, dont LCh et OKLAB : https://color-playground.ardov.me/spaces-3d
    • Ce n’est pas parfait, mais j’ai utilisé oklab et oklch pour l’interpolation des couleurs dans quelques situations, et le résultat était visuellement bien plus satisfaisant qu’une interpolation en RGB ou HSL
    • J’utilise OkLab avec satisfaction sur mon site, et c’est beaucoup plus reposant pour les yeux que la palette de couleurs que j’utilisais auparavant avec CIELAB

  • Si les valeurs CIELAB reposent sur des changements perceptifs, je me demande comment cela interagit avec l’accessibilité
    Faut-il s’inquiéter du fait que ce type de formule perceptuelle ait probablement été établi sur la base d’une vision standard ?
    Je me demande aussi si cela peut varier selon les types de déficience de la vision des couleurs, ou si ce n’est pas vraiment le sujet
    J’essaie de rendre mes graphiques aussi accessibles que possible, mais je n’ai jamais rien appris sur la couleur, donc je ne fais que suivre des conseils sans pouvoir les déduire moi-même
    Il est donc tout à fait possible que la question soit stupide

    • J’ai travaillé sur ce sujet
      Le contraste varie de façon non linéaire
      Les simulations sont assez faciles à appliquer, et celles de Machado et al. ne sont rien d’autre que des transformations matricielles

  • L’article place l’explication plus bas, mais APCA Contrast, le test de contraste lisible du brouillon de standard WCAG 3, est beaucoup plus équitable pour certaines couleurs que le ratio de contraste de WCAG 2.1
    Un bon article pour lire la théorie des couleurs derrière le contraste perceptuel : https://www.smashingmagazine.com/2022/09/realities-myths-con...
    Un article qui explique APCA de façon concise : https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA fonctionne bien, mais sa licence est très étrange et restrictive
      Avant de l’utiliser pour quoi que ce soit, mieux vaut examiner cette partie en détail et déterminer si vous pouvez vraiment vous en servir

  • Où est le code ?
    Il faut un algorithme utilisable non pas dans un formulaire web, mais dans n’importe quel logiciel.