Denis

Dans le même ordre d'idées, il y a le nouvel article de Pompage de l'édition d'avril 2004 qui traite admirablement bien du sujet : http://pompage.net/pompe/sprites/

Effectivement, XHTML c'est une version évoluée de HTML. Rien de plus, rien de moins. L'article d'OpenWeb proposé par Monique sert justement à établir la dizaine de points de différences entre les deux langages. La différence fondamentale entre les deux, c'est simplement que HTML repose sur la syntaxe du SGML, alors que XHTML repose sur la syntaxe XML. Au final, les deux se valeent il n'y en a pas un qui est mieux que l'autre. Tout est une question de déterminer jusqu'ou tu souhaites aller. Plus tu souhaite pousser l'expérience du code vers des plateformes alternatives comme le sans-fil, plus tu dois considérer aller vers XHTML. Par contre, pour quelqu'un qui souhaite y aller modestement, HTML demeure tout à fait convenable.

Mado, une question toute bête, mais je odis la poser quand même... Tu as bien changé le nom de fichier aux deux endroits ? Il y a le code dans le commentaire conditionnel et l'autre aussi.

Effectivement, c'est pas forcément plus clair... Difficile d'inspirer l'envie d'apporter une aide au projet si au départ, tout demeure si confus.

C'est bien dire que le malheur des uns fait le bonheur des autres... Ou certains souffrent de la trop grande permissivité de MSIE parce qu'il nuit à la campagne de sensibilisation aux méthodologie de conception Web, d'autres apprécient le fait qu'ils n'ont pas trop d'efforts à faire pour que leur code marche bien avec le navigateur le plus populaire au monde en date d'aujourd'hui...

En effet... que penser d'un menu en image dont chaque item aurait en alt la valeur "bouton" au lieu du libellé de l'image en question (exemple : expertise)... Ne riez pas, je vois ça tout le temps !

Nous nous entendons tous, Opera et FireFox sont bien meilleurs que l'hégémonique MISE à ce niveau... Je suis tout à fait d'accord avec toi Clair de lune, si quelqu'un est pour utiliser les fonctionnalités de pop up, je lui demande alors deux choses : 1 - avertir son utilisateur à priori que la nouvelle fenêtre va s'ouvrir ; 2 - avoir la décence de respecter la réalité de l'utilisateur et de ne pas imposer le suport de javascript pour naviguer. Si ces deux éléments sont pris en compte, les pop ups me dérangent beaucoup moins. De toute manière, moi je les ouvrirai dans un onglet de toute manière... mais tous n'ont pas ma chance d'utiliser un vrai navigateur Web !

Il n'y a effectivement pas de meilleur incitatif à mon avis pour se donner à la cause de l'accessibilité que de constater la réalité avec laquelle un aveugle doit composer pour profiter comme nous du Web à l'aide de la synthèse vocale... à condition d'avoir le coeur à la bonne place bien sûr. Se faire lire 5 minutes de Web par Jaws est suffisant pour comprendre la tenacité et la persévérance nécessaire pour l'utiliser à la journée longue. Chapeau à tous ceux qui le vivent et le font, ils n'ont que toute mon admiration. L'effort, aussi minimal soit-il, que je dois faire pour m'assurer de les aider à amoindrir la douleur de leur expérience d'utilisateur en codant accessible est bien minime en comparaison au leur, simplement pour pouvoir profiter de la technologie au même titre que moi.

Quel serait l'intérêt d'un forum si ce n'était pour s'aider les uns les autres ???

Il faut pas oublier non plus que les validateurs, aussi bons soient-ils ne peuvent jamais être à 100% fiables. Contrairement à la validation du code HTML, la validation des principes d'accessibilité repose en grande part sur énormément de validation devant être faite manuellement. Si l'outil peut vérifier la présence de ALT, il ne peut pas porter un jugement irréprochable sur les contrastes, la clarté du contenu ou des trucs comme ça ; il ne peut que donner des avertissements, lancer des pistes de vérification. Lors de ma formation en accessibilité cette semaine, le formateur avançait que près de 40% du travail de validation ne pouvait être automatisé. C'est donc dire qu'un résultat réussi dans un validateur d'accessibilité ne veut dire qu'une chose... c'est que le travail est bien parti. Mais la note parfaite chez Bobby, Cynthia Says, Acces-pour-tous et tous les autres ne signifie pas qu'un site soit accessible pour autant. Mais c'est un excellent départ.

Mais c'est qu'il sait demeurer positif ce pitidev... Bravo, t'as tout pigé. Viens ici que je te serre la pince !

