Accessibilité et réservation

Réserver avec un formulaire compréhensible et corrigeable

Une réservation peut échouer avant le paiement : champ ambigu, erreur introuvable, données perdues ou connexion difficile. Examinez la saisie et sa correction sur un dossier concret, en conservant le rôle de chaque voyageur.

Décrire ce que le voyageur doit saisir

Dans une réservation, un champ « nom » peut désigner le voyageur, le titulaire du paiement ou le contact du groupe. Distinguez ces rôles dans les libellés et expliquez le format attendu avant la saisie. Un exemple dans le champ disparaît lorsque la personne écrit : conservez les instructions utiles à côté du contrôle. Identifiez les champs obligatoires avec une indication textuelle compréhensible, plutôt qu’avec la seule couleur.

Pour une date, précisez le sens : naissance, arrivée ou départ. Pour un téléphone, indiquez si un indicatif international est nécessaire et pourquoi ce contact est demandé. N’utilisez pas les besoins d’un transporteur pour imposer les mêmes données à une visite libre. La collecte doit correspondre au produit et au rôle du voyageur. Dans un scénario pédagogique, comparez le formulaire d’une excursion et celui d’un billet nominatif : les équipes doivent pouvoir justifier chaque différence.

Permettre la correction sans recommencer

Après envoi, expliquez ce qui a échoué, où et comment le corriger. Un message « données invalides » laisse le voyageur sans prochaine action. Un récapitulatif des erreurs peut renvoyer aux champs concernés ; le message local doit reprendre le libellé et rester associé au contrôle. Le tutoriel WAI décrit notamment ces liens et l’association des messages. Vérifiez leur annonce dans le parcours réel, y compris lorsque la page ne se recharge pas.

Distinguez une erreur de saisie d’une réponse commerciale : une date correctement saisie peut ne plus avoir de départ disponible. Gardez les valeurs valides et proposez une suite adaptée, sans transformer un indisponible en champ mal rempli. Le scénario de recette doit comporter une erreur de date, un champ obligatoire oublié et un stock devenu indisponible. Retrouvez ensuite les corrections et les informations conservées, avec le clavier et une technologie d’assistance.

Maintenir le contexte entre les étapes

Un parcours long gagne à annoncer l’étape courante et celles qui restent. Le tutoriel WAI sur les formulaires multi-pages recommande de rendre la progression perceptible. Appliquez cette lecture à votre réservation : voyageurs, prestations, récapitulatif et paiement. Le retour à une étape précédente doit conserver les saisies utiles et rendre les conséquences d’un changement compréhensibles.

Dans un dossier fictif de deux chambres, revenez changer un enfant en adulte. Vérifiez occupation, options et prix total avant de poursuivre ; ne conservez pas silencieusement une ancienne offre incompatible. Notez quelles données restent valides et lesquelles sont à reconfirmer. Testez aussi une interruption de session. La possibilité de reprendre dépend du service : expliquez sa limite et ne promettez pas une conservation des prix ou du stock à partir de la seule sauvegarde du formulaire.

Réutiliser les données sans confondre les personnes

Le critère WCAG 2.2 sur la saisie redondante prévoit, dans un même processus, que certaines informations déjà fournies puissent être préremplies ou sélectionnées, avec des exceptions décrites dans sa documentation. Cela ne signifie pas copier automatiquement le contact principal sur tous les participants. Un choix explicite « utiliser les coordonnées du contact » peut éviter une ressaisie tout en laissant la personne corriger la donnée.

Préparez un groupe dont le payeur ne voyage pas et une famille dont deux participants partagent une adresse. Le récapitulatif doit montrer à qui chaque donnée appartient. Ne déduisez pas une identité ou une autorisation de cette adresse commune. Quand une information doit être redemandée pour une raison de sécurité ou parce qu’elle n’est plus valide, documentez le motif et le périmètre ; le critère possède des exceptions qu’un raccourci éditorial ne doit pas effacer.

Tester la connexion et la décision finale

La documentation WCAG sur l’authentification accessible traite les obstacles liés aux tâches cognitives, avec les aides et alternatives prévues par le critère. Vérifiez notamment le fonctionnement du gestionnaire de mots de passe et du collage dans votre parcours, puis la récupération d’accès. Un contrôle visuel du formulaire ne suffit pas à vérifier une connexion complète, surtout lorsqu’un prestataire externe intervient.

Terminez par un récapitulatif lisible et une action dont le libellé correspond à l’opération. Séparez une demande envoyée, un paiement en traitement et une réservation confirmée. Conservez comme preuve de recette le scénario anonymisé, les étapes parcourues, les erreurs rencontrées, les aides utilisées et l’état final retrouvé. Une réussite sur ce cas ne démontre pas la conformité de tout le site ; elle fournit un résultat reproductible pour la correction suivante.

Sources et périmètre des faits documentés

La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.

Questions fréquentes

Questions utiles avant de décider

Un libellé visible suffit-il à vérifier un champ ?

Il faut aussi examiner son association au contrôle, les instructions, les erreurs et son usage dans le parcours. La recette conserve le résultat de ces vérifications.

Peut-on réutiliser les coordonnées pour tout un groupe ?

Évitez la copie implicite. Distinguez les personnes et proposez une sélection explicite lorsque les mêmes données s’appliquent.

Une recette réussie prouve-t-elle la conformité WCAG ?

Elle documente le cas effectivement testé. Un audit de conformité demande un périmètre et une méthode couvrant les critères applicables.

Étape suivante

Appliquez cette méthode à des solutions concrètes.

Explorez les catégories du répertoire puis vérifiez les capacités et conditions auprès des sources officielles.

Explorer le répertoireParler du projet