Formulaires de compte et de connexion accessibles
En bref — la première porte ne doit bloquer personne
Créer un compte, se connecter, saisir un code reçu par SMS : ces formulaires sont la première porte d'une boutique. Quand ils sont mal construits — une étiquette qui disparaît, un mot de passe qu'on ne peut pas coller, un CAPTCHA en image sans alternative — une personne handicapée ne peut tout simplement pas entrer, et la vente est perdue avant d'avoir commencé. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA), applicable au commerce électronique depuis le 28 juin 2025, exige notamment :
- Une étiquette claire et persistante sur chaque champ — pas un simple texte d'invite qui s'efface (3.3.2, niveau A) ;
- La finalité des champs déclarée (e-mail, mot de passe…) pour que les gestionnaires de mots de passe et l'autoremplissage fonctionnent (1.3.5, niveau AA) ;
- Des erreurs de connexion identifiées, reliées au champ et annoncées au lecteur d'écran (3.3.1, niveau A · 4.1.3, niveau AA) ;
- Un CAPTCHA avec une alternative non visuelle : un test uniquement en image bloque les personnes aveugles (1.1.1, niveau A).
La frontière à connaître : l'authentification accessible — pouvoir coller son mot de passe ou son code, ne pas devoir résoudre une énigme cognitive — relève des critères 3.3.8 et 3.3.7 des WCAG 2.2. L'EAA s'aligne aujourd'hui sur les WCAG 2.1 via l'EN 301 549 : ces deux critères sont donc fortement recommandés, mais pas encore formellement exigés. Les y appliquer reste l'une des améliorations les plus rentables — c'est souvent là que les abandons se concentrent.
On juge un magasin à sa porte d'entrée. Si elle est étroite, mal éclairée, ou gardée par une devinette, certains clients renoncent avant même d'avoir regardé les rayons. En ligne, cette porte, c'est le formulaire de compte : création, connexion, mot de passe oublié, double authentification. C'est l'un des endroits où les obstacles d'accessibilité font le plus de dégâts, parce qu'ils sont bloquants : pas de connexion, pas de commande. Voici les règles WCAG à appliquer pour que tout le monde puisse franchir cette porte, ce que l'EAA exige précisément, et où passe la frontière avec les bonnes pratiques récentes des WCAG 2.2.
Pourquoi les formulaires de connexion excluent si souvent
Un formulaire de connexion concentre presque tous les pièges d'accessibilité d'un coup : des champs, des contraintes (mot de passe), des messages d'erreur, parfois un test anti-robot et un code à usage unique. Pour une personne qui utilise un lecteur d'écran, un champ sans étiquette annoncée n'est qu'une « zone de saisie » anonyme. Pour une personne ayant un handicap moteur, un mot de passe qu'on ne peut pas coller depuis un gestionnaire impose une frappe lente et risquée. Pour une personne ayant un trouble cognitif, un CAPTCHA qui demande de déchiffrer des lettres déformées est une barrière infranchissable. Et comme l'accès au compte est un prérequis à l'achat, chacun de ces obstacles se traduit directement en panier abandonné.
L'EAA s'appuie sur l'EN 301 549, fondée sur les WCAG 2.1 niveau AA. Pour les formulaires, les critères clés sont des fondations de niveau A et AA : 3.3.2 (Étiquettes ou instructions), 1.3.1 (Information et relations), 1.3.5 (Identifier la finalité de la saisie), 3.3.1 (Identification des erreurs), 3.3.3 (Suggestion après une erreur), 4.1.3 (Messages d'état), 2.1.1 (Clavier) et 1.1.1 (Contenu non textuel) pour les CAPTCHA. Les WCAG 2.2 ont ajouté en 2023 deux critères dédiés à la connexion — 3.3.7 et 3.3.8 — qui ne font pas encore partie du socle EAA, mais que nous traitons ici parce qu'ils règlent les abandons les plus fréquents.
Les 6 règles pour un compte et une connexion accessibles
Le texte d'invite ne remplace pas l'étiquette
Chaque champ — e-mail, identifiant, mot de passe — doit avoir une étiquette reliée par programmation (<label for> ou aria-label) et qui reste affichée pendant la saisie. Le placeholder (texte gris à l'intérieur du champ) ne suffit pas : il disparaît dès qu'on tape, n'est pas fiablement annoncé par les lecteurs d'écran, et son contraste est souvent trop faible. Ajoutez les instructions utiles (règles du mot de passe, format attendu) avant la saisie, et reliez-les au champ avec aria-describedby.
<label for="email">Adresse e-mail</label> au-dessus du champ ; les règles du mot de passe affichées et reliées via aria-describedby.→ Voir aussi le tunnel de commande et les formulaires accessibles.
L'autoremplissage et les gestionnaires de mots de passe sont une aide technique
Sur les champs qui collectent des informations sur l'utilisateur, ajoutez l'attribut autocomplete avec la bonne valeur : email, username, current-password pour la connexion, new-password pour la création ou le changement. C'est le critère 1.3.5 : il permet aux navigateurs, aux gestionnaires de mots de passe et aux aides techniques de reconnaître et de pré-remplir les champs — un vrai gain pour les personnes à handicap moteur ou cognitif. Prévoyez aussi un bouton « Afficher le mot de passe » réellement actionnable au clavier, avec un nom et un état accessibles (aria-pressed).
<input type="password" autocomplete="current-password"> ; un bouton « Afficher le mot de passe » qui bascule aria-pressed et reste utilisable au clavier.→ Voir aussi la navigation au clavier.
Dire ce qui ne va pas, où, et l'annoncer à voix haute
Quand la connexion échoue ou qu'un champ est invalide, le message doit être en texte (pas seulement un cadre rouge), relié au bon champ et proposer une correction quand c'est possible (3.3.1, 3.3.3). Surtout, comme le message apparaît après l'envoi sans recharger la page, il doit être annoncé dynamiquement au lecteur d'écran via une région live (role="alert" ou aria-live) — sinon la personne aveugle ne sait pas que sa tentative a échoué (4.1.3). Pour la connexion, restez prudent sur le détail : « identifiant ou mot de passe incorrect » protège la vie privée tout en restant clair.
role="alert" « Identifiant ou mot de passe incorrect » annoncé immédiatement ; le focus ramené sur le formulaire.→ Guide dédié : messages d'erreur et validation de formulaire accessibles.
Toujours prévoir une alternative non visuelle
Un test anti-robot uniquement en image (lettres déformées à recopier) est inaccessible aux personnes aveugles ou malvoyantes ; un test uniquement audio exclut les personnes sourdes. Le critère 1.1.1 demande, pour un CAPTCHA, un texte de remplacement qui en décrit la finalité et une alternative dans une autre modalité. La meilleure approche aujourd'hui : préférer un anti-robot invisible (analyse de comportement, jeton) qui n'impose aucune tâche ; si vous gardez un défi, offrez plusieurs formes (visuelle + audio) et une voie de secours humaine.
Laisser le temps, permettre le copier-coller, déclarer la finalité
Pour un code à usage unique, ne forcez pas la mémorisation et la re-saisie : laissez l'utilisateur le coller, et ajoutez autocomplete="one-time-code" pour que le système le propose automatiquement. Laissez un temps suffisant avant expiration et un bouton « Renvoyer le code » : une limite de temps trop courte relève du critère 2.2.1 (Réglage du délai). Découper le code en plusieurs cases est acceptable à condition que l'ensemble reste collable d'un coup et utilisable au clavier.
autocomplete="one-time-code" où l'on peut coller le code, un bouton « Renvoyer », un délai confortable.→ Voir aussi temps imparti, sessions et panier qui expire.
Tabuler sans piège, voir le focus, ne pas tout retaper
Tout le formulaire doit être atteignable et utilisable au clavier seul, dans un ordre logique, sans piège au focus, avec un focus visible (2.1.1, 2.1.2, 2.4.7). Et, bonne pratique des WCAG 2.2 : ne demandez pas de ressaisir une information déjà fournie dans le même processus — par exemple recopier l'e-mail pour le confirmer, ou retaper des données entre deux étapes — sauf raison essentielle (c'est le critère 3.3.7, Saisie redondante). Moins on demande, moins on exclut.
→ Voir aussi les libellés de liens et boutons.
Récapitulatif : ce qui est exigible, ce qui est recommandé
| Point à vérifier | Niveau | Statut EAA |
|---|---|---|
| Étiquette persistante & instructions — 3.3.2 / 1.3.1 | A | Exigé |
| Finalité des champs (autocomplete) — 1.3.5 | AA | Exigé |
| Erreurs identifiées, suggérées & annoncées — 3.3.1 / 3.3.3 / 4.1.3 | A · AA | Exigé |
| CAPTCHA avec alternative non visuelle — 1.1.1 | A | Exigé |
| Formulaire utilisable au clavier, focus visible — 2.1.1 / 2.4.7 | A · AA | Exigé |
| Authentification accessible — coller le code, pas d'énigme (3.3.8) | AA (2.2) | Recommandé |
| Saisie redondante — ne pas faire tout retaper (3.3.7) | A (2.2) | Recommandé |
Comment vérifier vos formulaires de compte
Quelques contrôles concrets à mener sur la création de compte, la connexion, le mot de passe oublié et la double authentification :
- Cliquez sur chaque étiquette : le focus se place-t-il bien dans le champ correspondant ? (preuve d'une liaison correcte)
- Essayez votre gestionnaire de mots de passe et l'autoremplissage : les champs sont-ils reconnus ? Le collage fonctionne-t-il ?
- Provoquez une erreur (mauvais mot de passe) et écoutez au lecteur d'écran : le message est-il annoncé ? relié au champ ?
- Cherchez l'alternative du CAPTCHA : existe-t-il une option audio, un mode invisible, ou une voie de secours ?
- Faites tout au clavier : peut-on créer un compte et se connecter sans souris, avec un focus toujours visible ?
Une partie se prête à la détection automatique : un scanner repère un champ sans étiquette, un autocomplete manquant, une image de CAPTCHA sans alternative textuelle, un contraste insuffisant. En revanche, savoir si une erreur est annoncée à voix haute, si le collage est bloqué, ou si un code peut être saisi sans stress demande un essai réel au clavier et au lecteur d'écran. Notre rapport signale les manquements détectables sur la page analysée et liste les points à vérifier manuellement.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi par où commencer.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (étiquettes de formulaire, autoremplissage, contraste, structure…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre demande d'audit est enregistrée — vous recevrez votre rapport WCAG par e-mail sous 24 h ouvrées.
Questions fréquentes
Un placeholder peut-il remplacer l'étiquette d'un champ ?
Non. Le texte d'invite (placeholder) disparaît dès qu'on saisit, son contraste est souvent trop faible et il n'est pas annoncé de façon fiable par les lecteurs d'écran. Le critère 3.3.2 demande une véritable étiquette, reliée au champ par programmation et visible en permanence. Le placeholder peut servir d'exemple de format, en complément de l'étiquette, jamais à sa place.
Le CAPTCHA est-il interdit par l'accessibilité ?
Non, mais un CAPTCHA uniquement en image ou uniquement en audio exclut une partie des utilisateurs. Le critère 1.1.1 demande un texte de remplacement qui décrit sa finalité et une alternative dans une autre modalité. La meilleure pratique est un anti-robot invisible qui n'impose aucune tâche ; si vous gardez un défi, proposez-le en plusieurs formes (visuelle et audio) avec une voie de secours humaine.
Faut-il vraiment autoriser le collage du mot de passe ?
Oui. Bloquer le collage « par sécurité » est un faux ami : cela empêche les gestionnaires de mots de passe de fonctionner, donc décourage les mots de passe forts, et pénalise lourdement les personnes à handicap moteur. Pouvoir coller son mot de passe ou son code relève de l'authentification accessible des WCAG 2.2 (3.3.8) : recommandé plutôt que strictement exigé par l'EAA aujourd'hui, mais c'est l'un des correctifs les plus simples et les plus rentables.
L'authentification accessible (WCAG 2.2) est-elle exigée par l'EAA ?
Pas encore formellement. L'EAA s'appuie sur l'EN 301 549, alignée aujourd'hui sur les WCAG 2.1. Les critères 3.3.8 (Authentification accessible) et 3.3.7 (Saisie redondante) sont apparus avec les WCAG 2.2 en 2023 et ne font donc pas partie du socle exigible actuel. Ce sont toutefois de fortes recommandations : les normes évoluent vers la 2.2, et ces critères règlent justement les obstacles les plus bloquants de la connexion. Les appliquer maintenant est un investissement sûr.
Un scan automatique vérifie-t-il un formulaire de connexion ?
En partie. Un outil détecte un champ sans étiquette, un attribut autocomplete manquant, une image de CAPTCHA sans alternative textuelle ou un contraste insuffisant. Mais savoir si un message d'erreur est annoncé à voix haute, si le collage est bloqué ou si un code peut être saisi sans difficulté demande un essai réel au clavier et au lecteur d'écran. Notre rapport combine le détectable automatiquement et la liste des points à contrôler manuellement.