Quelles sont les solutions pour faire des menus déroulants accessibles? Font ils forcement appel au javascript, ou existe il des solutions purement html/css?

Dans le cas ou l'on utilise quand meme un script (voir un menu flash) ajouter les liens dans un noscript avec des intitulés adequats suffit il à etre conforme aux normes d'accessibilité?

Je pourrais peut-être te conseiller ce lien : Faire un menu dynamique ouvert et accessible, sur Openweb, qui décrit, je pense, ce que tu souhaites faire.

N'étant pas un fana de la chose, j'en suis resté à Faire un menu dynamique ouvert et accessible qui explique comment faire un menu déroulant avec javascript, mais accessible sans celui-ci.

L'accessibilité exige que tout contenu accessible par un script soit également accessible sans celui-ci. C'est effectivement le rôle du <noscript>.

Je ne suis malheureusement pas certain que le menu fournit pas Open Web soit parfaitement accessible meme si il donne une solution plutot intéréssante.

En effet un des critères d'accessibilité est :

"Vérifier que l'information soit accessible lorsque les couleurs sont désactivées dans la page".

Sur ce menu, faites tous le test suivant :
dans les options accessibilité, désactivez l'option "ignorer les couleurs spécifiées dans les pages web" et vous verrez en quoi ce menu n'est pas parfaitement accessible malheureusement lorsque l'on désactive les couleurs dans la page.
Le chevauchement de l'information rend celle ci illisible.

Ah... que ne l'as-tu pas dit plus tôt :o

Je transmets de ce pas à l'auteur de l'article pour que les corrections nécessaires soient faites (a priori, rien de bien difficile)

Merci

Il faut néanmoins bien comprendre une chose au delà même de la résolution technique de ce type de menus :
Ce type de menus posent vraiment de très lourds problèmes à une frange importante de personnes handicapées.

- Les personnes ayant des problèmes de mobilité qui ont bcp de mal à pointer leur souris sur ce type de zones.

- Les enfants handicapées cognitif pour qui un clic doit obligatoirement definir une action.

- Les personnes malvoyantes qui une fois qu'elles ont zoomées la page et passent la souris sur ce type de menus doivent obligatoirement descendre dans la page pour voir l'ensemble des éléments et du coup enleve le focus du lien faisant disparaitre le sous menu.

- Les personnes souffrant de problème de concentration qui voit apparaitre de nul part un sous menu juste parcequ'elles voulaient cliquer sur un lien ?

Au delà même des personnes handicapées énormèment de personnes débutants sur le web ne repèrent pas du tout ce type de navigations peu intuitives.

Il faut donc bien comprendre que si ce type de menus peuvent etre techniquement accessibles (et ce n'est pas le cas a 100% aujourd'hui) cela ne veut pas dire que pour les utilisateurs ce sera le cas.

Euhhhhhhh, dans mes souvenirs l'auteur via tristan je l'espère est au courant depuis quasiment la redaction de l'article



Je veux bien voir ce que ca donnera alors, même dans les listes techniques de WAI personnes n'a réussi a rendre ce type de menus accessibles

Ouïe ! Aïe ! Pan sur le bec !

N'en jetez plus

Très franchement, comme je l'ai dit plus haut, je ne suis pas du tout un fana des menus à coulisse. C'est à dire que je ne m'en suis jamais servi personnellement, et que je n'aime guère en rencontrer sur un site.

Ajoutons-y le fait que j'étais totalement offline quand cet article a été publié sur OpenWeb... et on arrive à la conclusion : je n'y connais pas grand chose, là, d'où ce renvoi que je croyais prudent à l'article en question

Les réserves que tu fais sur le principe même de ces menus me renforcent dans mon antipathie latente à leur égards.

Cela dit, à ta première réponse, j'avais cru comprendre que le problème technique de couleurs était simple : il n'en est apparemment rien. Toutes mes excuses, donc.

La peste soit des menus à coulisse ! Belle illustration du problème de l'accessibilité "théoriquement standardisée" et de l'accessibilité réelle expérimentée...

Pour enfoncer le clou un peu plus, on peut dire qu'au jour d'aujourd'hui: il n'existe pas de menu déroulant accessible.

Et au vue des problèmes rappelés par Yoan (pardon, Yobiwan ), c'est le concept même de menu déroulant qui pose problème.

Matthieu

Bon, tant pis pour le mythe, je mets les pieds dans le plat. Oui, l'accessibilité absolue n'existe pas plus que l'interopérabilité absolue. Il y a et il y aura toujours un cas minimum où une page ne "marchera" pas. Un navigateur, une configuration, un réglage d'options, etc.

