jpv

Le cas de ce site est effectivement très intéressant, puisque qu'on pourrait même discuter du bien fondé du label bronze Les 45 liens sont une grossière tentative de spam-indexing, d'autant plus stupide qu'ils ne pointent sur rien Dans le même genre on à une pollution permanente de commentaires chargés de mots clés (le plus rigolo sur la page Je suis un as du référencement !) Concernant le label bronze il faut bien reconnaitre que le niveau WAI/A est tellement peut exigeant que ça permets de valider à peut près n'importe quoi... Ce qui est intéressant c'est d'aller jeter un oeil sur le site des concepteurs/réalisateurs notamment la page :Je fais du texte en image, c'est quand même plus simple.. Pour ma part je trouve que sur ce site ils ont fait d'incroyables efforts... Plus sérieusement cela montre effectivement les "limites" de la méthode accessiweb. Comme le dit Laurent, accessiweb est focalisé sur l'accessibilité de l'existant au détriment évident d'une reflexion, en amont, sur l'ergonomie du code et des structures de page. D'un autre coté, c'est une approche qui se défendait à l'époque de la création de braillenet, parcequ'à cette époque là quand vous parliez d'accessiblité du web la première question qui venait c'était : "ha bon ? parceque les handicapés utilisent internet ???". Si en plus il fallait pointer la nécessité de réécrire le code c'était plié ! Les deux récents sites labels OR d'accessiweb, posent le même genre de problème, sur le grand chalon on trouve par exemple cette page : Zut j'ai oublié de décrire mon frameset qui invalide ipso facto le label OR. De même qu'on trouve des coqueteries de code inquiétantes chez Intégrance, l'autre label OR avec par exemple cette page : Ca c'est du code Coco ! et ses superbes : <td colspan="2" class="bgwhite"><img src="../images/common/pixel.gif" alt="|" width="1" height="1"></td> pour séparer des liens adjacents. Le problème là ne viens pas de la méthode mais bien d'un surmenage évident de l'expertise. JP

D'autant qu'IBM en matière d'accessibilité ne démérite pas, c'est le seul mastodonte à avoir produit un navigateur vocal et le site cité c'est du XHTML, presque valide et équipé WAI/AAA. Je ne vois dans la prise en compte des problématique d'accessibilité par un géant du secteur que des avantages ne serait ce que par l'effet prescripteur d'une telle démarche.

Tout dépends de la cible finale, le fameux end-user qui est au web ce que la ménagère de moins de 50 ans est à la télé A l'évidence, si le produit final cible le "tout public" la question de rajouter une couche ecmascript peut se poser encore que ... Par contre si le produit final est à destination d'un public controlé, par exemple au travers d'un systeme utilisateur, la question de se pose plus, l'alternative ecmascripté est tout à fait crédible et assez avantageuse. Le projet auquel je faisais référence était un framework QCM pour la formation online de personnel administratif. Les concepteurs avaient trouvés "joli" de faire tous les formulaires en flash avec moult effets typiquement US-flashy... Pour adapter ces modules il m'aurait fallu un travail monstrueux pour rendre ça accessible à la navigation tabulaire, aux touches de direction du clavier, à la gestion de l'historique et j'en passe ... Pour quel bénéfice réel ?, pour un non-voyant la question de se pose même pas, les petites étoiles qui pivotent sur elle-même il s'en passe fort bien et je suis content de lui éviter le load d'un objet flash, les raccourcis/touches spécifiques et l'éventuelle perte de focus suite à une fausse manoeuvre... Pour les utilisateurs de la navigation tabulaire et les déficients visuels, même remarque, particulièrement pour ceux qui auraient besoin d'agrandir la taille de caractère, ce qui imposait une autre adaptation... Du coup, quand bien même cela demande effectivement un travail de maintenance plus important, les bénéfices de la solution scripté n'apportait que des avantages. Et il ne s'agissait là que de modules ultra simples, des cases à cocher et des réponses à tester, Si tu rajoutes à ça du drag and drop, des boucle d'animation et des rétro-actions complexes, le travail pour rendre ça accessible à tous et dans toutes les situations est colossal. Quand à la solution serveur, là encore il faut bien en mesurer les enjeux. Le scripting client, du moins dans ses applications basiques est remarquablement bien géré par les screens readers par exemple surtout en ce qui concerne la gestion d'evenement et les effets de focalisation (focus, select...). Du coup, pourquoi leur imposer un aller retour serveur, un rechargement de page, et une gestion de la reprise de focus ??? C'est pourquoi j'insistais sur l'analyse préalable du end-user, car si tant est que l'on puisses controler les minimum requis d'un applicatif de ce genre, alors franchement du script bien pensé et bien organisé c'est quand même extrèmement avantageux... Mais bon c'est vrai qu'il n'y à pas de solutions unique, ce sont toujours des cas d'espèces et c'est tant mieux sinon on s'ennuierait un peut...

Il n'est malheureusement pas souhaitable d'utiliser des lettres comme accesskey. La raison est que cela interfère avec les propres raccourcis du browser ou des logiciels de lecture d'écran. Par exemple si tu utilise la lettre S comme raccourcis clavier tu va désactiver le raccourcis "enregistrer sous" du navigateur et ainsi de suite. De fait tu te retrouves contraint de limiter aux seuls 9 premiers chiffres le recours aux accesskeys avec des "usages" comme 4 pour le moteur de recherche, 0 pour l'aide, 9 pour le contact webmaster... Tu trouvera ici Open Web : Accesskey, l'essai non transformé un excellent article sur ce sujet. Sinon un simple span avec une propriété CSS de soulignement, suffit à résoudre ton problème.

