# Checklist de contraste WCAG à appliquer avant de valider une maquette de thème

> Avant de donner le feu vert à une maquette de thème WordPress, ces seuils de contraste WCAG évitent des allers-retours coûteux une fois le développement lancé.

- Auteur : Clément Hadrot
- Publié le : 2020-07-16
- Mis à jour le : 2020-07-16
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/checklist-contraste-wcag-validation-maquette-theme/

## L’essentiel

- 4,5:1 pour le texte courant
- 3:1 pour le grand texte et les composants
- Vérifier aussi les états survol et focus

Valider une maquette de thème sur la seule impression visuelle — « ça respire bien », « le ton beige est élégant » — laisse souvent passer des combinaisons de couleurs qui deviendront un problème de conformité une fois le site en ligne, et un chantier de reprise coûteux une fois le développement terminé. Le contraste des couleurs se vérifie avec un outil, en quelques minutes, avant même le premier commit de code. Voici la checklist que je fais valider par le chef de projet avant de considérer une maquette prête pour le développement.

Cette checklist couvre le niveau AA des *Web Content Accessibility Guidelines* (WCAG) 2.1, le niveau généralement exigé en France par le référentiel RGAA et par la plupart des cahiers des charges publics ou privés sérieux.

## Les seuils à vérifier, un par un

1. **Texte courant sur son fond** : ratio de contraste minimal de 4,5:1 entre la couleur du texte et celle du fond, pour tout texte de moins de 18 points (ou 14 points en gras).
2. **Grand texte** : ratio minimal de 3:1 pour un texte de 18 points ou plus (ou 14 points en gras et plus), typiquement les titres.
3. **Composants d'interface et éléments graphiques** : ratio minimal de 3:1 pour les bordures de champs de formulaire, les icônes porteuses de sens et les contours de boutons, par rapport au fond adjacent.
4. **Texte sur image** : même seuil de 4,5:1 (ou 3:1 pour le grand texte), calculé sur la zone la plus défavorable de l'image, pas sur une moyenne.
5. **État survol et focus** : la couleur qui apparaît au survol ou au focus d'un lien ou d'un bouton doit conserver un contraste suffisant, y compris quand elle change complètement de teinte.
6. **Placeholders de formulaire** : souvent oubliés car considérés comme décoratifs, ils doivent pourtant respecter 4,5:1 s'ils transmettent une information non répétée ailleurs (un format de date attendu, par exemple).

## Où les designers se font piéger le plus souvent

> L'essentiel à retenir : 4,5:1 pour le texte courant ; 3:1 pour le grand texte et les composants ; Vérifier aussi les états survol et focus

Trois zones reviennent presque à chaque audit de maquette :

- Le gris clair sur fond blanc utilisé pour les légendes et métadonnées d'article (date, catégorie) : un `#999999` sur blanc affiche un ratio de 2,85:1, largement sous le seuil.
- Les boutons « fantômes » (contour seul, fond transparent) sur une image de fond claire, où le contour disparaît selon la zone de l'image survolée.
- La couleur de marque appliquée telle quelle sur du texte, sans vérifier son ratio sur fond blanc : un bleu de marque vif peut très bien fonctionner en aplat mais échouer une fois utilisé comme couleur de texte.

## Outils pour vérifier avant développement

Le vérificateur de contraste du WebAIM ou l'outil intégré aux inspecteurs de couleur de Figma suffisent largement à ce stade. Pour une maquette complète, l'extension de contraste des outils de développement de Chrome permet aussi de passer chaque combinaison au crible directement sur une capture d'écran exportée en image.

## Tableau récapitulatif des seuils AA

| Élément | Ratio minimal | Remarque |
| --- | --- | --- |
| Texte courant | 4,5:1 | Moins de 18 pt, ou 14 pt gras |
| Grand texte | 3:1 | 18 pt et plus, ou 14 pt gras et plus |
| Composants d'interface | 3:1 | Bordures, icônes porteuses de sens |
| Texte décoratif | Aucun | Purement esthétique, sans information |

## Ce que cette checklist ne remplace pas

Vérifier le contraste avant développement évite une grande partie des retouches, mais ne dispense pas d'un audit après intégration : le rendu réel dans le navigateur, avec les vraies polices et les vrais états interactifs, peut révéler des écarts qu'une maquette statique ne montre pas — un dégradé CSS appliqué sur un bouton, par exemple, change le contraste réel par rapport à l'aplat prévu en maquette.

> Je recommande toujours de faire cette vérification en présence du designer, pas après coup : ajuster une teinte de dix pour cent dans Figma prend cinq minutes, la même correction une fois le CSS écrit et validé par trois personnes en prend souvent une demi-journée.

## En résumé

Un contraste correct ne se devine pas à l'œil : il se mesure. Faire passer cette checklist avant la moindre ligne de CSS transforme une contrainte réglementaire en simple étape de validation, au même titre que la relecture orthographique des textes de la maquette.