[Résolu] Navigation responsive en <select>

Salut,
Est-ce une erreur du point de vue de l'accessibilité de choisir la solution <select> dans un contexte de navigation responsive ?

Merci d'avance.

Bonjour,

Je m'était brièvement penché sur la question et j'avais adopté le choix de basculer (via media queries) mon menu classique en un select en mode mobile (avec un poil de js pour changer de page à la sélection d'une option).

Sur certains des sites auxquels je me fie cette solution est évoquée (sans enthousiasme particulier mais sans non plus de mise en garde) "Sur mobile, la navigation sous forme de menu déroulant exploite la fonctionnalité de sélection de l’appareil, ce qui facilite la sélection." http://www.ergonomie-interface.com/conception-maquettage/responsive-webdesign-adapter-resolutions/

Personnellement j'ai été assez satisfait de la gestion native des select pour en faire un menu, reste à voir si toutes les interfaces mobiles le gère aussi bien...

D'après ce que j'ai pu lire, le principal problème d'accessibilité du select se situait avec la navigation au clavier (et encore) mais s'il n'est visible que sur une interface tactile...

Le select à aussi le défaut de masquer le nom des autres pages... donc je pense qu'il est envisageable mais sur une interface très réduite où la place est limitée (préférer un menu classique pour desktop et tablette).


Un vieux post (2006) sur le sujet : http://forum.alsacreations.com/topic-6-17396-1-Balise-Select-amp-Accessibilite-.html

a écrit :
D'après ce que j'ai pu lire, le principal problème d'accessibilité du select se situait avec la navigation au clavier (et encore) mais s'il n'est visible que sur une interface tactile...

Navigation tactile et au clavier peuvent ne pas être mutuellement exclusifs. Tu fais quoi des gens qui ont un clavier connecté en blutooth sur leur mobile par exemple ?

De toute façon, le <select> est fondamentalement une mauvaise idée pour faire des menus de navigation. Ce n'est pas son rôle, onchange ou pas.
Modifié par QuentinC (21 Jul 2014 - 13:22)

Salut salut,

QuentinC a écrit :
Navigation tactile et au clavier peuvent ne pas être mutuellement exclusifs. Tu fais quoi des gens qui ont un clavier connecté en blutooth sur leur mobile par exemple ?

On les brule ?
Plus sérieusement ce cas doit être assez rare non ?! Par contre j'ai AUCUNE idée de comment se comporte un mobile avec un clavier...!

QuentinC a écrit :
De toute façon, le &lt;select&gt; est fondamentalement une mauvaise idée pour faire des menus de navigation. Ce n'est pas son rôle, onchange ou pas.

+1 pour toi en y réfléchissant bien ca tombe sous le sens..
C'est un peu une solution de facilité car nativement les mobiles les plus répandus propose une gestion du select assez "sexy" (affiche toutes les options par dessus l'écran) qui évite de dev une autre solution à la main.

a écrit :
Plus sérieusement ce cas doit être assez rare non ?! Par contre j'ai AUCUNE idée de comment se comporte un mobile avec un clavier...!

JE ne pense pas que la situation iPhone/iPad + clavier blutooth soit si rare que ça, pour ne citer que cette variante. Je ne suis sûrement pas le seul à penser qu'écrire sur un clavier physique restera toujours plus confortable et plus rapide que sur un clavier virtuel.

Merci pour vos réponses.

QuentinC a écrit :

De toute façon, le &lt;select&gt; est fondamentalement une mauvaise idée pour faire des menus de navigation. Ce n'est pas son rôle, onchange ou pas.

A mes yeux, c'est le meilleur choix pour une navigation responsive ergonomiquement parlant.
Les liens peuvent être hiérarchisés.
Une fois déployé, select agit comme une lightbox. C'est très lisible et facilement utilisable. Tu peux scroller tout en bas du menu, ça n'affecte pas ta position dans la page.
Dans un contexte où "js" n'est pas activé, le bouton "submit" peut prendre la relève quand les autres solutions sont soit dans les choux, soit ils prennent toute la place. Si le menu est en position fixe, le site devient impossible à utiliser.

QuentinC a écrit :

Navigation tactile et au clavier peuvent ne pas être mutuellement exclusifs. Tu fais quoi des gens qui ont un clavier connecté en blutooth sur leur mobile par exemple ?

Le tactile ne se désactive pas quand tu connectes un clavier.

Cela dit, je viens de voir le problème de navigation au clavier avec google chrome. Quand Firefox attend qu'on appuie sur "entrée", Chrome valide automatiquement la première option. Si je trouve un moyen d'améliorer ce comportement, il n'y aura plus d'objection sur l'accessibilité du menu <select> hormis "ce n'est pas fait pour ça" ?

a écrit :
Les liens peuvent être hiérarchisés.

Ah, j'aimerais bien qu'on m'explique comment.