J'ai eu à m'occuper d'un cas de ce genre, tu à deux solutions: La première consiste à créer une couche applicative (avec actionscript) pour effectuer ce genre de comportement avec les touches du clavier, c'est assez facile mais ça ne résoudra pas completement le problème de l'accessibilité de flash qui est quelquefois possible et toujours une vraie galère... La seconde est de produire, chaque fois que nécessaire des alternatives adaptées avec une couche comportementale basée sur Ecmascript (javascript). Pour ce qui me concerne, je propose toujours cette seconde solution, car le travail à réaliser pour rendre des modules flash accessible est souvent supérieur à celui qui est nécessaire pour créer une alternative complète. L'autre aspect du problème est la structure générale du produit final, si ce sont des modules 100% flash, tu es dans la pire des situations... Si les modules flash ne sont utilisés que comme fonctionnalités du produit final alors une bonne analyse te permettra de jongler avec les deux solutions, adapter le module flash ou proposer une alternative selon ce qui est souhaitable et possible, au cas par cas. En tout état de cause, le domaine de l'e-learning fait partie des domaines toujours assez compliqué à rendre accessible, ça demande beaucoup de temps et beaucoup de test et de retour d'expérience utilisateur. Les problèmes auxquels tu vas te trouver confronté vont concerner essentiellement la prise en charge des fonctions du clavier, la gestion de l'historique de navigation et la gestion des comportements "souris", car sur ces trois domaines il va te falloir tout refaire, navigation tabulaire, raccourcis claviers, gestion du curseur par les touches de direction du clavier et l'élaboration d'un historique de navigation propre aux modules flash. Macromedia propose nativement certaines adaptations mais qui sont rarement utilisables telles qu'elles. Par contre, le controle de la synchronisation images/son peut t'offrir beaucoup de possibilités... Un dernier petit conseil : si il y à une vraie volonté de rendre ce produit accessible la première chose à faire est de voir comment tu peut limiter au maximum l'utilisation des modules flash au profit de solutions basées sur Ecmascript (javascript) qui, si elles sont bien pensées, offre souvent des possibilités équivalentes où à tout le moins satisfaisantes.

Et pour ajouter aux toujours excellentes interventions de l'ami Denis, quelques précisions qu'il est toujours utile de rappeller : - La part de la population française touchée par un handicap (du plus léger au plus grave) était en 2003 (rapport insee) de l'ordre de 15% Ce qui n'est pas rien. De fait pour le webmastering, refuser au nom de la "liberté d'entreprendre" qui en la matière serait plutot la liberté "de ne rien comprendre", d'améliorer l'accessibilité d'un site, c'est décider de diminuer de facto le potentiel de visite, ce qui est tout à la fois commercialement stupide, technologiquement rétrograde et particulièrement méchant quand on sait combien il n'est pas si difficile de le faire. - Cette proportion ne va qu'augmenter au même ryhtme que le vieillissement de la population pour atteindre selon les projections en vigueur le double du taux actuel, l'accessibilité des sites webs à ces publics ne sera alors plus un sujet de débat, mais un critère de survie économique. - Dans l'esprit du législateur "l'obligation" faite aux sites publics n'est pas une contrainte mais l'application stricto-sensu de la notion de "service-public", le débat sur ce sujet me semble assez vain. Ben non, justement, et cette remarque vaut également pour la comparaison avec le sous-équipement de l'espace urbain, Ce n'est pas du tout la même chose Faire un journal de l'envergure de l'équipe en braille représenterait des investissements collossaux et serait vraisemblablement économiquement désastreux, comme il est toujours difficile de boucler des budgets d'équipement des batiments et des structures urbaines, eut égard aux contraintes matérielles. Tout au contraire, rendre un site web accessible, n'est qu'une question de volonté, les incidences budgétaires sont mineures et largement auto-finançables par les effets positifs sur le potentiel commercial et l'image de marque. Mieux, si cette opération est menée en parrallèle à une normalisation (passage aux technologies standards) alors le bénéfice est immédiat et les gains de productivité sont au choix "intéressants, énormes ou incroyables", selon les cas. Pour rappel une normalisation cohérente peut diminuer les coûts de bande passante de l'ordre de 50% et ceux de la maintenance et du webmastering de l'ordre de 20%. Pour des sites qui payent la bande passante au débit, le gain immédiat se chiffre communément en dizaine de milliers d'euros, voir, pour des sites à fort trafic (plusieurs millions de pages vues), en million d'euros. Du coup, on se rends vite compte que non seulement l'opération est à coup-zéro mais qu'en outre elle produit son propre financement avant de participer au CA. Ceux qui mettent en avant la "compléxité" et le coût d'une normalisation et d'une mise aux normes "accessible", sont au mieux ignorants, au pire totalement incompétents. Parce qu'en réalité ce qu'ils vendent ce sont des sites qui coûtent plus cher à produire, plus cher à maintenir, plus cher à diffuser pour un potentiel commercial diminué ce qui est quand même un comble avant même d'être simplement ridicule. Je fais partie de ceux qui regrette amèrement le choix de ce terme "obligation" car on en voit le résultat immédiat et très "français", héritage des jacqueries d'antan, et on discute de cette scandaleuse "obligation" alors qu'on devrait discuter de choses beaucoup plus simples et immédiatement compréhensibles : Rendre un site web accessible c'est simplement faire preuve d'un minimum de citoyenneté, d'humanité et de bon sens. Passer un site aux standards c'est tellement profitable en termes économiques que le sujet n'est en même pas un. Refuser ces technologies innovantes (qui date quand même de 1999, ce qui laisse rêveur sur la veille technologique des agences web !) c'est un peut comme si votre fournisseur informatique vous recommendais chaudement d'utiliser windows 95 comme OS de production, ça vous ne ferait pas un peut peur ??? Maintenant le "vrai" problème ce n'est pas l'obligation de la loi, le réel problème c'est comment on va le faire. Car même si la loi ne concerne que les sites "publics" et assimilés, cela en fait quand même un bon paquet car outre l'administration cela concerne également les écoles, universités, centre de formation, mairies, conseils régionaux, centre de recherche, bibliothèques et centre de ressources documentaires, services sociaux et toutes les structures gravitant dans l'hydre de l'administration européenne. Et cela ne concerne pas "que" les pages webs, mais "tous" les documents électroniques, donc des pans entiers des systèmes d'informations associés. Une estimation de 2003 notait qu'il faudrait former entre 1000 et 1500 développeurs et formateurs spécialisés "par an" pour satisfaire au chantier, qui implique en sus de rendre les sites web accessibles de former les équipes de webmastering (!!) et de recontroler tous les sites à intervalles réguliers (tous les ans dans le cas du label accessiweb par exemple). Là il y à un vrai débat et, par ailleur une réelle opportunité pour tous ceux d'entres vous qui ont du mal à trouver des jobs...

