Définissez les besoins réels de l’entreprise
Imaginez un espace de coworking fictif à Budapest ajoutant une demande de visite dans son application. L’accueil a besoin d’un nom, d’une adresse pour répondre et d’un créneau souhaité. Taille de l’entreprise et coordonnées de facturation peuvent attendre. Le tutoriel du W3C sur les formulaires privilégie la collecte des seules informations nécessaires à la tâche.
Demandez à l’accueil de justifier chaque champ par une action concrète de suivi. Un téléphone facultatif permet une demande par courriel uniquement, mais l’équipe doit pouvoir répondre par ce canal. Imposer un compte peut aider les membres qui reviennent, tout en ajoutant une tâche aux nouveaux visiteurs. Tranchez avant de concevoir le formulaire.
Rendez chaque champ compréhensible pendant la saisie
Les recommandations du W3C sur les libellés associent chaque commande à une description de son rôle. Utilisez un libellé visible, comme Adresse e-mail pour notre réponse, qui reste affiché pendant la saisie. Placez l’explication du téléphone facultatif près du champ, là où le visiteur en a besoin.
Saisissez une adresse contenant un signe plus et un téléphone avec indicatif international. Demandez au développeur des modes de saisie adaptés, puis vérifiez que les caractères nécessaires restent disponibles. Clavier ouvert, tentez d’atteindre l’action finale sans perdre vos repères. Examinez la saisie réelle, pas seulement une capture d’écran.
Rédigez les messages qui aident à corriger
Le W3C recommande des messages clairs expliquant comment corriger les erreurs. Rédigez le message signalant une adresse e-mail manquante avant le développement ; faites-le tester par un collègue sans aide. Sait-il quel champ modifier et ce que l’application attend ? Vérifiez que la correction préserve le créneau souhaité.
Distinguez demande de visite et rendez-vous obtenu. Ici, l’accueil doit encore convenir d’un horaire : la confirmation doit donc annoncer une demande reçue, pas une visite réservée. Faites valider ce texte par l’équipe. Prévoyez aussi le message affiché lorsque l’application ne peut confirmer la réception, sans attendre le lancement pour improviser.
Testez les interactions avec les technologies d’assistance
React Native propose des libellés et rôles d’accessibilité, avec des différences selon la plateforme. Demandez une démonstration avec VoiceOver sur iOS et TalkBack sur Android. Faites trouver le formulaire, saisir les informations, corriger une erreur et identifier le résultat. Notez les besoins d’aide au lieu d’accepter une simple affirmation d’accessibilité.
Si un sélecteur de créneau personnalisé est proposé, comparez-le à une commande plus simple sur la même tâche. Il peut servir l’identité visuelle, mais demande du temps de développement et de test sur appareils. Désignez qui l’entretiendra. Associez des utilisateurs réguliers des technologies d’assistance concernées à la préparation de la revue.
Donnez à l’équipe des critères de validation clairs
Discutez ensemble de ces vérifications avant publication et attribuez chaque problème à un responsable. Elles constituent un point de départ pratique pour ce formulaire, sans remplacer un audit complet d’accessibilité.
- Envoyez une demande réaliste avec un texte agrandi et le clavier à l’écran.
- Laissez un champ obligatoire vide, corrigez-le et conservez les autres réponses.
- Accomplissez la même tâche avec les lecteurs d’écran des deux plateformes prises en charge.
- Faites confirmer par l’accueil que le message de réussite correspond à son action suivante.
- Répétez ces tests après modification des exigences des champs ou des composants du formulaire.