J'ai testé mon menu avec la plupart des cas courants. Le but de l'article était plutôt de démontrer que la prise en charge de l'accessibilité est possible et guère compliqué. Soyons francs, un expert ne va pas utilisé ce genre de menu, pour des raisons d'ergonomie entre autres, et l'article se devait d'être un truc prêt à l'emploi pour les débutants ou initiés qui souhaitent un menu déroulant.

Je préfère voir fleurir des menus un minimum accessibles plutôt que ceux qui ne le sont pas du tout, à défaut de voir disparaître ces "gadgets". N'oublions pas qu'il y a de plus en plus de débutants sur Internet. Vous me direz qu'il y a ce genre de menus dans tous les logiciels. Certes mais observez un débutant qui surfe. A aucun moment, il ne se sert d'un menu.

Malheureusement, dans l'industrie (du moins au Québec), c'est refuser d'utiliser un tel menu qui a rapidement pour effet de vous cataloguer comme n'étant pas un professionnel... et je ne parle même pas d'une version la plus techniquement accessible possible, je parle seulement de ces grosses horreurs à la DHTML Central dont j'ai si souvent abusé dans mes premières années de développeur et dont l'industrie continue de se régaler aujourd'hui...

Le problème avec ces menus, c'est que ceux qui les apprécuient ont perdu de vue qu'un jour, eux-mêmes étaient confus en les regardant... et aussi bien sûr, qu'encore en 2004, les sociétés se font construire des sites Web pour s'admirer le nombril et afficher des photos d'eux-mêmes plutôt que pour servir l'intérêt de leurs clients.

Bonjour à tous, ceci est mon premier billet sur Webmaster-Hub

Je vois à l'utilisation des menus déroulant, deux raisons, mais peut-être en existe t-il d'autres (?) :

• une volonté de faire apparaitre de (trop) nombreux items sur une page en un minimum d'espace visuel et atteindre rapidement une profondeur dans un site web en peu de clics ;
• une confusion entre le menu déroulant et la liste déroulante (formulaire avec balises html form-select-option).

Concernant le premier point, cela touche à une question d'efficacité de la conception en amont : on utilise le menu déroulant pour répondre à une question mal résolue/posée au départ ;
Concernant le second point, il relève plus de l'erreur (qui a dit faute ? ) de réalisation et n'est pas dur à résoudre, mais nombreux préfèrent le menu DHTML parce que "plus joli qu'un sélecteur de formulaire" (si-si, c'est du vécu je vous assure).

Ensuite, comparés aux menus déroulants des logiciels (pour suivre le propos de Fabrice), je vois également une différence essentielle : dans un logiciel les menus donnent accès à des "fonctionnalités", des "actions", or, dans une page web les menus déroulants ne donnent jamais accès à des fonctions-actions mais à des liens vers d'autres pages, ce qui est d'une nature totalement différente !
Et pourtant la forme est la même ; de quoi jeter le trouble encore un peu plus dans l'esprit de l'internaute.

Maintenant je me pose une question :

avec toutes ces applications que l'on porte de plus en plus sur le web, l'e-administration, les web-services,... les applications web vont se transformer en de vrais petits logiciels et la quantité d'information manipulée par "page" va probablement être (est déjà) plus importante.
Comment allons-nous manipuler plus d'information globale et par page sans passer par des astuces comme les menus déroulants ? On passe de la simple consultation de page à l'interaction forte avec la page. Beau boulot d'analyse et ergonomie en perspective

Arf ! Justement, regardez en bas à droite de la page sur laquelle nous somme actuellement. Très bon exemple : même effet visuel que le menu déroulant JavaScript mais autrement plus accessible et pratique, d'autant qu'ici une "action" est prévisible, par la nature de l'objet de formulaire et le bouton "Ok" permettant la validation du choix (rien de tout cela dans un menu déroulant JavaScript).

Mesdames et messieurs, permettez-moi de vous présenter (si vous ne le connaissez pas déjà) le spécialiste CSS d'OpenWeb et son designer attitré

Dan, il va falloir déposer le domaine openweb-hub



Avec les applications Web et les nouveaux langages ou extension de langages actuels qui sont envisagés, les questions d'accessibilité et d'ergonomie vont en effet se multiplier.
Quand on lit par exemple le projet d'extension du HTML aux fonctionnalités d'application Web de Yan Hixon et du WHAT Working Group, on voit qu'il y aura beaucoup à faire ! Et il y a de quoi s'inquiéter quand Hixon écrit clairement qu'il s'agit essentiellement pour l'instant de simplifier la vie des développeurs... L'utilisateur y gagnera-t-il autre-chose que de la complexité ?

Si tu voulais me confusionner tout rouge Laurent, tu as réussi

Bonjour Emmanuel,

Et bienvenue sur le Hub


Tant que tu es tout rouge (il n'y a pourtant pas de raison pourtant puisque Laurent n'a dit que la vérité B) ), j'en profite pour ajouter ma voix...