Salut gribouille, Si tu ne veux pas faire de rafraichissement de page la solution la plus simple est d'utiliser du javascript bien fait, notamment au niveau de la gestion des évenements qui vont déclencher la mise à jour des champs concernés. Si tes appels javascripts sont bien codés tu devrais pouvoir faire un truc acceptable, tout dépends évidemment des données à mettre à jour. Si ton process accepte de rafraichir la page tu peux faire ça coté serveur en PhP par exemple. Si les champs à mettre à jour nécessite des proccess de vérification ou des données stockées dans des tables, tu devra utiliser une technique similaire à celle de Gmail en interfaçant javascript et PhP, ou préloader les données dans des fichiers textes. Enfin si il s'agit de gérer un affichage de champs conditionnel selon des valeurs préalablement selectionnés, la solution passe par javascript + css. Sinon dans le genre solution alternative, tu peux envisager de batir ton formulaire en flash, mais à coté accessibilité tu vas avoir du mal. Comme tu le vois sans javascript pas beaucoup de solution... Il faudrait que tu détaille un peu plus...

Qu'elle version d'opéra ? Ici (opera 7.60 - 7321) ça fonctionne très bien, le menu apparait avec JS désactivé...

Visual friendly à été créé à une époque où l'accessibilité et les standards étaient encore extrèmement rare. La solution visual friendly passe par une réécriture à la volée des pages consultées selon un profil utilisateur (choix des couleurs, taille de caractères et tutti quanti). Bien que fonctionnelle la technologie est particulièrement lourde, oblige à produire du code non-valide sur la base d'un cahier des charges assez contraignant et, surtout, était fournie à des tarifs (abonnement mensuel) pour le moins prohibitif. Visual friendly comme son clone comfort de lecture ont eut quelques contrats avec des sites (premier ministre) ou intra/extranet (RATP).... Fort heureusement, la société, comme le dit Laurent à décidé d'ouvrir ses compétences aux techniques de développement standardisées et c'est une bonne nouvelle...

D'autant que cette propriété, en dehors de cas assez spécifiques, n'est pas d'un bénéfice formidable du point de vue ergonomique...

C'est sur qu'une ressource francophone sur la séparation comportement/structure ça ferais sacrément du bien... Mais, en même temps cela demanderais pas mal de compétences techniques, en plus d'un redactionnel impecable, car le DOM est comme tu l'à vu un truc très technique, un peut déroutant au départ et qui, de fait, se borne souvent à getElementById et getElementsByTagName... Mais bon si ya une iniative sur ce sujet je veux bien en être, je suis venu au DOM et au concept de séparation comportement/structure par la problématique de l'accessibilité, (qui est l'essentiel de mon activité pro), autrement dit pour EcmaScript, comment rendre un script non intrusif ni destructeur pour l'accessiblité d'un contenu. Je peux apporter pas mal d'éclairage la dessus, par contre je ne me risquerais pas, en tout cas pas tout de suite sur de la rédaction de ressource plus technique, les scripts que je produis fonctionnent bien mais face à une compétence comme celle de l'ami bobe, je mesure le chemin qu'il me reste à parcourir, (attention.. Top départ !) . En passant, merci pour la leçon bobe, et si tu à une minute pour glisser les deux ou trois commentaires qui vont bien, je suis sur que tu vas créer des vocations ... :) Sinon j'ai trouvé récemment un bon lien francophone pour aborder l'implémentation du DOM (malgrés son titre ) ici : cours DHTML JP

Les logiciels d'aide se répartissent en trois catégories : Les lecteurs d'ecrans, comme JAWS ou Window Eyes Les navigateurs vocaux comme IBM Home Page Reader Les navigateurs textuels, Les loupes et assimilés, comme Lynx ou Zoomtext. Les lecteurs d'ecrans transforment les informations portées à l'écran à destination d'une synthèse vocale ou d'un périphérique comme une plage braille. Ils fonctionnent donc aussi bien avec un logiciel de traitement de texte, qu'avec un navigateur internet. Généralement le navigateur de référence restent IE, mais Window Eyes fonctionnent aussi avec Mozilla par exemple. Les navigateurs vocaux ne sont destinés qu'à la navigation internet dont ils assurent un rendu graphique (affichage traditionnel) et une lecture vocale ou à destination d'une plage braille. Les navigateurs textuels affichent les pages web en mode texte et les loupes ont pour objectif d'agrandir ou de modifier une zone de l'ecran pour la rendre lisible par un mal-voyant. JAWS, Window Eyes et Home Page Reader, fonctionnent sous Windows, JAWS et HPR ont besoin d'IE, Window Eyes peut fonctionner avec d'autres navigateurs comme Mozilla par exemple, par contre certaines fonctions spécifiques semblent ne plus focntionner. Je ne connais pas bien les solutions pour linux mais ils existent des distributions adaptées ou des couches logicielles qui assurent la synthèse vocale et le support des plages brailles. Enfin Opera à annoncé le support d'une synthèse vocale intégrée. Je ne sais pas par contre si il y à une différence de traitement des lecteurs d'écrans en fonction du navigateur, pour Window eyes par exemple le rendu est strictement identique quelque soit le navigateur utilisé. Enfin pour HPR le problème ne se pose donc pas. Du point de vue du développeur, il est nécessaire de tester ses pages avec l'un ou l'autre de ces outils même si les directives d'accessiblité sont intégralement respectées, d'abord c'est très pédagogique et surtout c'est le seul moyen de comprendre les problèmes de structure et de hierarchie qui peuvent se poser. JP

