Victor BRITO a écrit :
Soit dit en passant, j'espère que tes sous-menus ne sont pas masqués au moyen d'un display: none.
Je ne suis pas sûr que ça soit rédhibitoire, à vrai dire. S'ils sont masqués ainsi mais qu'on peut les afficher et donc les rendre lisible, ça doit pouvoir rester utilisable. À voir. Mais bon, c'est vrai que ça ne coute rien de positionner en absolu en dehors de la zone visible, au moins quand la page ne comporte pas de liens afficher/masquer explicites.
zamoy a écrit :
Non, mes sous-menus ne sont pas masqués à l'aide d'un display:none, mais à l'aide d'un visibility:hidden... c'est pire/mieux/pareil?!? confused (pas taper hein)
Le
display:none fait que l'élément est considéré comme absent de la page (à quelques nuances près). Avec un lecteur d'écran, ça rend le contenu «invisible» (ha ha). Le
visibility:hidden a le même comportement dans la majorité des lecteurs d'écran.
Il y a peut-être (sans doute?) d'autres cas d'usage où display:none ou visibility:hidden empêchent l'accès au contenu.
Pour répondre à la question de départ, l'équivalent «clavier» des évènements mouseover et mouseout, ce sont les évènements focus et blur. Au focus sur le lien qui pointe vers ton index de rubrique (premier niveau du menu déroulant), tu affiches le sous-menu. Lorsque ce lien
ou les liens du sous-menu perdent le focus (blur), tu masques le sous-menu. La difficulté est de ne pas masquer le sous-menu quand tu passes du lien de la rubrique au premier lien du sous-menu ou inversement, ou d'un lien du sous-menu à un autre.
Je crois que Superfish, par exemple, exécute une fonction à chaque fois qu'un élément A du menu (quel que soit le niveau de profondeur) reçoit le focus (focus) ou le perd (blur), et fait des tests pour vérifier ce qu'il doit faire exactement. Ça peut être compliqué si on connait mal ou insuffisamment JavaScript, comme moi.
Maintenant la question bonus: quels sont les équivalents de mouseover et mouseout avec un écran tactile, hum?