Le Web universel

3.0 Couleur et contraste

Comment fonctionnent les rapports de contraste, où les calculs de WCAG 2.x montrent leurs limites, et pourquoi davantage de contraste n'est pas toujours préférable pour tous les lecteurs.

7 min read

Cette page a été traduite avec l'aide d'une IA. L'original en anglais fait foi.

Le contraste est le fondement de la lisibilité. Une lettre peut être magnifiquement dessinée, généreusement espacée et composée à une taille confortable, et échouer malgré tout si elle ne se détache pas nettement de son fond. En 2005, nous ne pouvions guère dire plus que « du texte sombre sur un fond clair, avec une bonne différence entre les deux ». Aujourd'hui, le contraste est mesurable, testable et inscrit dans la loi de nombreuses juridictions — et la mesure elle-même est devenue un sujet de recherche sérieux.

Le modèle de contraste de WCAG 2.x

Les Règles pour l'accessibilité des contenus web (WCAG) 2.x définissent le contraste comme un rapport entre la luminance relative de deux couleurs, allant de 1:1 (couleurs identiques) à 21:1 (noir pur sur blanc pur). Trois critères de succès l'appliquent :

  • 1.4.3 Contraste (minimum), niveau AA — le texte courant doit atteindre 4,5:1 ; le texte de grande taille (environ 24 pixels, ou 19 pixels en gras) peut descendre à 3:1.
  • 1.4.6 Contraste (amélioré), niveau AAA — 7:1 pour le texte courant, 4,5:1 pour le texte de grande taille, à l'intention des lecteurs souffrant d'une basse vision modérée.
  • 1.4.11 Contraste du contenu non textuel, niveau AA — 3:1 pour les composants d'interface et les graphiques porteurs de sens : bordures de champs, indicateurs de focus, icônes, éléments de graphiques.
Ces rapports constituent le bon point de départ pour tout projet. Ils sont simples à tester, ils sont opposables, et les respecter élimine les pires échecs — le texte courant gris pâle devenu à la mode dans les années 2010 échoue nettement au critère 1.4.3, et il le mérite.

Là où les calculs montrent leurs limites

La formule de WCAG 2.x est une mesure physique, non perceptuelle, et ses limites sont désormais bien documentées par le groupe de travail lui-même. Le rapport traite la polarité de façon symétrique : il attribue au blanc sur noir le même score qu'au noir sur blanc, alors que l'œil ne les perçoit pas de la même manière. Il ne prend en compte la graisse et la taille des caractères qu'à travers un unique seuil grossier de « texte de grande taille », alors qu'une police fine et maigre à 16 pixels et une police grasse au même rapport se lisent très différemment. Et vers l'extrémité sombre de l'échelle, la formule peut valider des paires de couleurs que des observateurs humains jugent faibles, tout en rejetant des paires qui se lisent correctement.

La piste de recherche APCA

Les travaux préparatoires de WCAG 3.0 incluent un candidat au remplacement, l'Accessible Perceptual Contrast Algorithm (APCA), issu de la recherche du W3C sur le contraste visuel. Il diffère du modèle 2.x sur trois points importants : il est fondé sur la perception plutôt que sur la seule luminance ; il tient compte de la polarité, en évaluant différemment le clair sur sombre et le sombre sur clair ; et ses seuils varient selon la taille et la graisse des caractères, de sorte qu'un caractère délicat aux traits filiformes est soumis à une exigence plus stricte qu'un caractère de labeur robuste.

L'APCA demeure une orientation à l'état de projet, non une norme de conformité. Pour l'instant, la position pragmatique est la suivante : se conformer à WCAG 2.x, et adopter la manière de penser de l'APCA — la graisse et la taille comptent, la polarité compte — comme un jugement de conception qui s'y superpose.

Davantage de contraste n'est pas toujours mieux

Il est tentant de traiter le contraste comme un curseur à pousser au maximum. Pour de nombreux lecteurs malvoyants, le contraste maximal aide réellement. Mais pour une minorité non négligeable, il nuit. Un contraste très élevé — en particulier du texte blanc pur sur noir pur — produit une halation, une lueur ou un flou autour des lettres, surtout chez les lecteurs atteints d'astigmatisme ou de sensibilité à la lumière. Certains lecteurs dyslexiques ou sujets au stress visuel rapportent que le noir sur blanc brut leur paraît agressif et préfèrent un fond légèrement adouci, comme un texte presque noir sur une surface blanc cassé.

