WCAG 1.4.1 : Utilisation de la couleur

Ce que signifie cette règle

WCAG 1.4.1 Utilisation de la couleur est un critère de niveau A relevant du principe « Perceptible ». Il stipule que la couleur ne doit pas être utilisée comme seul moyen visuel pour transmettre une information, indiquer une action, solliciter une réponse ou distinguer un élément visuel. Le mot clé ici est « seul » : la couleur n’est pas interdite, mais elle doit toujours être accompagnée d’au moins un autre indice visuel, comme des libellés textuels, des motifs, des formes, des bordures, des icônes ou des traitements typographiques, afin que la même information soit disponible, que l’utilisateur puisse ou non percevoir les différences de couleur.

Ce critère couvre un large éventail d’éléments d’interface. Les champs de formulaire qui deviennent rouges pour indiquer une erreur ne respectent pas ce critère si la couleur rouge est le seul indicateur. Les graphiques et diagrammes qui utilisent uniquement la couleur pour distinguer des séries de données ne respectent pas ce critère. Les liens stylés uniquement avec une couleur différente (sans soulignement, gras ou autre différenciateur non lié à la couleur) ne respectent pas ce critère lorsqu’ils apparaissent dans un bloc de texte courant. Les états de navigation, badges de statut, indicateurs de progression, marqueurs de champs obligatoires et affordances interactives sont tous concernés.

Une implémentation conforme fournit au moins un mécanisme non lié à la couleur en plus de la couleur. Par exemple : un champ en erreur encadré en rouge et accompagné d’une icône d’erreur et d’un libellé textuel descriptif ; un diagramme circulaire utilisant à la fois des couleurs distinctes et des remplissages à motifs ; des liens dans le corps du texte qui sont à la fois d’une couleur différente et soulignés. Une implémentation non conforme repose uniquement sur un changement de couleur : aucune forme, bordure, motif, étiquette ou différence de texte n’existe pour transmettre la même signification.

La spécification WCAG apporte une précision importante sur le périmètre : ce critère s’applique spécifiquement à la couleur en tant que moyen visuel de transmission d’information. Il n’exige pas que toute couleur soit supprimée, ni ne traite des rapports de contraste — cela est couvert par 1.4.3 et 1.4.11. Il ne s’applique pas non plus aux logos ou aux images décoratives dont la couleur ne porte aucune signification informationnelle. Le critère concerne strictement les situations dans lesquelles un utilisateur qui ne peut pas distinguer deux couleurs ou plus perdrait l’accès à une information ou à une fonctionnalité.

Pourquoi c’est important

Environ 300 millions de personnes dans le monde vivent avec une forme de déficience de la vision des couleurs (daltonisme), et 2,2 milliards de personnes dans le monde ont une déficience de la vision de près ou de loin selon l’Organisation mondiale de la santé. Le daltonisme touche environ 1 homme sur 12 et 1 femme sur 200 d’ascendance d’Europe du Nord, ce qui signifie que, dans un public typique de 100 personnes, environ 5 à 8 d’entre elles ne peuvent pas distinguer de manière fiable le rouge du vert — l’une des combinaisons de couleurs les plus courantes utilisées dans les interfaces pour signaler la réussite ou l’échec.

Pour les utilisateurs atteints de deutéranopie ou de protanopie (daltonisme rouge-vert), un formulaire qui met en évidence les champs invalides uniquement en rouge est, fonctionnellement, invisible en tant qu’indicateur d’erreur. Ils soumettent le formulaire, ne voient aucun changement évident et concluent que le système est en panne ou que leur soumission a été acceptée. Ce n’est pas un simple désagrément mineur : cela peut entraîner des transactions financières échouées, des rendez-vous médicaux manqués, des demandes de services publics infructueuses ou l’impossibilité de finaliser des achats en ligne.

Les utilisateurs malvoyants qui s’appuient sur des affichages à fort contraste ou des jeux de couleurs personnalisés peuvent avoir des substitutions de couleurs au niveau du système. Dans de tels environnements, les couleurs définies par l’auteur peuvent être entièrement remplacées, rendant tout indice basé uniquement sur la couleur dénué de sens, indépendamment de la capacité de l’utilisateur à percevoir la couleur. De même, les utilisateurs qui impriment des documents en noir et blanc, ou accèdent au contenu sur des écrans monochromes à encre électronique, perdent toute différenciation par la couleur.

