11548 sujets

JavaScript, DOM et API Web HTML5

Pages :
(reprise du message précédent)

QuentinC a écrit :
Ah, et petite question au passage, je fais comment si je veux commander deux articles ? Pourquoi ne pas mettre simplement des chekbox pour tout le monde ?


Tu ajoutes les produits les uns après les autres, tout simplement.
J'ai bien pensé à des checkbox mais cela peut provoquer des erreurs..
Le temps que tu gagnes avec des checkbox tu le perds à vérifier ton panier.

Pour le reste je suis d'accord avec toi.

Reste cette piste :
boteha-2 a écrit :
Ou pourquoi pas une simple animation CSS qui va chercher le bouton de soumission sous le tableau pour le placer sous la case radio qui est cochée.


Il est clair que cela s'adresse aux voyants mais aucun piège dans le code pour l'accessibilité.
a écrit :
Tu ajoutes les produits les uns après les autres, tout simplement.


OK. Du coup tes boutons radio ne font vraiment plus aucun sens. Ca doit définitivement être des boutons normaux. Inutile de se torturer le cerveau plus longtemps !

Ne pas oublier que le principe de base des boutons radio, c'est faire un choix unique et exclusif parmi un ensemble exhaustif de possibilités. Il n'y a qu'un seul élément sélectionné à la fois, ou autrement dit quand on change son choix, le précédent est effacé. Ce n'est pas vraiment ce qui se passe ici.

Quant à ton animation, je vois quand même un potentiel piège: un malvoyant utilisant un fort grossissement pourrait passer complètement à côté, et chercher le bouton de soumission là où il n'est plus. Ca ne me parait pas une bonne idée que de vouloir le déplacer d'une grande distance.

Tu vas aussi probablement avoir un problème de cohérence au niveau de l'ordre du focus, pour les utilisateurs voyants qui naviguent au clavier. Ils vont bien voir le bouton se déplacer mais il va rester dans son ordre de tabulation original, d'après l'ordre logique visuel il sera sauté et va donc paraitre impossible à atteindre ! Les seuls moyens de contrer ça est de déplacer effectivement le bouton au bon endroit dans le DOM et pas uniquement en CSS/JavaScript, mais là c'est moi avec mon lecteur d'écran qui risque de ne pas retrouver ce bouton baladeur. Ou sinon tu peux jouer avec tabindex, mais c'est ignoble et là tu vas au devant de bien plus gros problèmes encore.
Modifié par QuentinC (04 May 2025 - 19:23)
Bonjour QuentinC,

Merci de ton suivi.

QuentinC a écrit :
OK. Du coup tes boutons radio ne font vraiment plus aucun sens. Ca doit définitivement être des boutons normaux. Inutile de se torturer le cerveau plus longtemps !


Là je ne comprends pas bien.
L'intérêt de la case radio est d'imposer un choix unique.
C'est pourquoi je mets des cases radio et non checkbox.
C'est un choix d'ergonomie qui peut se discuter mais qui dans la vie réelle fonctionne bien.

QuentinC a écrit :
Quant à ton animation, je vois quand même un potentiel piège: un malvoyant utilisant un fort grossissement pourrait passer complètement à côté, et chercher le bouton de soumission là où il n'est plus. Ca ne me parait pas une bonne idée que de vouloir le déplacer d'une grande distance.


D'accord, j'abandonne cette piste.

En version PC (> 768px) j'ai en position fixed en bas de page un alias du bouton de soumission.
Il y a donc deux boutons submit ;
Un en bas de la liste.
<button type="submit" name="choix" value="Ajouter au panier">Ajouter au panier</button>


Un en bas de la page en position fixed qui dans le code html apparaît beaucoup plus bas, dans le footer.
<button type="submit" form="compid" name="choix" value="panier">&crarr;<i>Alias pour &laquo;&nbsp;Ajouter au panier&nbsp;&raquo;</i></button>


<i>Alias pour &laquo;&nbsp;Ajouter au panier&nbsp;&raquo;</i> = infobulle au survol.

Qu'en penses-tu en terme d'accessibilité ?

En version mobile (<= 768px) ce deuxième bouton est en display none car le footer est en position static.

En version mobile mon idée à présent est de passer le footer en position fixed (bas de page) et d'afficher l'alias de soumission, donc identique version PC.
Je sais qu'à une époque les navigateurs des téléphones détestaient position fixed, en général ne respectaient pas cette déclaration.

