Formulaire mobile accessible : la checklist UX et WCAG

Un formulaire peut sembler propre sur un grand écran et devenir impraticable dès que le clavier mobile s’ouvre. L’accessibilité se joue alors dans des détails très concrets : un label visible, une zone tactile suffisante, un focus qui reste à l’écran et une erreur que l’on sait corriger.

1. Accessible ne veut pas seulement dire « responsive »

Un formulaire responsive change de largeur. Un formulaire accessible reste compréhensible et utilisable avec différentes manières de voir, de saisir et de naviguer : toucher, clavier, zoom, lecteur d’écran, commande vocale ou appareil tenu d’une seule main.

Les WCAG 2.2 organisent ces exigences autour de contenus perceptibles, utilisables, compréhensibles et robustes. Pour un formulaire mobile, cela implique autant le code que la présentation et le wording.

Ne validez donc pas un écran uniquement parce qu’il « tient » dans un téléphone. La personne doit pouvoir identifier chaque champ, connaître le format attendu, revenir sur une réponse et comprendre le résultat de l’envoi.

2. Une structure visible et également lisible par les technologies d’assistance

Chaque contrôle doit avoir un label explicite associé dans le code. Un placeholder comme « Votre e-mail » disparaît dès que la saisie commence et ne remplace pas ce label. Les champs liés doivent être regroupés avec une structure adaptée, par exemple un fieldset et une legend pour un groupe de boutons radio.

• Le titre annonce l’objectif de l’étape, pas un vague « Informations ».
• Le label décrit la donnée attendue sans dépendre du contexte visuel.
• L’aide précède l’erreur : format, unité ou contrainte sont indiqués avant la saisie.
• Le caractère obligatoire ou facultatif est exprimé en texte, pas seulement par une couleur.
• L’ordre du DOM suit l’ordre de lecture et de tabulation.

Gardez les instructions courtes. Une longue notice au-dessus de six champs sera rarement mémorisée. Placez l’aide spécifique près du champ concerné et reliez-la avec les attributs appropriés.

3. Le bon composant réduit les erreurs avant même la validation

Utilisez les éléments HTML natifs chaque fois qu’ils couvrent le besoin. Ils offrent des comportements familiers et une meilleure compatibilité que des contrôles reconstruits uniquement pour leur apparence.

L’attribut autocomplete peut indiquer la finalité de données courantes comme le nom, l’adresse ou le téléphone. Cette information aide les navigateurs et certaines technologies d’assistance à proposer une saisie plus rapide et plus prévisible.

Acceptez des formats raisonnablement variés quand la normalisation peut être faite côté serveur. Obliger l’utilisateur à saisir exactement « 06XXXXXXXX » alors qu’il a tapé des espaces n’améliore ni la sécurité ni la qualité.

4. Une zone tactile doit pardonner le manque de précision

Le critère WCAG 2.2 « Target Size (Minimum) » fixe une cible d’au moins 24 × 24 pixels CSS, avec des exceptions et une règle d’espacement pour les cibles plus petites. Cette valeur est un minimum de conformité, pas nécessairement un objectif de confort.

Pour une action principale ou un choix fréquent, visez une surface plus généreuse. Rendez tout le label d’une case ou d’un bouton radio cliquable. Éloignez deux actions aux conséquences opposées et évitez les petites icônes sans libellé pour supprimer ou revenir.

Testez avec le pouce, en marchant ou dans un véhicule à l’arrêt, et avec un écran de petite taille. Les situations réelles révèlent des problèmes que le curseur précis d’un ordinateur masque.

5. Le contenu doit rester utilisable à 320 pixels CSS

Le critère de reflow vise notamment un usage sans défilement horizontal pour le contenu courant à une largeur équivalente à 320 pixels CSS, sous réserve des exceptions prévues. Ne réduisez pas la police pour faire entrer un formulaire trop large : laissez les blocs se réorganiser.

Sur mobile, le clavier réduit fortement la hauteur disponible. Un bouton fixe en bas peut masquer le champ actif, son aide ou son message d’erreur. Les WCAG 2.2 demandent aussi que le composant recevant le focus ne soit pas entièrement caché par un contenu créé par l’auteur.

• Ajoutez un espace de défilement correspondant aux barres fixes.
• Faites défiler le champ en erreur dans une zone réellement visible.
• Vérifiez le mode paysage et l’agrandissement du texte.
• Évitez les modales plus hautes que la zone disponible.
• Conservez un bouton retour accessible sans masquer les champs.

6. Une erreur doit nommer le problème et la correction

« Champ invalide » ne dit rien. Préférez « Saisissez une adresse e-mail contenant un @ » ou « Choisissez au moins une activité ». Placez le message près du champ, associez-le dans le code et fournissez également un résumé lorsque plusieurs erreurs sont présentes.

Après une soumission en erreur, conservez toutes les réponses correctes. Placez le focus à un endroit utile, sans changement de contexte inattendu. Ne signalez jamais une erreur uniquement par une bordure rouge : ajoutez un texte et, si nécessaire, une icône compréhensible.

Le succès mérite le même soin. Une confirmation doit dire ce qui a été reçu, ce qui se passe ensuite et comment corriger ou contacter l’entreprise si nécessaire.

7. Fractionner un long parcours sans perdre le contexte

Le W3C recommande de diviser les longs formulaires en étapes logiques et d’informer la personne de sa progression. Une étape ne doit cependant pas être créée pour chaque micro-action : regroupez ce qui forme une même décision.

Affichez un repère comme « Étape 2 sur 4 » avec un titre explicite. Le bouton « Continuer » doit enregistrer la réponse sans donner l’impression que la demande est déjà envoyée. Réservez « Envoyer ma demande » à l’action finale.

Le retour doit restaurer les valeurs et le bouton retour du navigateur ne doit pas casser le parcours. Pour une transaction importante, ajoutez un écran de vérification qui permet de relire et modifier les réponses avant la confirmation.

8. Matrice de tests avant publication

Testez avec des personnes qui ne connaissent pas le formulaire. Mesurez les hésitations et les erreurs, pas uniquement le temps total. Un parcours très rapide peut rester incompréhensible si la personne choisit une réponse par défaut.

Sources de référence : W3C WAI — tutoriel sur les formulaires ; W3C WAI — associer les labels aux contrôles ; W3C WAI — notifications et erreurs ; W3C — taille minimale des cibles ; W3C — reflow ; W3C — focus non masqué. Consultées le 31 juillet 2026.

En résumé

Un formulaire mobile accessible se construit avec peu de champs, des composants natifs, une structure explicite et des retours prévisibles. La conformité technique compte, mais le test réel reste indispensable pour vérifier que la personne comprend, corrige et termine le parcours.