Dire que j'ai oublié de vous mentionner l'innovation de Hixie, parue il y a quelques semaines; une autre façon d'intégrer du flash sans pour autant faire appel à la diaboliquement propriétaire balise embed :!: http://ln.hixie.ch/?start=1081798064&count=1 Pour les amoureux du code : <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" width="300" height="120"> <param name="movie" value="http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <!--[if !IE]> <--> <object data="http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf" width="300" height="120" type="application/x-shockwave-flash"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="pluginurl" value="http://www.macromedia.com/go/getflashplayer"> FAIL (the browser should render some flash content, not this). </object> <!--> <![endif]--> </object>

Affirmer que l'utilisation des feuilles de style ralenti le travail de développement par rapport aux vieilles méthodes, c'est avoir une vision très court-termiste de ton travail de développeur Web. Il est clair qu'au départ, basculer dans cette nouvelle technologie, c'est s'exposer à une courbe d'apprentissage assez abrupte. Il y aura cetainement des moments où tu ne sauras plus quoi faire pour t'en sortir et où tu rageras en te disant que tu aurais pu faire bien mieux et bien plus rapidement avec les vieilles méthodes du siècle dernier. Mais sache simplement que si tu persévères, si tu fais les efforts nécessaires et si tu poses les bonnes questions (tu disposes en ce forum d'un extraordinaire outil collaboratif te mettant en relation avec pleins de gens qui seront heureux de t'aider), avant longtemps, tu t'amuseras toi-même à te souvenir de la naîveté qui était tienne lorsque tu as posé cette question. Donne-toi la chance de découvrir cette technologie d'une puissance phénoménale et avant longtemps, tu te féliciteras de l'avoir fait. Entre-temps, nous sommes à ton entière disposition pour t'aider à cheminer là-dedans.

Il ne faudrait pas aussi oublier la référence des références pour tout ce qui a trait aux bonnes manières de coder, le site qui en a inspiré des centaines d'autres dont OpenWeb lui-même dans la francophonie, le site qui alimente Pompage.net sur une base quasi mensuelle, j'ai nommé A List Apart. Évidemment, il faut savoir lire l'anglais, mais ce site est de loin la meilleure référence qui soit. http://www.alistapart.com/ ALA, souvent imité, jamais égalé !

Oui, la réponse de Monique risque fort de ne pas te plaire... mais c'est la seule réponse qui vaille... l'attribut target à été viré et volontairement pas remplacé par quoi que ce soit, compte tenu que la pratique est condamnable. Que l'on soit d'accord ou non avec l'oriuentation, la réflexion veut que ce soit à l'utilisateur de décider s'il souhaite ouvrir une nouvelle fenêtre ou non, pas au programmeur. Pour ceux qui s'y opposent, il y a toujours la méthode par javascript.

Pas de problème. Tu comprendras que tu peux changer les diverses valeurs passées dans la "commande". Par exemple, tu pourrais changer l'épaisseur de l'encadré en modifiant la vlaeur de 1px par autre chose (2px, 20px 100px, etc.), la nature du trait (actuellement solid par dotted, dashed, double, etc.) ou sa couleur en modifiant la valeur hexadécimale (passer du noir #000 à une autre couleur quelle qu'elle soit, le rouge par exemple -- #f00). De plus, tu pourrais modifier le padding entre le contenu et la bordure en modifiant la valeur de la règle pour une autre valeur. Par exemple, 1em serait beaucoup plus grand et 0.1em, beaucoup plus petit. Les possibilités offertes par CSS sont infinies, d'ou l'intérêt de les apprivoiser.

Salut slek, pour encadrer un mot ou un groupe de mots, il faut utiliser les CSS. Que tu utilises ou non DW n'a pas d'importance là-dedans, c'est une application de la technologie qui importe. Tout ce que tu as à faire (question de garder ça très très simple), c'est d'insérer l'attribut style et ses valeurs dans l'élément HTML qui contient le ou les mots : <p style="border: 1px solid #000; padding: 0.3em;">le ou les mots à encadrer</p> Ça devrait être une bonne piste de départ.

Hummm... tout me semble correct à ce niveau. Par contre, il y a quelques autres petits problèmes. Peut-être ce compte-rendu t'aidera t-il à y voir plus clair ? http://www.contentquality.com/mynewtester/...rifsConfort.htm

Bienvenue parmi nous Clair de lune. Je suis doublement heureux de t'accueillir compte tenu du fait que dès ton premier site Web, tu prends déjà en compte des principes fondamentaux comme l'accessibilité. Compte tenu qu'il y a des développeurs qui font du Web depuis des années et qui ne se sont pas encore sensibilisés à l'importance de produire du contenu universellement accessible, ça me rend doublement fier de te compter parmi nous ! Au plaisir d'échanger souvent et constructivement !

La raison pour laquelle ça plante, ce n'est pas tant l'attribut src que la balise embed qui n'est pas reconnue en xhtml (car j'assume que ta page est en xhtml 1.0 transitionnel). Embed est une balise propriétaire avec laquelle tu indiques à netscape de faire le même travail que la balise object qui elle, vient directement de la norme. Donc qui valide. LE problème, c'est que pour t'assurer que tn flash s'affiche dans Netscape, tu dois l'utiliser. C'est donc un cercle vicieux entre la validité et la préservation dans NS. Heureusement, il y a une solution. Il suffit de réécrire différemment l'appel à ton fichier Flash, de manière à adresser le besoin de tous les navigateurs d'une manière conforme et universelle. A List Apart a produit un excellent article sur le sujet : http://alistapart.com/articles/flashsatay Ça devrait répondre à toutes tes questions.

