Ajout : je ne parle pas non plus d'un <a href="#"> ce n'est pas une ancre ;). Désolé pour le spam :P.
Le 22 juin 2012 13:26, Romain Gervois <cont...@romaingervois.fr> a écrit : > Hum ... sur ce genre de trucs l'alternative server-side est totalement > irréaliste (on est pas à l'abri de dévs server fada remarqué) : tout se > jouera sur le client. Sans JS, contenu visible et pas de lien ancre. Avec, > contenu masqué et lien ancre. > > L'élément button dans ce cas très précis revient à re-scripter la même > chose que ce qu'une ancre fait déjà très bien. > Et ce n'est pas lié à la complexité d'implémentation (un .focus() c'est à > la portée de n'importe qui). Le rôle fonctionnel d'une ancre est de se > positionner à un endroit du doc (tiens c'est ce que l'on recherche ;)) et > non dans ce cas ce n'est pas sale (on parle pas d'un void(0) là). > > Concernant le besoin du contexte de lien (pas toujours nécessaire on est > d'accord), je demande à voir si il n'y a pas un besoin possible dans ce > cas. On peut trouvé plusieurs longs paragraphes partiellement affichés > suivis d'un lien "Plus de détails" qui permet d'afficher avant ce dit lien > la suite du paragraphe. Bourrer le title d'un éventuel bouton n'est > certainement pas la solution. > > > "Note: penser à donner le statut disabled par défaut au bouton, et le > rendre actif en js. De cette manière, sans support js, le mécanisme > n'interfère pas (le bouton ne fonctione plus et ne donne donc pas de faux > espoirs...)." > > Le dév client qui fait ça : ça veut dire qu'il a des connaissances en JS. > Et il sait qu'un bouton grisé pour un mécanisme présent uniquement JS actif > n'a conceptuellement pas à figurer directement dans la source HTML ... > > Romain > > Le 22 juin 2012 13:00, Olivier Nourry <olv.nou...@gmail.com> a écrit : > > salut, >> >> ça peut ressembler à du pinaillage mais on devrait réserver les éléments >> A aux cas où une alternative est implémentée via un mécanisme >> client-serveur. En l'occurrence, un BUTTON parait plus adapté, si on fait >> en sorte que le bloc est déplié par défaut (sans JS). Les bénéfices >> utilisateurs sont subtils mais réels. Les arguments de plus grande facilité >> d'implém d'une ancre me paraissent insuffisants. Pour la pertinence du >> libellé (un lien pouvant avoir un contexte), déjà on n'a pas >> systématiquement besoin d'un contexte, et d'autre part on a tout ce qu'il >> faut sur les boutons (title dans le pire des cas). >> Cf. l'excellent article de Samuel Le Morvan: >> http://babylon-design.com/sus-au-a-href qui détaille bien tout. >> Note: penser à donner le statut disabled par défaut au bouton, et le >> rendre actif en js. De cette manière, sans support js, le mécanisme >> n'interfère pas (le bouton ne fonctione plus et ne donne donc pas de faux >> espoirs...). >> >> >> Cordialement, >> *Olivier Nourry* >> Twitter: @OlivierNourry <http://twitter.com/#%21/OlivierNourry> >> >> >> >> Le 22 juin 2012 10:49, Romain Gervois <cont...@romaingervois.fr> a écrit >> : >> >> Bonjour, >>> >>> Si je comprends bien, le texte à afficher / masquer se trouve avant le >>> mécanisme (d'affichage / masquage). >>> Alors clairement, cela nécessite de manipuler le focus (déplacement >>> devant le bloc concerné). >>> >>> Dans un cas comme celui là, un lien est bien plus adapté qu'un bouton : >>> non nécessité de re-scripter la même fonctionnalité pour le déplacement du >>> focus et exploitation possible du contexte de lien (si bien pensé et >>> implémenté). On pourrait bien sûr se reporter sur la pertinence de >>> l'intitulé du bouton mais cela reste bien moins souple. >>> >>> Enfin comme tout mécanisme de ce type, il est indispensable de stipuler >>> l'état soit par modification de l'intitulé ("Plus de détails" vers "Moins >>> de détails") soit par modification du title ("Plus de détails, afficher ces >>> détails" vers "Plus de détails, masquer ces détails"). >>> >>> Romain >>> >>> Le 21 juin 2012 16:52, Cyril Lamotte <clamo...@jouve.fr> a écrit : >>> >>> Salut ! >>>> >>>> J'utiliserai aussi un bouton, où alors l'attribut aria role="button". >>>> >>>> Je me penche sur une situation similaire sur un projet, >>>> >>>> Comment procèdes-tu pour déplacer le focus sur une zone de texte ? >>>> Doit-on prévenir l'utilisateur du déplacement du focus ? >>>> >>>> Bien cordialement, >>>> >>>> *Cyril Lamotte* >>>> Jouve I.T. Solutions - Développeur Front-end / Expert en accessibilité >>>> 02 43 08 39 97 >>>> >>>> Adoptez l'éco-attitude. N'imprimez ce courriel que si c'est vraiment >>>> nécessaire. >>>> >>>> Le présent mail ainsi que toutes les informations qu'il contient ne >>>> peuvent en aucun cas être considérés comme un engagement juridique de >>>> quelque nature que ce soit de JOUVE. Tout accord devra être formulé par >>>> écrit papier ultérieur signé par un représentant légal de JOUVE. Par >>>> ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et >>>> de le détruire ainsi que l'intégralité du document qui pourrait y être >>>> joint. >>>> Le 21/06/2012 11:39, CONVERT Yves a écrit : >>>> >>>> Bonjour la liste, >>>> >>>> Je suis confronté à un cas de figure qui me pose question. >>>> J'ai un bloc d'information qui gère deux états : ouvert et fermé. >>>> Après ce bloc, il y a un lien "Plus de détail". >>>> >>>> Quand je clique sur ce lien, des informations supplémentaires apparaissent >>>> dans le bloc. >>>> >>>> Le lien n'étant pas un vrai lien, mais fonctionnant comme un bouton >>>> d'action, se pose la question de ce que je dois mettre dans le href ? >>>> >>>> Dans la cinématique j'imaginais renvoyer le focus au début du bloc (ça >>>> oblige à relire toutes les informations du bloc, y compris celles déjà >>>> présentes dans l'état fermé). >>>> Le lien serait alors une ancre. >>>> >>>> Qu'en pensez-vous ? >>>> >>>> Yves Convert >>>> Micropole >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing >>>> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing list >>>> liste_gta@list.accessiweb.org >>>> >>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>> >>> _______________________________________________ >>> liste_gta mailing list >>> liste_gta@list.accessiweb.org >>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>> >>> >> >> _______________________________________________ >> liste_gta mailing list >> liste_gta@list.accessiweb.org >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >
_______________________________________________ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
