Bonjour Nicolas, Tu écris : Je viens de noter un différence notable de comportement entre les deux solutions techniques : avec un tabindex=-1, il est possible de tabuler en dehors de la page (vers la barre d’adresse ou les menus du navigateur), ce qui n’est pas possible avec la gestion d’évènements.
Le tabindex -1 permet de sortir un élément du parcours de tabulation et/ou de donner la capacité à un élément ne pouvant recevoir le focus de le recevoir via programmation. Ce que tu nous remontes n'est pas lié au tabindex mais à l'implémentation en tant que telle (qui ne serait d'ailleurs pas conforme au DP ARIA Dialog). L'implémentation avec tabindex -1 requière d'avoir un élément neutre en fin de dialog modal qui reçoit le focus et le redistribue (élément span avec tabindex 0 doté d'un listener pour gérer la tabulation dans les deux sens : tabulation et "tabulation arrière"). Concernant ta remarque sur la possibilité d'aller dans les menus ou la barre d'adresse du navigateur, cette possibilité reste offerte à l'utilisateur, peu importe l'implémentation, par l'utilisation des raccourcis navigateur (exemple : un Commande + L (Cmd+L ou Ctrl+L) sous Firefox pour se placer dans la barre d'adresse et il y a bien d'autres raccourcis). Ne pas penser à empêcher l'utilisateur de le faire (ce qui n'est d'ailleurs jamais demandé) mais s'assurer que la navigation clavier ne puisse se faire que sur la dialog modal. Et ça les deux implémentations le permettent. L'implémentation avec tabindex -1, bien que "plus compliquée" techniquement, me semble plus robuste si l'on envisage des fonctionnalités de navigation pouvant être offertes via extension ou nativement par le navigateur (ça existe peut être déjà). Mais d'un point de vue accessibilité, le choix est libre. Supplément : le DP ARIA Dialog ne le demande pas mais les éléments de second plan doivent être masqués aux ATs (usage d'aria-hidden à true sur un parent "englobant"). Tu écris : Après pas mal de recherches, il s’avère que Internet Explorer 8 et 9 ne désactivent pas la tabulation sur les bouton radio avec un tabindex négatif. Du coup, la seule solution qui fonctionne dans mon cas est la gestion des évènements au clavier. C'est très ennuyeux ce souci avec IE mais non, cela ne rend pas l'implémentation via tabindex -1 inapplicable. Cela peut se contourner en désactivant les éléments de formulaire via disabled. A l'époque d'IE 6, les select posaient problème avec ces même dialog modals, pas pour cela que l'on ne contournait pas le problème ;). Romain Le 7 août 2014 11:35, Chardon Nicolas <[email protected]> a écrit : > Je viens de noter un différence notable de comportement entre les deux > solutions techniques : avec un tabindex=-1, il est possible de tabuler en > dehors de la page (vers la barre d’adresse ou les menus du navigateur), ce > qui n’est pas possible avec la gestion d’évènements. Après pas mal de > recherches, il s’avère que Internet Explorer 8 et 9 ne désactivent pas la > tabulation sur les bouton radio avec un tabindex négatif. Du coup, la > seule solution qui fonctionne dans mon cas est la gestion des évènements au > clavier. > > > > Nicolas > > > > *De :* Chardon Nicolas > *Envoyé :* lundi 4 août 2014 17:31 > *À :* GTA > *Objet :* RE: [Liste GTA] Design Pattern "Dialog" et tabindex > > > > Bonjour Romain, > > > > Merci pour ta réponse qui me conforte dans l’approche par gestionnaire > d’évènement que je trouve plus fine. En ce qui concerne la problématique de > performance, mon inquiétude vient du fait que j’ai environ 400 éléments > dans la page qui doivent recevoir un tabindex=-1, au sein d’un DOM assez > touffu (environ 2800 nœuds), ce qui sur des navigateurs anciens comme > Internet Explorer 8, me préoccupait un peu. C’est peut-être un excès de > précaution de ma part … > > > > Nicolas > > > > *De :* liste_gta [mailto:[email protected] > <[email protected]>] *De la part de* Romain Gervois > *Envoyé :* lundi 4 août 2014 10:23 > *À :* GTA > *Objet :* Re: [Liste GTA] Design Pattern "Dialog" et tabindex > > > > Bonjour Nicolas, > > Les deux implémentations (tabindex ou listeners) sont tout à fait > acceptables. Le DP ne se positionne pour aucune des deux (et il a bien > raison là dessus). Celle basée sur les listeners est assez intéressante du > fait qu'elle ne travaille pas sur les éléments et qu'elle n'a de ce fait > aucun impact sur leurs spécificités éventuelles. > > Pour l'histoire de la performance, je suppose que l'affirmation se base > sur le fait que l'une nécessite un parcours de l'arbre et l'autre pas. Je > ne sais pas si la problématique de performance est vraiment réelle et > impactante dans ce contexte ; je suis preneur de ressources si tu as ;). > > Pour le tabindex -1 sur le bouton radio sous IE 8 (pas testé pour ma > part), le comportement que tu décris indique la présence d'un bug (absence > ou mauvaise implémentation d'IE). Là comme ça, je dirai pas le choix il > faut "patcher" via propriété/attribut disabled du bouton radio. > > Romain > > > > Le 31 juillet 2014 15:33, Chardon Nicolas <[email protected]> a > écrit : > > Bonjour à toutes et à tous, > > > > Pour les fenêtres modales, le design pattern WAI ( > http://www.w3.org/TR/wai-aria-practices/#dialog_modal) recommande que la > navigation au clavier reste dans la fenêtre modale. Dans le wiki AcceDe Web > ( > http://wiki.accede-web.com/notices/interfaces-riches-javascript/fenetres-modales-pop-in#comportement-avec-javascript), > la technique JavaScript recommandée consiste à rajouter un « tabindex=-1 » > à tous les éléments ne faisant pas partie de la modale. > > > > Sur un document complexe, le rajout d’un tabindex=-1 sur tous les > éléments pouvant prendre le focus peut concerner un grand nombre > d’éléments, et engendrer des problématiques de performances. Le design > pattern du WAI ne parle que du comportement de la tabulation, et j’ai > trouvé plusieurs ressources sur le web qui utilisent une approche par la > gestion des évènements du clavier pour respecter le pattern : > > http://juicystudio.com/article/custom-built_dialogs.php#comment9 > > http://drublic.de/blog/accessible-dialogs-modals/ > > > > Cette approche par gestion des évènements clavier me semble plus > pertinente, d’un point de vue de la solution technique, et elle respecte le > design pattern : > > Quels sont vos avis sur ce sujet ? > > > > De plus, lors d’un test sur Internet Explorer 8, j’ai pu prendre le focus > sur un bouton radio avec un tabindex=-1 : avez-vous déjà rencontré ce > problème ? > > > > En vous remerçiant par avance de vos lumières sur ce sujet, > > > > Cordialement, > > > > *NICOLAS CHARDON * > > *ARCHITECTE IHM * > > *VSC Technologies* > > 2 place de la Défense – CNIT 1 – BP 440 – 92053 Paris La Défense Cedex > > TÉL. : +33 (0)1 58 13 73 22 (73 22) - [email protected] > > Voyages-sncf.com, 23 sites couvrant plus de 30 pays. > > *[image: cid:[email protected]]* > > *[image: V.png]* <http://mobile.voyages-sncf.com/> > > Téléchargez notre application mobile <http://mobile.voyages-sncf.com/> > > *[image: twitter.jpg]* <https://twitter.com/Voyagessncf_com> > > Suivez-nous sur Twitter <https://twitter.com/Voyagessncf_com> > > *[image: Facebook.png]* <https://fr-fr.facebook.com/VoyagesSncf.com> > > Rejoignez-nous sur Facebook <https://fr-fr.facebook.com/VoyagesSncf.com> > > *[image: GooglePlus-512-Red.png]* > <https://plus.google.com/+voyagessncf/posts> > > Rejoignez-nous sur Google + <https://plus.google.com/+voyagessncf/posts> > > > > > > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > > > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > >
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