Les touches proposées par Stéphane sur acces-pour-tous ne représentent pas seulement ce qu'il considère comme une bonne pratique, ils représentent ce que l'ensemble des gens qui les utilisent s'entendent pour considérer comme l'usage usuel. En ce sens, nous sommes aussi près d'une norme que nous pouvons l'être aujourd'hui. Ton beau rêve n'est donc peut-être pas si loin si on considère cela comme ça. Mais le problème, c'est que je retrouve de plus en plus d'opinions à l'effet que les accesskeys posent plus de problèmes qu'ils n'en résoudent... J'ai effectivement lu à quelques endroits par le passé (je pense entre autres à un post sur Mezzoblue) que les accesskeys posaient un certain nombre de problèmes, mais je n'ai jamais été au fond des choses encore. C'est un problème qu'il faudrait bien sonder et documenter une fois pour toutes. Je constate également des incohérences avec le support des balises proposées pour l'accessibilité qui me scient les jambes. Par exemple, apprendre que les balises <em>, <strong> et <title> ne sont que pas ou peu supportées dans les configurations logicielles de bases des synthétiseurs vocaux. L'utilisation de ces balises demeurent pertinentes d'un point de vue sémantique, mais c'est quand même terriblement décevant de constater qu'elle n'aident pas automatiquement à rendre un document plus accessible. Je reviens encore avec le même exemple que j'ai laissé dans un autre thread, mais si le title n'est pas automatiquement pris en charge par les synthétiseurs vocaux, alors il faut se mettre à repenser la manière dont nous épinglons nos liens. Personnellement, j'ai depuis longtemps pris l'habitude sur mon site d'épingler mon hyperlien sur quelques mots significatifs dans un billet et d'ajouter du contexte complémentaire avec la balise title. Cette pratique est évidemment très bonne parce qu'elle offre un surplus d'information aux utilisateurs, mais elle n'aide en rien les personnes aux prises avec des limitations fonctionnelles, à la base ceux qui en auraient le plus besoin pour se retrouver dans l'océan de liens récupérés d'un coup dans une page. Il faut savoir que les utilisateurs de lecteurs d'écran ont la possibilité de scanner directement tous les hyperliens d'une page afin de se promener plus vite dans celle-ci et trouver ce qui les intéressent. La directive de ne pas apposer un lien sur "pour en savoir plus" devient encore plus pertinente si les balises title, qui auraient ajouté du contexte au fameux "pour en savoir plus", ne sont pas lues. Imaginez vous sur un site de nouvelles ou tous les liens pointent vers les versions complètes de résumés. Trois cent résumés d'articles, trois cent liens "pour en savoir plus" impossibles à démêler. Apprendre que la balise title n'est pas systématiqument lue, génère un énorme problème dans bien des cas.

Pour ceux que ça intéresse, je viens de retruver ce document sur les acceskeys, gracieuseté du validatoeur W3C... si il y a une autorité capable d'établir une note de base sur l'utilisation des accesskeys, c'est bien le W3C http://validator.w3.org/accesskeys.html Une piste intéressante pour réfléchir à une normalisation des touches d'utilisation ?

Un petit compte rendu de la formation en accessibilité que j'ai suivi hier à Montréal. Je vous file l'url des documents reliés au cours, pour votre culture personnelle. C'est assez complet pour un premier survol. http://www.accessibiliteweb.com/formationenligne/ Monique, si tu comptes être à la formation d'accessiWeb, pourrais-tu me ramasser de la documentation s'ils en distribuent ? PDF ou autre format électronique, s'ils en ont. Si tu peux m'avoir des documents papiers, je paierais pour que tu me les fasses parvenir.

J'arrive peut-être un peu tard, le problème existe t-il encore ? Je regarde la page mentionné au premier message et je ne note pas d'erreurs apparentes... Si ça peut donner un coup de main, j,aime bien me référer à cet outil du site accessify pour la génération de tableaux HTML accessibles : http://www.accessify.com/tools-and-wizards...ilder_step1.asp

Infidèle !!! Suppôt de Satan !!! En fait, ça revient à dire ce que j'ai toujours dit... on est jamais mieux servi que par soi-même. Lorsqu'on code manuellement nos trucs, on peut contrôler ce qui se passe. Le reste du temps, c'est la roulette russe. Je reconnais bien DW là-dessus. Mieux qu'il était, mais encore bien loin de la perfection que nous offre le codage à la main.