Si tu pensais à de l'indentation ou de l'ASCII-art p.ex. "Catégorie" puis ". . . Sous-catégorie" puis ". . . . . . Sous-sous-catégorie", ce n'est pas de la hiérarchisation, c'est de la bidouille à 2€; sémantiquement ça n'a aucune valeur.

Si tu pensais à <optgroup>, il y a certains navigateurs où les intitulés des groupes ne s'affichent pas, et/ou où les diférents groupes ne sont pas toujours clairement mis en évidence. JE crois que c'est le cas de certaines versions d'IE par exemple, car il utilise les COMBOBOX du système, qui n'ont pas cette fonctionnalité.

a écrit :
Le tactile ne se désactive pas quand tu connectes un clavier.

C'était effectivement à ça que je voulais rendre attentif.

a écrit :
Cela dit, je viens de voir le problème de navigation au clavier avec google chrome. Quand Firefox attend qu'on appuie sur "entrée", Chrome valide automatiquement la première option. Si je trouve un moyen d'améliorer ce comportement, il n'y aura plus d'objection sur l'accessibilité du menu <select> hormis "ce n'est pas fait pour ça" ?

Tu ne pourras pas améliorer ce comportement. Ca fait plus de 10 ans que différents navigateurs partagent deux opinions totalement différentes sur la façon de déclencher onchange, et ce n'est pas près de changer. Aucune des deux visions n'est plus juste ou plus fausse que l'autre à mon avis. Tiens, on pourrait par curiosité aller voir ce que dit la doc équivalente au WCAG pour les éditeurs de navigateurs (j'ai oublié le nom), juste pour savoir si quelqu'un a raison ou bien si rien n'est précisé.

Tu peux faire légèrement mieux en mettant un timer, mais tu risques de t'attirer les foudres des gens pressés, et tu n'as pas de moyen fiable pour savoir si ton onchange a été déclenché à la suite d'une interaction clavier, souris, touch, ou autre. Et en plus je ne suis même pas sûr que ça résoud fondamentalement le problème. Il faut au moins 1s de délai pour que ça commence à avoir une utilité.

Petit exemple rapide pour illustrer ce que je pense quand je parle de timer :

var select = document.getElementById('tonSelect');
var timer = null;

select.onchange = function(){
var _this = this;
if (timer) clearTimeout(timer);
setTimeout(function(){
window.location.href = _this.value;
}, 2000);
};

select.onblur = function(){
if (timer) clearTimeout(timer);
};

Merci pour ta réponse.
Deux méthodes pour hiérarchiser :
1. Il y a un lien dans le <li> parent du sous-menu et dans ce cas, <optgroup> n'est pas pertinent. Je pense donc à nbsp pour décaler visuellement les liens de niveau 2.
Mon choix du select ne s'est pas fait en 2 secondes. J'ai cherché, testé, réfléchi.
Il semble que les entités html se sont pas rendu par les lecteurs d'écran d'après les recherches que j'ai effectué lors de ma réflexion sur le choix à faire en navigation responsive.

2. Il n'y a pas de lien dans le li de niveau 1 et dans ce cas là, on peut utiliser <optgroup>. Encore une fois, on parle d'un contexte responsive. D'après mes tests, ça se comporte plutôt correctement.

Personnellement, ergonomie > *. Si je dois faire du code un peu sale pour améliorer le confort des utilisateurs, je ne me gène pas. Quand je dis ça, j'englobe tout le monde. D'où ma question de départ.

Enfin, j'ai trouvé quelqu'un qui s'est penché sur le problème du select + clavier :
http://jsfiddle.net/adamyocum/7aTcQ/

a écrit :
1. Il y a un lien dans le <li> parent du sous-menu et dans ce cas, <optgroup> n'est pas pertinent. Je pense donc à nbsp pour décaler visuellement les liens de niveau 2.
Mon choix du select ne s'est pas fait en 2 secondes. J'ai cherché, testé, réfléchi.
Il semble que les entités html se sont pas rendu par les lecteurs d'écran d'après les recherches que j'ai effectué lors de ma réflexion sur le choix à faire en navigation responsive.

Qu'est-ce que tu me parles de <li> dans le cadre de <select> ??? Je comprends pas là. Tu utilises des vrais <select> ou bien des zones déroulantes simulées en javascript ?

Sinon c'est bien ce que je disais: que ce soit des points, des tirets, des espaces insécables pour indiquer la profondeur, ça ne change rien: c'est du bricolage, ça n'a sémantiquement aucune valeur. Je suis utilisateur de lecteur d'écran, je ne vais pas m'amuser à compter le nombre de symboles qu'il y a avant le véritable intitulé pour comprendre la hiérarchie de ton contenu.

Salut,
Désolé si j'ai pu paraitre confus. J'ai parlé de <li> pour mieux placé dans le contexte des menus et sous menus.

Les entités HTML sont lus par les lecteurs d'écrans ?

