Pour améliorer ce formulaire, préparez un dossier de recette avec les règles de la demande, quatre situations à examiner et une décision attendue pour chacune. Vous pourrez ensuite comparer ce qui était prévu et ce qui s’est produit. L’exemple suivant est fictif ; aucun essai utilisateur n’a été réalisé.
Poser les règles de l’atelier fictif
Imaginons un atelier proposant deux périodes : samedi matin et dimanche matin. Son formulaire reçoit une réservation, une modification ou une demande d’information. Le contact sert à recevoir la réponse de l’organisateur. Ces choix sont des hypothèses de travail pour notre prototype, sans lien avec une offre réelle.
Préparez une page de dossier nommée « Atelier, version A ». Inscrivez qui décidera de chaque règle : l’organisateur pour les disponibilités, la personne qui traite les demandes pour la référence d’une modification. Une décision encore ouverte reçoit un nom et une échéance, plutôt qu’une réponse inventée dans la maquette.
Garder les repères techniques à portée
Le tutoriel W3C organise étiquetage, instructions, validation et retours.
Un label peut associer le champ par un for égal à son id : étiquetage W3C.
L’aide peut être associée au champ par aria-describedby : instructions W3C.
Les notifications W3C concernent les erreurs et la réussite.
required contrôle la présence ; aria-required informe sans valider : validation W3C.
Préparer quatre cas qui obligent à décider
Le tableau décrit des situations plausibles et les décisions proposées pour ce seul prototype. Il ne contient aucun résultat observé. Faites approuver ces hypothèses avant de vous en servir comme critères de recette.
| Objet | Donnée attendue | Décision proposée | Prochaine action |
|---|---|---|---|
| Information générale | Nature et contact, sans période | La période n’est pas nécessaire | Traiter la question |
| Réservation pour samedi soir | Une période du catalogue fictif | Ce choix ne figure pas au catalogue | Faire choisir une période proposée |
| Modification d’une réservation | Référence de la demande initiale | L’objet à modifier reste inconnu | Demander cette référence |
| Contact changé pendant la demande | Adresse retenue pour la réponse | L’adresse finale doit être désignée | Faire confirmer le contact voulu |
Pour chaque ligne, créez une fiche avec un identifiant, par exemple « Atelier A, modification sans référence ». Recopiez la nature, la période et le contact utilisés, puis la décision approuvée. L’identifiant sert à retrouver le dossier ; il ne remplace pas les valeurs qui expliquent le cas.
Si l’organisateur ajoute finalement le samedi soir, le deuxième cas change de sens. Mettez à jour la version du catalogue dans la fiche avant le prochain essai. Vous saurez ainsi si deux observations parlent des mêmes disponibilités ou de deux règles différentes, sans attribuer cette différence au comportement du formulaire.
Consigner une observation sans conclure trop vite
Gardez une colonne « observé » vide avant la séance. Lorsque vous pourrez examiner le prototype, consignez les mots affichés et la décision réellement prise dans le scénario. Si vous n’accédez pas au traitement de la demande, notez cette limite. La réservation demeure un objet à confirmer, même si l’écran semble annoncer son acceptation.
Terminez chaque fiche par une action attribuée : clarifier une règle avec l’organisateur, retrouver une référence ou reprendre une situation avec les mêmes valeurs. N’inscrivez pas « résolu » lorsque seule une proposition a été écrite. Cette distinction organise le suivi du dossier, sans prétendre valider un système existant.
Pour préparer le passage sans souris, prolongez la fiche avec le guide pour tester la navigation au clavier. Pour une maquette, le guide pour tester un prototype Figma aide à préparer la séance. Séparez les observations de la maquette de celles du futur site développé.
Le dossier obtenu reste une préparation de travail, sans certification WCAG, RGAA ou légale. Ses décisions concernent cet atelier fictif ; les disponibilités, règles et résultats d’un autre formulaire devront être établis séparément.
Questions fréquentes
Un astérisque suffit-il pour un champ obligatoire ?
Non. Expliquez ce signe et indiquez les champs concernés.
Faut-il afficher toutes les erreurs pendant la frappe ?
Pas systématiquement : choisissez un moment adapté à la saisie du champ.
Peut-on se limiter à la validation du navigateur ?
Non. Validez aussi les données côté serveur.
Sources
Documentation consultée lors de la relecture du 10 octobre 2026.