Je suis vraiment très heureuse de te retrouver ici et toute rouge aussi de pouvoir compter sur la participation de tant de membres de qualité sur le Hub (le groupe Open Web, celui des Pompeurs, les bloggeurs et autres experts...)

tu veux que j'en rajoutes une couche, mon vieux ??? Bienvenue parmi nous, ça fait drôlement plaisir de te retrouver ici ! ^_^

Bonjour,


J'ai fait une recherche sur "accessibility" dans les archives de la mailing list, la notion d'accessibilité ne semble quand même pas négligée...

Question posée le 9 juin 2004

Réponse

Le sujet est abordé aussi dans ces discussions :
- Why not JavaScript?
- Suggestion for a Specification: XUL Basic

C'est intéressant cette réflexion parce qu'elle reflète bien la mauvaise perception des clients, des gestionnaires de projets et du marché en général à l'endroit des développeurs se présentant contre ce type de développement. Du moins dans les environnements dans lesquels j'ai évolué, la première impression laissée par la dénigration des menus DHTML, c'est toujours plus perçu comme une question de paresse qu'autre chose. Pour le commun des mortels qui pense que les menus DHTML c'est le nec plus ultra du développement Web, affirmer que la technique est mauvaise passe toujours mal.

C'est en effet une approche qui se justifie, même si du point de vue de BrailleNet ca n'est bien sur pas suffisant de faire du "minimum" accessible.

Par contre si je peux emmetre une idée d'article, il serait peut etre interessant de rédiger un article sur les problèmes d'accessibilités que posent ce types de menus.

Tout en ne critiquant pas du tout ton article, il a juste une conséquence, les gens pensent faire un menu accessible si ils suivent tes conseils, ce qui n'est donc pas le cas selon tes propres dire.

La nuance serait donc à mon avis de rigueur pour bien montrer aux gens que ce types de menus posent de lourds problèmes.

yobiwan: yaka

Bon, alors, là, j'aimerais comprendre...

SVP, penchez vous un peu sur cela : Accessible Website Menu qui se targue justement d'être en JS, W3C Compliant en rapport avec l'XHTML, le CSS, et ... WAI-AAA !



Alors, ce menu javascript est-il ou n'est-il pas conforme (et non compatible )

P.S. : Ce n'est pas la première fois que je le donne sur le forum, de même que ce n'est pas la première fois que j'entends dire "ca n'existe pas"... alors, svp, éclairez ma lanterne !

En fait, comme le disait je ne sais plus qui dernièrement, le problème avec ces menus c'est qu'il est possible qu'ils soient 100% accessibles techniquement, mais pas fonctionnellement pour certains internautes qui pourraient demeurer confus à leur utilisation. Ainsi, d'un point de vue ergonomique et utilisabilité, ils posent certains problèmes aux utilisateurs quand même.

Nous pourrions établir un parallèle facile entre une page HTML conforme et une autre, conforme ET sémantique...

De plus, il ne faut pas perdre de vue que ce n'est pas parce que Sylcake vend son menu comme étant "the world's first fully-featured and accessible DHTML menu" qu'il faille prend ça pour du cash sans le tester... Ça a l'air très bien certes, mais ce ne serait qu'avec un panneau élargi d'utilisateurs avec différentes configurations plus hétéroclytes les unes que les autres que nous verrions si c'est réellement le cas. ^_^

Ahhhh, enfin, voilà une réponse qui m'est claire et intelligible, sans oublier, raisonnée !

Sous cet "angle", je perçois mieux ces remarques...

Bonjour,

Ce menu a exactement le même problème que celui d'Openweb si on supprime la couleur !

Il sera accessible aux non-voyants mais pas à certains mal-voyants.

je ne vois donc pas comment il peut etre triple A

Et toc pour Sylcake... ^_^

Parce que sérieusement, se vanter d'être un "full patch triple A", c'est s'attirer plus de scepticisme que de reconnaissance... le problème fut cuisant pour Dave Shea également lorsqu'il a lancé le CSS Zen Garden.