Au-delà du handicap, ce critère bénéficie à une large population : utilisateurs mobiles en extérieur en plein soleil, utilisateurs sur des écrans de faible qualité avec une mauvaise reproduction des couleurs, et personnes âgées dont la perception des couleurs diminue naturellement avec l’âge. Une utilisation accessible de la couleur améliore également le référencement de manière indirecte : les libellés textuels descriptifs ajoutés pour satisfaire ce critère fournissent un contenu sémantique supplémentaire que les moteurs de recherche peuvent indexer. Du point de vue de l’ergonomie, des libellés textuels explicites et des indices visuels en plus de la couleur réduisent la charge cognitive pour tous les utilisateurs en rendant la signification de l’interface redondante et renforcée.

Règles Axe-core associées

WCAG 1.4.1 nécessite des tests manuels, car les outils automatisés ne peuvent pas déterminer de manière fiable si la couleur est utilisée comme seul moyen de transmettre une information. Il s’agit d’un jugement sémantique et visuel : un outil automatisé peut détecter que deux éléments ont des couleurs différentes, mais il ne peut pas déterminer si ces couleurs sont le seul facteur de différenciation, ou si l’information portée par cette différence de couleur est également transmise par un autre mécanisme. L’outil devrait comprendre l’intention de conception et l’ensemble du contexte de rendu visuel pour pouvoir faire cette détermination.

• Test manuel requis — Distinction de la couleur des liens : Axe-core ne peut pas vérifier automatiquement si les liens dans le corps du texte sont distinguables du texte non cliquable environnant par un moyen autre que la couleur seule. Un testeur humain doit inspecter visuellement la page et confirmer que les liens disposent d’un indice non lié à la couleur supplémentaire (comme un soulignement, un poids de police en gras ou une icône visible) lorsqu’ils apparaissent en ligne dans des paragraphes de texte. Les outils automatisés peuvent détecter qu’un lien existe, mais pas si sa présentation visuelle repose uniquement sur une différence de teinte.
• Test manuel requis — États d’erreur de formulaire : Lorsqu’un champ de formulaire entre dans un état d’erreur, les outils automatisés ne peuvent pas déterminer si le changement visuel (comme une bordure ou un arrière-plan rouge) est la seule indication de l’erreur, ou s’il est accompagné d’une icône d’erreur, d’un message textuel ou d’un autre indice non lié à la couleur. Un testeur doit interagir avec le formulaire, déclencher des erreurs de validation et inspecter la manière dont l’erreur est communiquée visuellement.
• Test manuel requis — Visualisations de données : Les graphiques, diagrammes, cartes et schémas qui utilisent la couleur pour distinguer des catégories, des séries de données ou des régions ne peuvent pas être évalués automatiquement pour la conformité à 1.4.1. Un testeur humain doit vérifier si des motifs, des libellés ou des textures sont également présents pour différencier les éléments codés par couleur.
• Test manuel requis — Indicateurs de statut : Les badges, étiquettes et indicateurs de statut (comme les indicateurs en ligne/hors ligne ou les libellés d’état de commande) qui s’appuient sur la couleur pour communiquer l’état ne peuvent pas être signalés automatiquement. Le testeur doit confirmer que chaque statut est également transmis par un libellé textuel, une icône ou un changement de forme.

Comment tester