Merci pour le temps que tu m'accordes.

a écrit :
Désolé si j'ai pu paraitre confus. J'ai parlé de <li> pour mieux placé dans le contexte des menus et sous menus.

Je ne comprends toujours pas. Soit tu utilises des vrais <select> et alors <li> dans <select> est totalement incorrect, soit tu utilises des zones déroulantes simulées en javascript et alors depuis le début de ce sujet ce n'est pas très clair.

a écrit :
Les entités HTML sont lus par les lecteurs d'écrans ?

Cette question est mal posée. Les entités ne sont qu'une manière de représenter des caractères qui n'existent pas dans l'encodage de la source, ou que l'éditeur de la source est incapable d'écrire.

Étant donné que tu parlais d'espaces insécalbes juste avant, si tu réfléchis deux minutes, tu constateras que ça n'a pas de sens de « lire » des espaces avec une synthèse vocale; sauf si on effectue une revue du texte caractère par caractère, mais hors contexte d'édition, personne ne fait ça.

En braille par contre, ça garde tout son sens.

Salut,
Donc une personne ayant un handicap visuel qui a besoin d'une assistance vocale pour utiliser le web n'entendra pas "espace, espace, espace" si je met 3 fois &nbsp. Par contre, en braille, les &nbsp seront restitués.

Merci pour les infos.
Je suis un peu moins convaincu par mon choix du coup. Je vais continuer à chercher, tester et tester. ^^

a écrit :
Donc une personne ayant un handicap visuel qui a besoin d'une assistance vocale pour utiliser le web n'entendra pas "espace, espace, espace" si je met 3 fois &nbsp.

Non, et quel cauchemar sinon !

a écrit :
Je suis un peu moins convaincu par mon choix du coup. Je vais continuer à chercher, tester et tester. ^^

C'était bien mon intention de te démontrer que c'était une mauvais idée. Par contre, il n'y a absolument aucun consensus sur un potentiel autre caractère que tu pourrais utiliser. Certains synthétiseurs lisent certaines ponctuations et caractères spéciaux alors que d'autres les ignorent. Par exemple, NVDA est connu pour ne pas lire les * + = et autres caractères même basiques dans sa configuration par défaut.

Du coup
* Soit tu utilises des chiffres pour indiquer l'arborescence
* Soit tu admets qu'on ne peut pas représenter d'arborescence simplement dans un <select>, et tu utilises autre chose. Les listes <ul> et <ol> conviennent très bien pour cela.

Merci à toi. Sujet clos pour moi.

Plutôt que le menu déroulant, on peut aussi utiliser un menu de navigation «progressive» (avec un peu d'aria).

P.s. : il y a plein d'autres choses intéressantes sur cette page pour créer des éléments accessibles.

Patidou a écrit :
Plutôt que le menu déroulant, on peut aussi utiliser un menu de navigation «progressive» (avec un peu d'aria).

P.s. : il y a plein d'autres choses intéressantes sur cette page pour créer des éléments accessibles.

Quelques petits bugs, mais dans l'ensemble c'est du très bon, et ça marche. Jolie trouvaille !

Pour avoir dû implémenter ça sur un site responsive avec une navigation monstrueuse (4 sous-niveaux), je reconnais que ça a des avantages certains. C'est clair que cette solution est pas parfaite, en même temps, quand on demande d'avoir 100 liens répartis sur 4 niveaux et que ça tienne tout sur mobile, expliquez-moi comment faire ça clean

Pour le optgroup, gros défaut : il ne peut y avoir qu'un seul niveau (j'y avais pensé, mais cela ne convenait pas).

<hs> Bon anniversaire Quentin ! </hs>

Salut,

Nico3333fr a écrit :
en même temps, quand on demande d'avoir 100 liens répartis sur 4 niveaux et que ça tienne tout sur mobile, expliquez-moi comment faire ça clean

C'est surtout qu'il y a un problème au niveau de l'ergonomie.

a écrit :
<hs> Bon anniversaire Quentin !
Smiley cligne
</hs>

Merci!

a écrit :
en même temps, quand on demande d'avoir 100 liens répartis sur 4 niveaux et que ça tienne tout sur mobile, expliquez-moi comment faire ça clean

Rappelle-moi de ne jamais essayer d'aller chercher quelque chose sur ce site. A mon avis pour en arriver là, il n'y a pas seulement potentiellement un problème d'accessibilité, il y a de manière bien plus certaine un problème d'ergonomie/utilisabilité, je suis d'accord avec Victor.

Ou alors je suis pénible et ce n'est pas normal d'aller voir ailleurs si je n'ai pas le sentiment de me rapprocher au moins un peu de ce que je cherche après 3 ou 4 clics.

En plus pour le nombre de niveaux, il me semblais avoir lu quelque part qu'au-delà de trois, la complexité perçue augmentait énormément...