D'autant plus que la majorité des gens qui sont susceptibles d'êtres des clients pour le fameux menu, ce sont des développeurs avec un minimum de capacité de réflexion sur l'ambiguité qu'un telle déclaration soulève.

certes je ne lui donnerais pas triple A mais ce menu reste qd meme à mon avis la solution la plus complete qui existe à ce jour.

Pour info c'est moi qui lui avait signalé le probleme avec la désactivation de couleur (de retour de mon stage avec yobiwan) ainsi que divers autres petites choses comme la possibilité de pouvoir choisir son raccourci clavier pour accéder au menu, choses qu'il a d'ailleurs pris en concidération depuis.

Coté désactivation des couleurs normalement qd on le fait dans ie le menu ne déroule plus ce qui n'est certes pas idéal mais mieux que d'avoir un chevauchement.

Maintenant cela me fait me poser une question depuis un certain temps, il est dit qu'il ne faut pas qu'il y ai perte d'info qd par exemple les javascripts sont désactivés mais un utilisateur qui désactive javascript ne fait pas sans cesse des tests avec un coup activé un coup pas activé.
Si il arrive sans le javascript activé il ne verra jamais le menu déroulant, il ne saura meme pas qu'il existe donc y a t il réellement une PERTE d'information? Je ne pense pas car il a quand meme accès à l'info en cliquant sur les intitulés de niveau 1. Ce n'est pas comme un pop up full javascript ou l'utilisateur n'as aucune alternative

Il existe au moins un cas où ce menu fonctionne mal: désactiver une option du menu sur un navigateur donné (MSIE) et une version donnée (la 5). Le problème a été corrigé sur la version 6, a priori. En effet, ignorer les couleurs de la page doit mettre un fond blanc et non pas supprimer carrément le fond. Je note que la Web Developper Bar sur Mozilla fait de même. Je vais donc voir s'il est possible de détecter ça. Menu non WAI pour l'instant. A suivre...



J'entends par là qu'il s'agit juste de montrer la voie. Certains feront des dérivés moins bien, d'autres mieux mais l'accessibilité s'en trouvera augmentée. J'essaye de faire le plus performant possible mais chacun adaptera mon exemple avec plus ou moins de bonheur. Je ne pense pas que chacun teste X navigateurs, X OS, X versions, X options, etc.

Qui plus est (corrigez-moi si je me trompe), le travail de Fabrice sur ce menu dans le cadre d'OpenWeb, ce n'est pas de fournir une solution toute cuite dans le bec à tout le monde. Ce n'est pas d'offrir un script qui sera réutilisé partout à des fins commerciales ou personnelles.

Le menu est déjà très bien et bien que tout porte à croire qu'il pourrait encore être amélioré (nommez-moi un truc qui ne le soit pas), il constitue justement surtout une bonne base de travail avec laquelle les développeurs pourront travailler pour obtenir leur propre version. Et c'est ça la différence fondamentale entre ce menu et celui de Sylcake, puisque UDM s'avère être payant.

De toute manière, comme nous l'avons dit plus haut, conceptuellement, il est impossible de faire un tel menu parfaitement accessible. On aura beau essayer de pallier à tous les petits revers technologiques, le constat sera toujours qu'une portion de la population éprouvera des problèmes avec ceux-ci.

Pourquoi ne pas passer à autre chose et revoir la manière dont nous scénarisons la navigation sur nos sites Web ?

Le blanc est une couleur non ?



Mon seul souci reste alors le titre de l'article : "Faire un menu dynamique ouvert et accessible "
Nous venons de la voir, il ne l'est pas.



Que je suis heureux d'entendre cette phrase --> oublions ce type de menus qui ne sont pas accessible : voilà peut etre la vraie solution. Tambouriner partout que ce type de menus n'est pas accessible et réussir à les faire totalement disparaitre plutot que tenter de trouver des solutions qui sont a priori vouées à l'echec et qui peuvent faire penser que ce type de menus peut devenir accessible.

Bonjour,


Je ne peux qu'appuyer cette position.
Même si le problème des couleurs peut être résolu, il en est un qui subsitera vraisemblablement :
la perte du focus... et la disparition des choix possibles.