La question est mal posée... Le problème n'est pas de savoir si un logiciel pour handicapé, en loccurence pour le web, un navigateur vocal ou un lecteur d'écran, sait interpréter une page "non-conforme", "aussi bien " qu'IE ( ). De plus un lecteur d'écran fait fait comme tout le monde, il "affiche" tout ce qu'il peut, comme il peut, avec ce que tu lui donne à digérer ... La vraie question est de savoir si le respect des normes peut aider les navigateurs vocaux et les lecteurs d'écrans à mieux interpréter une page web, et là la réponse est évidemment oui, l'accessiblité au contenu web ayant été une des préoccupations majeures à l'établissement des normes. Une page non-conforme peut très bien être impeccable pour un lecteur d'ecran et de même une page "conforme" peut très bien être un véritable casse-tête, tout dépends de la volonté de l'auteur de rendre ou non son contenu accessible. De ce point de vue là, les normes concernent essentiellement le respect d'une grammaire offrant un minimum d'accessibilité en garantissant par exemple que chaque image possèdent un attribut descriptif ou que le texte possèdent un minimum de hiérarchie (titre et paragraphe)... Mais ça ne suffit pas à rendre un contenu vraiment accessible et c'est à l'auteur de prendre cet aspect à sa charge en s'appuyant sur les recommendations et les guides comme le WCAG, qui comme son nom l'indique n'est pas une norme... La permissivité et la tolérance des navigateurs, et des éditeurs WYSIWYG pour être plus précis, sont un autre problème et si cette tolérance à permis, selon certains, l'essor du web, le prix à payer est extrèmement lourd parce que justement cette tolérance s'est faite au détriment de l'accessibilité. Disons qu'une page "non-conforme" à de très grandes chances de ne jamais pouvoir être accessible et qu'une page "conforme" à de très grandes chances de pouvoir le devenir... Quant au rendu sur IE, pour être vraiment honnête, on doit être pas mal à attendre qu'IE ne rende plus rien (!), histoire de pouvoir commencer à faire un boulot vraiment propre

Tu n'à pas à te préoccuper de cet avertissement si, comme le dis monique, ton script n'à pas vocation à afficher ou à gérer du contenu. Donc si ton script est juste un marqueur et que les résultats sont envoyé ailleurs, (du genre xiti et consorts) il te suffit de mettre le contenu du script entre des balises de commentaire pour éviter qu'il ne soit affiché en tant que texte sur un navigateur qui n'interpréte pas javascript, et tu ne tiens pas compte de l'erreur. Sinon, d'une manière générale, les directives concernant l'accessibilité ne sont pas des règles de validation comme celles concernant le code de tes pages. C'est à toi de juger si tel ou tel avertissement s'applique et en cas de doute de tester avec un navigateur graphique,, un screen reader et un navigateur texte les effets du script.

Resultat des tests : Je confirme que c'est bon pour IE6, 5.5, Moz, FF, OP 7.54 (j'ai pas trouvé la 7.6...) Seul petit probleme sur Netscape 7 où il est difficile d'accrocher le sous-menu, mais bon, netscape 7 est particulièrement buggé sur ce genre de comportement. Pour opera, de toutes manières, ils modifient tellement l'implémentation CSS/DOM de version en version qu'il est bien difficile d'y trouver son compte, sans compter qu'ils tentent d'assurer une compatibilité Gecko/IE en mélangeant les méthodes ce qui rends encore plus obscur le developpement sur cette plateforme en provoquant des effets pour le moins étrange. Le dernier en date en ce qui me concerne: on peut obtenir un focus sur un lien en display:none ou visibility:hidden avec la navigation tabulaire, qui en plus utilise une séquence de touche propriétaire, le pied total quoi !... Le script de bobe parait donc être une bonne base pour gérer facilement des menus en rollover scripté. C'est pierre qui va être content :) Seul petit bémol, à mon gout et parce que j'aime bien triturer le code, je trouve la syntaxe un chouia compliqué à suivre, donc à adapter eventuellement. Mais bon ce doit être juste une question d'habitude...

Vu, Joli code por de l'arrache Voila qui devrait satisfaire l'ami pierre duquel nous n'avons plus de nouvelles... Deux petites questions : hideSubMenu referme tous les objets ul référencés, ce qui ne permet pas d'inclure des sous-sous menus ? Et pour mon information personnelle: Si je comprends bien, la syntaxe hideSubMenu: function() passe la fonction en référence de l'objet, c'est donc équivalent à une instanciation de classe ??? Pareil pour make : tu à un lien de référence sur cette déclaration ? Je ne connaissais pas cette syntaxe très intéréssante, mais il est vrai que bien qu'apprentis forcené du DOM, je trouve qu'il est très compliqué de trouver des tutos/doc/références qui ne se contente pas de réécrire bêtement les specs... En tous cas en francophonie un tuto bien fait sur le couple EcmaScript / DOM fait cruellement defaut et ne favorise pas l'effort nécessaire de séparation comportement/structure, qui n'est somme toute que l'équivalent de la séparation contenu / forme introduite par la standardisation, qui nous débarasserait des bouillies javascriptés actuelles. JP

Super, En passant felicitation pour webnaute... De mon cote j'ai enfin un script qui fonctionne sur Gecko (y compris firefox et les clones) et IE, mais comme tu à l'air plus doué que moi j'attends le tiens pour confronter les méthodes En passant, j'ai été surpris de ne rien trouver de vraiment convaincant qui serait dans l'esprit de l'article de PPK ( séparation comportement/structure). Et tu à raison, c'est hallucinant qu'Opéra ne supporte pas document.styleSheets... JP

