1178 sujets

Accessibilité du Web

Ouvrir un menu déroulant : quelle balise html employer ?

Pages :
Bonjour,

Prenons un menu déroulant simplifié de ce genre :

<div class="tab" id="ore">Produit 1812 &gt; <button disabled="disabled">Table d&#039;orientation</button>
<table class="ore">
<tbody>
<tr><th colspan="2">Ce produit appartient aux rayons suivants</th></tr>
<tr><th>Espace</th><th>Rayon</th></tr>
<tr><td><a href="j.php?a=lien_1">Cordon et C&acirc;ble RJ45</a></td><td><a href="lien_2">Connecteur et prise RJ45</a></td></tr>
<tr><td><a href="lien_3">Accessoire de r&eacute;seau</a></td><td><a href="j.php?a=lien_4">R&eacute;seau r&eacute;sidentiel</a></td></tr>
</tbody></table>
</div>


table class="ore" est en display none et activé par les css

div.tab {position: relative; line-height: 1.5em}
table.ore {position: absolute; left: 0; top: 1.4em; display: none; background-color: #FFF; border: 1px solid #5E7493; z-index: 1}
div.tab button:hover+table {display: block}
div.tab button {background: none; border: 0; padding: 0; font-size: 1em; cursor: pointer; color: #976A69}
div.tab button:hover {color: #900}


Je me pose quelques questions.

J'ai lu que pour l'accessibilité <button> est mieux que <a href="#'>

Cela dit ce menu est dans un formulaire.
J'ai constaté sous Firefox que <button>, même sans type="submit" agit comme un bouton de soumission. Je ne sais pas si ce comportement est normal mais c'est comme ça.

Seule solution que j'ai trouvée : disabled="disabled"

On ouvre donc un menu avec un bouton désactivé.
Un peu bizarre pour l'accessibilité.

Faut-il employer une autre balise ?
Le cas est-il traité en html 5 ?

Je me pose aussi la question du type de cursor employer pour cet usage.
J'ai choisi pointer sans conviction.

Enfin je me demande s'il est possible de faire la même chose sans passer par position: absolute mais là c'est plus une question de css que d'accessibilité.

Merci d'avance pour vos lumières.
Modérateur
Bonjour,

1) Par défaut, les boutons sont de type submit. Pour éviter qu'ils soient de type submit il suffit de leur donner un autre type, a priori button.
<button type="button">Presque n'importe quoi ici</button>


2) Pour le cursor, "pointer" me semble bien.

3) On peut surement se passer de "position:absolute", tellement il existe de combines en css. Smiley lol Smiley lol Smiley lol
Après, ça ne sera pas forcément très propre ! Smiley smile

Amicalement,
Bonjour,

1)
<button type="button">
Effectivement cela fonctionne.

J'utilise aussi <button> hors formulaire.
Dans ce cas pas besoin de préciser de type je suppose ?
Je sais que cela marche sans type mais l'absence de type est-elle une erreur vis-à-vis du W3C ou de l'accessibilité ?

2)
Ok, pointer

3)
C'est un cas où il semble difficile de se passer de position absolute car l'ouverture du menu ne doit pas modifier la mise en page.
Le menu s'affiche en premier plan superposé.
Cela juste par esthétique, il est généralement moche de décaler un contenu vers le bas pour laisser la place au menu.
Modérateur
Bonjour,

1) Je mettrais <button type="button">

3) Un petit exemple pour la route ...