Cela affecte les mal-voyants qui utilisent un système de loupe, mais aussi tous les maladroits qui maîtrisent mal les mouvements de la souris (et je parle d'expérience... combien de fois un tel menu - y compris ceux des logiciels - ne s'est pas "refermé" parce que je n'arrête pas à temps le déplacement de ma souris !).

Fabrice ! Laurent ! Qu'en pensez-vous ? OpenWeb pourrait-il prendre position sur la question en remettant l'article et le code en contexte pour démontrer, suite aux dicussions qui ont eu lieu ici, que la technique ne devrait plus être ?

Il n'en faudrait pas tellement pour revoir le texte et reconnaître les faiblesses fonctionnelles incontournables de l'approche. Une humeur serait peut-être le moyen d'amener le sujet sur OWG.

Commençons par un aveu: cet article avait surtout pour vocation d'attirer les amateurs de ces gadgets vers un site parlant des standards et de l'accessibilité. Il s'agissait de casser l'image de ces deux domaines.

Je vais me permettre un parallèle: au début, Linux passait pour un système de chevelu asocial. Enfin, il ne faisait pas que passer. :-) Quelque soit les efforts que l'on faisait, on avait jamais la bonne distribution, le dernier kernel, etc. Maintenant, Linux est un OS professionnel distribué par des boîtes côtées en bourse.

Il n'y a pas si longtemps les standards, et là je plaide pleinement coupable, était sur la même voie. On flinguait tous les cons qui ne comprenaient rien à l'Internet. Peu à peu, on a appris à soutenir les efforts plutôt qu'à les détruire. Les standards sont devenus incontournables et il suffit de consulter The Weekly Standards, CSS Vault ou Web Standards Awards pour le constater.

L'accessibilité commence à sortir de cette phase normale et structurante. Il m'arrive encore moi aussi de m'emballer contre les mauvaises personnes. Souvent même. Tout ceci est bon signe, le signe de l'on approche de la maturité.

Je suis donc parfaitement d'accord avec l'idée qu'il faut expliquer pourquoi les frames, les menus déroulants et autres tableaux posent encore des problèmes même s'il est possible de les rendre partiellement accessible. On ne pouvait pas présenter l'accessibilité il y a encore quelques mois comme on avait fait des standards, on aurait plus nui qu'autre chose. Il faut encourager, laisser du temps et expliquer que ce n'était qu'un premier pas.

Un site passant le validateur W3C ne respecte pas forcément la philosophie du Web. Un site passant le validateur Bobby n'est pas forcément accessible. Nous avons démontré les lacunes du Web à l'ancienne, il est temps maintenant de présenter les avantages du Web moderne. Beaucoup ont commencé mais la vocation d'OpenWeb n'est pas d'être un pionnier en terme de débats.

Je propose donc un article de fond sur le non-emploi des frames ou du JS par les professionnels et pourquoi. Avec des arguments d'accessibilité mais pas seulement. J'avais aussi lancé l'idée d'une partie interview comme un axe important d'OpenWeb dans la vision que j'en avais. Yobiwan? ;-)

C'est vrai que la mission d'OpenWeb n'est pas de tout voir et tout faire pour le web conforme et accessible francophone. Depuis un peu plus d'une année, il y a de plus en plus de gens vraiment intéressants avec énormément de choses intelligentes à dire qui sont apparus de nulle part pour venir bonifier le discours tenus par les "dinosaures" comme nous qui prêchions tout ça il y a deux trois ans...

Je peux facilement penser à une dizaine de personnes, que je ne nommerai pas mais que tout le monde commence à connaître. Il y a forcément eux ou trois d'entre eux qui pourraient se mettre à la tâche... Mais lesquels ?

Complètement pour et je serais heureux avec mes collégues de participer à ce genre d'initiatives comme pour l'article sur les accesskeys.

hello, j'arrive sûrement un peu tard après les débats, ça se trouve je ressort de la cave poussièreuse ce topic

J'ai fait une adaptation du menu d'OpenWeb à l'adresse http://iubito.free.fr/prog/menu.php

UDM4 est bien foutu, mais trop complexe a utiliser, par exemple il est possible de naviguer au clavier.... mais en apprenant des raccourcis clavier inhabituels (F12 et chéplukoi).

Je trouve le menu d'OpenWeb comme une bonne base, pas exploitable (menu qui disparaît dès la perte du focus par ex.) mais qui m'a franchement servi.

Beaucoup de gens me demandent de mettre une arborescense (des sous-sous-sous-...-menus) et je suis contre parce que c'est pas évident pour un mal-voyant ou un maladroit, déjà que certains mal-voyants sont génés par un niveau qui apparaît (comme actuellement)...

voilà, encore merci à OpenWeb sans qui j'aurai pas mon super menu ! (mais maintenant impossible de partir en vacances sans recevoir 100 mails concernant le menu )

P.S.: des exemples d'inaccessibilité : pour s'inscrire sur ce forum, un code visuel (image) de vérification.... alors ça pour les copains aveugles c'est méchant de chez méchant !