Cool, Il est vrai que qu'il est très difficile de trouver des explications claires, concernant la propagation des evenements, particulièrement lors de la phase de bouillonement. J'ai refait des essais sur une structure plus "classique" de listes imbriquées ou le currentTarget est l'element LI parent d'un element UL à déployer. Le script utilise deux guetteurs (mouseover / mouse out) sur le currentTarget LI qui appelle deux fonctions qui affiche ou masque un noeud enfant, en loccurence un UL imbriqué. Evidemment, l'event se propage gaiement jusqu'au browser qu'il finit par fermer (sur IE) Je parviens bien à suivre la propagation avec les propriétés de l'event passé aux fonctions mais je ne parviens pas à stopper la propagation de l'evenement ni avec stopPropagation(), ni avec cancelBubble, et je ne comprends pas vraiment pourquoi... J'ai tenté de contourner le problème en affectant un id, lors de l'initialisation aux éléments à traiter, en imaginant, naïevement, que l'event traitant un objet "unique" bouillonnerait tranquille dans son coin sans conséquence sur les autres objets, mais je me suis vite rendu compte de mon erreur. J'attends avec impatience votre retour ici car la demande initiale de pierre est très inttéréssante en ce sens qu'elle permettrait de fournir une méthode élégante pour produire des menus à roll-over qui ne ressembleraient plus aux usines à gaz javascriptés, imbitables et innacessibles qui pullulent sur le web. Cela permettrait également de fournir une alternative, peut-être plus interessante que celles que l'on peut trouver actuellement, aux limitations du hover de IE et ce en serais pas un luxe. JP PS: si besoin je tiens mes sources à votre disposition...

Salut bobe, Bonnes remarques Bobe, c'est vrai que j'ai la mauvaise habitude d'utiliser l'objet navigator pour detecter le browser, mais c'est vrai aussi que c'est beaucoup plus pratique, surtout lors du developpement d'une fonction. Dont acte, ce n'est pas très difficile à modifier... Je ne comprends pas bien la remarque sur addEventListener qui est référencé comme la méthode à utiliser pour initialiser un gestionnaire d'evenement sur des éléments non clickable, comme les dt du menu. J'ai vu que vous aviez l'air beaucoup plus expérimenté que moi sur ce sujet (la propagation des évenement), peut-être quelques explications serait utiles, pour résoudre l'intéressant probleme de pierre. Le problème apparait bien sur firefox/firebird, je vais fouiller dans cette voie, j'ai bien trouvé une solution qui fonctionne mais qui n'est pas vraiment satisfaisante. Par contre je ne vois pas le rapport entre la sémantique du modèle de raphael et le probleme de pierre, il est vrai que je n'utiliserais pas ce format pour construire un menu mais les arguments de raphael sont recevables. Peut-être qu'avec votre avis éclairé pourrions nous sortir un script propre ? JP

[re]{3} Pierre Comme promis voici une derniere (?) release du script : Comme je l'imaginais il est effectivement possible d'utiliser une boucle de detection pour identifier avec certitude l'element dd à deplier. Du coup grosse simplification puisque on à plus à tester le browser pour plier/replier les sous-menus. La seule necéssité de structure HTML est que l'élément DD à replier doit être le prochain élément de ce type dans le motif primaire : dl->dt->dd. Par contre rien n'interdis d'intercaler d'autres éléments entre le dl et le dt D'autres part, c'était une chose qui m'éttonnais, dans l'exemple de raphael, le dispositif laissait le menu "ouvert" lorsque le focus était perdu sur l'event mouseout. Cela ne me semblait pas très logique eut égard au comportement habituel d'un rollover, quoique cela puisse représenter un interêt ergonomique. Bref, j'ai donc modifier le dispositif en rajoutant un gestionnaire d'évenement sur l'event onmouseout pour simuler parfaitement le roll-over et en transformant la fonction afficher en switch pur. Enfin j'ai débarrassé le script de l'astuce de l'id provisoire qui ne se justifie plus si on implémente un event mouseout. Le résultat est un script conforme, beaucoup plus souple concernant les écarts de structure HTML et indépendant de l'interprétation du DOM en ce qui concerne le traitement des events. Si le scripting client est ok et le browser compatible DOM 2, le menu apparait plié et focntionne parfaitement, dans le cas inverse, rien ne se pase et le menu apparait déplié... Du coup raphael si tu me lis, regarde le script , je suis sur que ca te donner plein de bonnes idées (et si t'a besoin d'un coup de main hésite pas...). Donc le code : // Detection sommaire de IE (this.navigator.userAgent.toLowerCase().indexOf("msie")==-1) ? DOM=1 : DOM=null; function init() { var cible=0; //Si on a le support du DOM requis if(document.getElementsByTagName("dt") && document.getElementById){ for(i=0;i<document.getElementsByTagName("dt").length;i++){ //Si le grand-pere est bien le menu :=) if(document.getElementsByTagName("dt")[i].parentNode.parentNode.getAttribute("id")=="menu"){ //Affectation du gestionnaire d'evenement if(DOM){ document.getElementsByTagName("dt")[i].addEventListener("mouseover",afficher,true); document.getElementsByTagName("dt")[i].addEventListener("mouseout",afficher,true); } //(Note : envoyer un fax a bilou pour lui parler du support des standards...) else{ document.getElementsByTagName("dt")[i].onmouseover=afficher; document.getElementsByTagName("dt")[i].onmouseout=afficher; } //Fermeture du sous-menus //Pour tous les enfants du parent de l'élément dt identifié for(z=0;z<document.getElementsByTagName("dt")[i].parentNode.childNodes.length;z++){ //L'élément à replier est le prochain élément dd de la descendance if(document.getElementsByTagName("dt")[i].parentNode.childNodes[z].nodeName=="DD" && cible==0) cible=document.getElementsByTagName("dt")[i].parentNode.childNodes[z]; } //On replie if(cible){ cible.style.display="none"; cible=0; } } } } } function afficher(){ var cible; //L'element à switcher est le prochain element DD du parent de l'élément dt sur lequel on a l'event for(i=0;i<this.parentNode.childNodes.length;i++){ if(this.parentNode.childNodes[i].nodeName=="DD" && !cible)cible=this.parentNode.childNodes[i]; } //On switch (la premiere condition corrige un affichage d'erreur indue d'IE) if(cible){ (cible.style.display=="block")? cible.style.display="none" : cible.style.display="block"; } } Et yop la boum... JP PS: Il y à moyen d'optimiser encore le code, voire de le généraliser mais je verrais ca plus tard....

