Comment un patient malvoyant sait-il qu’il vient de rater la validation d’un créneau de consultation ? Sur un établissement de santé, cette question n’est pas théorique : le formulaire de prise de rendez-vous est souvent la seule porte d’entrée numérique vers un service, et une erreur mal signalée pousse une partie des visiteurs à raccrocher le téléphone plutôt qu’à insister sur le site.
Le sujet n’est pas l’hébergement des données de santé, encadré par ailleurs par des règles strictes et indépendantes de l’accessibilité. Il s’agit ici de la mécanique du formulaire lui-même : structure, messages d’erreur, gestion du focus, et cohérence entre ce qui s’affiche à l’écran et ce qu’un lecteur d’écran restitue.
Structurer un formulaire de prise de rendez-vous en plusieurs étapes
La plupart des modules de prise de rendez-vous découpent le parcours en étapes : choix du praticien, du motif, du créneau, puis coordonnées du patient. Chaque étape doit rester un formulaire autonome du point de vue de l’accessibilité, avec un titre de niveau h2 annoncé au changement d’étape et un focus posé explicitement sur ce titre ou sur le premier champ actif.
Regroupez les champs qui vont ensemble avec fieldset et legend plutôt qu’avec un simple paragraphe en gras au-dessus d’un groupe de cases à cocher. Pour un choix de créneau horaire présenté sous forme de boutons radio stylés, la legend doit rappeler le contexte : « Créneaux disponibles le 14 novembre », pas seulement « Choisissez ».
Le cas du sélecteur de praticien
Un widget de sélection de praticien construit en JavaScript, avec photo et disponibilités, se comporte souvent comme une simple carte cliquable. Sans rôle explicite, un lecteur d’écran l’annonce comme du texte inerte. Ajoutez un vrai <button> ou un lien avec un intitulé complet : « Docteur Amina Torres, cardiologue, prochain créneau le 15 novembre » plutôt qu’un « Choisir » répété pour chaque praticien.
Gérer les erreurs sans faire disparaître la saisie
Rien n’est plus décourageant qu’un formulaire de rendez-vous qui se vide après une erreur de validation sur le champ téléphone. Conservez systématiquement les valeurs saisies, et associez chaque message d’erreur à son champ via aria-describedby, en plus d’un résumé des erreurs en haut du formulaire.
<label for="tel-patient">Téléphone</label>
<input type="tel" id="tel-patient" aria-describedby="err-tel" aria-invalid="true">
<p id="err-tel" role="alert">Le numéro doit contenir 10 chiffres.</p>
Ce résumé d’erreurs, placé en tête de formulaire et pointant vers chaque champ concerné via des ancres internes, permet à un utilisateur de clavier de corriger sa saisie sans redescendre champ par champ.
Déplacer le focus au bon endroit après soumission
Après une tentative échouée, le focus doit se poser sur le résumé des erreurs ou sur le premier champ fautif, jamais rester en bas de page sur le bouton « Valider ». Un appel à element.focus() juste après l’affichage des erreurs suffit, à condition que l’élément ciblé possède un tabindex="-1" s’il ne reçoit pas naturellement le focus.
- Placer un
tabindex="-1"sur le conteneur du résumé d’erreurs pour le rendre focalisable par script - Appeler le focus après le rendu du DOM, pas avant, pour éviter un focus perdu
- Annoncer le nombre d’erreurs détectées dans le texte du résumé
Le cas particulier de la confirmation par SMS ou e-mail
Une étape de confirmation par code reçu par SMS ajoute un champ de saisie court, souvent stylé en cases séparées façon carte bancaire. Ce pattern visuel casse fréquemment la sémantique : préférez un unique champ input type="text" inputmode="numeric" autocomplete="one-time-code" plutôt que six champs d’un caractère liés par du JavaScript de saut automatique, qui perturbe la navigation au clavier et la lecture par synthèse vocale.
Tester le parcours complet, pas seulement le formulaire isolé
Un audit d’accessibilité qui s’arrête au formulaire de contact générique passe à côté du vrai risque : le parcours de rendez-vous, avec ses étapes conditionnelles, ses créneaux qui se rafraîchissent en Ajax et ses messages de succès. Testez au clavier seul, du choix du praticien jusqu’à l’écran de confirmation, sans jamais toucher la souris, et vérifiez qu’un lecteur d’écran annonce bien chaque changement de créneau disponible.
Sur un module de prise de rendez-vous, une simple région
aria-live="polite"autour de la liste des créneaux évite qu’un changement de date rende le calendrier silencieux pour un utilisateur non-voyant.
En résumé
Un site hospitalier n’a pas de marge d’erreur sur son formulaire de prise de rendez-vous : structurez chaque étape avec des titres et des groupes explicites, conservez la saisie en cas d’erreur, déplacez le focus vers les messages utiles et testez le parcours entier au clavier avant toute mise en production.
