« L’accessibilité, c’est un sujet à part, ça n’a rien à voir avec la sécurité » — cette phrase, entendue lors d’une revue de projet, ne résiste pas longtemps à l’examen d’un cas concret rencontré sur un formulaire de connexion personnalisé, construit sans passer par le formulaire natif de WordPress. Deux défauts d’accessibilité, en apparence mineurs, ont directement contribué à un comportement des utilisateurs qui a fragilisé la sécurité globale du site.
Ce cas illustre un principe plus général : un formulaire mal conçu pour l’accessibilité pousse les personnes qui l’utilisent vers des solutions de contournement, et ces contournements sont rarement neutres du point de vue de la sécurité.
Le formulaire en question
Le formulaire de connexion personnalisé remplaçait l’écran natif de WordPress par une interface sur mesure, pour des raisons purement visuelles. Le champ de mot de passe utilisait un attribut type="text" avec un script JavaScript pour masquer visuellement la saisie, plutôt que l’attribut standard type="password". Le label du champ n’était associé à aucun attribut for correspondant à l’identifiant du champ, et l’attribut autocomplete="current-password", qui permet aux gestionnaires de mots de passe de reconnaître correctement le champ, était absent.
Ce que cela a concrètement provoqué
Les gestionnaires de mots de passe intégrés aux navigateurs, ainsi que les gestionnaires tiers utilisés par une partie des utilisateurs, échouaient à reconnaître ce champ comme un champ de mot de passe légitime. Résultat observé sur plusieurs mois d’utilisation : une proportion notable d’utilisateurs, frustrés par l’absence de remplissage automatique, avait pris l’habitude de saisir un mot de passe simplifié et mémorisable de tête plutôt que le mot de passe complexe généré par leur gestionnaire pour les autres services.
Pourquoi ce lien n’est pas anecdotique
Un gestionnaire de mots de passe encourage, par construction, l’usage de mots de passe longs et générés aléatoirement, différents pour chaque service. Dès qu’un formulaire empêche ce mécanisme de fonctionner correctement — par un défaut d’étiquetage, un type de champ non standard, ou l’absence de l’attribut autocomplete approprié — l’utilisateur revient naturellement vers une stratégie moins sûre : un mot de passe court, mémorisable, potentiellement réutilisé ailleurs.
Les attributs qui manquaient
type="password"sur le champ, plutôt qu’un champ texte masqué par scriptautocomplete="current-password"pour signaler explicitement la nature du champ aux gestionnaires de mots de passe- Un attribut
forsur le<label>correspondant à l’identifiant du champ, condition de base du RGAA pour l’association label-champ
La correction appliquée
<label for="mot-de-passe-connexion">Mot de passe</label>
<input
type="password"
id="mot-de-passe-connexion"
name="mot-de-passe"
autocomplete="current-password"
required
>
Cette correction, strictement conforme aux critères d’accessibilité attendus pour un champ de formulaire, a rétabli le fonctionnement normal des gestionnaires de mots de passe pour l’ensemble des utilisateurs du site, sans nécessiter la moindre modification de la logique de traitement du formulaire côté serveur.
Ce que cet exemple ne prétend pas démontrer
Un audit RGAA complet couvre un périmètre bien plus large que ce seul formulaire de connexion, et ne se substitue à aucun moment à un audit de sécurité dédié : la conformité à l’accessibilité et la robustesse face à des tentatives d’intrusion restent deux évaluations distinctes, avec leurs propres méthodologies. Ce cas illustre simplement un point de croisement précis, pas une équivalence générale entre les deux disciplines.
Un champ de mot de passe qui empêche un gestionnaire de mots de passe de fonctionner correctement ne crée pas seulement une gêne pour l’utilisateur : il crée, indirectement, une incitation à des pratiques moins sûres.
Notre verdict
Traiter l’accessibilité et la sécurité comme deux sujets parfaitement étanches ignore les points de contact bien réels entre les deux disciplines, dont ce formulaire de connexion offre un exemple concret et facilement vérifiable. Respecter les attributs standards attendus pour un champ de mot de passe — type natif, label correctement associé, attribut autocomplete pertinent — ne coûte rien en complexité de développement et referme, au passage, une porte ouverte sans le vouloir à des pratiques de mots de passe plus fragiles.
