Accessibilité des formulaires : les erreurs les plus courantes

Un formulaire inaccessible, c'est un utilisateur qui abandonne sans se plaindre

Un bouton mal contrasté se voit à l'œil. Un formulaire inaccessible, lui, ne se voit pas. Il se traduit juste par des abandons silencieux, des tickets support répétitifs. Ou des utilisateurs qui renoncent avant même de comprendre pourquoi ça ne marche pas.

Le W3C consacre un tutoriel entier aux formulaires dans ses ressources d'accessibilité — signe que c'est l'un des composants les plus piégeux à réussir. Voici les erreurs qui reviennent le plus souvent, avec le critère WCAG qu'elles cassent et la correction concrète.

Aucune de ces erreurs n'est spécifique à un framework ou à un outil de design en particulier. On les retrouve sur un formulaire codé à la main comme sur un composant généré par une librairie UI réputée. La bibliothèque ne protège jamais automatiquement contre un mauvais usage.

Les erreurs de label et de message d'erreur

Le placeholder qui remplace le label

C'est l'erreur la plus répandue. Un champ sans label visible, avec juste un texte d'exemple en gris clair à l'intérieur. Le problème : ce texte disparaît dès que l'utilisateur commence à taper, et les lecteurs d'écran le traitent de façon incohérente selon les navigateurs.

Le correctif est simple : chaque champ garde un <label> visible, associé par for/id. Le placeholder reste utile en complément — jamais en remplacement. C'est le critère WCAG 3.3.2 (Labels ou instructions).

L'erreur signalée seulement par la couleur

Une bordure qui passe au rouge, sans rien d'autre : ça échoue le critère 3.3.1 (Identification des erreurs). Une personne daltonienne, ou qui navigue avec un contraste réduit, ne perçoit tout simplement pas le changement.

Le champ en erreur doit porter un texte explicite à côté de lui, pas seulement une couleur. Techniquement, aria-invalid="true" plus aria-describedby pointant vers ce texte.

Le message qui ne dit pas quoi corriger

« Champ invalide » ne sert à rien. « L'adresse email doit contenir un @ » se corrige en cinq secondes. Un bon message d'erreur nomme le champ concerné et propose la correction attendue — pas juste le constat de l'échec.

Les erreurs de timing et d'attributs techniques

Valider à chaque frappe

Afficher une erreur dès la première lettre tapée dans un champ email crée une friction inutile, avant même que l'utilisateur ait fini d'écrire. C'est aussi anxiogène pour certains profils, notamment neuro-atypiques (voir notre article sur la neuro-inclusion en UX). La bonne pratique : valider à la perte de focus (blur) ou à la soumission, jamais à chaque caractère.

L'autocomplete manquant sur les champs personnels

Un champ email, téléphone ou adresse sans attribut autocomplete approprié échoue le critère 1.3.5 (Identifier la finalité de la saisie). Cet attribut permet aux navigateurs et aux technologies d'assistance de préremplir intelligemment le champ. Le gain de temps dépasse largement le public en situation de handicap.

Le champ obligatoire mal signalé

Un astérisque seul, sans légende expliquant ce qu'il signifie, ou pire, un champ obligatoire qui ne l'indique qu'au moment de l'erreur de soumission. L'indicateur doit être visible avant que l'utilisateur remplisse le champ, avec l'attribut required qui l'accompagne techniquement.

Les champs liés qui ne sont jamais groupés

Une adresse postale éclatée en quatre champs (numéro, rue, code postal, ville). Ou un groupe de cases à cocher pour un même choix. Dans les deux cas, sans <fieldset> ni <legend> qui les rassemble. Un lecteur d'écran annonce alors chaque champ isolément, sans jamais faire comprendre qu'ils forment un seul ensemble logique. Le correctif est un simple wrapper sémantique — aucun changement visuel requis.

Les erreurs de composants personnalisés

Le sélecteur de date qui ignore le clavier

Un datepicker ou un menu déroulant custom, construit à partir de <div> plutôt que d'éléments natifs, échoue souvent le critère 2.1.1 (Clavier). Impossible à ouvrir, naviguer ou fermer sans souris. C'est l'un des points qu'on retrouve régulièrement dans nos principes fondamentaux de l'UI design : un composant visuellement abouti n'est pas automatiquement un composant utilisable.

Le réflexe le plus fiable reste de partir d'un élément natif (<input type="date">, <select>). On le personnalise visuellement en CSS, plutôt que de reconstruire le comportement clavier à la main.

Le focus qui devient invisible

Un contour de focus supprimé en CSS (outline: none) sans remplacement visible casse le critère 2.4.7. Pour un utilisateur qui navigue au clavier, c'est l'équivalent d'un curseur de souris qui disparaîtrait de l'écran. Impossible de savoir où on se trouve dans le formulaire. Un style de focus personnalisé est acceptable — son absence totale ne l'est jamais.

Ce que ces erreurs coûtent réellement

Un formulaire de paiement ou d'inscription abandonné à cause d'une erreur mal signalée ne remonte dans aucune métrique produit habituelle. L'utilisateur ne clique pas sur un bouton « signaler un bug » — il ferme l'onglet.

C'est ce qui rend ces erreurs particulièrement coûteuses à long terme. Elles n'apparaissent dans aucun tableau de bord. Jusqu'à ce qu'un audit RGAA ou une plainte les révèle d'un coup, sur l'ensemble du site à la fois.

Auditer un formulaire existant en dix minutes

Pas besoin d'outillage lourd pour un premier passage :

• Naviguer le formulaire entier au clavier seul (Tab, Shift+Tab, Entrée) → chaque champ et bouton doit être atteignable et actionnable
• Zoomer le navigateur à 200% → aucun champ ni label ne doit disparaître ou se chevaucher
• Soumettre le formulaire vide → les erreurs doivent apparaître en texte, pas seulement en couleur
• Vérifier chaque <label> dans l'inspecteur → un for qui ne correspond à aucun id est un label cassé, même s'il s'affiche correctement à l'écran

Conclusion : la majorité des correctifs ne coûtent rien en design

Aucune des erreurs listées ici ne demande de repenser l'interface visuelle. Un label qui reste affiché, un message d'erreur qui nomme le problème, un attribut autocomplete bien renseigné. Ce sont des corrections de quelques minutes par champ, pas un chantier de refonte.

Le vrai coût est ailleurs — dans les formulaires jamais audités, où ces erreurs s'accumulent silencieusement jusqu'à devenir la norme plutôt que l'exception.