La leçon n'est pas d'abaisser le contraste sous les minimums. C'est que les exigences de contraste définissent un plancher, et que la bonne typographie travaille dans la plage située au-dessus de ce plancher sans se précipiter vers le plafond. Un presque-noir, tel qu'un gris très foncé sur un blanc cassé chaud, passe confortablement le niveau AAA et se lit plus sereinement que du #000 sur #FFF. Mieux encore, les systèmes peuvent laisser le choix aux lecteurs : la requête média prefers-contrast signale qu'un utilisateur a demandé à son système d'exploitation plus (ou moins) de contraste, et une feuille de style peut y répondre en renforçant la couleur du texte, en épaississant les bordures et en supprimant les translucidités décoratives. Sous Windows, le mode forced-colors va plus loin et substitue la palette propre de l'utilisateur ; les designs doivent le tolérer plutôt que le combattre.

Ne jamais coder le sens par la seule teinte

Environ un homme sur douze, et une part bien plus faible de femmes, présente une forme de déficience de la vision des couleurs, le plus souvent une difficulté à distinguer les rouges des verts. Le critère WCAG 1.4.1 (Utilisation de la couleur) existe pour eux : la couleur peut renforcer le sens, mais ne doit jamais le porter seule. Un lien qui ne se distingue du texte courant que par sa teinte est invisible pour de nombreux lecteurs — associez-lui un soulignement. Un état d'erreur signalé uniquement par une bordure rouge a également besoin d'une icône ou d'un message. Un graphique dont les séries ne diffèrent que par la teinte a besoin d'étiquettes, de motifs ou d'annotations directes.

C'est un vieux principe de l'imprimé sous des habits neufs. Les designers d'information du vingtième siècle savaient qu'une carte lisible en photocopie était une carte plus solide. Concevez comme si votre page pouvait être vue en niveaux de gris, car pour certains lecteurs, c'est effectivement le cas.

Deux courbes de graphique distinguées uniquement par du rouge et du vert, indiscernables pour de nombreux lecteurs daltoniens, à côté du même graphique avec un motif de tirets et des étiquettes directes ajoutés.

Pourquoi ce chapitre est nouveau

Lorsque la première édition de ces recommandations a été rédigée, WCAG 2.0 n'avait pas encore été publié ; il n'existait aucune exigence chiffrée de contraste à citer, aucun outil de navigateur pour la tester, et aucune requête média par laquelle un lecteur aurait pu exprimer une préférence de contraste. Les deux décennies écoulées ont produit la norme du 4,5:1, son adoption juridique, un corpus de critiques de sa formule, et un successeur perceptuel qui prend forme dans le projet de WCAG 3.0. Le contraste est passé du goût à la mesure — puis, utilement, à un débat sur ce que la mesure devrait être.

En CSS

:root {
  --ink: #1f1a13;
  --paper: #f6f1e7;   /* ≥ 4.5:1 against ink (WCAG 1.4.3) */
  --accent: #b03a10;  /* check at the size and weight it's used */
}

@media (prefers-contrast: more) {
  :root { --ink: #000; --paper: #fff; }
}

Recommandations

  • Respecter WCAG 1.4.3 (4,5:1 pour le texte courant) comme plancher absolu ; viser 1.4.6 (7:1) lorsque le public est plus âgé ou malvoyant.
  • Appliquer 1.4.11 : les indicateurs de focus, les bordures de champs et les icônes porteuses de sens exigent 3:1 par rapport à leur environnement.
  • Juger les polices fines et maigres plus strictement que le seul rapport ne le suggère ; la graisse et la taille modifient le contraste effectif.
  • Éviter le noir pur sur blanc pur pour la lecture au long cours ; un gris très foncé sur un blanc cassé doux réduit la halation sans sacrifier la conformité.
  • Ne jamais laisser la teinte porter seule le sens — souligner les liens, étiqueter les états, annoter les graphiques.
  • Prendre en charge prefers-contrast et tolérer le mode forced-colors plutôt que de le neutraliser.
  • Suivre les travaux sur l'APCA dans le projet de WCAG 3.0, mais se conformer à la version 2.x aujourd'hui.

Pour aller plus loin