Esr-ce toujours le cas, on peut espérer que cela a évolué avec la hauteur des écrans de téléphone ?
Modifié par boteha_2 (06 May 2025 - 19:39)
a écrit :
Là je ne comprends pas bien.
L'intérêt de la case radio est d'imposer un choix unique.
C'est un choix d'ergonomie qui peut se discuter mais qui dans la vie réelle fonctionne bien.


On a toujours deux problèmes à mon avis:

Initialement, tu voulais que ton bouton radio soumette le formulaire immédiatement. Si c'est toujours le cas, concrètement, tu effectues une action (ajouter au panier).
Donc ça doit être un bouton normal, pas un bouton radio.
Une action = un bouton normal. C'est fait pour ça. D'ailleurs tu l'as dit toi-même, tu caches le bouton radio pour afficher une icône de panier, alors pourquoi persister avec un bouton radio ?



Si tu as abandonné cette idée de soumission automatique, faisant de l'ajout au panier une action en deux temps (1/choix du produit, 2/ajout), ce qui est aussi une possibilité d'interface tout à fait valable, alors en imposant des boutons radio plutôt que des cases à cocher, en fait tu compliques inutilement la vie de celui qui veut commander plusieurs produits.
Avec des boutons radio, il faut 1/cocher le premier produit, 2/ajouter au panier, 3/cocher le second produit, 4/ajouter au panier.
Avec des cases à cocher, 1/cocher le premier produit, 2/cocher le second produit, 3/ajouter au panier
Sachant que ça ne change absolument rien pour celui qui ne veut commander qu'un seul produit, tu n'as rien à perdre que de mettre des cases à cocher.
En plus avec les boutons radio, l'utilisateur pourrait ne pas remarquer que le le second choix annule le premier, et il pourrait se demander ensuite mais pourquoi il n'est pas dans mon panier ? Bien sûr on peut toujours revenir en arrière et ajouter ce qui manque avant de passer à la caisse, mais ça reste des manipulations en plus qui auraient pu être évitées.
On pourrait se faire la réflexion inverse, mais au-delà de la forme carrée ou ronde du bouton, c'est une question de logique. A mon avis, quand je sélectionne un second produit, le premier ne devrait pas être déssélectionné. Sauf si c'est pour sélectionner une variante d'un produit donné comme la couleur ou la taille, où là effectivement je serai d'accord avec toi, c'est logique aussi, il est bien plus probable que je veuille prendre soit le bleu soit le rouge et pas les deux.
C'est ce genre de réflexion qui amène à faire le choix d'interface, radio ou checkbox.

Au final, encore plus que des cases à cocher ou des boutons radio, des boutons normaux qui ajoutent immédiatement au panier sont encore plus simples !
Sur un site où je commande régulièrement, il y a une page distincte pour chaque variante, et honnêtement c'est ce que je trouve le plus simple. Il n'y a pas trop de doute. Sur la page du produit en bleu, le rouge et le noir sont proposés, et ça ouvre la page correspondante par un lien classique.

Plus on simplifie la vie de l'utilisateur, plus on augmente les chances qu'il arrive au bout de sa commande et qu'il revienne. Ca a été prouvé, et ça peut avoir économiquement des conséquences très concrètes.
Personnellement je ne compte plus le nombre de fois où j'ai été embêté pour l'une ou l'autre mini bêtise, bizarrerie ou inaccessibilité de l'interface et qui, du coup, ont fini par me faire abandonner et aller voir ailleurs où c'était plus simple.

a écrit :
Qu'en penses-tu en terme d'accessibilité ?



Rien de particulier, je n'y vois pas de problème.


a écrit :
En version mobile (<= 768px) ce deuxième bouton est en display none car le footer est en position static.
En version mobile mon idée à présent est de passer le footer en position fixed (bas de page) et d'afficher l'alias de soumission, donc identique version PC.
Je sais qu'à une époque les navigateurs des téléphones détestaient position fixed, en général ne respectaient pas cette déclaration.
Esr-ce toujours le cas, on peut espérer que cela a évolué avec la hauteur des écrans de téléphone ?


Aucune idée, je ne peux pas te répondre.

Ce qui est certain par contre, c'est que pour un lecteur d'écran, position: fixed; ne change absolument rien. C'est toujours l'ordre dans le DOM qui fait foi.

Au passage, display: none; sur le bouton submit bloque également l'envoi direct en appuyant sur enter dans n'importe quel champ, car c'est comme s'il n'était pas là.
Modifié par QuentinC (07 May 2025 - 07:31)
Bonjour QuentinC,

