Blog Metlivi

Comment empêcher les commandes au clavier de perturber le glissement d'un taquin à la souris

Si vous développez un taquin sur navigateur pour servir d'accessoire à un jeu de rôle sur table, veillez à ce que le glisser à la souris et les mouvements au clavier s'appliquent au même état du jeu, tout en limitant la portée des raccourcis clavier au puzzle lui-même. Les points clés à vérifier sont le focus, la gestion des événements et la finalisation du glisser : une pression sur une touche dans un champ de texte ne doit pas déplacer une tuile, et un glisser ne doit pas être interrompu ou perdu lorsque le pointeur franchit le bord d'une tuile.

15 octobre 20266 min de lecturePar Metlivi Editorial Team
Section 1

Commencez par identifier ce qui déplace le puzzle de manière inattendue

Lorsqu'un puzzle réagit à une touche fléchée pendant une action à la souris, la cause réside souvent dans un écouteur de clavier à la portée trop large. Un gestionnaire d'événements attaché à document ou à window peut intercepter les touches fléchées même si le joueur tape du texte dans un champ d'indice, utilise un menu ou interagit avec un autre contrôle. Il peut également déclencher le comportement par défaut du navigateur, comme le défilement de la page, tout en modifiant l'état du puzzle.

Reproduisez le problème à l'aide d'une courte liste de vérification : cliquez sur une tuile et faites-la glisser ; glissez au-delà des limites du puzzle ; appuyez sur une touche fléchée pendant que le puzzle a le focus ; puis appuyez-en sur une pendant qu'un champ de saisie d'indice, un bouton ou un menu a le focus. Observez si le plateau change, si la page défile, si le focus se déplace ou si le glisser s'interrompt. Ces observations permettent de distinguer un problème lié au gestionnaire du puzzle d'un souci de suivi du pointeur ou du comportement par défaut du navigateur.

Section 2

Définissez une limite de focus explicite pour le puzzle

Considérez le plateau comme un contrôle doté d'un point d'entrée clavier clairement défini. Utilisez un conteneur de plateau pouvant recevoir le focus et ne gérez les touches du puzzle que lorsque ce plateau est actif, ou lorsque le focus se trouve sur une tuile appartenant au plateau. Maintenez les contrôles sans rapport, tels que les boutons d'indice et les champs de texte, en dehors de ce périmètre de gestion des touches. Rendez l'emplacement du focus bien visible afin que le joueur sache quand le plateau est prêt à réagir.

Vérifiez la cible de l'événement (event.target) avant d'interpréter une touche. Si le focus se trouve dans un champ de saisie, une zone de texte, un élément éditable ou sur un bouton distinct, n'interférez pas avec la touche. Pour un outil d'aventure coopératif, cet aspect est essentiel lorsqu'un joueur saisit une rune, un nom ou un indice pendant qu'un autre manipule le puzzle : la saisie au clavier ne doit pas provoquer de déplacement accidentel de tuile.

L'accessibilité au clavier doit néanmoins être préservée. Les recommandations du W3C précisent que les fonctionnalités doivent, dans la mesure du possible, être utilisables via une interface clavier, et considèrent le déplacement d'objets vers un emplacement comme une action devant pouvoir être effectuée au clavier. Délimitez soigneusement la portée des touches au lieu de les supprimer purement et simplement. W3C : Comprendre le critère de succès 2.1.1 : Clavier

Section 3

Séparez les commandes du puzzle des comportements par défaut du navigateur

Choisissez un ensemble restreint et documenté de touches pour le plateau, comme les touches fléchées lorsque le plateau a le focus. Dans le gestionnaire, vérifiez d'abord que la touche pressée est bien utilisée par le puzzle et que le plateau est la cible active. Ce n'est qu'ensuite qu'il faut appliquer le déplacement et, si nécessaire, annuler l'action par défaut du navigateur pour cette touche. Évitez de neutraliser systématiquement toutes les touches de manière globale : les joueurs peuvent avoir besoin d'écrire normalement, de naviguer dans le navigateur et d'utiliser des contrôles en dehors du puzzle.

La méthode preventDefault() annule l'action par défaut du navigateur lorsque l'événement est annulable, mais elle n'empêche pas l'événement de se propager vers d'autres gestionnaires. Cela signifie qu'elle peut empêcher le défilement de la page sans pour autant corriger un second écouteur qui déplace lui aussi une tuile. Repérez et ciblez précisément le gestionnaire qui modifie l'état du jeu ; ne recourez pas à une annulation généralisée pour pallier l'absence d'une attribution claire des événements. MDN : Event : méthode preventDefault()

Section 4

Assurez la continuité du glisser du pointeur sur l'ensemble du plateau