Ha oui j'oubliais : Je ne suis pas certain que ce soit vraiment une bonne iddée (quoi que) de proposer à raphael de modifier son script. En passant, immense respect pour son excellent boulot sur alsacreation ... La raison est que tant que perdurera l'Infame Essai de redmond sur les browsers (je me moque), il est très difficile de généraliser ce genre de méthode... Il y à autant de différence sur le support du DOM entre Gecko et IE que sur les CSS pour te donner une idée. Donc l'implémentation de ce genre de dispositif necessite des structures HTML consolidée, par exemple dans notre cas en ce qui concerne les retours chariots du code HTML. Du coup le pauvre risque d'être inondé de messages et de demande d'aide parceque un zélé webmestre aura voulu supprimer un retour chariot ou modifier l'arborescence du motif primaire du menu. Mais bon pourquoi pas... JP PS : en y repensant il existe bien une solution pour etre sur de tomber sur le bon enfant en utilisant une boucle de detection fondé sur la valeur de classe CSS (il faudrait donc utiliser des classes CSS au lieu de l'héritage utilisé par raphael) de l'element à déplier, je regarderais ça ce soir...

Reresalut pierre Bon ben finalement, j'ai trouvé les niaiseries de mon premier essai, donc voici le code qui va te permettre d'atteindre ton objectif : plus de javascript dans la page :) // Detection sommaire de IE (this.navigator.userAgent.toLowerCase().indexOf("msie")==-1) ? DOM=1 : DOM=null; function init() { //Si on a le support du DOM requis if(document.getElementsByTagName("dt") && document.getElementById){ for(i=0;i<document.getElementsByTagName("dt").length;i++){ //Si le grand-pere est bien le menu :=) if(document.getElementsByTagName("dt")[i].parentNode.parentNode.getAttribute("id")=="menu"){ //Affectation du gestionnaire d'evenement if(DOM){ document.getElementsByTagName("dt")[i].addEventListener("mouseover",afficher,true); } //(Note : envoyer un fax a bilou pour lui parler du support des standards...) else{ document.getElementsByTagName("dt")[i].onmouseover=afficher; } } } } } function afficher(){ //Note: envoyer un fax a bilou... (DOM) ? indexN=3 : indexN=1; //Si on a un element depliable (pour faire la distinction entre les titres et les liens if(cible=this.parentNode.childNodes[indexN]){ //Si on en à un déjà ouvert on le ferme if(document.getElementById("ouvert")){ document.getElementById("ouvert").style.display="none"; document.getElementById("ouvert").removeAttribute("id"); } //On ouvre le sous-menus courant cible.style.display="block"; cible.setAttribute("id","ouvert"); } } Quelques commentaires: La fonction init() s'implémente sur le onload du body. Tu peux virer tous les id des dt, ils ne servent plus à rien Tu dois absolument respecter l'ecriture des listes, du point de vue du DOM les retours chariots du code HTML sont des nodes valides, donc un en plus ou un en moins peuvent planter le dispositif. Comme tu le remarqueras il y à une différence d'interprétation entre IE et Gecko sur l'interprétation de l'arborescence du DOM, qui doit d'ailleurs être en relation avec les fameux retours charios du code HTML. D'ou la nécessité pour la focntion afficher de modifier la valeur de l'index de l'enfant recherché. A vrai dire je ne sais pas qui à raison sur le coup Gecko ou IE. Enfin, ce dispositif ne fonctionne qu'avec les browsers implémentant DOM 2, nottament pour le support de getElementsByTagname qui n'est pas une spécification du DOM HTML mais est une implémentation sauvage d'une propriété du DOM XML, (on embrasse les developpeurs sur les deux joues...) Donc, maintenant que ta page est equipée d'un joli dispositif, te reste à trouver moyen d'offrir une alternative aux browsers ne pouvant pas supporter le dispositif. La solution passe par l'implémentation, par défaut de tes sous-menus dans leur états dépliés et de les refermer à l'ouverture de la page par la fonction init. Il te suffit d'inverser la valeur de classe CSS concernant les dd à ouvrir et de profiter de la boucle d'intialisation pour les fermer en adressant le troisieme (gecko) enfant du parent ou le premier (ie); Le code: // Detection sommaire de IE (this.navigator.userAgent.toLowerCase().indexOf("msie")==-1) ? DOM=1 : DOM=null; function init() { //Si on a le support du DOM requis if(document.getElementsByTagName("dt") && document.getElementById){ for(i=0;i<document.getElementsByTagName("dt").length;i++){ //Si le grand-pere est bien le menu :=) if(document.getElementsByTagName("dt")[i].parentNode.parentNode.getAttribute("id")=="menu"){ //Affectation du gestionnaire d'evenement if(DOM){ document.getElementsByTagName("dt")[i].addEventListener("mouseover",afficher,true); //Fermeture du sous-menus if(cible=document.getElementsByTagName("dt")[i].parentNode.childNodes[3])cible.style.display="none"; } //(Note : envoyer un fax a bilou pour lui parler du support des standards...) else{ document.getElementsByTagName("dt")[i].onmouseover=afficher; if(cible=document.getElementsByTagName("dt")[i].parentNode.childNodes[1])cible.style.display="none"; } } } } } function afficher(){ //Note: envoyer un fax a bilou... (DOM) ? indexN=3 : indexN=1; //Si on a un element depliable (pour faire la distinction entre les titres et les liens if(cible=this.parentNode.childNodes[indexN]){ //Si on en à un déjà ouvert on le ferme if(document.getElementById("ouvert")){ document.getElementById("ouvert").style.display="none"; document.getElementById("ouvert").removeAttribute("id"); } //On ouvre le sous-menus courant cible.style.display="block"; cible.setAttribute("id","ouvert"); } } Et te voila avec un menu "tous temps", déplié, utilisable et accessible pour les vieux browsers, les lecteurs d'écrans ect, plié et utilisable pour les browsers DOM 2. Elle est pas belle la vie ? Note : C'est testé sur IE 6+ et Gecko, si tu à des difficultés d'implémentation contacte moi...

