La propriété CSS accent-color teinte le rendu natif d’une case à cocher, d’un bouton radio, d’une barre de progression ou d’un curseur de plage, sans qu’il soit nécessaire de masquer l’élément natif pour le remplacer par une reconstruction en <span> ou en pseudo-éléments. Sur un écran de réglages d’extension, où l’on trouve souvent une dizaine de cases à cocher pour activer ou désactiver des options, cette propriété change la donne.
Avant cette propriété, uniformiser la couleur d’une case à cocher aux couleurs de la marque du client obligeait à une reconstruction complète : masquage de l’élément natif avec opacity: 0 ou appearance: none, ajout d’un élément visuel de substitution, gestion manuelle des états :checked, :focus et :disabled, et souvent une régression discrète sur la navigation au clavier ou le lecteur d’écran.
Le problème du composant personnalisé
Reconstruire une case à cocher en CSS pur revient à réinventer un comportement que le navigateur fournit déjà correctement : focus visible, activation par la barre d’espace, état indéterminé pour les cases à cocher partiellement sélectionnées dans une liste, et prise en charge native par les technologies d’assistance. Chaque reconstruction manuelle risque de perdre un de ces comportements, surtout si elle est copiée d’un projet à l’autre sans revue attentive.
Sur l’écran de réglages d’une extension qui gère des points de fidélité pour une boutique locale, la maquette fournie par le client demandait des cases à cocher dans la couleur de sa charte graphique, un bleu profond plutôt que le bleu WordPress par défaut. La première tentation, reconstruire les cases en composants personnalisés, aurait ajouté une trentaine de lignes de CSS et de JavaScript pour un résultat identique à ce qu’une seule propriété permet.
La propriété accent-color
accent-color s’applique directement sur le sélecteur natif et accepte n’importe quelle valeur de couleur CSS valide, y compris une variable personnalisée définie ailleurs dans la feuille de style.
.extension-reglages input[type="checkbox"],
.extension-reglages input[type="radio"] {
accent-color: #1a3c6e;
}
.extension-reglages input[type="range"] {
accent-color: #1a3c6e;
}Le navigateur applique automatiquement une teinte cohérente à l’état coché, avec un contraste suffisant calculé par son propre moteur de rendu pour rester lisible. Aucune règle supplémentaire n’est nécessaire pour l’état :focus-visible, qui reste géré nativement, ni pour l’état :disabled, qui s’assombrit automatiquement.
Ce que la propriété ne couvre pas
La personnalisation reste limitée à la teinte : la forme de la case (carrée ou arrondie), sa taille exacte au pixel près ou l’ajout d’une icône personnalisée à l’intérieur restent hors de portée d’accent-color. Pour un besoin de personnalisation plus poussé, la reconstruction manuelle garde son intérêt, mais elle devient un choix délibéré plutôt qu’un réflexe systématique.
Un point de vigilance mérite d’être noté : sur un écran d’administration WordPress, la feuille de style de l’extension s’ajoute à celle du cœur, qui ne définit pas accent-color par défaut sur les cases de réglages standard. Restreindre la règle à un sélecteur de conteneur propre à l’extension, comme .extension-reglages dans l’exemple, évite de teinter par erreur des cases à cocher appartenant à d’autres écrans du même tableau de bord.
Compatibilité et repli
- La propriété est prise en charge par les versions récentes de Chrome, Firefox et Safari disponibles début 2023.
- En l’absence de prise en charge par un navigateur plus ancien, l’élément reste affiché dans sa couleur native par défaut : la dégradation est silencieuse et ne casse rien.
- Aucune détection de fonctionnalité n’est nécessaire côté CSS : une règle non comprise est simplement ignorée par le navigateur.
La règle que je retiens sur ce type d’ajustement : avant de reconstruire un composant natif, vérifier si une propriété CSS récente ne fait pas déjà le travail en une ligne.
Pour aller plus loin
Cette propriété illustre un mouvement plus large de la plateforme web : redonner aux développeurs la possibilité de personnaliser des éléments natifs sans sacrifier leur accessibilité, plutôt que de pousser systématiquement vers des reconstructions en JavaScript. Sur un écran d’administration, où la charge de maintenance d’une extension se paie sur plusieurs années, ce genre de simplification compte autant que la fonctionnalité elle-même. Cet article concerne uniquement les éléments de formulaire natifs ; les composants React du cœur de l’éditeur suivent des mécanismes de style distincts qui ne sont pas couverts ici.