Edit : le html est bien entendu exactement celui que tu as donné en exemple !
Edit2: quelques modifications cosmétiques pendant la nuit (au passage, je signale que déclencher l'apparition d'un menu sur un :hover n'est pas terrible pour ceux qui naviguent au clavier, et je ne vois pas trop comment ça pourrait marcher correctement)

body
{
	font-family: sans-serif;
	font-size: 2rem;
	background: #000;
}
button
{
	font-family: sans-serif;
	font-size: 2rem;
	outline: none;
}
div.tab
{
	display: block;
	line-height: 1.5em;
	text-align: center;
	color: #fff;
}
table.ore
{
	position: relative;
	top: -100vh;
	color: #000;
	background-color: #fff;
	border: 0;
	z-index: 1;
	margin: 0 auto;
	pointer-events: none;
}
div.tab button
{
	background: none;
	border: 0;
	padding: 0;
	font-size: 1em;
	cursor: pointer;
	color: #fff;
}
div.tab button:hover+table {top: 0; transition: top 1s;}
div.tab button:hover {color: #900}
table a
{
	position: relative;
	display: block;
	border-radius: 50%;
	font-size: 1rem;
	border: 0.5rem solid red;
	background: red;
	color: #fff;
}
table tr:nth-of-type(3) td:nth-of-type(1) a
{
	left: -100vw;
	transform: rotate(0.5turn);
}
table tr:nth-of-type(3) td:nth-of-type(2) a
{
	right: -100vw;
	transform: rotate(-0.5turn);
}
table tr:nth-of-type(4) td:nth-of-type(1) a
{
	bottom: -200vh;
	transform: rotate(0.5turn);
}
table tr:nth-of-type(4) td:nth-of-type(2) a
{
	bottom: -200vh;
	transform: rotate(-0.5turn);
}
div.tab button:hover+table tr:nth-of-type(3) td:nth-of-type(1) a
{
	left: 0;
	transform: rotate(0turn);
	transition: left 1s, transform 1s;
}
div.tab button:hover+table tr:nth-of-type(3) td:nth-of-type(2) a
{
	right: 0;
	transform: rotate(0turn);
	transition: right 1s, transform 1s;
}
div.tab button:hover+table tr:nth-of-type(4) td:nth-of-type(1) a
{
	bottom: 0;
	transform: rotate(0turn);
	transition: bottom 1s, transform 1s;
}
div.tab button:hover+table tr:nth-of-type(4) td:nth-of-type(2) a
{
	bottom: 0;
	transform: rotate(0turn);
	transition: bottom 1s, transform 1s;
}

Amicalement,
Modifié par parsimonhi (14 Sep 2020 - 05:49)
Modérateur
Bonjour,

Si l'on veut faire du css pur, j'ai le sentiment qu'une solution avec un seul bouton (et pas d'autres éléments html genre un checkbox plus ou moins caché qu'on mettrait devant tout ça) soit impossible à réaliser si on est soucieux de l'accessibilité (et donc entre autre de la navigation clavier). En effet, on n'aurait, pour déplier le menu que le :hover (à oublier selon moi quand on parle d'accessibilité, et puis même hors question d'accessibilité, faire une action sur un hover, ça craint) ou le :focus (qui est difficile, voir impossible à gérer en css pur en cas de navigation clavier dans un menu).

Du coup, l'avantage qu'aurait un <button> sur un <a href="#'> me semble passer au second plan.

Un petit exemple complet qui marche avec deux <a> au lieu d'un <button> (et sans position:absolute puisque c'était la question de départ, et même si je ne vois pas trop en quoi ça dérange d'avoir un position:absolute):
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<title>Test</title>
<style>
body
{
	font-family: sans-serif;
	font-size: 2rem;
	background: #000;
	padding: 0;
	margin: 0;
}
a
{
	color: #fff;
	text-decoration: none;
	outline: 0;
}
a:focus,
a:hover
{
	color:#ff0;
}
a[href="#"]
{
	display: none;
}
#ore:target a[href="#"]
{
	display: inline-block;
}
#ore:target a[href="#ore"]
{
	display: none;
}
div.tab
{
	display: block;
	line-height: 1.5em;
	text-align: center;
	color: #fff;
}
table.ore
{
	position: relative;
	top: -100vh;
	color: #000;
	background-color: #fff;
	border: 0;
	z-index: 1;
	margin: 0 auto;
}
#ore:target table {top: 0; transition: top 1s;}
table a
{
	visibility: hidden;
	position: relative;
	display: block;
	border-radius: 50%;
	font-size: 1rem;
	border: 0.5rem solid red;
	background: red;
	color: #fff;
}
#ore:target table a
{
	visibility: visible;
}
table tr:nth-of-type(3) td:nth-of-type(1) a
{
	left: -100vw;
	transform: rotate(5turn);
}
table tr:nth-of-type(3) td:nth-of-type(2) a
{
	right: -100vw;
	transform: rotate(-5turn);
}
table tr:nth-of-type(4) td:nth-of-type(1) a
{
	bottom: -200vh;
	transform: rotate(5turn);
}
table tr:nth-of-type(4) td:nth-of-type(2) a
{
	bottom: -200vh;
	transform: rotate(-5turn);
}
#ore:target table tr:nth-of-type(3) td:nth-of-type(1) a
{
	left: 0;
	transform: rotate(0);
	transition: left 1s, transform 1s;
}
#ore:target table tr:nth-of-type(3) td:nth-of-type(2) a
{
	right: 0;
	transform: rotate(0);
	transition: right 1s, transform 1s;
}
#ore:target table tr:nth-of-type(4) td:nth-of-type(1) a
{
	bottom: 0;
	transform: rotate(0);
	transition: bottom 1s, transform 1s;
}
#ore:target table tr:nth-of-type(4) td:nth-of-type(2) a
{
	bottom: 0;
	transform: rotate(0);
	transition: bottom 1s, transform 1s;
}
</style>
</head>
<body>
<div class="tab" id="ore">Produit 1812 &gt;
<a href="#" title="Replie le menu">Table d&#039;orientation</a>
<a href="#ore" title="Déplie le menu">Table d&#039;orientation</a>
<table class="ore">
<tbody>
<tr><th colspan="2">Ce produit appartient aux rayons suivants</th></tr>
<tr><th>Espace</th><th>Rayon</th></tr>
<tr><td><a href="j.php?a=lien_1">Cordon et C&acirc;ble RJ45</a></td><td><a href="lien_2">Connecteur et prise RJ45</a></td></tr>
<tr><td><a href="lien_3">Accessoire de r&eacute;seau</a></td><td><a href="j.php?a=lien_4">R&eacute;seau r&eacute;sidentiel</a></td></tr>
</tbody></table>
</div>
</body>
</html>

Amicalement
Modérateur
Bonjour
a écrit :

Je sais que cela marche sans type mais l'absence de type est-elle une erreur vis-à-vis du W3C ou de l'accessibilité ?

Ce n'est pas une erreur de ne pas indiquer type, mais c'est une bonne pratique de toujours le mettre car 1) cela rend explicite que le bouton ne fait rien (hors javascript custom), 2) Cela évitera des problèmes/bugs lorsque ton bouton se retrouvera dans un form.
Modérateur
Greg_Lumiere a écrit :
Bonjour,