Resalut pierre J'ai testé la solution que je te donnais dans mon message précédent ce matin au petit dej. Malheureusement, je ne parviens pas à initialiser correctement le gestionnaire d'evenement sur l'élément dt... J'ai donc modifié l'approche du probleme en prenant comme objectif une méthode plus "classique" qui consiste à créer l'attribut onmouseover à postériori lors de l'initialisation de la page en utilisant le même scenario : Récupérer le tableau des éléments dt, créer l'attribut onmouseover sur les éléments identifiés qui invoque une fonction afficher basée sur l'enfant à déplier et la mise à jour d'un attribut id provisoire pour replier le "dernier sous-menu affiché". J'ai une solution qui fonctionne parfaitement sur Gecko mais, évidemment, le plus grand bricolage logiciel depuis l'invention de tim, à savoir IE, resiste impertubablement à la méthode standard ecmascript/dom de création et d'initialisation d'attribut. Je te fais signe dés que j'ai trouvé la solution pour dompter IE. JP PS : si un expert traine dans le coin pourrait-il me dire où se situe le problème ou la niaiserie de code dans la séquence suivante : Je ne reçois ni erreur ni exception de l'interpréteur javascript mais le dispositif reste totalement silencieux... // Detection sommaire de IE (this.navigator.userAgent.toLowerCase().indexOf("msie")==-1) ? DOM=1 : DOM=null; function init(){ //Test de support DOM if(document.getElementsByTagName("dt") && document.getElementById){ for(i=0;i<document.getElementsByTagName("dt").length;i++){ if(document.getElementsByTagName("dt")[i].parentNode.parentNode.getAttribute("id")=="menu"){ //Mise en place du gestionnaire d'évènement if(DOM){ document.getElementsByTagName("li")[i].addEventListener("onmouseover", afficher, true); } else{ eval(document.getElementsByTagName("li")[i].onmouseover=afficher); } } } } }

