Guide pratique · 4 min de lecture
Réservation sur mobile : tester obstacles et interruptions
Recetter une réservation sur téléphone : petits écrans, clavier, zoom, chargement lent, erreurs et reprise d’une action interrompue.
Par Rédaction Doclineo · Rédaction assistée par IA · Révision éditoriale du
Une page qui tient dans un écran de téléphone n’est pas forcément utilisable. Le clavier peut masquer le bouton, une erreur peut apparaître hors écran et un double appui peut envoyer deux demandes. Le test mobile doit suivre une tâche complète, pas seulement vérifier une capture.
Cette grille est une méthode de recette proposée. Elle ne vaut ni audit exhaustif d’accessibilité ni certification ; elle aide à repérer des obstacles concrets avant de faire tester le service plus largement.
Reproduire des conditions variées sans prétendre représenter tout le monde
Testez plusieurs largeurs, un navigateur mobile courant et au moins un appareil réel. Ajoutez le zoom, un clavier externe ou une navigation au clavier, puis une lecture avec technologie d’assistance si l’équipe sait la réaliser correctement. Un émulateur est utile, mais ne couvre pas tous les comportements d’un téléphone.
Le test « une seule main » repère certains efforts et gestes difficiles ; il ne doit pas devenir une norme supposée convenir à tous. Observez les personnes dont les besoins diffèrent, notamment en matière de vision, de motricité ou de compréhension, avec un protocole respectueux.
Vérifier ce qui reste visible pendant l’action
Le nom du lieu, la date et le résultat de la sélection doivent être lisibles sans défilement horizontal de toute la page. Les tableaux peuvent avoir leur propre zone de défilement, annoncée clairement, mais le reste du contenu doit rester stable.
Examinez les barres fixes, bandeaux de cookies et fenêtres d’aide. Ils ne doivent pas recouvrir la validation ni prendre presque tout l’écran après l’ouverture du clavier. Un bouton collé au bas de l’écran doit rester atteignable avec les zones réservées par le système.
Tester chaque champ avec le clavier réellement affiché
Vérifiez le format proposé pour l’e-mail et le téléphone, la possibilité de coller une information, les accents et les noms composés. Ne supposez pas qu’un nom tient dans une seule forme ou qu’un numéro appartient toujours au même pays.
Le W3C recommande des libellés explicites et des instructions utiles, ainsi que des erreurs permettant de corriger la saisie. Sur téléphone, vérifiez que le message et le champ concerné restent repérables lorsque le clavier est ouvert.
Références : W3C WAI — Concevoir des formulaires accessibles.
Ralentir puis interrompre le réseau pendant les étapes décisives
Le chargement doit annoncer une action en cours sans laisser croire que rien ne se passe. Empêchez les envois répétés côté interface, puis vérifiez aussi la protection côté serveur : désactiver un bouton n’est pas une garantie suffisante.
Coupez le réseau juste après la confirmation d’un rendez-vous fictif. Au retour, l’application doit permettre de retrouver le résultat réel. Un message « erreur » ne prouve pas que le serveur n’a rien enregistré.
Sur petit écran, faites défiler le tableau horizontalement pour voir toutes les colonnes.
| Essai | Ce que l’on observe | Critère de réussite |
|---|---|---|
| Petit écran et zoom | Titre, champs, validation | Aucune action essentielle cachée |
| Clavier ouvert | Erreur et bouton | Correction possible sans tâtonnement |
| Réseau ralenti | Attente et appuis répétés | État visible, une seule opération |
| Interruption après envoi | Reprise | Résultat retrouvé sans doublon |
| Retour arrière | Données et sélection | État cohérent, pas de paiement répété |
Réduire l’effort de lecture au bon endroit
Gardez les informations décisives près de l’action : lieu, heure, conditions et résultat attendu. Une longue introduction commerciale avant le formulaire retarde la tâche ; une explication courte au point de décision peut éviter une erreur.
Les icônes seules doivent avoir un nom accessible et, si leur sens est ambigu, un texte visible. Le contraste, le focus clavier et les zones cliquables doivent faire partie d’un audit plus complet, pas être déduits du seul aspect « moderne » du design.
Consigner une anomalie reproductible
Pour chaque défaut, notez l’appareil, le navigateur, la largeur, l’étape, l’action et le résultat observé. Utilisez des données fictives et évitez d’enregistrer des informations personnelles dans les captures. Une vidéo courte peut montrer le clavier ou un décalage impossible à expliquer par une image.
Après correction, rejouez le scénario et les étapes voisines. Une barre fixe déplacée peut réparer la validation tout en cachant une alerte plus haut. Conservez les principaux cas dans la recette de chaque évolution du parcours.
Questions complémentaires
Un score de performance élevé garantit-il un bon parcours mobile ?
Non. Il renseigne sur un ensemble de mesures dans des conditions données. Il ne prouve ni la compréhension du formulaire, ni les permissions, ni l’absence de doublon lors d’une interruption réseau.
Sources et portée des références
Les références étayent les points indiqués dans le texte. Les exemples fictifs, calculs et grilles proposés par Doclineo sont distingués des recommandations de ces organismes.
-
W3C WAI — Concevoir des formulaires accessibles
Étiquettes, instructions, erreurs et confirmation ; la grille de recette Doclineo n’est pas une certification d’accessibilité.
Source consultée le .
Signaler une erreur éditoriale : indiquez le titre et le passage concerné, sans transmettre de données de santé personnelles.