1. Analyse automatisée de base : Exécutez axe DevTools, Lighthouse ou le vérificateur d’accessibilité Accsible sur la page. Bien que ces outils ne signalent pas directement les violations de 1.4.1, ils peuvent faire apparaître des problèmes connexes tels que l’absence d’alternatives textuelles, un contraste insuffisant ou l’absence de libellés de formulaire qui sont corrélés à une utilisation de la couleur seule. Notez les problèmes signalés et utilisez-les comme points de départ pour l’inspection manuelle. Dans axe DevTools, ouvrez l’extension de navigateur, cliquez sur « Analyze » et examinez la catégorie « Needs Review » en plus de la liste des violations, car certains problèmes liés à la couleur peuvent y apparaître.
2. Simulation en niveaux de gris : Utilisez une extension de navigateur ou une fonctionnalité d’accessibilité du système d’exploitation pour afficher la page en niveaux de gris (saturation nulle). Sur macOS, allez dans Réglages du système > Accessibilité > Affichage et activez « Utiliser les niveaux de gris ». Sur Windows, allez dans Paramètres > Options d’ergonomie > Filtres de couleur et sélectionnez « Niveaux de gris ». Vous pouvez aussi utiliser les outils de développement du navigateur : dans Chrome, ouvrez DevTools, appuyez sur Ctrl+Maj+P (ou Cmd+Maj+P sur Mac), tapez « Emulate vision deficiencies » et sélectionnez « Achromatopsia ». Passez en revue chaque élément interactif, indicateur de statut, champ de formulaire, graphique et lien en niveaux de gris et confirmez que toutes les informations restent compréhensibles sans la couleur.
3. Simulation du daltonisme : Utilisez l’émulateur de déficience visuelle de Chrome DevTools (même chemin que ci-dessus) pour simuler la deutéranopie, la protanopie et la tritanopie. Pour chaque simulation, parcourez tous les parcours utilisateurs — soumission de formulaire avec erreurs, interprétation de données dans des graphiques, navigation entre états actifs et inactifs — et vérifiez qu’aucune information n’est perdue. Des outils comme le simulateur de daltonisme Coblis ou Colour Oracle (une application de bureau) peuvent également être utilisés pour simuler le daltonisme sur l’ensemble de l’écran.
4. Liens dans le corps du texte — vérification manuelle : Identifiez tous les hyperliens qui apparaissent dans des paragraphes de texte courant (par opposition aux menus de navigation ou aux listes de liens autonomes). Pour chacun de ces liens, confirmez qu’il est visuellement distinguable du texte non cliquable environnant par au moins un mécanisme non lié à la couleur. Le mécanisme acceptable le plus courant est le soulignement. Si le lien repose uniquement sur une différence de couleur, c’est un échec.
5. Validation de formulaire — vérification manuelle : En utilisant la navigation au clavier (Tab pour déplacer le focus, Entrée ou Espace pour activer les contrôles), remplissez un formulaire et laissez délibérément des champs obligatoires vides ou saisissez des données invalides. Soumettez le formulaire. Inspectez visuellement la manière dont les erreurs sont communiquées. Confirmez que l’indication d’erreur n’est pas fournie par la couleur seule : chaque erreur doit avoir une description textuelle visible, une icône, ou les deux, en plus de tout changement de couleur.
6. Vérification avec lecteur d’écran (NVDA + Firefox) : Ouvrez la page dans Firefox avec NVDA en cours d’exécution. Parcourez tous les champs de formulaire, graphiques et indicateurs de statut à l’aide du curseur virtuel. Confirmez que les messages d’erreur, les libellés de statut et les descriptions de données sont annoncés par le lecteur d’écran. Cela valide la couche programmatique, même si l’accès via lecteur d’écran seul ne satisfait pas l’exigence visuelle de 1.4.1 pour les utilisateurs daltoniens voyants.
7. Revue des graphiques et diagrammes : Pour chaque visualisation de données, essayez d’interpréter les données en utilisant uniquement la forme, le motif ou les libellés textuels, en ignorant délibérément la couleur. Si la visualisation devient ininterprétable sans la couleur, elle échoue. Confirmez qu’une alternative textuelle (tableau de données, légende avec motifs, libellés de données directs) est disponible.

Comment corriger

Lien en ligne dans le corps du texte — Incorrect

<!-- Link is distinguishable from surrounding text only by color.
     A user with color blindness cannot identify it as a link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
  before continuing.
</p>

Lien en ligne dans le corps du texte — Correct

<!-- Link is underlined in addition to being a different color.
     The underline provides a non-color visual cue that identifies it as a link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
  before continuing.
</p>

État d’erreur de formulaire — Incorrect

<!-- Error is communicated only by a red border.
     A color-blind user cannot distinguish this from a normal field. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->

État d’erreur de formulaire — Correct

<!-- Error is communicated by a red border AND a visible error icon AND a text message.
     The text message is also linked via aria-describedby for assistive technology. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
/>
<p id='email-error' class='error-message'>
  <svg aria-hidden='true' focusable='false' class='error-icon'>
    <!-- error icon SVG path data -->
  </svg>
  Please enter a valid email address.
