Tabulation qui remonte en arrière : perturbant ou acceptable ?

Bonjour les gens,

C’est pour une broutille, sur une page d’ailleurs peu accessible, parce qu’elle contient une pile de CANVAS.

L’ébauche : http://test.rasama.org/calc-1/

Le test, sous Chrome seulement (je m’occupe des autres navigateurs plus tard) :

Tab * 2 pour arriver à «Formules», entrée pour ouvrir, tab * 2 pour arriver à «Éditer le nom», entrée pour afficher le champ et deux boutons (idem pour les autres).

À partir de là, si vous faites tab, le focus remonte en arrière, vers le bouton «OK» situé en haut. C’est à ce sujet que je me disais que ce serais sympa d’avoir des opinions.

Je pourrais mettre les boutons «OK» et «Annuler» en bas du champ, mais pour les maniaques de la souris, je me disais que c’était mieux de les placer là où sont les autres boutons qui disparaissent, sans que ça ne pose de problème pour les maniaques du clavier, puisque tab permet d’y accéder après l’édition (ou la non-édition).

En même temps je me demande si ce comportement n’est pas trop surprenant ou perturbant. Ce qui me dérange aussi, c’est que rien ne laisse deviner que tab va faire remonter en haut.

Je balance entre le pour et le contre.

Dans «Disposition», j’ai un chose similaire, mais qui me semble moins surprendre, alors elle m’éveille peu de questions : la tabulation fait traverser les boutons pour l’axe X, avant de descendre et faire traverser les boutons pour l’axe Y, puis revient vers les boutons plus à droite qui opèrent sur les deux axes en même temps. Comme je disais, je pense que là ça va.
Modifié par hibou57 (30 Apr 2015 - 10:26)

En marge, je me demande aussi si les petites info-bulles qui s’affichent pour indiquer un problème avec un champ avec setCustomValidity(), sont considérées comme accessibles ou pas.

J’ai un doute, parce que je viens d’en voir une s’afficher tout en bas de la page, et qui comme elle était tout en bas, était affichée coupée, je ne voyais que la moitié de la hauteur de la ligne.

Je pense que dans un contexte desktop, c'est déjà plutôt étrange d'avoir un bouton OK en haut plutôt qu'à proximité des champs. Ce genre d'agencement est à réserver pour les mobiles.

Pour une personne fortement malvoyante qui utilise une loupe d'écran et qui n'en voit qu'une petite partie à la fois, les sauts imprévisibles de ce genre sont synonymes de désorientation. Il faut que l'ordre de tabulation soit suffisament prévisible pour que tu n'aies pas besoin d'indiquer quel est le prochain composant qui doit obtenir le focus. Cette information ne serait sans doute pas très utile d'ailleurs; elle risquerait plutôt d'embrouiller l'esprit pour rien.

QuentinC a écrit :
Pour une personne fortement malvoyante qui utilise une loupe d'écran et qui n'en voit qu'une petite partie à la fois, les sauts imprévisibles de ce genre sont synonymes de désorientation.

C’est bien ce que je me disais. Je vais revenir à du plus classique, et faire correspondre l’ordre dans lequel les contrôle apparaissent dans le flux avec l’ordre dans lequel ils sont utilisés.

QuentinC a écrit :
Il faut que l'ordre de tabulation soit suffisament prévisible pour que tu n'aies pas besoin d'indiquer quel est le prochain composant qui doit obtenir le focus. Cette information ne serait sans doute pas très utile d'ailleurs; elle risquerait plutôt d'embrouiller l'esprit pour rien.

Oui, je me disais la même chose.

QuentinC a écrit :
Je pense que dans un contexte desktop, c'est déjà plutôt étrange d'avoir un bouton OK en haut plutôt qu'à proximité des champs. Ce genre d'agencement est à réserver pour les mobiles.

Pourquoi ça passe mieux sur un mobile ? (je n’ai pas de smartphone, alors je ne peux pas deviner)


P.S. Ne pas trop se fier au lien que j’ai posté, c’était un instantané, la version actuelle est assez différente, et le lien contient des erreurs de diverses nature (validité HTML5 et WCAG).
Modifié par hibou57 (02 May 2015 - 11:44)

Voici, avec une logique plus classique : http://test.rasama.org/calc-2/ (je laisse la première version à côté pour comparaison).

Maintenant je suis ambivalent sur un autre point : si par exemple tu fais «Éditer le nom», puis «OK» immédiatement, tu as un message d’erreur (parce que le nom n’est pas changé). Les messages d’erreur et d’alerte s’affichent entre les champs et les boutons. Ça me parait plus logique comme ça (ça exprime bien l’interposition), ça permet aussi de s’assurer que le message sera vu parce qu’il faut passer par là pour accéder aux boutons, mais je n’aime pas ce changement de géométrie, je veux dire, les boutons qui descendent quand un message apparait. Je n’aime pas les changement de géométrie en général, ils me semblent perturbant, et j’essaie de les éviter autant que possible. Du coup, mon avis balance...

Une petite idée m’est venu : je trouve que le texte «Annuler», même s’il est standard, n’est pas très parlant, et s’oppose mal au «OK», alors j’ai mis un autre texte. Tu en penses quoi ? (mais tout le monde peut répondre).

En marge, j’ai aussi abandonné l’usage des DETAILS et SUMMARY, parce qu’ils sont trop peu supportés et que leur effet n’était pas terrible. Plus tard je trouverai un autre moyen de masquer des sections, et je serais obligé, pour ne pas avoir une page à rallonge avec les fonctions à venir (tables de calcul, annotations, aide pas à pas, etc).

Si tu (ou un autre membre) as envie de faire des commentaires, ne te prive pas, ça peut toujours être intéressant à noter.
Modifié par hibou57 (02 May 2015 - 19:14)