Pour tester l’accessibilité, on se base sur des référentiels comme les WCAG (Web Content Accessibility Guidelines) du W3C ou le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) applicable en France (voir à ce sujet l’article de Marc Hage Chahine).
Parmi les vérifications, ils prescrivent entre autres de vérifier le contraste entre le premier plan (le texte, les objets graphiques et les éléments UI) et l’arrière-plan (le fond sur lequel ils s’affichent), pour garantir leur visibilité par tous, même dans des conditions dégradées.
Ces tests, les sites n’affichant que des éléments noirs sur fond blanc (ou l’inverse) les passent haut la main.
Cependant, l’objectif du RGAA n’est pas d’imposer des sites noirs et blancs ni d’empêcher les designers d’utiliser des palettes subtiles !
L’objectif réel est de faire en sorte que la perception d’une information ou l’utilisation d’un composant ne dépende pas d’une capacité visuelle que tous les utilisateurs ne possèdent pas au même niveau.
Dans une recette classique, on recherche ce qui se passe avec une donnée incorrecte, une valeur extrême, une interruption réseau ou un navigateur différent. Sur une interface, on vérifie que les éléments sont correctement placés, que les couleurs utilisées respectent la charte graphique décrite dans les Spécifications.
Dans une recette d’accessibilité, on ajoute une autre question :
« Cette interface reste-t-elle réellement utilisable par des personnes qui ne la perçoivent pas comme moi ? »
Pour y répondre, il faut pouvoir se mettre à la place d’un utilisateur différent, et vérifier le contraste de luminance est un des moyens de s’assurer que l’interface est perceptible par le plus grand nombre.
Contraste de luminance, de quoi parle-t-on ?
La luminance d’une couleur correspond à la quantité de lumière émise par l’écran pour cette couleur. Plus sa luminance est élevée, plus la couleur apparaît lumineuse.
Le contraste de luminance correspond à la différence de luminance entre deux couleurs ou deux zones affichées à l’écran.
Plus cette différence est importante, plus les éléments se distinguent visuellement les uns des autres.
C’est ce contraste qui doit être mesuré lors des tests d’accessibilité pour répondre aux prescriptions du RGAA (et du WCAG): Typiquement, on mesure un rapport entre la couleur du premier plan (le texte, un composant UI, un objet graphique) et l’arrière-plan (le « fond » sur lequel il est affiché).
La valeur de ce rapport varie entre 1/1 (blanc sur blanc, noir sur noir, aucune différence entre les deux plans, le texte est « invisible » sur le fond) et 21/1 (noir sur blanc, ou blanc sur noir, la différence maximale possible, le texte est parfaitement visible pour tous).
En pratique, c’est plutôt simple. On peut, par exemple, utiliser Colour Contrast Analyser (un outil gratuit créé et géré par TPGi, qui opère elle-même sous la bannière de sa maison mère, Vispero)
Il suffit de sélectionner à la pipette un pixel de chacune des deux couleurs dont on veut évaluer le contraste (ou d’en spécifier la valeur, en hexadécimal ou de nombreux autres formats). L’outil affiche la valeur de contraste et sa conformité aux niveaux AA et AAA des WCAG, pour du texte « normal », du texte « grand » et des composants UI ou objets graphiques.
Une autre solution est de réaliser de savants calculs (voir la méthode en fin d’article), mais … cela risque d’être fastidieux !
3 sujets évoqués ci-dessus méritent d’être creusés :
- Qu’entend-on par texte normal et texte grand ?
- Quel niveau doit-on viser, AA ou AAA ?
- Quelles sont les valeurs de contraste à respecter ?
Lors des tests d’accessibilité, deux couleurs très différentes ne sont pas nécessairement deux couleurs suffisamment contrastées. Le testeur ne mesure pas leur différence de couleur : il mesure leur différence de luminance.
Texte normal ou texte grand ?
De nombreux testeurs définissent (à tort) le texte « grand » comme la taille de texte utilisé pour les titres (balises <H1>, <H2>, <H3>) et le texte normal comme la taille utilisée pour les paragraphes (<p>).
La réalité est un peu plus complexe.
En effet, selon les directives des WCAG (Web Content Accessibility Guidelines), la distinction entre « grand texte » (large text) et « texte normal » dépend à la fois de la taille de la police et de sa graisse (son épaisseur).
Historiquement, les WCAG utilisent les « points » (pt) pour définir la taille.
Sur le web, la conversion standard considère que 1 pt = 1,333 px.
Ainsi, 14 pt correspond environ à 18,5 px, et 18 pt correspond à 24 px.
Voici les règles de conversion en pixels (px) et en points (pt) :
| Type de texte | Taille (Style normal) | Taille (Style gras / Bold) |
| Texte normal | Moins de 24 px (18 pt) ou police fine (« light ») | Moins de 18,5 px (14 pt) |
| Grand texte | 24 px (18 pt) et plus | 18,5 px (14 pt) et plus |
La graisse, sur le web, est définie par :
- les attributs HTML : <strong> qui indique une importance sémantique forte, <b> qui attire l’attention visuelle sans ajouter d’importance sémantique, <h1> à <h6> (Balises de titres) et <th> appliquée aux cellules d’en-tête dans les tableaux.
- la propriété CSS font-weight avec des valeurs numériques standard sur une échelle allant de 100 à 900 (par pas de 100)
- Des mots-clés CSS : Les valeurs textuelles normal (équivalent à 400), bold (700), ou relatives comme bolder (plus gras que le parent) et lighter (plus fin)
Ainsi, définir s’il s’agit de texte normal ou grand nécessite de prendre en compte à la fois la taille (en pixels) et la graisse définie par le style.
Le contraste de luminance à respecter sera différent en fonction de cette distinction.
Niveau AA ou AAA ?
Pourquoi viser le Niveau AA ?
- Pour des raisons de conformité réglementaire : C’est le niveau légalement requis en France (RGAA) et en Europe (European Accessibility Act).
- Pour un meilleur équilibre design / accessibilité : Il supprime les principaux obstacles d’accès pour les personnes en situation de handicap tout en laissant une vraie liberté créative et ergonomique.
- Pour une large compatibilité : La majorité des bibliothèques d’interface (UI frameworks) et des outils de design actuels sont conçus pour respecter ce seuil.
Quand intégrer le Niveau AAA ?
- Applications ciblées : Pour des plateformes destinées prioritairement à des publics âgés ou ayant des déficiences visuelles sévères.
- Améliorations ponctuelles : Le W3C déconseille d’exiger le niveau AAA pour tout un site, mais on peut appliquer certains critères AAA au cas par cas (ex: maximiser le contraste des boutons d’action ou bannir les interruptions de session).
La stratégie la plus efficace consiste à sécuriser un niveau AA à 100 %, puis à piocher dans les critères AAA les plus faciles à intégrer dans le projet.
Par exemple, pour les media audio/vidéo, les exigences diffèreront :
- Niveau AA → Sous-titres et audiodescription pré-enregistrés
- Niveau AAA → Langue des signes (LSF) et audiodescription en direct
Quelles sont les valeurs de contraste à respecter ?
Une fois que la distinction texte normal/grand est établie, et que le niveau d’exigence est déterminé, les valeurs minimales sont claires :
| Type de texte | Rapports de contraste requis | |
| Niveau AA | Niveau AAA | |
| Texte normal | 4.5:1 | 7:1 |
| Grand texte | 3:1 | 4.5:1 |
Le contrôle du contraste devient alors un très bon exemple d’application concrète à l’accessibilité de l’analyse des valeurs limites.
Voici un exemple d’étude du contraste de 6 couleurs proches sur un fond gris identique (#E3E3E3).
Ces 6 nuances de bleu sont basées sur une même teinte de bleu-indigo (température ~225°), avec une saturation presque constante (~70 %).
Visuellement, les couleurs des caractères (1ère colonne) sont extrêmement proches … mais les résultats des tests sont catégoriques : OK ou KO.
Pas de place pour l’appréciation subjective « Ça me paraît lisible, donc ça doit être accessible » !
Qui peut être gêné par un contraste insuffisant ?
Lorsque l’on parle d’accessibilité, on pense parfois immédiatement aux personnes aveugles. Pourtant, les contrôles de contraste ne leur sont pas directement destinés : une personne qui ne perçoit pas visuellement l’écran utilisera généralement d’autres moyens d’accès au contenu, comme un lecteur d’écran.
Les exigences de contraste concernent avant tout les personnes qui utilisent leur vision pour consulter l’interface, mais dont les capacités visuelles sont réduites. Le W3C souligne notamment que les personnes malvoyantes peuvent éprouver des difficultés à lire un texte lorsque sa luminance est trop proche de celle de son arrière-plan. Cette difficulté peut encore être accentuée lorsqu’une déficience de la vision des couleurs est également présente.
Les personnes malvoyantes
La malvoyance recouvre des situations très diverses. Une personne peut conserver une vision suffisante pour utiliser directement un écran tout en présentant une acuité visuelle réduite ou une moindre sensibilité aux différences de luminosité.
Imaginons par exemple un texte gris clair sur fond blanc. Une personne ayant une bonne acuité visuelle pourra encore reconnaître assez facilement la forme des caractères. Pour une personne dont la sensibilité au contraste est plus faible, les contours des lettres risquent au contraire de se confondre progressivement avec l’arrière-plan.
C’est précisément l’une des raisons pour lesquelles les WCAG imposent un rapport minimal entre les luminances du texte et du fond.
Les personnes dont la vision des couleurs est altérée
Certaines personnes distinguent difficilement certaines couleurs : rouge et vert, bleu et violet, ou d’autres combinaisons selon le type de déficience.
Il faut toutefois éviter une confusion : le daltonisme et le manque de contraste sont deux problèmes différents.
Deux couleurs peuvent être difficiles à distinguer par leur teinte tout en présentant un contraste de luminance important. À l’inverse, deux couleurs très différentes peuvent avoir des luminances suffisamment proches pour rendre un texte difficile à lire.
C’est justement l’intérêt du contraste de luminance : il ne repose pas uniquement sur la capacité de l’utilisateur à reconnaître les couleurs. Le W3C précise qu’un contraste de luminance suffisant améliore la lisibilité même lorsque l’utilisateur ne perçoit pas l’ensemble du spectre des couleurs.
On peut noter aussi qu’un outil comme Colour Contrast Analyzer propose un simulateur de daltonisme, permettant de prévisualiser ce que percevront les différents types de daltoniens .
Les personnes âgées
La sensibilité au contraste peut également diminuer avec l’âge, sans qu’une personne se considère nécessairement comme malvoyante.
Le vieillissement peut notamment s’accompagner d’une diminution de l’acuité visuelle, de la perception des couleurs et de la sensibilité au contraste. Le W3C identifie explicitement ces évolutions parmi les difficultés pouvant affecter l’utilisation du Web par les personnes âgées.
C’est d’ailleurs l’une des justifications du seuil de 4,5:1 retenu pour le niveau AA des WCAG : il vise notamment à compenser une perte modérée d’acuité et de sensibilité au contraste.
Le seuil renforcé de 7:1 du niveau AAA répond à des pertes visuelles plus importantes.
Et finalement… presque tout le monde dans certaines circonstances
Un contraste suffisant ne bénéficie cependant pas uniquement aux personnes présentant une déficience permanente.
Prenons un utilisateur ne présentant aucune difficulté visuelle particulière et plaçons-le :
- devant un ordinateur portable dont la luminosité est faible ;
- avec un écran de qualité médiocre ;
- sur une terrasse avec le soleil qui se reflète sur son smartphone ;
- devant un vidéoprojecteur dont l’image manque de luminosité ;
- ou simplement en situation de fatigue visuelle.
Le petit texte gris pâle que le graphiste trouvait très élégant peut soudain devenir beaucoup moins confortable à lire.
Il s’agit ici non plus nécessairement d’un handicap permanent, mais d’une situation d’usage qui dégrade temporairement les conditions de perception.
Pour le testeur, la conclusion est donc importante :
Tester le contraste, ce n’est pas vérifier le confort visuel d’un utilisateur théorique doté d’une vision parfaite.
C’est vérifier que l’information reste perceptible malgré la diversité réelle des capacités visuelles et des conditions d’utilisation.
Ce n’est pas se demander : « Est-ce que moi, je réussis à lire ce texte ? »
Mais c’est se poser objectivement la question :
« Le contraste mesuré respecte-t-il le niveau nécessaire pour que cette information reste accessible à des utilisateurs dont la perception visuelle peut être moins performante que la mienne ? »
C’est précisément pourquoi le RGAA transforme cette question subjective en critères mesurables, notamment avec des rapports minimaux de contraste pour les textes, les composants d’interface et certains éléments graphiques.
Et comme promis, la méthode de calcul complète (et complexe)
À partir de deux couleurs hexadécimales, le calcul WCAG se fait en trois étapes : convertir les valeurs hexadécimales en RGB normalisé, calculer la luminance relative de chaque couleur, puis calculer leur rapport de contraste.
Prenons deux couleurs :
- couleur de premier plan : #1E40A5
- couleur d’arrière-plan : #E3E3E3
Pour rappel, le code hexadécimal d’une couleur code 3 valeurs de 2 caractères pour chacun des 3 canaux RGB (Red/Green/Blue)
- Convertir les valeurs hexadécimales en RGB normalisé
Il faut d’abord convertir chaque composante hexadécimale en valeur décimale comprise entre 0 et 255, puis la normaliser entre 0 et 1 :
R_{sRGB}=\frac{R_{8bit}}{255}
G_{sRGB}=\frac{G_{8bit}}{255}
B_{sRGB}=\frac{B_{8bit}}{255}
Pour la couleur de premier plan #1E40A5 :
- R = 1E = 30 → 30/255 ≈ 0,1176
- G = 40 = 64 → 64/255 ≈ 0,2510
- B = A5 = 165 → 165/255 ≈ 0,6471
Pour la couleur d’arrière-plan #E3E3E3 :
- R = E3 = 227 → 227/255 ≈ 0,8902
- G = E3 = 227 → 227/255 ≈ 0,8902
- B = E3 = 227 → 227/255 ≈ 0,8902
- Linéariser chacune des trois composantes
Pour chaque composante C_{sRGB} on applique la formule :
Plus simplement, si on utilise une formule Excel, en supposant la valeur en cellule A1 :
=SI(A1<=0,04045; A1/12,92; ((A1+0,055)/1,055)^2,4
Cette étape est indispensable. On ne peut pas simplement appliquer directement les coefficients 21 %, 72 % et 7 % aux valeurs RGB comprises entre 0 et 255.
Pour #1E40A5, après linéarisation :
R ≈ x 0,0130 / G ≈ 0,0513 / B ≈ 0,3763
Pour #E3E3E3, les trois composantes étant identiques :
R ≈ G ≈ B ≈ 0,7682
- Calculer la luminance relative
La luminance relative de chaque couleur se calcule ainsi :
L = 0,2126R + 0,7152G + 0,0722B
On obtient une valeur comprise entre 0 (pour le noir #000000) et 1 (pour le blanc #FFFFFF)
Pour le premier plan #1E40A5 :
L = 0,2126(0,0130) + 0,7152(0,0513) + 0,0722(0,3763) ≈ 0,0666
Pour l’arrière-plan #E3E3E3 :
L = 0,2126(0,7682) + 0,7152(0,7682) + 0,0722(0,7682) ≈ 0,7682
Enfin, le rapport de contraste est calculé avec la formule suivante :
CR=L_{clair}+0,05 / L_{sombre}+0,05
où L_{clair} correspond à la luminance relative la plus élevée et L_{sombre} à la plus faible.
Ici :
L_{clair}=0,7682
L_{sombre}=0,0666
Le rapport de contraste est donc : CR=(0,7682+0,05) / (0,0666+0,05) = (0,8182 / 0,1166) ≈7,02:1
Le contraste entre le premier plan #1E40A5 et l’arrière-plan #E3E3E3 est donc d’environ 7,02:1.
Heureusement, il y a des outils pour réaliser automatiquement ces fastidieuses opérations …
À propos de l’auteur :
Après 15 ans en tant que consultant QA pour Henix, et 8 ans en tant que responsable du cursus de reconversion « Consultant Qualification Logicielle » pour l’EQL (École de la Qualité Logicielle), j’ai pris ma retraite.
Je reste passionné par les problématiques du Test, et je suis avec attention l’évolution du métier, grâce notamment à l’IA.
Je poursuis une deuxième carrière « allégée », en dispensant des formations de préparation à la certification ISTQB Foundation et ISTQB CT-GenAI (Tester avec l’IA)
Contact : pascal.delamaire@pad-coach-qa.fr