</p>

Légende de graphique basée uniquement sur la couleur — Incorrect

<!-- Bar chart where categories are differentiated by fill color alone.
     Users with color blindness cannot distinguish the categories. -->
<svg role='img' aria-label='Quarterly sales by region'>
  <rect x='10' y='50' width='40' height='100' fill='#e63946' />
  <rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
  <rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch red'></span> North</li>
  <li><span class='swatch green'></span> South</li>
  <li><span class='swatch yellow'></span> West</li>
</ul>

Légende de graphique basée uniquement sur la couleur — Correct

<!-- Bars use both distinct colors AND distinct pattern fills (via SVG patterns).
     Legend items include a text label. An accessible data table is also provided. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
  <defs>
    <pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
      <line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
    </pattern>
    <pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
      <circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
    </pattern>
    <pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
      <rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
    </pattern>
  </defs>
  <rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
  <rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
  <rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
  <li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
  <li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
  <caption>Quarterly sales by region (data table)</caption>
  <thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
  <tbody>
    <tr><td>North</td><td>100</td></tr>
    <tr><td>South</td><td>130</td></tr>
    <tr><td>West</td><td>80</td></tr>
  </tbody>
</table>

Badge de statut — Incorrect

<!-- Order status communicated only by background color.
     "Pending" (yellow), "Shipped" (blue), and "Delivered" (green) are
     visually identical to many color-blind users. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>

Badge de statut — Correct

<!-- Status is communicated by color AND a visible text label.
     The text label is the primary conveyor of meaning. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>

Erreurs courantes

• Supprimer les soulignements des liens en ligne et se fier uniquement à la couleur : Appliquer text-decoration: none aux éléments d’ancrage à l’intérieur des paragraphes de texte courant est l’un des échecs 1.4.1 les plus fréquents. Le soulignement est l’indice non lié à la couleur par défaut pour les liens ; le supprimer sans ajouter un autre différenciateur non lié à la couleur (comme un poids de police en gras ou une icône) entraîne un échec immédiat chaque fois que ce lien apparaît dans un texte environnant d’une couleur différente.
• Utiliser des paires de couleurs rouge/vert pour les états réussite/échec sans icônes ou texte supplémentaires : Le rouge pour l’échec et le vert pour la réussite est culturellement intuitif mais inaccessible pour les utilisateurs atteints de deutéranopie ou de protanopie, qui sont précisément les formes de daltonisme les plus courantes. Associez toujours ces couleurs à des icônes distinctes (une coche versus une croix) et à des libellés textuels explicites (« Valide » versus « Erreur »).
• Marquer les champs de formulaire obligatoires uniquement avec un astérisque coloré : Un astérisque rouge (*) à côté d’un libellé de champ communique le caractère obligatoire par la couleur si l’astérisque lui-même n’a pas de légende ou d’explication textuelle visible associée. La solution consiste à inclure une note visible telle que « * indique un champ obligatoire » près du formulaire, garantissant que l’astérisque lui-même porte une signification au-delà de sa couleur.
• Utiliser uniquement la couleur pour les états actif/sélectionné dans les menus de navigation : Mettre en évidence l’élément de navigation actuellement actif uniquement en modifiant sa couleur de texte ou d’arrière-plan — sans également changer le poids de la police, ajouter un soulignement ou un indicateur de bordure — signifie que les utilisateurs daltoniens ne peuvent pas identifier la page sur laquelle ils se trouvent.
• Info-bulles de graphiques qui répètent l’indice de couleur sans ajouter de libellés : Certaines bibliothèques de graphiques affichent des info-bulles qui montrent un échantillon de couleur correspondant à la série de données mais aucun libellé textuel pour le nom de la série. Si l’info-bulle est le seul endroit où les données sont désambiguïsées et qu’elle repose uniquement sur un échantillon de couleur, c’est un échec.
• Étapes de progression qui changent uniquement de couleur pour indiquer l’achèvement : Les assistants de formulaires multi-étapes stylisent souvent les étapes terminées avec un arrière-plan vert et les étapes à venir avec un arrière-plan gris. Si aucun texte (« Terminé », « En cours », « À venir ») ou icône (coche) n’accompagne le changement de couleur, l’état de l’étape est communiqué uniquement par la couleur.
• Se fier à la couleur du texte de l’espace réservé pour indiquer la validation de saisie : Modifier la couleur du texte d’espace réservé (par exemple, le rendre rouge en cas d’erreur) est à la fois un indice basé uniquement sur la couleur et inaccessible pour d’autres raisons (le texte d’espace réservé ne remplace pas les libellés ou les messages d’erreur). L’état de validation doit être communiqué par un élément de message d’erreur visible et persistant.
• Supposer que les libellés ARIA suffisent à satisfaire 1.4.1 : Ajouter aria-label ou aria-describedby à un élément rend l’information disponible pour les utilisateurs de lecteurs d’écran, mais 1.4.1 est un critère visuel. Il exige un indice visuel non lié à la couleur pour les utilisateurs daltoniens voyants, et pas seulement une alternative textuelle programmatique. Les deux sont nécessaires, mais ARIA seul ne permet pas de satisfaire 1.4.1.
• Distinguer des lignes ou cellules de tableau uniquement par des couleurs d’arrière-plan alternées : Bien que l’alternance de couleurs de lignes (zébrage) soit généralement décorative et ne constitue pas en soi un problème 1.4.1, tout tableau qui utilise uniquement la couleur d’arrière-plan pour regrouper, catégoriser ou mettre en évidence des lignes ou cellules spécifiques comme distinctes sur le plan informationnel doit fournir un libellé textuel, une icône ou un en-tête pour transmettre ce même regroupement ou cette même distinction.
• Considérer les indices basés uniquement sur la couleur comme exemptés parce qu’ils sont « simplement décoratifs » : Les développeurs soutiennent parfois qu’un point de couleur indiquant un statut ou une étiquette de catégorie colorée est décoratif plutôt qu’informationnel. Si la suppression de la couleur (ou l’affichage en niveaux de gris) entraîne la perte, pour l’utilisateur, d’une information dont il a besoin pour comprendre ou utiliser l’interface, il s’agit par définition d’une information et cela doit respecter 1.4.1.