Pour une interaction de type glisser-déposer, suivez un unique pointeur actif, depuis la pression initiale qui amorce le glisser jusqu'à son relâchement ou son annulation. Les événements de pointeur (Pointer Events) fournissent pointerdown, pointermove, pointerup et pointercancel ; la capture du pointeur (pointer capture) permet de continuer à diriger les événements ultérieurs vers le plateau, même si le pointeur sort de sa zone de contact initiale. Réinitialisez l'état de glisser actif aussi bien sur pointerup que sur pointercancel, afin qu'un geste interrompu ne laisse pas le puzzle bloqué dans un état de glisser. MDN : Événements de pointeur (Pointer events)

Évitez de reconstruire ou de remplacer la tuile déplacée d'une manière qui romprait le suivi du pointeur. Si l'interface déplace un élément dans le DOM pendant le glissement, MDN souligne que la capture du pointeur doit être définie après ce déplacement. Déterminez ce qui se produit lorsque le pointeur est relâché sur une case non valide : pour un taquin, replacer la tuile à sa position précédente ou l'ajuster automatiquement à une case autorisée est bien plus intuitif que de déplacer discrètement d'autres tuiles non concernées.

Section 5

Permettez d'effectuer le même mouvement sans glisser

Un puzzle peut combiner la prise en charge de la souris, du clavier et d'entrées simples par pointeur. Par exemple, cliquer ou appuyer sur une tuile adjacente à l'espace vide pourrait la déplacer ; faire glisser cette tuile pourrait rester un geste facultatif de manipulation directe ; et les touches fléchées, lorsque le plateau a le focus, assureraient le contrôle au clavier. Toutes ces commandes d'entrée doivent appeler la même logique de validation des mouvements, afin qu'un déplacement soit accepté ou refusé de manière cohérente, quelle que soit la méthode utilisée.

Cela offre également un point de contrôle précieux lors de la conception : un joueur peut-il résoudre le puzzle par de simples clics ou pressions, sans jamais devoir glisser ? Les directives WCAG 2.2 du W3C traitent l'accès au clavier et les alternatives à pointeur unique au glissement comme deux exigences distinctes. Parmi les exemples proposés figure le remplacement d'un glisser par des clics sur des boutons directionnels. Une alternative exclusivement réservée au clavier ne répond pas en soi au besoin d'une alternative au pointeur. W3C : Comprendre le critère de succès 2.5.7 : Mouvements de glissement

Dans le cas d'un taquin, cliquer sur une tuile voisine à la fois constitue souvent une alternative naturelle car elle respecte la règle des déplacements adjacents propre au puzzle. Si cette interaction manque de clarté, des boutons de déplacement visibles peuvent indiquer la direction possible. La technique G219 du W3C fournit des exemples de contrôles par pointeur unique effectuant la même action sous-jacente sans nécessiter de mouvement de glissement. W3C : G219 : S'assurer qu'une solution alternative est disponible pour les mouvements de glissement qui agissent sur le contenu

Section 6

Testez avec une courte matrice de validation des entrées

Avant d'utiliser le puzzle en cours de partie, testez chaque mode d'entrée avec la même disposition de plateau et le même état initial. Vérifiez qu'un mouvement valide met à jour le plateau une seule fois, qu'un mouvement non valide le laisse inchangé et que les contrôles indépendants conservent leur comportement normal.

  • Souris : faites glisser une tuile autorisée, relâchez-la hors du plateau et tentez un déplacement interdit. Assurez-vous que le plateau ne perd pas le suivi du glisser et qu'aucune modification inattendue ne survient.

  • Clavier : placez le focus sur le plateau, testez chaque direction prise en charge, puis déplacez le focus vers un champ de texte et écrivez-y. Vérifiez que seules les touches lorsque le plateau est ciblé déplacent les tuiles, et que la saisie de texte ne fait pas défiler la page ni ne modifie le plateau.

  • Pointeur sans glissement : cliquez ou appuyez sur une tuile voisine autorisée. Confirmez que le résultat est identique à celui des autres méthodes de commande.

  • Interruption : annulez ou interrompez un glisser en cours, puis lancez-en un autre. Vérifiez qu'aucune sélection résiduelle ne persiste.

Si un test échoue, examinez en priorité la couche technique la plus ciblée : la cible de l'événement et l'état du focus pour le comportement du clavier ; la capture du pointeur et la réinitialisation de l'état pour les glissements interrompus ; et le validateur de mouvement partagé en cas de règles incohérentes. Cette méthodologie offre au créateur un moyen concret de localiser le problème sans transformer cet accessoire d'aventure en un tutoriel généraliste sur les contrôles d'interface.

Section 7

Sources

À lire aussi

Continuer sur ce thème