Denis

Ma réponse ne repose sur aucun fondement de scientifique, mais elle semble fonctionner. Il suffirait d'encoder certains caractères de l'adresse pour duper la majorité des crawlers. Bien sûr, rien n'est plus infaillible que de ne pas la dévoiler du tout, mais ça a le mérite de protéger mes adresses un peu (je reçcis beaucoup moins de spam sur ces adresses que sur d'autres). Par exemple, pour encoder le _AT_ il suffirait de le remplacer par @. Pour ma part, comme l'adresse est un .com, je remplace le com par com (com). Ce qui donne : nom@nomdedomaine.com Je suis certain que c'est loin d'être infaillible, mais je gage aussi sur le fait qu'il y a tellement d'adresses à récolter sur le Web que dès qu'elle est un peu plus compliquée à récupérer, la plupart des crawlers passeront à la suivante. Pour une liste complète du jeu de caractères iso-8859-1 (que vous utilisez probablement pour la plupart puisque vos sites sont probablement en français) et leur encodage en entités numériques (ou autres), voir : http://www.blooberry.com/indexdot/html/tagpages/text.htm Évidemment, vous faites sauter les "amp" de chaque encodage, qui ne sont ici que pour me permettre de les faire affficher convenablement.

Au Québec, le gouvernement est en train de faire de nombreux efforts pour rendre son projet de gouvernement en ligne accessible et conforme aux normes. Il y a plein de bonne volonté, mais le problème est toujours le même. Si les dirigeants et leurs représentants comprennent l'intérêt à développer en ce sens, ils passent leur temps à se questionner sur les raisons pour lesquelles les agences qui développent pour eux le Web (ou leurs propres ressources intenres) sont incapables de livrer des sites répondant à ces critères de qualité. La réalité est forcément la même en france, bien que vous soyez à un autre stade de ce processus. Rien ne sera parfaitement réalisé avant de nombreuses années encore, mais chaque petit pas dans cette direction est un pas dans la bonne direction. Soyons patients et prenons tout ce qui passe

Et pour le bénéfice des millions de téléspectateurs qui nous regardent à la maison, tu pourrais partager les raisons de ta honte, pour que d'autres en apprennent un tout petit peu également ?

Et par pur hasard, il y aurait pas un bon samaritain quelque part qui aurait déjà fait une étude comparative des modèles de copyright par pays ?

Bienvenue parmi nous migo ! En espérant que tu te plairas dans notre pettie communauté. --

C'est juste ça ? Je suis un peu déçu Autrement je suis d'accord avec Monique... ça prendrait un peu plus d'informations pour que nous puissions t'être d'une quelconque utilité.

En ce qui me concerne, la principale raison de vouloir plusieurs extensions pour le même nom de domaine irait dans le sens de la réponse de Dan... protéger le nom. Ensuite, pour les faire pointer tous au même endroit, il me semble que de simples répertoires hébergés individuellement pour chacun des noms de domaines dits "secondaires" avec une redirection vers le nom de domaine principal font l'affaire, non ?

En retard, mais avec toute la bonne volonté du monde, j'ai trouvé ça ce matin. C'est assez clair, mais c'est peut-être différent pour vous européens. http://www.copyright.gov/circs/circ1.html#noc

Tu confonds ici deux concepts très différents. Il y a sémantique HTML et Web sémantique. Une recherche rapide sur Google pour "semantic web" et "html semantics" te permettra d'y voir un peu plus clair. Le document auquel tu réfère sert à "mesurer" la sémantique de l'information contenue dans le document. Pour y arriver, l'outil recherche un certain nombre d'éléments et de technologies comme RDF ou FOAF, qui ne figurent évidemment pas dans tes pages. Ce qui explique pourquoi ça ne fonctionne pas pour toi. Ce que tu cherches toi, c'est mesurer la valeur sémantique de ton code, pas de ton contenu. Pour cela, il n'existe malheureusement pas d'outils automatisés comme par exemple le validateur. C'est une question d'analyse et de recul vis-à-vis tes intentions pour faire les meilleurs choix - et les plus optimisés. C'est lorsque je m'aventure dans des réponses comme celles-là que je m'ennuie de Karl Dubost et Laurent Denis...