Merci de ton suivi.

La question de l'ergonomie de l'ajout au panier est très intéressante, nous pouvons en discuter pendant des heures.

Il n'existe pas une seule approche valable.

QuentinC a écrit :
Au final, encore plus que des cases à cocher ou des boutons radio, des boutons normaux qui ajoutent immédiatement au panier sont encore plus simples !


C'est ce qu'on peut appeler l'approche classique que l'on trouve quasiment partout. Sans doute la plus efficace, ce qui explique qu'on la trouve partout...

L'approche à double clic a néanmoins un avantage : moins d'erreurs, surtout en version Mobile.

QuentinC a écrit :
Avec des cases à cocher, 1/cocher le premier produit, 2/cocher le second produit, 3/ajouter au panier
Sachant que ça ne change absolument rien pour celui qui ne veut commander qu'un seul produit, tu n'as rien à perdre que de mettre des cases à cocher.


D'accord mais ensuite dans le panier tu risques de te prendre la tête pour entrer les quantités à commander : le 2 mètres en bleu j'en veux dix, où est-il dans la liste ? je cherche... Et si j'ai déjà dans le panier du 3 mètres en bleu je risque de confondre.

Mon approche repose sur un principe qui ne peut pas être mauvais : faire les choses les unes après les autres.
Je n'ai pas précisé que l'ajout au panier t'envoie automatiquement dans le panier, ce qui très peu de sites font.
Je sélectionne le 2 mètres en bleu.
Je l'ajoute au panier.
Dans le panier je saisis la quantité voulue.
Par un bouton je retourne au produit.
Je sélectionne le 3 mètres en rouge.
etc...
Je t'assure que c'est rapide et efficace.
J'ajoute que cela permet de choisir l'ordre dans lequel tu mets les produits dans le panier. Avec des cases checkbox ce sera l'ordre des versions dans la page.

Si ton panier se limite à une seule version d'un seul produit tu valides directement le panier sans avoir à chercher son icône dans la page, car tu es dans le panier après l'ajout.

QuentinC a écrit :
Sur un site où je commande régulièrement, il y a une page distincte pour chaque variante, et honnêtement c'est ce que je trouve le plus simple. Il n'y a pas trop de doute. Sur la page du produit en bleu, le rouge et le noir sont proposés, et ça ouvre la page correspondante par un lien classique.


Là c'est plus discutable.
Pour le client, une page unique avec toutes les versions facilite la comparaison des prix et des délais.
Côté éditeur, tu n'as qu'une seule page à référencer.
Tous les avis sont concentrés sur la même page.

Ton approche est la plus répandue, proche du standard.
Quand les produits sont complexes avec de nombreuses versions mon approche est assez valable.
Si je peux conclure ce n'est pas facile d'arbitrer.
Modifié par boteha_2 (07 May 2025 - 20:06)
a écrit :
D'accord mais ensuite dans le panier tu risques de te prendre la tête pour entrer les quantités à commander : le 2 mètres en bleu j'en veux dix, où est-il
dans la liste ? je cherche... Et si j'ai déjà dans le panier du 3 mètres en bleu je risque de confondre.
Mon approche repose sur un principe qui ne peut pas être mauvais : faire les choses les unes après les autres.


Je n'y avais pas pensé, mais oui, s'il y a la quantité à rentrer derrière, ça change la donne. Ma version checkbox devrait être remplacée par un tableau avec un champ de saisie par ligne pour être complet... vite pénible même sur PC, et pas du tout mobile friendly.
C'est vrai que sur les sites auxquels je pensais en premier: électronique, livres ou vêtements/chaussures, on ne commande généralement pas exactement le même produit en plusieurs exemplaires.

a écrit :
Je n'ai pas précisé que l'ajout au panier t'envoie automatiquement dans le panier, ce qui très peu de sites font.


Aha, c'est une bonne idée ça. Effectivement je l'ai rarement vu.

a écrit :
Quand les produits sont complexes avec de nombreuses versions mon approche est assez valable.


Je comprends mieux maintenant, et effectivement je n'avais pas ce contexte. Du coup je te rejoins, si on part d'un produit sur lequel on peut personnaliser plein de choses / choisir plein d'options, c'est sans doute plus simple d'avoir toutes les possibilités sur une page de base unique.

a écrit :
Si je peux conclure ce n'est pas facile d'arbitrer.


ON est bien d'accord, il n'y a pas qu'une seule solution, c'est le moins qu'on puisse dire.