Les touches d'accès au champ de saisie de mon formulaire doivent-elles être sémantiques ou regroupées physiquement?
Je crée un formulaire similaire à celui ci-dessous (avec <label/> balises, champ de saisie accesskeys et ordonné logiquement tabindices). Le formulaire sera rempli une poignée de fois en succession rapide par des administrateurs de bureau chevronnés - donc très à l'aise avec un clavier.
Cela m'a fait réfléchir: dans des cas d'utilisation similaires si les clés d'accès de mon formulaire devaient être mappées sémantiquement/linguistiquement (p = code de projet, n = notes, etc), ou mappé dans un cluster physique (a, s, d, etc) pour accès le plus rapide?
(J'admets que la plupart des utilisateurs passeront probablement par tab via le formulaire s'ils choisissent de ne pas abandonner la souris. Pourtant, ce sera quelque chose à considérer pour les futurs projets.)
Modifier: Tous les champs sont obligatoires.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Si tous les champs sont obligatoires, je n'en attribuerais qu'un au premier. "P" pour Project dans ce cas. Plutôt que d'attribuer des raccourcis clavier à tous les champs, il y a d'autres choses qui peuvent être faites pour assurer une saisie rapide des données, telles que:
- Si ce formulaire est présenté dans une fenêtre contextuelle, assurez-vous que le champ de saisie Nom du projet obtient le focus.
- Si la "Note" est le dernier champ qui doit être rempli avant de soumettre, assurez-vous que l'action Soumettre peut être invoquée en appuyant sur la touche Entrée.
etc..
Mais pour répondre à votre question ... presque toujours sémantique, à moins qu'il n'y ait de meilleures alternatives symboliques. Comme utiliser Alt + <et Alt +> pour "Précédent" et "Suivant", plutôt que d'utiliser P et N. Alt ++ et Alt + - pour incrémenter et décrémenter. Utilisation de Alt + 1, Alt + 2, Alt + 3 pour parcourir rapidement une poignée d'onglets, etc.
La sémantique est meilleure que physique. Les utilisateurs ne vont pas passer leurs doigts sur les touches pour naviguer séquentiellement d'un champ à l'autre. Ils vont naviguer vers le champ, taper une entrée pour cela, puis continuer, il n'y a donc aucun avantage à faciliter la frappe rapide des touches d'accès rapide.
Comme vous le constatez, il y a la touche de tabulation, qui est généralement préférable pour parcourir chaque champ dans l'ordre de toute façon parce que l'utilisateur n'a pas à regarder pour voir quelle clé faire ensuite. Pour cette raison, les clés d'accès servent vraiment à sauter vers un champ spécifique, par exemple lorsque l'utilisateur met à jour le formulaire, plutôt que d'entrer la saisie initiale. À cet effet, chaque champ doit avoir une clé d'accès si possible. À quelques exceptions près, c'est de toute façon la norme MS.
Plus important que le mappage sémantique des clés est d'utiliser une lettre au début de l'étiquette correspondante. Par exemple, votre champ Code de facturation doit être Alt-B et non Alt-C, même si la plupart de vos utilisateurs ont tendance à le considérer simplement comme "le code". Selon les directives de MS UX, les clés d'accès ne sont pas destinées à être mémorisées. Il est plus important pour les utilisateurs de voir rapidement quelle clé d'accès utiliser que d'avoir des propriétés mnémoniques.
Voir page 409 de MS Windows 7 ser Experience Interaction Guidelines pour plus de conseils.