Donner à chaque état un second signal visible
Le critère 1.4.1 des WCAG 2.2 exige que la couleur ne soit pas le seul moyen visuel de transmettre une information, d’indiquer une action, de demander une réponse ou de distinguer un élément. Une erreur ne peut donc pas être signalée uniquement par une bordure rouge. Ajoutez un message précis, une icône dont le sens existe aussi en texte ou un autre traitement persistant. La règle vaut aussi pour réussite, avertissement, sélection, obligation et valeur modifiée.
- Associez la couleur d’erreur à « Saisissez une adresse électronique valide », pas à un simple contour rouge.
- Associez la couleur de réussite à une confirmation qui nomme l’action ou le champ réussi.
- Associez la couleur d’avertissement à un libellé ou une icône et précisez si la poursuite est sûre.
Séparer libellés, instructions et messages de validation
Un libellé persistant identifie ce que recueille le contrôle ; une instruction précise le format attendu ; un message de validation explique la correction. Ne rassemblez pas ces rôles dans un placeholder ou une étoile colorée. Les WCAG demandent des libellés ou instructions lorsqu’une saisie est requise, et les erreurs détectées doivent être décrites textuellement. Placez le message près du contrôle, liez-les par programmation et conservez la valeur saisie quand sa correction reste possible.
- Employez un libellé visible qui demeure après la saisie au lieu de dépendre du placeholder.
- Annoncez les contraintes avant envoi, comme le format de date ou la longueur minimale du mot de passe.
- Après validation, nommez le champ concerné et décrivez la correction sans exposer de donnée sensible.
Tester séparément texte et limites des composants
Le contraste textuel et le contraste non textuel sont deux contrôles distincts. Selon les WCAG 2.2, le texte courant demande généralement au moins 4,5:1 et le grand texte admissible au moins 3:1. Les informations visuelles nécessaires pour identifier les composants et leurs états demandent généralement 3:1 face aux couleurs adjacentes. Mesurez le message sur son fond, puis la bordure du champ, l’indicateur sélectionné, la marque d’erreur et le focus selon leur information respective.
- Mesurez séparément aide et erreur : une bordure forte ne compense pas des mots insuffisamment contrastés.
- Comparez une limite de champ nécessaire à la surface voisine lorsque cette limite identifie le contrôle.
- Testez icônes, coches et marques d’état face aux couleurs contiguës, pas face à un fond sans rapport.
Maintenir le focus visible dans chaque état
Le focus clavier ne correspond ni au survol, ni à la sélection, ni à la validation. Un champ invalide focalisé doit montrer simultanément où ira la saisie et pourquoi la valeur est fausse. Conservez un indicateur de focus dédié au lieu de le remplacer par la bordure d’erreur. Testez-le sur les états normal, erreur, avertissement et réussite, ainsi qu’à proximité des contrôles désactivés. Évitez les déplacements lorsque les bordures épaississent grâce à un contour ou un espace réservé.
- Utilisez un focus dont la surface et le contraste satisfont les exigences WCAG visées par le projet.
- Gardez le repère visible en présence d’une bordure d’erreur, d’un fond rempli ou d’une sélection.
- Testez ordre et visibilité au clavier, avec zoom, contraste élevé et mise en page responsive étroite.
Traiter la désactivation comme une décision de comportement
Les contrôles inactifs sont exemptés de plusieurs exigences de contraste WCAG, mais le faible contraste explique mal pourquoi une action est indisponible. Un bouton d’envoi inactif peut cacher les conditions manquantes. Lorsque possible, laissez agir puis expliquez la validation ; lorsque la désactivation est nécessaire, gardez un libellé lisible, bloquez réellement l’interaction et expliquez la condition à proximité. Ne distinguez jamais actif et inactif par la seule couleur.
- Employez l’état disabled natif seulement si le contrôle ne peut vraiment pas fonctionner dans le contexte.
- Expliquez le prérequis, comme accepter les conditions ou compléter un champ, avant l’action indisponible.
- N’imitez pas la désactivation par du gris : clavier, pointeur et sémantique d’accessibilité doivent concorder.
Examiner tout le parcours de validation
Une revue de palette sans interaction reste incomplète. Testez formulaire intact, focus, saisie valide, saisie invalide, envoi, rejet serveur, correction et réussite. Ajoutez un résumé si un long formulaire comporte plusieurs erreurs, sans supprimer les messages locaux. Déplacez le focus seulement si cela facilite la compréhension. Vérifiez que les annonces dynamiques restent brèves et ne se répètent pas à chaque touche. Documentez ensemble couleurs, paires de contraste, textes, icônes et associations programmatiques.
- Vérifiez chaque état au clavier, avec zoom, lecteur d’écran et au moins un mode de couleurs forcées.
- Consignez les paires exactes de premier plan et de fond pour retester les changements de jetons.
- Retestez les erreurs asynchrones et serveur, souvent absentes des styles de validation côté client.
Sources primaires
Les affirmations factuelles de cet article sont vérifiées dans ces spécifications publiées.