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)