TerrainScénario type
Un formulaire de démarche rendu accessible : avant, après
Un formulaire de demande d'attestation semble simple. Il peut pourtant être impossible à remplir pour une personne aveugle ou qui n'utilise pas la souris. Voici les corrections, en scénario type.
Ce scénario type décrit la remise à niveau d’un formulaire de démarche en ligne : une demande d’attestation, en quatre étapes, proposée par une collectivité. Il est composite et sert à montrer, avant et après, des corrections typiques.
Le constat de départ
Un audit rapide, mené au clavier puis avec un lecteur d’écran, met au jour six familles de problèmes. Aucune n’est exotique, toutes sont fréquentes.
| Avant | Après |
|---|---|
| Les champs n’ont qu’un texte indicatif dans le champ, qui disparaît à la saisie | Une étiquette visible et associée à chaque champ, le texte indicatif ne servant plus que d’exemple |
| Les erreurs s’affichent en rouge en haut de page, sans annonce | Un message d’erreur par champ, relié au champ, annoncé au lecteur d’écran, avec un résumé en tête et un lien vers chaque erreur |
| Le menu déroulant de la commune se pilote à la souris uniquement | Une liste native au clavier, ou un composant testé aux touches fléchées et à la touche Échap |
| Le focus clavier est invisible | Un contour net sur chaque élément actif, d’un contraste suffisant avec le fond |
| Un captcha d’images à reconnaître | Une protection côté serveur, sans interaction demandée à l’utilisateur |
| Les étapes changent sans prévenir et la session expire après dix minutes | Un indicateur d’étape lisible, un enregistrement du brouillon et un avertissement avant expiration |
Trois corrections qui changent tout
Les étiquettes. Un champ sans étiquette associée est muet pour un lecteur d’écran : l’utilisateur entend « champ de saisie » sans savoir quoi y écrire. Associer l’étiquette au champ prend quelques minutes et règle une majorité de blocages.
Les erreurs. Dire « formulaire invalide » ne suffit pas. Chaque erreur doit nommer le champ, expliquer la correction attendue (« Saisissez la date au format jour/mois/année ») et être accessible sans la couleur. Le résumé en tête de formulaire aide tout le monde, y compris les personnes qui remplissent vite.
Le focus. Après l’envoi d’une étape, le focus doit se placer sur un point logique : le titre de l’étape suivante ou le résumé des erreurs. Sinon, une personne qui navigue au clavier se retrouve en haut de page, sans repère.
Un formulaire accessible est un formulaire dont chaque message a été relu comme s’il serait entendu, et non vu.
Vérifier et maintenir
- Tester au clavier l’ensemble du parcours, sans souris.
- Tester avec un lecteur d’écran comme NVDA ou VoiceOver, sur au moins une étape complète.
- Contrôler les contrastes et l’affichage à 200 % de zoom, puis sur mobile.
- Intégrer les tests dans la livraison de chaque évolution, pour ne pas régresser.
Les outils automatiques détectent une partie seulement des défauts ; le test manuel reste indispensable. Une déclaration d’accessibilité honnête, qui liste les écarts restants et propose un moyen de contact, complète le dispositif. Voir notre expertise web accessible et la solution accessibilité et inclusion.
Scénario type construit à partir de situations courantes ; il ne décrit pas une organisation réelle.
Pour approfondir : Accessibilité & inclusion
Questions fréquentes
Quel référentiel suivre ?
En France, le RGAA (version 4.1.2), qui s'appuie sur les WCAG. Les WCAG 2.2, publiées en octobre 2023, ajoutent des critères utiles, notamment sur la taille des cibles et l'aide à la saisie.
Un captcha est-il compatible avec l'accessibilité ?
Rarement dans sa forme visuelle ou sonore classique. Mieux vaut des protections invisibles côté serveur ou une alternative réellement utilisable.