[Résolu] Mise en place d'une balise INPUT

(reprise du message précédent)

A mon avis, ce n'est pas très malin d'avoir <><input /></a> ou <a><button></button></a>, quand bien même c'est W3C valide.

Je ne sais pas comment les navigateurs ont résolu cette ambiguïté mais mieux vaut ne pas s'y fier: deux zones cliquables sont superposées, il pourrait arriver qu'une se déclenche mais pas l'autre... d'Oû un lien ou un bouton qui ne marcherait peut-être pas dans certaines configuration.

Pour la même raison, j'éviterais aussi <button><a></a></button>, ou pire, plusieurs liens dans le même bouton; juste pour éviter la confusion entre un clic sur le bouton ou sur le(s) lien(s) qui peuvent être traitées différemment.

Pour des questions d'accessibilité, de sémantique et de logique, hors formulaire, je pense qu'il serait plus juste de toujours utiliser des liens, quitte à les styler pour qu'ils aient l'apparence de boutons. Je réserverais les vrais boutons pour les actions liées aux formulaires, et inversément, je n'utiliserais pas de lien pour soumettre un formulaire (pratique courante mais fondamentalement illogique, les lecteurs d'écran proposent des racourcis pour sauter directement au bouton d'envoi, c'est embêtant de ne pas pouvoir les utiliser parce que le « bouton » est en fait un lien).
Après, on peut discuter sur les formulaires qui sont constitués uniquement de champs cachés en-dehors du bouton d'envoi... dans ce cas, un lien est presque plus logique puisque l'utilisateur ne voit même pas qu'il y a un formulaire derrière.

QuentinC a écrit :
A mon avis, ce n'est pas très malin d'avoir &lt;&gt;&lt;input /&gt;&lt;/a&gt; ou &lt;a&gt;&lt;button&gt;&lt;/button&gt;&lt;/a&gt;, quand bien même c'est W3C valide.

Je ne sais pas comment les navigateurs ont résolu cette ambiguïté mais mieux vaut ne pas s'y fier: deux zones cliquables sont superposées, il pourrait arriver qu'une se déclenche mais pas l'autre... d'Oû un lien ou un bouton qui ne marcherait peut-être pas dans certaines configuration.

Pour la même raison, j'éviterais aussi &lt;button&gt;&lt;a&gt;&lt;/a&gt;&lt;/button&gt;, ou pire, plusieurs liens dans le même bouton; juste pour éviter la confusion entre un clic sur le bouton ou sur le(s) lien(s) qui peuvent être traitées différemment.

Pour des questions d'accessibilité, de sémantique et de logique, hors formulaire, je pense qu'il serait plus juste de toujours utiliser des liens, quitte à les styler pour qu'ils aient l'apparence de boutons. Je réserverais les vrais boutons pour les actions liées aux formulaires, et inversément, je n'utiliserais pas de lien pour soumettre un formulaire (pratique courante mais fondamentalement illogique, les lecteurs d'écran proposent des racourcis pour sauter directement au bouton d'envoi, c'est embêtant de ne pas pouvoir les utiliser parce que le « bouton » est en fait un lien).
Après, on peut discuter sur les formulaires qui sont constitués uniquement de champs cachés en-dehors du bouton d'envoi... dans ce cas, un lien est presque plus logique puisque l'utilisateur ne voit même pas qu'il y a un formulaire derrière.

Salut Quentin,
le problème du button seul est qu'il repose sur un évènement JS (on click ici) d'ou la lien autour, l'attribut href n'étant pas autorisé sur les button. D'autre part un button ne peut pas contenir d'autres éléments intéractifs comme les liens, c'est invalide.
Et je viens de m'apercevoir dans la spec HTML5 que les liens rentrent dans le même cas, peut-être pour les raisons que tu donnes.
C'est vrai que les buttons ne devraient être implémentés que dans un form. Du coup je me demande bien à quoi peut servir le type=button.
Modifié par Hermann (26 Mar 2013 - 20:38)

a écrit :
le problème du button seul est qu'il repose sur un évènement JS (on click ici) d'ou la lien autour, l'attribut href n'étant pas autorisé sur les button.

Perso, j'estime qu'au jour d'aujourd'hui, javascript n'est plus en soi un problème pour l'accessibilité, si les scripts sont bien conçus. C'est juste que 99,9% des scripts modifient le DOM incorrectement (erreur n°1: placer un div dynamique au mauvais endroit comme systématiquement à la fin du document; erreur n°2: oublier d'ajouter ou de mettre à jour les alt des icônes qui changent de place et/ou de forme; erreur n°3: modifier le DOM au mauvais moment (Focus dans les formulaires), etc, etc.)
Sans avoir vraiment vérifié, il me semble que le WCAG2 va un peu dans le même sens: il tolère javascript à condition que ce soit fait correctement.

ceci dit, c'est sûr que si l'objectif est un sans js, alors il n'y a pas d'autre choix que de NE PAS utiliser type="button", que ce soit pour <input> ou <button>.

a écrit :
D'autre part un button ne peut pas contenir d'autres éléments intéractifs comme les liens, c'est invalide.
Et je viens de m'apercevoir dans la spec HTML5 que les liens rentrent dans le même cas, peut-être pour les raisons que tu donnes.

Tiens, je ne le savais pas. À priori, je ne vois pas d'autre raison à ce que ce soit interdit. Ce qui confirme que c'est se fier à un comportement indéfini... comme quoi, nos maîtres y ont pensé bien avant nous.

a écrit :
C'est vrai que les buttons ne devraient être implémentés que dans un form. Du coup je me demande bien à quoi peut servir le type=button.

JE vois au moins deux bonnes raisons d'utiliser type="button" :
1 - Pour une action relative au formulaire qu'on est en train de remplir mais indépendante de l'action d'envoi. Par exemple « plus d'options » qui ouvre un panel d'options supplémentaires, « Ajouter un utilisateur... » qui ouvre une pop-up à l'ancienne pour faire sa sélection (au passage, souvent plus accessible que les versions autocomplétées qu'on voit maintenant), ou « Vérifier » ou « Appliquer » qui vérifierait/appliquerait des modifications en envoyant des requêtes AJAX sans pour autant valider définitivement. Enfin bref, je vois pas mal d'utilisations justifiées dans ce style.
2 - Étant donné que les navigateurs ne sont pas d'accord entre eux sur quoi envoyer s'il y a plus d'un bouton submit, duquel activer à l'appui sur entrée, que ça dure depuis des lustres et que tout le monde semble s'en ficher totalement, un hack pratique est <button type="button" onclick="this.form.action='XXX'; this.form.submit();"> ou <button type="button" onclick="this.elements['machin'].value='truc'; this.form.submit();">

Mais quoi qu'il en soit, type="button" est prévu pour s'utiliser conjointement et obligatoirement avec javascript. Donc à proscrire si on vise l'accessibilité avec js désactivé; ou pas de contradication en soi si on vise une accessibilité plus pragmatique autorisant js.