Denis

Mais noooooon, pas du tout. Effectivement, "art" est beaucoup plus approprié que "science". C'est d'ailleurs ce que j'avais en tête, mais mes coquins doigts m'ont trahis.

La réponse la plus éloquente (bien qu'assez peu constructive par elle-même) à une question comme celle-là, c'est certainement de rediriger vers le jardin zen... rien qu'à voir, on voit bien que les CSS peuvent faire tout ce que le vieux HTML sauvage peut faire, et tellement plus encore. Personne ne peut nier la créativité que l'on y observe. Malgré la pertinence des liens proposés par Monique, il faut reconnaître que c'est quand même pas mal à avaler d'un coup. Si tu n'utilises pas du tout les CSS, il faut commencer progressivement, ne serait-ce que par les éléments de CCS-1 uniquement comme travailler les couleurs et les fontes. Essayer de passer directement d'un paradigme à l'autre, c'est certainement d'être condamné à l'échec avant même d'avoir eu la chance de réussir.

Hey là, on me cite hors contexte... ça faisait un moment que ça ne m'étais pas arrivé! Faut lire! Tout ce que je dis, c'est que pour deux sites absolument semblables avec les mêmes efforts de référencement et les mêmes ratios de pertinence de contenus le site conforme et accessible sera forcément mieux indexé... pas que les normes sont la panacée du SEO.

Ce qui laisse à penser que la solution serait de réinstaller FF (s'il n'est plus sur l'ordinateur), de désinstaller la ou les extensions les plus récentes, de désinstaller FF et de le réinstaller à nouveau?

Qu'est-ce qui s'est passé exactement entre ces 7 heures? Un reboot seulement?

Loin de moi l'intention de nourrir un troll vraisemblablement très affamé, mais on ne devrait pas se méfier d'un mec qui se vante d'hacker ses trucs? ok, j'ai compris ----> []

C'est vrai que le métier de référenceur a mauvaise presse, compte tenu évidemment du caractère incertain des résultats. Cependant, comme tu le dis si bien, on retrouve ce genre d'amateurisme partout (vous me permettrez, compte tenu du type de prestations que j'offre, de me retenir de pointer quoi ou qui que ce soit). C'est bien de le rappeler car moi le premier (non, pas la tête!), avant d'arriver ici, je tenais la profession de référenceur en bien piètre estime... mauvaises expériences obligeant. Sauf qu'après avoir discuté avec plusieurs personnes ici, je me suis rendu compte que si j'avais croisé dans ma vie quelques opportunistes, il y avait réellement un fondement derrière la pratique, alimenté de réflexions et d'expériences très concrètes. Et depuis, je ne peux que reconnaître l'évidence... le référencement, c'est une "science" comme le sont l'accessibilité, les normes, l'ergonomie, l'utilisabilité et tout le reste.

C'est pas beau la vie? Bonne chance!

Ouais tu sais, c'est pas facile... Bien dit. Je crois qu'il faille simplement retenir que pour deux sites auxquels les mêmes efforts ou stratégies de référencement sont prodigués, celui qui est conforme jouiera d'un avantage supplémentaire devant le Grand Google. L'analogie est excellente. Je la retiendrai!

Et si on convenait tout simplement qu'une bonne dose de plusieurs éléments est ce qu'il y a de mieux pour faire plaisir au grand Google? Non, non, je suis sérieux. Certainement, on ne peut pas se fier uniquement à la pertinence des termes utilisés dans le nom de domaine, mais il faut tout de même admettre qu'à la lumière de l'exemple de "mariage" cela pourrait avoir une certaine incidence. Chose certaine, je demeure convaincu que cela ne peut pas nuire. Je suis d'avis que si c'est possible et que ça apporte quelque chose de concret et de constructif, tout en simplifiant les efforts de l'utilisateur, alors oui, opter pour un nom de domaine contenant un terme clé est souhaitable. Mais si pour ce faire, il faut se résoudre à un nom de domaine qui implique utiliser les deux côtés d'une carte d'affaire pour l'inscrire et une séance d'hypnotisme pour le retenir, alors non, bien évidemment. Quoi qu'il en soit, ça prend beaucoup plus qu'un nom de domaine pour rafler les premières places!

Effectivement, c'est vraiment très intéressant. Beaucoup de matière à réflexion. Merci beaucoup!

Par la qualité même du code HTML produit par la solution, j'aurais tendance à penser que l'indexation naturelle d'un forum comme PunBB devrait être assez intéressante.

Je suis loin d'être un expert des CMS, mais j'ai entendu le plus grand bien des solutions Plone et Drupal, toutes deux plutôt comformes aux normes et accessibles sans trop d'efforts. http://plone.org/countries/fr http://drupal.org/ Avec une légère préférence pour le second. J'ai aussi entendu beaucoup de bien de Xoops.

C'est clair, il est important de s'assurer d'être le grand décideur à propos des informations qui concernent ton nom de domaine. Je ne peux que souligner l'importance de tout d'abord faire affaire avec un régistraire pour acheter ton nom de domaine et ensuite de contacter un hébergeur, quel qu'il soit, pour ouvrir avec eux un compte concernant uniquement l'hébergement. Si un hébergeur essaie de mêler les deux, alors je ne pourrais que te conseiller de fuir au plus vite, indépendamment des coûts. Rapelle-toi que quand ce n'est pas assez cher, c'est probablement que c'est louche!

Ce n'est pas par manque d'intérêt mais bien par manque de temps, rassure-toi! Je n'ose plus dire que je reviens pour de bon, mais c'est dans mes résolutions de 2006 d'essayer d'être plus présent.

Bon, je ne veux pas forcément prêcher pour ma paroisse, mais je crois que ce lien s'impose ici pour vanter les mérites de reléguer l'utilisation des tableaux HTML pour structurer des données tabulaires uniquement et non des mises en page complètes.

Merci Monique d'avoir ramené l'info sur la liste de discussion de W3Québec, ça m'avait complètement échappé (autant la traduction que la version anglaise, c'est tout dire)! Je suis aussi impressionné par toutes les nouveautés qui accompagnent la v1.0 de la toolbar. Vraiment, on assiste ici à une vraie première version stable, bien mature et bien efficace.

Je suis d'accord avec Le-Juge et Sibelius, bien qu'ils aient des avis en partie opposés sur la question. Ce qui est intéressant, c'est qu'ils ont tous les deux raison quelque part. Sibelius avance que l'on peut utiliser plus d'un h1 dans une page et selon la spécification HTML, il a tout à fait raison. H1 est le premier titre d'une hiérarchie de titres et de sous-titres dans une page. En ce sens, il peut effectivement avoir plus d'une section dans une page et par extension, plus d'un H1. Ça tombe sous le sens. Pour sa part, Le-juge affirme qu'on ne devrait en utiliser qu'un seul, malgré ce qu'en dit la recommandation. Je suis d'accord avec lui, non pas dans une perspective de conformité avec la norme, mais bien de bonne pratique envers certains utilisateurs car en limitant chaque page à un seul grand titre (le h1), on permet aux utilisateurs de synthèses vocales de structurer plus facilement les pages qui leur sont lues. Passé cette considération, ce n'est qu'une question de philosophie : soit on estime que le h1 représente l'idée générale de l'ensemble de la page (en quel cas il est utilisé en support complémentaire à l'élément title), soit qu'on estime qu'il représente l'idée générale de la section d'une pagecontenant plusieurs idées (en quel cas il est forcément beaucoup moins en relation avec le title). Comme la magie des CSS permet de toute manière de donner aux hx le look qu'on souhaite utiliser, un h1 ou un h2 pour structurer le premier élément de chaque sous-sections d'une page revient au même, dans la mesure où justement, cette hiérarchisation est cohérente du début à la fin. Soit on considère notre premier élément de chaque section comme un h1, soit comme un h2. Le résultat sera le même au niveau de la structure si le tout est bien fait, mais sera aussi mauvais dans un cas comme dans l'autre si c'est fait maladroitement. Ce qu'il faut retenir principalement je crois, c'est que la norme HTML à cet égard nous permet d'utiliser plus d'un h1 si on en a envie, mais que les règles d'accessibilité proposent implicitement l'utilisation d'un seul h1, dans l'optique de favoriser l'appropriation des contenus par l'ensemble le plus élargi possible de publics. À chacun de trancher en fonction de ses convictions donc.

Il n'y a pas de solutions magiques... il faut viser le plus haut niveau d'excellence possible, en sachant très bien qu'il y aura toujours un cas de figure qui posera quand même problème dans une situation ou dans une autre. Je dirais comme Monique, autant que possible, viser la complémentarité entre le contenu des deux attributs. Et finalement, ne pas oublier le longdesc qui pointera vers un fichier de description externe, lorsque ça devient trop long dans le title.

Pas bête du tout !

Si vous me le permettez, revenons un peu à l'essence de la question initiale... Ce sera effectivement conforme si ton utilisation de l'élément <a> est à la base syntaxiquement correcte. Conforme, mais pas bonne d'un point de vue utilisabilité. L'accessibilité, en soit, n'a rien à voir avec cette déviation d'une pratique. Point de vue utilisabilité, créer un lien qui ne sert à rien ou qui n'a aucun effet ne risque, à terme, que de laisser à penser qu'il y a une erreur de conception sur la page. Not good. Dans un tel cas, il faut ajouter que par défaut, un synthétiseur vocal comme Jaws NE LIT PAS l'attribut title. On ne peut donc pas se fier à ce dernier si on souhaite appliquer une solution accessible car un lien vide sans attribut title ne dirait pas grand chose à l'utilisateur. De plus, si l'utilisateur est le moindrement impatient, sa souris aura quitté le lien avant que l'info-bulle n'apparaisse. Mauvais dans ce cas là aussi, considérant que si justement rien ne se passe, la patience de notre internaute sera déjà mise à l'épreuve. Je répondrai comme je ne sais plus qui, il faudrait mettre le lien sur une image, avec un beau petit alt sur l'image et un title complémentaire sur le lien. Tout le monde y gagne, et si c'est fait proprement ce sera à la fois conforme et accessible. À la rigueur tu pourrais carrément faire sauter l'élément <a> et te contenter d'un title sur une image de point d'interrogation par exemple. Si ça ne mène nulle part, détourner l'élément <a> sera conforme, mais ni sémantique, ni correct. Quant à l'attribut abbr, s'il ne s'agit pas d'une abbréviation, cela me semble complètement sans intérêt. Ceci dit dans un cas comme dans l'autre, pour rendre l'attribut title visible sur la tabulation, il faudrait utiliser l'événement onfocus il me semble. Mais dans un tel cas, ça prendrait un lien et on retombe dans le détournement de la raison d'être initiale de l'élément <a>. C'est donc à mon avis à éviter. Pourquoi ne pas faire une image avec une instance en mouseover/onfocus avec du texte qui apparaît dans la deuxième instance, et avoir ce texte là sur le alt ? Il me semble que ça règlerait tous les problèmes, surtout si on prend la peine de mettre une page explicative au bout de l'hyperlien...

Je ne suis personne pour émettre un tel commentaire, mais personnellement, je commence à trouver Opéra plus intéressant que Firefox, notamment pour tous les éléments d'accessibiltié. Alors, d'un ppoint de vue utilisateur, dans l'ordre depuis mon passage à Mac OS, je dirais : 1. Opéra 2. Firefox 3. Safari Et j'ai le bonheur de ne plus avoir à supporter MSIE sur ma machine. Évidemment d'un point de vue développeur on inverse Opera et Firefox car tout développeur sérieux ne peut vivre sans la Web Developer toolbar.

Ça l'aurait bien fait par contre!

Faudrait pas démoniser javascript non plus... après tout, c'est facile de mettre le blâme sur la technologie. Si le javascript est utilisé de la bonne manière (c'est-à-dire de manière à assurer l'accessibilité des contenus), il ne devrait pas y avoir de problèmes car ton site offrira alors toujours de liens texte en complément des pseudo-liens créés par javascript. J'ignore complètement quel est le support de javascript dans les crawlers de Google, mais comme Yahoo indexe tout manuellement et humainement, il y a fort à parier que de tels problèmes ne se posent pas pour lui (et par association, à tous ces autres moteurs qui se basent sur ses registres pour afficher des résultats de recherche comme AlltheWeb, AltaVsita et plusieurs uatres). Après tout, on peut supposer que tous ceux qui travaillent à remplir les listes de Yahoo se servent de navigateurs récents, donc supportant pleinement JS. Si effectivement, malgré des liens textes, tu ne passes toujours pas dans les crawlers de Google, alors c'est clair qu'il y a autre chose qui cloche... et encore une fois, inutile de démoniser javascript avant d'avoir fait le tour du code... ou même ton outil actuel de développement. Au fait, quel est-il ? Pour ce qui est de DreamWeaver, comme tout outil qui génère automatiquement le code à ta place, tu risques de retomber dans les mêmes problèmes à moyen ou long terme, c'est-à-dire que tu finiras par trouver que ton site indexe mal et tu ne seras pas plus à même d'identifier pourquoi. Je suggèrerais donc, le plus humblement du monde et uniquement si tu en as les capacités, de plutôt chercher à comprendre les causes de ton insuccès et t'attacher à corriger les problèmes à la main.

Et c'est pour ça que le bouton précédent existe, non ? Qu'est-ce qu'ils ont les gens a toujours vouloir garder l'utilisateur captif sur leur site ? Si les contenus intéressent les gens, ils reviendront d'eux mêmes...