Fenêtres modales : ouvrir, fermer et reprendre sans perdre le fil

Un visiteur ouvre une fenêtre pour modifier une adresse de livraison. Il utilise le clavier, mais la sélection continue derrière la fenêtre. Après fermeture, il ne sait plus où reprendre. Ce scénario fictif montre pourquoi une interface doit être testée pendant ses transitions, et pas seulement lorsqu’elle est immobile.

Une fenêtre de confirmation, un aperçu de document ou un panneau de réglages ajoute une étape au parcours. Avant de valider ce composant avec votre prestataire web, définissez ce qui se passe à l’ouverture, pendant la navigation et à la fermeture. Voici une méthode centrée sur les fenêtres modales, avec des essais simples à conserver pour les prochaines mises à jour.

Choisir si la fenêtre doit bloquer le reste de la page

Une fenêtre modale impose de terminer ou de quitter son interaction avant de revenir à la page. Un panneau non modal permet de continuer à utiliser le contenu autour. Ce choix doit correspondre à la tâche : faut-il réellement interrompre la consultation pour afficher une information secondaire ?

La documentation MDN distingue ces deux comportements pour l’élément HTML dialog. Son ouverture avec showModal rend le reste de la page inerte ; show ouvre une fenêtre non modale. Cette différence concerne l’interaction, pas seulement l’apparence du fond. MDN : fonctionnement de l’élément dialog.

Dans un exemple fictif de catalogue, un aperçu rapide peut parfois être remplacé par une fiche dédiée ou une zone qui se déplie. Comparez les parcours avant de retenir une fenêtre superposée. Moins de couches peut rendre le fonctionnement plus facile à expliquer et à vérifier.

Écrivez la décision dans la maquette : « Cette fenêtre bloque le reste de la page jusqu’à sa fermeture » ou « Ce panneau laisse le catalogue utilisable ». Le développeur et la personne chargée des tests doivent partir de la même intention.

Prévoir une entrée et une sortie au clavier

Le focus désigne l’élément qui reçoit les actions du clavier. Le guide de conception du W3C recommande de le déplacer dans une fenêtre modale lors de son ouverture. Tab et Maj + Tab y parcourent les éléments accessibles sans passer derrière. Échap ferme la fenêtre ; un bouton de fermeture visible est aussi recommandé.

À la fermeture, le focus revient normalement au contrôle qui a ouvert la fenêtre. Si ce contrôle a disparu ou si la tâche mène logiquement ailleurs, une autre destination cohérente est prévue. Le point de départ à l’intérieur dépend du contenu : pour un texte long, placer immédiatement le focus sur un bouton situé en bas peut masquer le début. W3C : modèle de conception des fenêtres modales.

Pour votre recette, décrivez une suite observable : atteindre « Modifier l’adresse », ouvrir la fenêtre, lire les informations, parcourir ses champs, annuler, puis poursuivre la page. Recommencez en validant une modification fictive. Notez l’élément sélectionné à chaque transition, plutôt que de cocher seulement « clavier testé ».

Donner un sens clair à Fermer, Annuler et Enregistrer

Une croix ne dit pas toujours ce qu’il advient des modifications. Décidez si elles sont abandonnées, conservées comme brouillon ou déjà appliquées. Le texte des actions doit refléter ce fonctionnement.

Dans notre exemple, « Annuler » pourrait laisser l’adresse d’origine intacte, tandis que « Enregistrer » attendrait la confirmation du serveur avant de fermer la fenêtre. Ce sont des choix de conception à valider pour votre application, pas des comportements garantis par le navigateur.

Prévoyez aussi un échec d’enregistrement : la personne doit comprendre le problème et pouvoir corriger ou réessayer sans perdre involontairement ses réponses. Testez une fermeture après une saisie, puis une nouvelle ouverture. Comparez les données affichées avec celles réellement enregistrées.

MDN rappelle l’importance d’un moyen de fermeture utilisable sur les appareils sans clavier physique. Une touche Échap fonctionnelle sur ordinateur ne remplace donc pas un contrôle visible et utilisable au toucher. Les réglages et le code du composant peuvent modifier son comportement : vérifiez le résultat réel dans les navigateurs retenus pour votre projet. MDN : fermeture et accessibilité de dialog.

Garder le contrôle sélectionné à l’écran

Un en-tête fixe, un bandeau inférieur ou un bouton flottant peut recouvrir le contrôle atteint au clavier. Le problème peut apparaître uniquement après agrandissement du texte ou lorsque la fenêtre contient davantage d’informations.

Le critère WCAG 2.2 « Focus non masqué, minimum », de niveau AA, demande que le composant recevant le focus clavier ne soit pas entièrement caché par du contenu créé par l’auteur, avec des précisions et exceptions dans le texte du critère. Sa documentation cite notamment les en-têtes et pieds de page fixes. Cette exigence minimale ne signifie pas qu’un contrôle partiellement masqué offre une bonne expérience. W3C : comprendre le focus non masqué.

Pour la recette, utilisez un contenu long et faites défiler la fenêtre. Sur téléphone, ouvrez le clavier virtuel et atteignez le dernier champ. Vérifiez que les consignes, le contrôle actif et les actions restent utilisables. Il s’agit d’essais complémentaires : ils ne constituent pas à eux seuls un audit de conformité.

Conserver une recette qui couvre les interruptions

Demandez une démonstration avec des données de test, sans modification de dossier client réel :

• ouvrir et fermer la fenêtre plusieurs fois depuis le même bouton ;
• parcourir ses contrôles en avant et en arrière au clavier ;
• vérifier que la page derrière ne reçoit pas les interactions lorsque la fenêtre est modale ;
• annuler après une modification, puis rouvrir et vérifier les valeurs ;
• simuler un enregistrement refusé et corriger la saisie ;
• refaire le parcours sur petit écran, avec zoom et contenu long ;
• vérifier avec un lecteur d’écran que la fenêtre et ses actions sont compréhensibles.

Pour chaque anomalie, conservez le point de départ, les actions effectuées et le résultat attendu. Une vidéo courte ou une suite de captures peut aider le prestataire à reproduire le problème. Après correction, rejouez le parcours complet : une fermeture réparée ne suffit pas si la prochaine ouverture perd à nouveau le focus.

Le livrable utile est une fenêtre dont le rôle est clair, dont les actions correspondent aux données enregistrées et dont on peut sortir pour poursuivre son travail. Cette vérification ciblée complète les contrôles du formulaire et du site ; elle ne permet pas de déclarer l’ensemble du service accessible ou conforme.