Relation avec la réglementation d’accessibilité de la Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires d’accessibilité web et mobile alignées sur WCAG 2.2. WCAG 1.4.1 Utilisation de la couleur est un critère de niveau A, ce qui signifie qu’il relève du niveau de conformité de base obligatoire en vertu de cette circulaire.

La circulaire impose la conformité au niveau A de WCAG 2.2 dans un délai d’un an pour les institutions publiques et de deux ans pour les entités du secteur privé. Les catégories d’organisations suivantes sont explicitement couvertes : institutions publiques et organismes gouvernementaux, plateformes de commerce électronique, banques et institutions financières, hôpitaux et prestataires de soins de santé, opérateurs de télécommunications comptant 200,000 abonnés ou plus, agences de voyage agréées, entreprises de transport privées et écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

Pour ces entités, le non-respect de WCAG 1.4.1 constitue une violation réglementaire. Concrètement, une institution publique turque dont le portail web utilise uniquement la couleur pour indiquer les erreurs de formulaire, ou une banque dont l’interface de banque en ligne utilise des indicateurs de statut basés uniquement sur la couleur pour les états de transaction, serait en infraction avec les exigences de la circulaire. Les plateformes de commerce électronique — un secteur important et en forte croissance en Turquie — utilisent couramment des indicateurs de disponibilité de produits codés par couleur, des badges promotionnels et des messages d’erreur de panier, qui doivent tous fournir des alternatives non liées à la couleur conformément aux exigences de la circulaire.

La conformité à 1.4.1 est particulièrement impactante dans le contexte turc, compte tenu du nombre important d’utilisateurs accédant aux services publics, à la banque et au commerce électronique sur des appareils mobiles, où la qualité de l’écran et les conditions de luminosité ambiante réduisent encore la fiabilité de la couleur en tant que seul vecteur d’information. Il est conseillé aux organisations couvertes par la circulaire d’auditer toutes les utilisations de la couleur comme mécanisme d’information sur l’ensemble de leurs propriétés numériques, de donner la priorité à l’ajout de libellés textuels et d’indices iconographiques en plus des états codés par couleur, et d’inclure 1.4.1 à la fois dans les chaînes d’analyse d’accessibilité automatisées et dans des protocoles de test manuel structurés dans le cadre de leur programme de conformité.