Ne connaissant pas ELM ou même ce que veut dire QCM, je ne saurais pas trop t'aider. Par contre, pour ce qui est de rendre un truc accessible, peut-être votre solution résiderait-elle dans la création d'une source alternative ou parallèle à cet éventuel contenu qui serait purement textuelle pour le bénéfice de ceux qui ne pourraient l'utiliser ?

Ce n'est malheureusement pas aussi simple. Quelqu'un est surpris ? Si tu souhaites utiliser du gras pour mettre une véritable emphase sur quelques mots et que cette emphase apporte une véritable valeur ajoutée au message, alors tu utilises un <strong> parce que cet indice est important au message. Si tu veux mettre du gras pour le nom du site Web, comme tu le fais actuellement, alors utilises le <b> car ton emphase n'est que visuelle, elle n'apporte aucun sens supplémentaire au message, elle ne fait qu'attirer l'attention sur les mots. De toute manière, pour deux trucs qui se valent en terme de récultats, entre 4 caractéres pour écrire un <b> et 20 caractères pour écrire <span class="gras">, l'optimisation te pousse nettement vers le premier choix. Mais si on devait résumer, alors oui ; si tu dois faire du gras, utilises le <strong> parce qu'en définitive, si tu veux mettre du gras, c'est que ce traitement apporte une valeur ajoutée. Mais rappelle toi que trop de <strong> tue le <strong>, comme trop de <div> tue le <div>.

Et franchement, quelle est la différence entre un <span> et un <b> ? Dans les deux cas, tu es aux prises avec une balise qui n'a strictiement rien à voir avec ta structure de code...