Salut pierre, Ce n'est pas très difficile mais cela necessite que tu manipules un peut Ecmascript et le DOM et que tu utilise un outil comme le DOM inspector de Mozilla pour tester l'arbre de la page. Dans ton cas la séparation comportement/structure pour reprendre la terminologie de Peter implique de remplacer les events sur les dt du menu de raphael par un gestionnaire d'evenement, qui sera mis en place par une fonction d'initialisation invoquée à l'ouverture de la page sur le onload. D'autres parts tu devras acceder aux éléments de manière anonyme en parcourant l'arbre du DOM, aussi bien lors de l'initialisation que lors du switch de la classe CSS des sous-menus. Dans cette perspective, les ID des sous-menus ne servent plus à rien, car on peut accéder au sous-menus à afficher en prenant comme position de référence l'element dt surveillé par le gestionnaire d'evenement et en adressant son premier enfant ou l'élement de sa descendance, identifié comme l'élement à afficher. Donc tu peux virer tous les id des sous-menus... Dans la technique du roll-over l'affichage du sous-menu ne pose pas de problème, par contre afin d'eviter une boucle qui va traiter tous les éléments à chaque evenement, comme dans le dispositif de raphael, ce qui n'est pas très économique, tu vas utiliser une astuce en affectant à un element "affiché" un id provisoire qui sera utilisé par la fonction de traitement de l'evenement. Voici, globalement le scenario de ton script, que tu devras mettre dans un fichier externe pour débarasser completement ta page de tout notion de script . Ce scenario est théorique, je n'ai pas eu le temps de le tester mais le script final devrait y ressembler fortement. Pour la fonction d'initialisation : 1. Detecter IE pour invoquer la syntaxe propriétaire du browser redmondien concernant les gestionnaire d'evenement. 2. Capturer le tableaux des éléments dt de la page avec document.getElementsByTagName("dt") . 3. A l'aide d'une boucle, parcourir chaque element du tableau en testant l'attribut id du parent de son parent (la structure nodale est : div id='menu' -> dl -> dt ou dt est l'enfant à identifier du parent dl du parent div), les éléments qui t'intéressent sont donc ceux dont le parent du parent est l'élément div ayant valeur d'id "menu" Tu fais le test avec l'adresse: document.getElementsByTagName("dt").parentNode.parentNode.getAttribute('id')="menu". 4. Pour chaque element identifié, affecter le gestionnaire d'evenement en utilisant les deux syntaxes : - Pour Gecko : document.getElementsByTagName("dt").addEventListener("evenement", fonction, true) - Pour IE : eval(document.getElementsByTagName("dt").evenement=fonction) note : l'affectation à la fonction est une affectation d'objet donc tu ne met pas d'accolade au nom de la fonction passé au gestionnaire d'evenement Chaque element dt correctement adressé va donc être surveillé en relation avec l'évenement onmouseover. Il te suffit maintenant d'ecrire la foonction qui sera invoquée lors de l'evenement surveillé sur l'element identifié, cette fonction devra switcher la classe CSS de l'enfant de l'élément surveillé pour l'afficher, créer un attribut id provisoire servant à identifier "le dernier sous-menus affiché", switcher la classe CSS de ce "dernier sous-menu affiché" pour le replier, détruire l'attribut id provisoire et le réaffecter à l'élément affiché courant. L'appel de la fonction se fait avec fonction(this.firstChild) ou fonction(this.childNodes[n]) ou [n] est l'index de l'élément enfant à déplier dans la descendance renvoyée par le DOM inspector. L'ordre de traitement à une grande importance et devra être : 1. Tester si il existe un élément ayant un id provisoire avec document.GetElementById("ouvert") 2. Si oui, switcher la classe CSS de cet élément pour le replier et effacer la valeur de l'attribut id provisoire avec document.GetElementById('ouvert').removeAttribute('id') 3. Switcher la classe CSS de l'élément passé en paramètre de la fonction par le egstionnaire d'évenement, donc de l'enfant dd de l'élément dt sur lequel à lieu l'evenement courant. 4. Affecter un attribut id provisoire "ouvert" avec this.firstChild.setAttribute('id','ouvert') ou this.childNodes[n].setAttribute('id','ouvert') Prendre un peut de lexomil et tester... Ta page équipée de ce dispositif sera, coformément au developpement ecmascript "standard", completement debarassé de toute notion de script ecmascript et tes roll-over seront inoxydable. Par contre, comme tu peux le constater ca demande un peut d'investisement en temps de développement L'autre intérêt de cette méthode est que pour créer un nouveau sous-menu, il te suffit de rajouter un bloc dl->dt->dd->ul sans autre formalités, car en réalité c'est la structure de ta liste qui va piloter le script et non l'inverse comme dans l'exemple de raphael. Tu peux même envisager de rendre le traitement itératif pour prendre en charge plusieurs structure de menu/sous menus, en utilisant des id de menu du genre "menu1", "menu2" ect Enfin, en terme de charge de traitement le recours au DOM est très économique ce qui peut représenter un gain de temps de chargement non négligeable pour de grandes listes. Si tu coinces, ou si tu n'à rien compris (t'inquiete pas si tu es novice dans le developpement Ecmascript/DOM c'est normal), dis le moi, je trouverais bien une heure ou deux pour écrire le script. En passant et pour être parfaitement econome, tu pourrais tout aussi bien traiter le roll-over avec une classe CSS qui focntionnera parfaitement bien sur Gecko et réserver le traitement ecmascript à notre ami IE. La tu serais pas mal : méthode standard quand c'est possible et cautere sur une jambe de bois, mais sans pollution scriptée, pour les afficionados de l'ogre monopolistique de redmond... :) JP

Bonjour marie, Ton site à l'air bien sympathique. Malheureusement il comporte quelques erreurs au niveau des CSS et aussi du code HTML. Le fait qu'il s'affiche comme tu le veux dans IE est un tour de force d'IE mais ta syntaxe et ton gabarait CSS posant problème il ne s'affiche plus du tout correctement dans les autres navigateurs. Ce n'est jamais une bonne idée d'utiliser IE comme browser de test, essaye plutot mozilla ou firefox puis une fois que ca fonctionne bien de regarder le résultat sur IE et de faire les corrections nécessaires pour que tout colle. Ci-dessous ton gabarit CSS que j'ai corrigé (il y aurait d'autres solutions mais bon j'avais juste quelques minutes avant de manger... ) body { margin : 0px; padding : 0px; font-family : verdana, arial, helvetica, sans-serif; background-color : #ff6600; font-size : 0.8em; } a { color : #ffffff; font-size : 1.2em; } .enfants { position : absolute; top : 80px; left : 50px; width : 150px; } .parents { position : absolute; top : 200px; left : 580px; width : 150px; } .accueil { background-image : url(images/fonds_acc.jpg); background-repeat : repeat; width : 780px; height : 430px; } p{ background-color : #ffffff; margin-left:5%; margin-right:5%; padding:10px; } Quelques remarques : Ta page index est constituée d'un div "accueil" qui va servir de contener pour tout le reste, c'est à dire l'image, les liens et le texte. Tous les éléments seront positionnés par rapport à ce contener principal, donc ils doivent être tous contenus dans "accueil". Ce contener étant par défaut positionné en haut à gauche du body, tu n'a pas besoin de spécifier de position. Partant de cette base le reste est simple : L'image et le texte viennent l'un au dessus de l'autre, et les deux liens vont être encapsulés dans deux divs, que l'on va positionner en "absolu" par rapport au contener accueil de manière à les positionner exactement ou tu veux. Dernière remarque : l'élément blockquote est destiné à afficher une citation, ce qui n'est pas le cas de ton texte, dans ce cas un élément p suffit, dont on modifie les marges gauche et droite pour l'afficher "au centre" du contener principal "accueil". Comme tu l'à compris ton squelette HTML doit se modifier en conséquence : div class="accueil"> <img src="http://www.zengrafom.org/site/images/acc_jaj_001.jpg" alt="Graphisme page d'accueil de l'Asbl jour après jour" width="780"> <p>Parce qu'un enfant à l'hôpital, ce n'est jamais juste et quand il s'agit de maladie comme le cancer, la révolte est encore plus grande. Parce qu'il faut organiser le mieux possible le quotidien de ces enfants, ainsi que le soutien moral et parfois financier de leurs familles. Parce que ces enfants, plus que jamais, ont besoin de cadeaux et d'amis sincères, mais aussi de voyages et de rêves. Parce que le rêve, c'est l'espoir, et qu'au royaume de l'espoir, il n'y a pas d'hiver... </p> <div class="enfants"> <a href="enfants/index.html" title="Lien vers les pages pour les enfants">le coin des enfants</a> </div> <div class="parents"> <a href="parents/index.html" title="Lien vers les pages pour les parents">Le coin des parents</a> </div> </div> Corrigé de quelques erreurs (la balise title du premeir lien...) N'hésite pas à essayer de t'inspirer de ce modèle pour les pages suivantes qui comportent aussi beaucoup d'erreurs. J'essayerai d'y jeter un oeil dés que j'ai un petit moment. Bon courage pour la suite