Ce WE, j'ai fait une petite pause sur le développement du blog pour essayer de répondre à un besoin rencontré durant la conception :
Lorsqu'on travaille sur un design système ou une charte de couleur, il est particulièrement pénible de devoir vérifier à chaque ajout/changement de couleur si son contraste est bon avec toutes les autres couleurs.
J'ai donc décidé de me bricoler un utilitaire pour pouvoir vérifier simultanément plusieurs couleurs et me construire une charte rapidement.
Je ne partagerais pas le code de ce projet qui est vraiment dégueulasse (j'ai vraiment fait du quick and dirty), pour un résultat très perfectible. Je me contenterais de partager quelques un des apprentissages (en vrac) que j'ai fait en bossant sur ce sujet.
Color JS
Color.js(S'ouvre dans un nouvelle fenêtre) c'est cool 😎 !
Cette bibliothèque permet de créer de réaliser toutes sortes d'opérations sur les couleurs (conversions, décalage, …), notamment comparer le contraste entre deux couleurs.
Les créateurs de cette bibliothèque sont des dingos des math, en particulier quand elles s'appliquent à l'image (on trouve notamment une ancienne du W3C et le créateur du SVG). Je me suis perdu pendant une petite heure à lire plein de trucs intéressants (que je ne comprenais pas toujours 😅) dans leur doc.
Algorithmes de contrastes
Il existe plusieurs algorithmes de calcul des contrastes, pas juste celui utilisé par les WCAG.
Avertissement
Pour viser la conformité
Pour être conforme, l'algo des WCAG est le seul qui fasse foi, même si on lui reproche un manque de fiabilité dans certains contextes et sur certaines couleurs.
Cela ne veut pas dire qu'on ne peut pas aussi vérifier les contrastes avec d'autres algorithme. Il faut juste retenir qu'en plus d'obtenir un contraste suffisant cet algorithme, il faut toujours continuer à valider avec l'algo WCAG.
En bref : L'algo WCAG permet de valider la conformité, les autres permettent d'affiner nos choix pour une meilleur usabilité
Parmi eux, l'Accessible Perceptual Contrast Algorithm (APCA) a retenu mon attention, principalement parce qu'elle est envisagée[1] pour remplacer l'algo actuel dans les WCAG 3.
Cette méthode de calcul est bien plus complexe que l'algo des WCAG 2 et se veut plus fiable.
Astuce
Le contexte compte pour l'APCA
Pour cette méthode le contexte est important et elle ne donnera pas le même résultat si on inverse la couleur de fond et la couleur de texte[2] (contrairement à l'algo des WCAG 2, qui donne toujours le même résultat)
Usage des couleurs accessible
Avec cet outils, j'ai essayé de trouver un équilibre qui me permette de garantir la lisibilité des textes (la base) mais aussi de faire passer des informations par des couleurs, en m'efforçant de trouver des couleurs secondaires avec un ratio suffisamment élevé pour les distinguer des autres couleurs de texte utilisées (l'objectif n'est pas de pouvoir utiliser la couleur de mon texte comme couleur de fond mais juste de pouvoir utiliser une seconde couleur de mise en avant qui se distingue même avec des troubles de perception de la couleur)
Le schéma ASCII ci-dessous n'est pas accessible. Aller à la description du schéma
Couleur du fond
/ \
/ \
ratio de 4.5:1 ratio de 4.5:1
/ \
/ ratio \
Couleur du texte ———— de 3:1 ———— Couleur de mise en avantDescription du schéma
Le schéma forme un triangle pointant vers le haut. Sur la pointe du haut, il est inscrit "couleur du fond" et sur les deux pointes du bas "Couleur du texte" et "Couleur de mise en avant". Entre chaque pointes, les relations suivantes sont indiquées :- Couleur du fond et du texte : ratio de 4.5:1
- Couleur du fond et de la mise en avant : ratio de 4.5:1
- Couleur du texte et de la mise en avant : ratio de 3:1
Information
À propos du ratio 3:1
Ce ratio est insuffisant pour garantir la lisibilité d'un texte affiché sur un fond, en revanche il est jugé suffisant pour distinguer un élément graphique ou un très grand texte. En choisissant des couleurs de texte qui respectent ce ratio, je devrais pouvoir garantir qu'on les distingue quelque soit le handicap de perception de couleur.
J'ai bien réussi à trouver des couleurs qui respectent cette configuration, mais l'exercice est très contraignant et restreint fortement les possibilités de couleurs. De plus tout ce montage s'effondre dès que l'on veut introduire une 4e couleur… et pour le blog je compte bien utiliser au moins 5 couleurs ! (Une pour le fond, une pour le texte, une pour de la mise en avant simple et deux pour identifier les propos de Myriam et moi-même…)
Je laisse donc tomber cette idée et me contenterais de m'assurer que mes couleurs de fonds respecteront systématiquement un ratio de 4.5:1 avec mes couleurs de texte. Les nuances autrement passées par la couleur (comme par exemple "qui parle ?") devront passer par du texte ou d'autres marqueurs visuels.
Astuce
Et pour les autres troubles ?
En plus des troubles de la perception des couleurs, je ne dois pas oublier les autres handicaps. Pour certains troubles cognitif, il faut que je fasse attention à ce que le "langage graphique" que je mettrais en place ne soit pas trop complexe. Quitte à privilégier du texte, et tant pis pour la lourdeur (ce sera un équilibre à trouver)
Et ne faut pas non plus oublier ceux qui dépendent d'un lecteur d'écran. Pour eux, si je me repose sur des indications visuelles pour convier des nuances, il faut que celles-ci ressortent dans le texte (éventuellement avec du texte masqué visuellement).
JS optimisation
En plus de ces considérations sur l'accessibilité, je me suis aussi beaucoup frotté à la manipulation du DOM et je suis notamment tombé sur cet intéressant article, détaillant de nombreuses façon d'optimiser sa manipulation : Performance Optimization in DOM Manipulation(S'ouvre dans un nouvelle fenêtre)
Je n'ai lu que le début (j'ai encore de la lecture devant moi) mais le début est déjà très intéressant avec un concept important : parcourir le DOM est très coûteux et déclenche pleins de rafraîchissements inutiles de la page.
Il conseille donc d'éviter d'enchaîner les actions de type "lire puis écrire" en série :
- je lis le DOM, puis j'écris dedans
- je lis le DOM, puis j'écris dedans
- et ainsi de suite
à la place, il recommande d’enchaîner les lectures, puis d’enchaîner les écritures. En faisant cela, on réduirait les rafraîchissement forcés de la page. Plus efficace encore, il propose d'attendre juste avant le prochain assez rafraîchissement (Javascript a une méthode pour ça) pour faire toutes les écritures. Note : je n'ai pas appliqué cette dernière.
Conclusion
J'ai implémenté un outil, ou plutôt un POC (Proof of Concept), et je n'en suis pas très content…
Outre qu'il est mal codé et immaintenable, il est aussi peu utilisable, car basé sur une idée de l'usage des couleurs (voir plus haut) qui ne marche pas (mais il m'aura au moins permis de me démontrer ça).
En revanche, j'imagine un intérêt à une nouvelle version (mieux codée) et surtout avec un concept différent, où au lieu de créer des grands groupes de couleurs et vérifier leurs ratios relatifs, je pourrais laisser l'utilisateur définir les couples de couleurs qu'il veut former et ensuite lui faire un rapport sur les combinaisons qu'il a composé.
Non seulement cela permettrait une application plus fine et fournirait des directive très claires aux utilisateurs de la charte/système créé, cela permettrait aussi d'utiliser d'autres algo comme l'APCA[2:1].
La nuance est importante. À ce jour, nous ne savons pas avec certitude si cet algorithme sera utilisé par les WCAG 3 et comment. Beaucoup de choses peuvent changer entre maintenant et la finalisation de cette norme (qui n'est pas pour tout de suite). ↩︎
l'APCA s'intéresse de très prêt à l'effet de la couleur sur la lisibilité et, selon les très complexes calcul de cet algo, une couleur n'a pas le même impact sur la lisibilité si elle est utilisée pour le texte ou pour le fond. Il semble d'ailleurs que ce soit particulièrement vrai avec les schémas de couleurs utilisés en "mode sombre" ↩︎ ↩︎