Ou alors details...


Intéressant ! Je me demande pourquoi ce n'est pas plus largement utilisé.

Après, sémantiquement, c'est peut-être aussi un peu limite !

Amicalement,
@Parsimonhi: Je ne sais pourquoi cette balise ne décore pas plus notre paysage virtuel qu'à l'heure actuelle. Peut-être car les navigateurs ne l'ont pas intégrée de suite dans les meilleures conditions, va savoir.
Sémantiquement ça a tout son sens, autant que toute autre balise html5. De plus les robots tiennent compte du contenu masqué.
J'ajouterais qu'une petite couche d'attribut Aria ne peut faire de mal et hop, un composant prêt à l'emploi et totalement personnalisable.

Quand je pense à toutes les ruses auxquelles il fallait faire appel avant... mais ça c'était avant!
Modifié par Greg_Lumiere (14 Sep 2020 - 10:47)
Bonjour,

Merci pour toutes ces informations très intéressantes.

Je reprends à tête reposée ce soir ou un peu plus tard.

Je vous tiens informés.
Modérateur
Greg_Lumiere a écrit :
@Parsimonhi: Je ne sais pourquoi cette balise ne décore pas plus notre paysage virtuel qu'à l'heure actuelle. Peut-être car les navigateurs ne l'ont pas intégrée de suite dans les meilleures conditions, va savoir.
Sémantiquement ça a tout son sens, autant que toute autre balise html5. De plus les robots tiennent compte du contenu masqué.
J'ajouterais qu'une petite couche d'attribut Aria ne peut faire de mal et hop, un composant prêt à l'emploi et totalement personnalisable.

Quand je pense à toutes les ruses auxquelles il fallait faire appel avant... mais ça c'était avant!


Je plussoie en totalité !

