Accessibilité web : plan de mise aux normes des contrastes

Accessibilité web: plan de mise aux normes des contrastes

Pourtant, un audit rapide sur un panel de sites e-commerce ou institutionnels révèle encore des textes en gris clair (#999999) sur fond blanc, des boutons dont la bordure se confond avec l’arrière-plan et des indicateurs de focus pratiquement invisibles.

Le problème n’est pas technique. Les ratios sont documentés, les outils existent et les méthodes de correction sont relativement simples. Ce qui manque le plus souvent, c’est un plan d’action qui traite les contrastes comme une contrainte de conception dès le premier pixel, et non comme un correctif cosmétique ajouté à la fin du projet.

La conformité en matière d’accessibilité numérique ne consiste donc pas à foncer tous les textes ni à lancer un scan automatique avant la mise en production. Elle demande de comprendre ce qui doit être mesuré, dans quel contexte, et comment inscrire ces décisions dans le design system et le cycle de développement.

Les exigences du RGAA 4.1.2: ratios et seuils de conformité

Le Référentiel général d’amélioration de l’accessibilité (RGAA) 4.1.2 reprend, sur ce point, les exigences des WCAG 2.1 au niveau AA. Deux valeurs structurent le travail sur les contrastes:

La taille ne suffit pas à elle seule à faire passer un texte dans la catégorie « grand texte ». Il faut également tenir compte de la graisse et de la manière dont le texte est effectivement rendu. Un titre défini à 20 px dans la maquette reste soumis au seuil de 4,5:1, même s’il paraît visuellement imposant par rapport au corps de texte.

Le RGAA distingue par ailleurs le contraste des textes de celui des éléments graphiques et des composants d’interface. Une bordure de champ, une icône informative ou un indicateur de focus n’est pas décoratif dès lors qu’il aide l’utilisateur à comprendre la structure ou l’état de l’interface.

Un ratio à recalculer, pas une couleur à juger à l’œil

Prenons un exemple fréquent: #767676 sur #FFFFFF. Cette combinaison produit un ratio d’environ 4,54:1. Elle passe donc tout juste le seuil de 4,5:1 applicable au texte courant.

La différence avec la teinte voisine #757575 est souvent mal interprétée. Cette dernière est légèrement plus sombre et produit un ratio d’environ 4,61:1 sur fond blanc: elle reste donc au-dessus du seuil. À l’inverse, #777777 sur blanc tombe autour de 4,48:1 et devient légèrement non conforme pour du texte courant.

Ce type d’écart illustre le problème des validations « à l’œil ». Deux gris peuvent sembler identiques dans une maquette et se retrouver de part et d’autre du seuil réglementaire. Il ne faut pas non plus confondre le ratio avec une note de lisibilité globale: un texte peut satisfaire le ratio tout en restant inconfortable dans une petite taille, une graisse très fine ou un environnement très lumineux.

Un ratio de 4,54:1 et un ratio de 4,48:1 se ressemblent à l’écran. Pour un contrôle de conformité, ils ne racontent pourtant pas la même histoire.

Comment calculer concrètement

Deux approches se complètent.

• Les outils de mesure: Colour Contrast Analyser de TPGi permet de tester les combinaisons directement sur le bureau. Le vérificateur de contraste de WebAIM convient aux contrôles rapides et aux premières explorations de palette.
• L’intégration dans le processus de design: dans Figma, des extensions comme Contrast ou Stark permettent de vérifier une combinaison directement sur la maquette. L’enjeu est de placer cette vérification au moment où les couleurs sont choisies, pas après la validation visuelle de l’écran.

Le calcul compare la luminance relative de la couleur de premier plan et celle de l’arrière-plan. Il ne suffit donc pas de mesurer « le gris du texte » une fois pour toutes: il faut examiner chaque association réellement utilisée. Un même gris secondaire peut être acceptable sur un fond blanc et insuffisant sur un fond légèrement teinté, un gris de surface ou une image.

Dans un design system, la bonne pratique consiste à associer les couleurs par rôle:

• texte principal sur fond de page;
• texte secondaire sur fond de page;
• texte dans les cartes et surfaces secondaires;
• texte d’un bouton sur sa couleur d’action;
• icône sur fond de composant;
• état d’erreur ou de succès;
• bordure et état de focus.

Cette matrice rend visibles les combinaisons qui échappent aux contrôles réalisés sur un seul écran.

Les confusions qui reviennent dans les audits

Plusieurs raccourcis produisent régulièrement des non-conformités.

« 3:1 suffit pour les titres. »

Uniquement si le titre entre réellement dans la catégorie du grand texte. Un intertitre à 18 px en graisse normale reste soumis au seuil de 4,5:1. De même, une taille généreuse ne dispense pas de tester la graisse et le rendu effectif de la police.

« Les couleurs de marque passent toujours. »

Une couleur identitaire n’est pas automatiquement une couleur de texte. Un violet, un orange ou un vert choisi pour un aplat de communication peut être parfaitement pertinent pour une surface et trop clair pour du texte courant. Il faut parfois conserver la couleur de marque pour les éléments décoratifs et créer une déclinaison plus sombre pour les contenus informatifs.

« Le contraste concerne uniquement les lettres. »

Le contraste des composants compte aussi: bordures de champs, contours de boutons, icônes indispensables à la compréhension, indicateurs de focus et éléments graphiques porteurs d’information.

« Une couleur claire sur une image est acceptable si le visuel est joli. »

Un texte posé sur une photographie ou un dégradé ne bénéficie pas d’un fond uniforme. La partie de l’image située derrière chaque portion de texte peut changer le contraste. Il faut prévoir un aplat, une couche de protection, une zone de texte distincte ou une autre composition.

Composants d’interface et lisibilité: les règles invisibles

Le contraste des composants est souvent découvert tard, parce que les équipes mesurent d’abord les paragraphes et les titres. Pourtant, un utilisateur peut rencontrer davantage de difficultés avec un champ qu’il ne distingue pas, un bouton dont l’état actif est imperceptible ou un focus qui disparaît sur une surface colorée qu’avec un texte légèrement trop clair.

Les éléments concernés

Un composant d’interface est un élément avec lequel l’utilisateur interagit ou dont il dépend pour comprendre une action, un état ou une information. Cela inclut notamment:

• les bordures et contours des champs de formulaire;
• les boutons et leurs changements d’état;
• les cases à cocher, boutons radio, interrupteurs et curseurs;
• les icônes fonctionnelles, comme une loupe, un panier ou un chevron;
• les indicateurs de focus visibles au clavier;
• les graphiques, courbes et pictogrammes qui transmettent une donnée;
• les séparateurs lorsqu’ils servent à comprendre la structure de l’information.

La bordure d’un champ en #E0E0E0 sur fond blanc ne présente pas un ratio d’environ 1,8:1, comme on le lit parfois: le rapport réel est proche de 1,32:1. Il est donc très inférieur au seuil de 3:1 attendu pour un composant qui doit être distingué de son environnement.

Cela ne signifie pas que toutes les bordures doivent être épaisses ou très sombres. Un champ peut aussi être identifié par une surface, une étiquette persistante, un espacement et une structure suffisamment marquée. Mais si la bordure est utilisée comme indice principal de la zone de saisie, elle doit rester perceptible.

Ne pas supprimer l’information dans les états

Un composant ne se résume pas à son état initial. Il faut vérifier au minimum:

• repos;
• survol;
• focus clavier;
• activation;
• erreur;
• succès;
• désactivation;
• sélection ou ouverture.

La couleur d’un bouton au repos peut être conforme, puis devenir illisible à l’état désactivé parce que l’interface applique automatiquement une opacité. Un lien peut être visible dans un paragraphe et perdre son contraste au survol si une couleur plus claire est utilisée. Un contour de focus peut convenir sur fond blanc et disparaître entièrement sur une section bleu sombre.

Le focus mérite une attention particulière. Il ne doit pas être supprimé uniquement parce qu’il gêne la direction artistique. Si l’outline natif est remplacé, le nouvel indicateur doit être visible sur les fonds réellement présents dans l’interface. Une simple variation subtile de couleur ne suffit pas toujours; une bordure, un halo ou une combinaison de deux signes visuels peut être plus robuste.

Le contraste ne remplace pas les autres indices

La couleur ne doit pas être le seul moyen de distinguer une information. Une erreur de formulaire signalée uniquement par un texte rouge reste difficile à interpréter pour certaines personnes. Il faut associer la couleur à un message, une icône ou une indication textuelle explicite.

Même logique pour les graphiques: cinq courbes de couleurs différentes ne constituent pas une visualisation solide si les teintes sont proches ou si l’utilisateur ne peut pas identifier chaque série autrement. Des motifs, des libellés directs, des styles de ligne ou des marqueurs peuvent compléter la palette.

Pour cartographier correctement un formulaire ou un tunnel de conversion, la méthode est simple:

1. Identifier chaque élément interactif et chaque indice visuel nécessaire à sa compréhension.

2. Mesurer sa couleur par rapport au fond immédiatement adjacent, et non par rapport au fond général de la page.

3. Tester les états clavier, survol, erreur, sélection et désactivation.

4. Vérifier les icônes sans leur libellé lorsque l’icône porte une information autonome.

5. Refaire le parcours avec un zoom élevé, une luminosité réduite et différents écrans.

Cette cartographie peut être réalisée une fois pour un design system, puis entretenue grâce aux tokens de couleur et aux composants documentés. Le gain ne vient pas seulement du premier audit: il vient du fait que la même erreur ne réapparaît pas dans chaque nouvelle page.

Sanctions financières et responsabilités: le rôle de l’Arcom

La conformité n’est pas uniquement une question de rendu visuel. Elle implique aussi une organisation, une documentation et une répartition claire des responsabilités.

Le cadre français prévoit notamment des sanctions financières pouvant atteindre 50 000 € pour certains manquements liés à l’accessibilité d’un service en ligne, avec un renouvellement possible lorsque la situation perdure. L’absence de déclaration d’accessibilité ou de documents de pilotage peut également exposer l’organisme concerné à une sanction spécifique.

Les obligations ne se présentent pas exactement de la même manière pour tous les acteurs. Les organismes publics, les collectivités, les établissements concernés et certaines entreprises privées doivent examiner leur situation au regard des textes applicables et de leur activité. Une agence ou un intégrateur ne porte pas nécessairement la responsabilité juridique principale, mais sa prestation peut être déterminante dans la conformité finale du service.

Le rôle de l’Arcom

L’Arcom intervient dans le dispositif de contrôle prévu pour certains services numériques. Le processus peut s’appuyer sur un constat, un signalement ou une vérification, puis conduire à une demande de mise en conformité et, si le manquement persiste, à une sanction.

Dans un projet web, cette dimension change la façon de travailler. Le commanditaire ne peut pas se contenter de demander « un site accessible » sans préciser les exigences attendues, les livrables et les modalités de contrôle. De son côté, le prestataire ne devrait pas présenter une simple déclaration d’intention comme une garantie de conformité.

Le contrat et le cahier des charges peuvent préciser:

• la version du RGAA prise comme référence;
• les composants et parcours inclus dans l’audit;
• les responsabilités respectives du design, du développement et de la rédaction;
• les tests manuels prévus en complément de l’automatisation;
• la gestion des contenus ajoutés après la mise en ligne;
• la procédure de correction et de recontrôle.

La conformité ne naît pas d’un dernier scan avant la publication. Elle se construit dans les décisions de conception, les composants réutilisés et la manière dont l’équipe traite les régressions.

La déclaration d’accessibilité joue également un rôle important. Elle doit présenter le statut du service, les contenus qui ne sont pas accessibles, les raisons de ces écarts, les moyens de contacter l’organisme et les voies de recours. Le schéma pluriannuel et le plan d’action donnent une visibilité sur la trajectoire de correction.

Un document honnête, qui décrit les limites connues et les travaux planifiés, est plus utile qu’une déclaration qui affirme une conformité générale sans démonstration. Il permet aux utilisateurs de comprendre la situation et aux équipes de disposer d’un cadre de suivi.

Vers le futur WCAG 3.0: comprendre l’algorithme perceptuel APCA

Le calcul actuel du contraste repose sur un ratio de luminance relative. Il a le mérite d’être reproductible et facile à intégrer dans les outils, mais il ne décrit pas toutes les situations de lecture. La taille, la graisse, la polarité et la durée d’exposition influencent pourtant la perception réelle.

Le W3C travaille sur WCAG 3.0, qui vise une approche plus nuancée de l’évaluation. L’algorithme APCA, pour Advanced Perceptual Contrast Algorithm, est souvent présenté dans ce contexte. Il exprime le contraste sous la forme d’une valeur de luminosité, généralement notée Lc, et tient davantage compte de la relation entre le texte et son arrière-plan.

Pourquoi APCA attire l’attention

Le ratio traditionnel traite les couleurs selon une formule générale. Il ne fait pas varier directement le seuil en fonction de la taille et de la graisse du texte. APCA cherche au contraire à mieux représenter la lisibilité perceptuelle:

Il faut toutefois éviter de transformer APCA en nouveau tableau de seuils définitifs. La méthode évolue encore, les recommandations d’usage ne constituent pas à elles seules une obligation juridique française et le futur cadre de conformité n’est pas réductible à un nombre unique.

Un texte noir sur fond bleu marine illustre une autre confusion fréquente. La combinaison peut sembler « extrême » parce que le noir et le bleu appartiennent à deux familles de couleurs différentes, mais leurs luminances sont proches. Le contraste est donc généralement faible, souvent autour de 1,1:1 à 1,5:1 selon la teinte exacte du bleu marine, et certainement pas proche de 12:1. Pour obtenir un contraste élevé sur un fond bleu sombre, il faut en général un texte très clair, et non du noir.

De la même manière, #999999 sur blanc produit un ratio d’environ 2,85:1, pas 2,1:1. Cette valeur reste insuffisante pour du texte courant selon le RGAA 4.1.2. Le fait qu’un titre soit affiché en 32 px ne permet pas de conclure automatiquement à sa conformité dans une future méthode APCA: il faudrait connaître la version de l’algorithme, le seuil appliqué, la graisse, la police et le contexte de lecture. La taille peut modifier l’évaluation, mais elle ne transforme pas mécaniquement un gris clair en choix accessible.

Préparer l’avenir sans abandonner le standard actuel

APCA peut être utile en phase exploratoire pour repérer les zones fragiles d’une palette et réfléchir à la hiérarchie typographique. Il ne doit cependant pas remplacer les vérifications fondées sur le RGAA 4.1.2 tant que celui-ci reste la référence applicable à votre projet.

La bonne approche consiste à conserver deux niveaux de lecture:

• valider aujourd’hui les combinaisons avec les critères actuellement applicables;
• observer les évolutions méthodologiques pour éviter de reconstruire demain une palette trop proche des limites.

Cette prudence est particulièrement importante pour les gris secondaires, les textes fins et les interfaces en mode sombre. Une palette qui passe de justesse le ratio actuel peut devenir difficile à maintenir dès qu’une nouvelle police, une nouvelle taille ou un nouvel arrière-plan est introduit.

Stratégie de mise en conformité: au-delà des outils automatiques

Un scan Axe ou Lighthouse détecte certains défauts de contraste entre le texte et son arrière-plan. C’est un bon point de départ, pas un audit complet.

Les outils automatiques ne comprennent pas toujours l’intention d’un composant. Ils peuvent manquer:

• le contraste d’une bordure de champ ou d’un indicateur d’état;
• les différences entre repos, survol, focus et désactivation;
• une icône qui devient indispensable lorsque le libellé disparaît sur mobile;
• un texte placé sur une image ou un dégradé variable;
• un élément dont la lisibilité dépend d’une superposition ou d’une transparence;
• une information transmise uniquement par la couleur.

Ils ne vérifient pas non plus tous les autres aspects de l’accessibilité: navigation au clavier, ordre de lecture, alternatives textuelles, intitulés de contrôles, sous-titrage ou compatibilité avec les technologies d’assistance. Le contraste est un point d’entrée mesurable, mais il ne constitue pas un audit RGAA complet.

Repartir du design system

La première étape consiste à dresser la liste des tokens de couleur utilisés dans l’interface. Il faut identifier leur rôle, et pas seulement leur valeur hexadécimale:

• texte principal;
• texte secondaire;
• texte désactivé;
• fond de page;
• fond de carte ou de champ;
• couleur d’action;
• couleur de lien;
• bordure;
• focus;
• erreur, alerte et confirmation.

Ensuite, chaque token doit être associé aux fonds sur lesquels il peut apparaître. Un token $text-secondary n’est pas « conforme » en soi: il l’est ou non selon le contexte où il est rendu.

La correction doit se faire au niveau des tokens plutôt qu’au niveau des occurrences. Si le gris secondaire est trop clair, modifier cinq écrans séparément crée une dette difficile à repérer. Modifier la valeur dans le système de conception permet de propager la correction aux composants, aux maquettes et, si l’architecture est bien structurée, au code.

Il faut néanmoins contrôler les effets secondaires. Assombrir un texte secondaire peut réduire l’écart avec un texte principal, modifier la hiérarchie visuelle ou rendre un bouton trop lourd. L’accessibilité ne consiste pas à maximiser tous les contrastes sans discernement. Elle consiste à construire une hiérarchie lisible, avec des différences suffisamment nettes et cohérentes.

Tester les composants dans leur contexte réel

Après la palette, vient le test des composants. Pour chacun, vérifiez les états qui existent réellement dans le produit. Un formulaire de paiement, une navigation principale et une liste filtrable ne mobilisent pas les mêmes états ni les mêmes risques.

Sur un bouton, contrôlez le texte, le fond, l’icône éventuelle et le changement d’état. Sur un champ, contrôlez la bordure, le libellé, le texte saisi, le texte indicatif, le message d’erreur et le focus. Sur une icône, demandez-vous si elle est décorative ou si elle porte une information que l’utilisateur doit percevoir.

Les images et les dégradés exigent une approche spécifique. Il peut être nécessaire d’ajouter un voile sombre, de déplacer le texte vers une zone plus uniforme, d’insérer une surface opaque ou de revoir complètement la composition. Une solution qui fonctionne sur la photographie de la maquette peut échouer dès que le visuel est remplacé par une autre image.

Automatiser la régression, sans automatiser le jugement

Les tests de contraste peuvent être intégrés à la chaîne d’intégration et de déploiement. Des outils comme @axe-core/cli ou pa11y peuvent signaler certains écarts et empêcher qu’une modification introduise un défaut connu.

Il faut cependant définir ce que le test couvre. Un outil lancé sur la page d’accueil ne vérifiera pas nécessairement un état d’erreur inaccessible dans un formulaire, un menu ouvert au clavier ou une modale affichée après une action. Les scénarios doivent donc inclure des états représentatifs, avec des données réalistes.

Le contrôle humain reste indispensable pour répondre à des questions que le ratio ne résout pas:

• Le focus est-il repérable pendant une navigation rapide?
• La hiérarchie entre texte principal et texte secondaire reste-t-elle claire?
• Les informations importantes sont-elles encore compréhensibles sans la couleur?
• Les éléments d’une image ou d’un graphique sont-ils identifiables?
• La lecture est-elle confortable sur un écran peu lumineux ou très contrasté?

L’objectif n’est pas d’opposer outils et expertise. Les outils réduisent le volume des vérifications répétitives; l’expertise permet d’interpréter les résultats et de repérer les situations qu’un calcul isolé ne voit pas.

Passer de la correction ponctuelle à une pratique durable

Une mise aux normes réussie ne se termine pas lorsque les couleurs sont validées. Les contenus évoluent, les équipes changent, de nouveaux composants apparaissent et les campagnes marketing réintroduisent parfois des teintes que le design system avait écartées.

Pour éviter ce retour en arrière, documentez les choix de palette avec des exemples d’usage. Une documentation utile ne dit pas seulement « utiliser le bleu principal ». Elle précise:

• sur quels fonds le bleu peut être utilisé comme texte;
• quand il doit être réservé à une surface ou à une bordure;
• quelle couleur employer pour le texte d’un bouton;
• comment traiter les états de focus et d’erreur;
• quelles combinaisons sont interdites;
• comment vérifier une nouvelle couleur avant de l’ajouter.

Le même principe vaut pour les maquettes. Une bibliothèque de composants accessible ne doit pas exposer uniquement l’état par défaut. Les variantes de focus, d’erreur, de désactivation et de sélection doivent être visibles et utilisables par l’équipe produit.

La formation joue aussi un rôle concret. Les designers n’ont pas besoin de devenir spécialistes de la réglementation pour éviter les erreurs les plus courantes, mais ils doivent savoir pourquoi un gris est choisi, comment un ratio se lit et pourquoi une bordure ou une icône peut être soumise à une exigence différente du texte.

Enfin, le suivi doit être intégré au calendrier du produit. Un contrôle de contraste à chaque nouvelle fonctionnalité, complété par un audit manuel périodique, coûte moins cher qu’une reprise globale après plusieurs mois de dérive.

L’accessibilité des contrastes n’est pas un sujet de « design inclusif » abstrait. C’est une contrainte technique mesurable, un risque juridique à encadrer et une décision de conception qui touche directement la compréhension de l’interface. Un champ identifiable réduit l’hésitation. Un focus visible sécurise la navigation au clavier. Une palette pensée pour plusieurs contextes reste lisible sur un écran lumineux, en faible luminosité et dans un mode sombre correctement conçu.

L’accessibilité numérique, le design d’interface et l’ergonomie ne sont pas trois objectifs concurrents. Lorsqu’ils sont traités au même moment, ils décrivent le même travail: rendre l’action évidente, l’information lisible et l’interface fiable.