1178 sujets

Accessibilité du Web

Pages :
Bonjour,

J'ai développé un menu déroulant très simple à base de CSS et d'une toute petite touche de JS, mais je réalise qu'il n'est pas adapté à la navigation par tabulation en effectuant des tests...

Existe-t-il un équivalent à onmousemove pour ce mode de navigation? Si la réponse est négative, comment puis-je contourner ce problème et permettre à tous de rentrer dans les sous-menus?

Merci par avance.
Modifié par zamoy (22 Mar 2010 - 22:31)
Salut,

Qu'on le réalise en JavaScript ou uniquement en CSS, un menu déroulant ne sera jamais accessible à 100 %.

Pour que les sous-menus d'un menu déroulant soient atteignables au clavier, il faut que l'élément chapeautant le sous-menu comporte un lien permettant d'accéder à une URL où les éléments du sous-menu sont affichés en permanence, pour ainsi dire. Autrement dit :
page d'accueil
<ul id="ton-menu-deroulant">
  <li>
    <a href="rubrique-1.html">Rubrique 1</a>
    <ul>
      <li><a href="rubrique-1-1.html">Rubrique 1.1</a></li>
      <li><a href="rubrique-1-2.html">Rubrique 1.2</a></li>
      <li><a href="rubrique-1-3.html">Rubrique 1.3</a></li>
    </ul>
  </li>
  <li>
    <a href="rubrique-2.html">Rubrique 2</a>
    <ul>
      <li><a href="rubrique-2-1.html">Rubrique 2.1</a></li>
      <li><a href="rubrique-2-2.html">Rubrique 2.2</a></li>
      <li><a href="rubrique-2-3.html">Rubrique 2.3</a></li>
    </ul>
  </li>
</ul>

au niveau de chaque rubrique de premier niveau
<ul id="menu-non-deroulant">
  <li><a href="rubrique-1-1.html">Rubrique 1.1</a></li>
  <li><a href="rubrique-1-2.html">Rubrique 1.2</a></li>
  <li><a href="rubrique-1-3.html">Rubrique 1.3</a></li>
</ul>

Soit dit en passant, j'espère que tes sous-menus ne sont pas masqués au moyen d'un display: none. Smiley cligne
Modifié par Victor BRITO (22 Mar 2010 - 18:38)
Ah bon, y'a pas moyen d'accessibilier à 100% un menu déroulant... pfff, dommage...

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?!? Smiley confused (pas taper hein)
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. Smiley cligne

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. Smiley lol

Maintenant la question bonus: quels sont les équivalents de mouseover et mouseout avec un écran tactile, hum?
Victor BRITO a écrit :
Salut,

Qu'on le réalise en JavaScript ou uniquement en CSS, un menu déroulant ne sera jamais accessible à 100 %.


Légende urbaine. Dans cette optique, rien n'est accessible. Même pas au 50% qui constitue déjà un excellent résultat. En parlant d'inaccessibilité per se des menus déroulants, tu commence par te placer hors WCAG. C'est un mauvais départ.
Florent V. a écrit :

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.


ce n'est effectivement pas invalidant. Ce qui est invalidant, c'est le contenu caché en display:none et qui le restera alors qu'il est pertinetn dans un lecteur d'cran, parce qu'aucune fonction accessible ne le rendra perceptible. Typiquement, les labels masqués, les liens d'accès rapides masqués, les contenus de pseudos-liens remplis avec CSS masqués, etc. (bon, ces derniers restent spécialement non accessibles même sans display:none, mais pour d'autres raisons).
Florent V. a écrit :

Maintenant la question bonus: quels sont les équivalents de mouseover et mouseout avec un écran tactile, hum?


La réponse évoque un doigt, mais la pudeur me l'interdit Smiley cligne
Modifié par Laurent Denis (22 Mar 2010 - 21:55)
Laurent Denis a écrit :


La réponse évoque un doigt, mais la pudeur me l'interdit Smiley cligne


haha , allez , et un tabindex avec un doctype permissif ?
AVec un tactile, il faut bien ouvrir le menu d'une façon ou d'une autre.... pour l'ouvrir il faut toucher l'élément désiré.... ce qui revient au même que cliquer je pense. J'ai aucune idée en fait, je n'ai pas d'appareil tactile.
QuentinC a écrit :
AVec un tactile, il faut bien ouvrir le menu d'une façon ou d'une autre.... pour l'ouvrir il faut toucher l'élément désiré.... ce qui revient au même que cliquer je pense. J'ai aucune idée en fait, je n'ai pas d'appareil tactile.


C'est ça : toucher = cliquer. Smiley cligne
a écrit :
C'est ça : toucher = cliquer.

Donc les appareils tactiles n'ont aucun équivalent aux évènements mouse over/out, c'est bien ça ?

Chouette ! Une autre bonne raison outre WCAG pour (enfin) les faire enlever : dire que ça ne peut pas marcher sur iphone.
Le mouse over c'est certain (c'est d'ailleurs dans la doc d'apple), pour le mouse out logiquement ça devrait être pareil.

Sinon je ne vois pas bien pourquoi il faudrait les enlever... Il y a un problème d'accessibilité?
Modérateur
Patidou a écrit :
C'est ça : toucher = cliquer. Smiley cligne


Selon le contexte, ça pourrait aussi être toucher = claquer Smiley belle Smiley lapin

Smiley dehors
a écrit :

Sinon je ne vois pas bien pourquoi il faudrait les enlever... Il y a un problème d'accessibilité?

Oui. En fait il ne faut pas les enlever mais les doubler d'un équivalent utilisable au clavier, en l'occurence onfocus et onblur.... qu'on n'utilise pas tout à fait de la même manière.
a écrit :

Ah OK, alors je suis dans le bon quand je fais des textes qui se déplie.

Ca dépend des conditions qui font qu'ils se déplient et des conditions qui font qu'ils se replient.
QuentinC a écrit :

Ca dépend des conditions qui font qu'ils se déplient et des conditions qui font qu'ils se replient.


Ce que je voulais dire c'est que j'utilise à la fois "mouse" et "blur" pour ceux qui naviguent au clavier. Et j'essaye de ne pas pas utiliser le "display:none", plutôt positionner les éléments en dehors de la page. Smiley cligne
Pages :