Amicalement,
Bonjour,

1) <details> paraît en effet intéressant.
MDN ne fait toutefois aucune allusion à son emploi pour un menu déroulant.

Comme si les menus déroulants n"étaient pas depuis des lustres un élément essentiel de l'ergonomie.

Dès que j'ai le temps je teste <details> et surtout le comportement sur des navigateurs non compatibles.
Avec un peu chance on peut s'en sortir avec du Css ou Javscript pour les vieux coucous.

2) Toujours donner un type à button.
Ok.

3) Merci pour vos codes.
Je les publie dans un codepen dès que j'ai le temps.
boteha_2 a écrit :
Bonjour,

1) &lt;details&gt; paraît en effet intéressant.
MDN ne fait toutefois aucune allusion à son emploi pour un menu déroulant.

Comme si les menus déroulants n"étaient pas depuis des lustres un élément essentiel de l'ergonomie.
mais... why not? Smiley cligne

boteha_2 a écrit :
Dès que j'ai le temps je teste &lt;details&gt; et surtout le comportement sur des navigateurs non compatibles.
Avec un peu chance on peut s'en sortir avec du Css ou Javscript pour les vieux coucous.
En effet, s'il vous faut une large rétro-compatibilité, il faut prévoir un paliatif. Fort heureusement les solutions ne manquent pas:
* un fallback entièrement en JS comme le prévoit Bootstrap pour ce type de menu (à mes yeux c'est l'option Z hihi)
* la méthode de la checkbox qui couplée avec une petite couche de Css est redoutable d'efficacité. Perso j'aime peu utiliser un élément de formulaire pour un effet visuel mais quand il faut..
* une méthode entièrement en Css. Un poil plus complexe à mettre en oeuvre mais waterproof (ceci est susceptible de vous inspirer.

Le seul écueil puisse être de dire au navigateur dans quelle circonstance utiliser le fallback.

Après en regardant de près la compatibilité n'est pas mauvaise, on voit que Edge l'a adopté dès le début, Firefox depuis 2017, Chrome depuis 2015, Safari a un rendu parfait depuis 2018 et Opera depuis 2013. Côté mobile RAS.
De plus le fallback naturel de cette balise est de restituer son contenu tel quel, en bloc, laissant ainsi l'information disponible à tout à chacun.
Modifié par Greg_Lumiere (15 Sep 2020 - 09:09)
Modérateur
<details> nécessite en effet un pollyfill pour Internet Explorer, pour faire un menu déroulant, un simple fallback n'est souvent pas adapté. C'est pour cela que je n'y suis pas passé, préférant mes vieilles mais fonctionnelles recettes JS/CSS. Mais sinon c'est clairement engageant comme solution.

Je déconseille aussi la méthode checkbox, qui est une fausse bonne idée: utilisation de fonctionnalité non standard, problèmes d'accessibilités et sémantique aux oubliettes.
Modérateur
Bonjour,

Je pense qu'il faut oublier internet explorer. Même Microsoft vient d'annoncer qu'il allait cesser complètement de s'en occuper dans les mois qui viennent. Les 2% de parts de marché que revendique encore Internet Explorer devraient faire moins de 1% l'année prochaine.

Par contre, depuis hier, j'ai trouvé quelques bugs avec la balise <details> pour des navigateurs récents. L'un des plus gênants se manifeste avec Chrome (au moins sous Mac OS, je n'ai pas essayé ailleurs) et Safari lorsqu'on essaie de faire des transitions sur les éléments contenu dans <details> autre que l'élément <summary>. Or c'est justement la première chose qu'on essaie de faire quand on veut faire un menu déroulant.

Html de test
<details>
<summary>Test</summary>
<p>Mon joli texte</p>
</details>


Css qui semble ne pas marcher ni avec chrome ni avec safari (pas d'effet de transition), mais qui marche avec firefox :
p
{
	position: relative;
	left: -20em;
}
details[open] p
{
	left: 0;
	transition: left 1s ease;
}


Palliatif css pour chrome (effet de transition obtenu via une animation) :
p
{
	position:relative;
	left: -20em;
}
@keyframes openDetails
{
	0%   {left: -20em;}
	100% {left: 0;}
}
details[open] p
{
	animation: openDetails 0.5s ease-out forwards;
}

J'ai peut-être raté quelque chose, mais je n'ai pour l'instant pas trouvé mieux.

Amicalement,
Modérateur
a écrit :

Je pense qu'il faut oublier internet explorer. Même Microsoft vient d'annoncer qu'il allait cesser complètement de s'en occuper dans les mois qui viennent. Les 2% de parts de marché que revendique encore Internet Explorer devraient faire moins de 1% l'année prochaine.

Je m'en fiche un peu des parts de marché revendiquées par Microsoft, j'ai pas mal de sites avec 10%, les plus faibles parts sont de 5% et les plus hautes de 15%. Donc non c'est trop tôt pour «laisser tomber»

Après oui <details> est très intéressant (même s'il n'est pas fait pour cela, ce qui provoque et demande quelques contournements).
Bonjour,

parsimonhi a écrit :
Le :hover (à oublier selon moi quand on parle d'accessibilité, et puis même hors question d'accessibilité, faire une action sur un hover, ça craint) ou le :focus (qui est difficile, voir impossible à gérer en css pur en cas de navigation clavier dans un menu).


Cette discussion est passionnante, les exemples de code très intéressants, notamment l'emploi de la :targent par Greg Lumiere, mais j'ai l'impression que l'on oublie en route quelque chose d'important.

L'événement qui déclenche un menu déroulant ne doit-il pas forcément être :hover ?
C'est le comportement de TOUS les logiciels pour PC. Imaginez-vous un logiciel où vous devez ouvrir un menu déroulant par un clic et le fermer par un autre clic ? C'est bien sûr possible mais pas dans les habitudes et vous seriez sans doute énervés.
Il est vrai que l'ergonomie sur téléphone est différente.
Et qu'un site Internet n'est pas exactement un logiciel pour PC.

Une autre piste est donc d'essayer de rendre le :hover accessible.
Une petite couche d'attribut Aria ?
Une action sur <button> par :hover en css et en click par JS ?
Modifié par boteha_2 (15 Sep 2020 - 21:54)
Modérateur
boteha_2 a écrit :

L'événement qui déclenche un menu déroulant ne doit-il pas forcément être :hover ?
C'est le comportement de TOUS les logiciels pour PC. Imaginez-vous un logiciel où vous devez ouvrir un menu déroulant par un clic et le fermer par un autre clic ? C'est bien sûr possible mais pas dans les habitudes et vous seriez sans doute énervés.
Il est vrai que l'ergonomie sur téléphone est différente.
Et qu'un site Internet n'est pas exactement un logiciel pour PC.

Déjà sur mobile, on a pris l'habitude de cliquer puisqu'on ne peut pas faire autrement. Donc, je ne pense pas que les gens attendent forcément des hovers. Ils s'en passent très bien sans même s'en apercevoir.

Ensuite, si les applications utilisent des hovers, on doit quand même cliquer sans arrêt. Par exemple, sur mon macintosh, si je veux voir se déplier le "menu du haut" alors que je suis en train d'écrire cette réponse sur le site Alsacréations, je dois d'abord cliquer une fois dans la barre de menu (pour lui donner le focus) avant de pouvoir déplier les menus via des hovers. Et je pourrais multiplier les exemples (en gros, dès qu'on a plusieurs fenêtres ou onglets quelque part, il faut cliquer). Donc bon, on est loin de se balader partout en faisant simplement des hovers.

Après, c'est vrai aussi que quand on met un hover dans un code css, un mobile va quand même déclencher l'action de ce hover sur un clic. Du coup, on peut très bien se dire qu'on va mettre des effets hover un peu partout, que sur un pc de bureau, ça va (peut-être) faciliter la vie de l'internaute, et que sur mobile, il pourra quand même s'en sortir en cliquant pour simuler le hover (aux bugs près) : admettons.

Mais dès que c'est un peu compliqué (genre des menus avec des sous-menus), le hover, en fait, c'est un peu galère. Vraiment, je n'aime pas du tout. Il ne faut pas avoir de problèmes articulaires qui rendent difficile le déplacement de la souris, ou un pavé tactile pas assez grand qui oblige à faire plusieurs tentatives avant de réussir le dépliage. Et aussi, ce qui est vraiment pénible, c'est quand on va d'un point A à un point B et qu'on déclenche un hover qui vient cacher le point B. Par exemple, si on est sur le bouton "emploi" de cette page, et qu'on veut aller au lien "Recherche avancée", bah on doit "faire le tour". Là, ça va, on sort assez vite du hover du bouton "emploi", mais y en a certains qui nous mettent des boutons énormes et il faut faire des "kilomètres" avec la souris pour les contourner, sans compter les cas où on a une série de boutons qui se touchent et que tous déclenchent une "apparition" sur un hover. On met des plombes à contourner tout ça.

Enfin, au niveau du code, le hover (ou le focus) ce sont des états qui ne sont pas toujours faciles à gérer parce que dès qu'on quitte l'endroit qui a déclenché le hover (ou le focus), bah, l'effet disparait. Il faut donc combiner pour que ça ne se produise pas : prise de tête assurée dès que c'est un peu sophistiqué !

Amicalement,
boteha_2 a écrit :

L'événement qui déclenche un menu déroulant ne doit-il pas forcément être :hover ?
Pas nécessairement tel que l'a démontré Parcimonhi.

boteha_2 a écrit :
C'est le comportement de TOUS les logiciels pour PC. Imaginez-vous un logiciel où vous devez ouvrir un menu déroulant par un clic et le fermer par un autre clic ? C'est bien sûr possible mais pas dans les habitudes et vous seriez sans doute énervés.
Justement non, pas énervé ni même un tantinet agacé dans la mesure où, l'exemple pour le Mac est tout aussi vrai sur Windows (et sans trop me tromper je dirais que c'est idem sur Linux à interface graphique), lorsque je veux activer une fonctionnalité d'un menu je dois cliquer au préalable. Il n'est que le niveau 2 que j'atteindrai au survol. Et encore, cette habitude est venue avec le temps ; je me souviens encore de ces logiciels où il fallait cliquer à tous les sous-niveaux pour les dévoiler.

boteha_2 a écrit :
Et qu'un site Internet n'est pas exactement un logiciel pour PC.
Cela reste très proche tout de même, non ?

boteha_2 a écrit :
Une autre piste est donc d'essayer de rendre le :hover accessible.
Là on part à l'envers je pense. Pour rappel, le contenu développé au survol n'est certainement pas une information capitale, elle ne serait pas cachée sinon. Donc il s'agit bien d'une aide complémentaire facultative et j'insiste sur le "facultative". On n'y trouveras pas le dernier script de Sir Spielberg ni un coupon de réduction d'exception.
Bien sûr il ne faut pour autant pas boycotter cette fonctionnalité mais se dire qu'elle ne sera utile qu'à ceux qui disposent d'un dispositif de pointage le permettant. Un petit plus.

boteha_2 a écrit :
Une petite couche d'attribut Aria ?
Telle que je vois ces attributs - et je ne suis pas spécialiste en la matière car... bref passons - leur utilité majeure n'est pas de rendre plus accessible des évènements mais bien des composants. Aider la machine à comprendre et interpréter au plus juste l'élément pointé et cela, en surcouche. On commence par un code html impeccable et ensuite on ajuste pour le confort de l'utilisateur, palier aux défauts d'implémentation des navigateurs ou des assistants. Donc en principe on ne devrait pas avoir à s'en servir pour détourner une interprétation native d'un élément.

boteha_2 a écrit :
Une action sur &lt;button&gt; par :hover en css et en click par JS ?
J'espère jamais n'avoir à en arriver là.
Bonjour,

Je suis d'accord avec vos remarques, j'ai exagéré la nécessité du :hover.

D'ailleurs je remarque que :

Sur Firefox le menu déroulant s'ouvre au clic.
Une fois un menu ouvert tout s'ouvre au hover.
C'est peut-être un comportement paramétrable mais c'est celui que j'ai sur mon PC.

Sur Chrome ouverture au clic.

Sur Excel ouverture au clic.

Sur Photoshop ouverture au clic.

Je ne m'en étais pas rendu compte mais l'ouverture au clic semble la règle.
Pages :
Sujet clos
Aller à