Avec un peu de retard, mais plein de bonne volonté, je me lance quand même dans une réponse pour essayer de t'éclairer un peu sur ce que j'entendais. Je m'excuse d'avance, je sais que ce sera long. Commençons par le point 2 si tu le veux bien. Tu utilises trois spans pour créer le menu du haut pour les items inscription, newsletter et forum. Voici comment tu as codé le CSS qui accompagne ces <span> : /* les 3 boutons du header*/ .bt1 { position: absolute; top: 18px; left: 470px; font-size: 13px; } .bt2 { position: absolute; top: 38px; left: 440px; font-size: 13px; } .bt3 { position: absolute; top: 58px; left: 415px; font-size: 13px; } Autrement dit, en positionnant ces trois <span> comme des éléments distincts, tu leur donnes un rôle semblable à celui qu'un <div> remplirait, donc un élément block. Pour faire la distinction entre un élément en-ligne (ex. le span), par opposition à un élément bloc (ex. le div) et la différence entre un <div> et un <span>, voir les articles suivants : http://www.netmechanic.com/news/vol6/css_no16.htm http://www.webmasterworld.com/forum83/3980.htm http://webdesign.about.com/cs/htmltags/a/aa011000a.htm C'est pas terrible, mais c'est ce que j'ai trouvé de mieux pour le moment. C'est pourquoi je faisais initialement allusion à l'effet d'utiliser une liste HTML avec trois <li> plutôt que trois <span> (ou mieux, <div>). Sémantiquement parlant, le <ul> serait plus indiqué pour regrouper ton menu que ces trois liens qui actuellement ne sont pas regroupés du tout. Est-ce que je suis un peu plus clair ? Et maintenant, pour le point 4 : "span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir". Prenons quelques exemples, tu comprendras tout de suite. <span class="gras">Enseignons.be</span> <span class="gras">échange de ressources pédagogiques</span> <span class="gras">50 préparations</span> P.S.:<span class="gras">Enseignons.be étant à ses débuts, peu de préparations se trouvent à ce jour sur notre serveur. Nous vous demandons votre plus grande collaboration pour que rapidement des documents soient à disposition des autres utilisateurs, afin de pouvoir lancer le mouvement d'échange.</span> Dans les deux cas, tu utilises une classe "gras" pour simuler la balise <b> que tu as décidé de ne pas utiliser, fort probablement parce que tu as lu quelque part qu'elle ne véhiculait aucune valeur sémantique (et c'est vrai). En remplaçant ton <b> par un <span class="gras">, tu es tombé dans le même piège que tout le monde (je n'y ai pas échappé non plus il y a quelques années). Heureusement, c'est le genre de truc qu'on te dit une fois et plus jamais tu ne refais l'erreur par la suite. Si tu voulais conférer aux mots que tu soulignes une valeur supplémentaire d'emphase (et pas juste un effet visuel), tu devrais utiliser la balise <strong> qui est tout à fait indiquée pour cela. Dans ce cas-ci, c'est un abus de CSS et de span. En résumé, si tu veux juste faire du gras, sachant que la seule valeur sera visuelle, garde plutôt ce bon vieux <b> qui fait partie de la norme XHTML 1.0 strict de toute manière. Si tu veux aller un peu plus loin en terme de focus, utilise le <strong>. Dans le deuxième cas, pour l'exemple de ton paragraphe avec un P.S., tu utilises un <span> de trop. Tu aurais tout aussi bien pu écrire <p class="gras"> et t'éviter le recours à un <span>... parce que la sémantique, c'est aussi l'économie des balises. Ça peut se faire... ce serait très formateur pour tout le monde je crois. Pour commencer, je te propose de réfléchir sur le rôle que doit remplir chaque bout de code. En fonction de la réponse, tu auras déjà une meilleure idée du choix de balise HTML à utiliser pour tes pages. Revenons à ce fameux menu avec trois <span> pour réfléchir sur les menus en général. Qu'est-ce qu'un menu, sinon une série de liens, regroupées ensemble ? Pour que le sens de regroupement existe ailleurs que simplement viuellement, il faut les structurer pour qu'ils soient contenus dans un bloc, un conteneur. C'est pourquoi le <ul> peut être tout indiqué, puisqu'il regroupe un nombre illimité d'items (les <li>) de menu potentiel. Mais ce n'est pas la seule solution... d'un point de vue accessibilité, un <p> avec trois <a> à l'intérieur, séparés par des caractères délimitateurs adjacents comme le | pourraient aussi faire l'affaire, tout comme le ferait un <ol> ou même un <div>, traité comme un paragraphe (mais dans un tel cas, il faudrait que tu te questionnes sur la pertinence d'utiliser le <div> puisque le <p> serait tout indiqué). Fais cette réflexion avec chaque bouts de code utilisés et pose toi la question de la pertinence du code choisi... est-il le plus approprié pour le travail, en fonction de ce que tu connais de sa raison d'être ? J'arrête ici pour le moment, parce qu'on va finir par me crier de me la fermer !

Bonjour LadyARwen, bienvenue sur le Hub. Quel logiciel ? Flash ou Shockwave ? Pour ce qui est de développer des applications Flash qui soient accessibles, bien peu de gens savent faire... mais c'est néanmoins tout à fait possible depuis Flash MX et Flash Player 6. Il y a ce livre blanc écrit par Bob Regan qui pourrait peut-être t'aider : http://www.markme.com/accessibility/archives/005515.cfm

Arf, et comment. J'en suis venu à avoir la même sensibilité épidermique envers les intégrateurs HTML qui ne connaissent pas le W3C...

Bienvenue parmi nous, j'espère que tu t'y plairas et que nous saurons t'apporter tout plein de petits trucs pour ton site Web

Bien que j'ai tendance à toujours essayer de dissuader mes clients de recourir à ce type de pratiques pour plutôt préconiser une solide réflexion sur l'architecture des contenus, je dois dire que je suis plus ou moins d'accord avec un tel nivellement par le bas. Oui, ces menus peuvent présentés un certain nombre de problèmes pour un certain nombre d'utilisateurs très marginalisés, mais ils ne sont pas impossibles à utiliser pour autant par ceux-ci... tant et aussi longtemps qu'ils sont construits intelligemment, avec une structure HTML irréprochable, sémantique et bien sûr, sans javascript.

C'est incroyable tout de même le pouvoir de Microsoft... même quand on ne s'occupe pas d'eux, ils parviennent à nous faire faire du mauvais sang quand même... Et dire que nous n'avons pas la moindre idée de ce qu'ils nous réservent... ah, les joies de l'espionnage industriel ; si seulement....

Euh... c'est moi qui en ai manqué beaucoup plus que je ne le croyais dans les derniers mois, ou on savait déjà depuis près de deux années qu'il n'y aurait pas d'IE 7, et aucune nouvelle mouture du navigateur de Microsoft avant Longhorn ? Il me semble qu'il n'y a là absolument rien de nouveau.

Parce qu'après une si idyllique relation, Google nous laisserait tomber comme une vieille chaussette pour une petite jeunesse, une nouvelle mode ?

Cette information me semble éronnée. S'ill est vrai qu'il n'est pas nécessaire de spécifier le prologue XML parce que certains navigateurs sont imcapables de le supporter (lire MSIE entre autres), le spécifier n'est pas un mal, pas plus que de déterminer le charset de l'information à faire afficher. Non, ce n'est pas grave, c'est une façon alternative d'accéder aux contenus, mais ce n'est pas la seule. Les accesskeys soulèvent de nombreuses controverses parce que leur utilisation N'est pas standardisée. Tu trouveras toute l'information souhaitée à ce sujet dans un article de Laurent Denis, paru sur OpenWeb : http://openweb.eu.org/articles/accesskey_e...non_transforme/ L'attrribut title est bien sûr conforme aux diverses normes (x)HTML. Tu peux donc en abuser en toute confiance. L'important c'est de ne pas tomber dans l'excès inutile, comme pour faire dire à la valeur du title le même type d'information que le lien porte lui-même. Oui bien sûr, mais pour bien comprendre ce dont je parle, il faudrait d'abord que tu lises ce petit texte qui te dresseras un portrait initial : http://openweb.eu.org/articles/respecter_semantique/ Grosso modo, la sémantique HTML, c'est tout d'abord de pratiquer une économie des balises HTML que tu utilises, tout en réfléchissant auxquelles sont les plus appropriées pour remplir un rôle précis. L'exemple clasique, ce serait d'utiliser une liste à puces pour faire un menu, plutôt que d'utiliser un paragraphe avec des br par exemple. Dans le cas de ton propre site, nous pourrions justement réfléchir sur l'intérêt des : 1. fameux trois items de menus en span qui causent un problème d'accessibilité ; 2. span utilisés comme des éléments de block alors que le div sert justement à cela ; 3. br pour créer de l'espace entre deux paragraphes ; 4. span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir. 5. Etc. L'imbrication de divs n'est pas gênante, tant et aussi longtemps que chacun de ces div peut être justifié. Mais comme cette question nous ramène aux textes que je t'ai proposé plus haut, je te laisse tout d'abord les lire.

Le plus curieux en ce qui me concerne, c'est que je n'ai jamais eu autant de visites sur mon site que depuis quelques mois... # 6614 pages lues en 24h # 231638 pages lues en 30 jours # 1245033 pages lues en 6 mois Jamais mes statistiques de fréquentation n'ont été aussi fortes. Et mon PR descendrait ? je n'y comprends vraiment rien.

Qui ? Nous ? Jamais voyons !

Merci Ernestine Dans le même ordre d'idées, une "claque", openweb-style http://openweb.eu.org/humeurs/calques_perdent/ Nizouille, je reviendrai sous peu pour pousser plus de l'avant mes réponses à tes questions. Là, il est l'heure d'aller coucher les enfants.

Surtout quand tu n'as plus à le supporter depuis des années. Mais tout le monde n'a pas ma chance.