Actuellement en pleine étude benchmark pour trouver le bon CMS pour mon entreprise, j'aurais voulu avoir votre avis sur le produit NextCMS . Notre site doit être accessible à tous et répondre aux normes WAI. Il semblerait que ce gestionnaire de contenu réponde à ces exigences, qu'en pensez-vous? Connaissez-vous d'autres outils de ce genre?
1178 sujets
Accessibilité du Web
Bonjour et bienvenue bernard.s 
Difficile de répondre sans voir un site en ligne... Beaucoup de prestataires tentent de profiter de "l'accessibilité" pour vendre des trucs impensables... Mais rien ne prouve que ce soit le cas ici
Il y a des cms libres et gratuits qui permettent d'atteindre l'accessibilité, il doit déjà y avoir des commentaires sur ce sujet sur le forum et aussi sur le blog. Si tu ne trouves pas, préviens-nous
Peux-tu me donner par mp quelques liens vers des sites réalisés avec le cms dont tu parles ?
Difficile de répondre sans voir un site en ligne... Beaucoup de prestataires tentent de profiter de "l'accessibilité" pour vendre des trucs impensables... Mais rien ne prouve que ce soit le cas ici
Il y a des cms libres et gratuits qui permettent d'atteindre l'accessibilité, il doit déjà y avoir des commentaires sur ce sujet sur le forum et aussi sur le blog. Si tu ne trouves pas, préviens-nous
Peux-tu me donner par mp quelques liens vers des sites réalisés avec le cms dont tu parles ?
Je suis allé visiter les 3 adresses que tu m'as données par mp
Je n'ai pas visité les sites complets, mais au hasard d'une page, j'ai lancé la validation de la page en cours via l'outil du W3C et la page était valide sur chaque site... C'est déjà un plus
J'ai un peu fouillé le code, un survol et ça semble codé proprement, il ne semble pas y avoir d'abus de div, encore un plus
Aucun des sites présentés ne peut être considéré comme accessible, parce qu'ils ne répondent pas aux critères d'accessibilité... Ca ne veut pas dire qu'il ne sont pas capable de faire un site accessible.
Comme en plus, ils présentent, avec de bons arguments les standards du web et l'accessibilité, je serais tenté de leur faire confiance... Toutefois, avant de passer commande, je leur demanderais des adresses de sites accessibles afin d'en vérifier les éléments d'accessibilité mis en place.
Le prix de base n'est pas très élevé, toutefois, je suppose qu'il faudra prévoir, si vous souhaitez personnaliser graphiquement le site un budget beaucoup plus conséquent pour la mise en place de graphismes et charte graphique
Heuuuuuuuu ! un truc à vérifier, comme les sites visité ne peuvent pas être considérés comme accessibles, il est possible que l'accessibilité fasse l'objet d'une facturation complmentaire.
Le choix d'un outil de publication sur le web ne s'arrête pas aux seuls critères de validité du code et à l'accessibilité, il faut que le cms réponde au plus près possible au cahier des charges que vous avez établi au préalable... A quoi servirait un outil valide sur lequel vous ne pourrez pas publier ?
Quand aux cms libres et gratuits, il en existe certainement qui répondent à tous ces critères, mais avez-vous, en interne, un développeur web qui pourra le mettre en service, le maintenir et le rendre accessible ?
Je n'ai pas visité les sites complets, mais au hasard d'une page, j'ai lancé la validation de la page en cours via l'outil du W3C et la page était valide sur chaque site... C'est déjà un plus
J'ai un peu fouillé le code, un survol et ça semble codé proprement, il ne semble pas y avoir d'abus de div, encore un plus
Aucun des sites présentés ne peut être considéré comme accessible, parce qu'ils ne répondent pas aux critères d'accessibilité... Ca ne veut pas dire qu'il ne sont pas capable de faire un site accessible.
Comme en plus, ils présentent, avec de bons arguments les standards du web et l'accessibilité, je serais tenté de leur faire confiance... Toutefois, avant de passer commande, je leur demanderais des adresses de sites accessibles afin d'en vérifier les éléments d'accessibilité mis en place.
Le prix de base n'est pas très élevé, toutefois, je suppose qu'il faudra prévoir, si vous souhaitez personnaliser graphiquement le site un budget beaucoup plus conséquent pour la mise en place de graphismes et charte graphique
Heuuuuuuuu ! un truc à vérifier, comme les sites visité ne peuvent pas être considérés comme accessibles, il est possible que l'accessibilité fasse l'objet d'une facturation complmentaire.
Le choix d'un outil de publication sur le web ne s'arrête pas aux seuls critères de validité du code et à l'accessibilité, il faut que le cms réponde au plus près possible au cahier des charges que vous avez établi au préalable... A quoi servirait un outil valide sur lequel vous ne pourrez pas publier ?
Quand aux cms libres et gratuits, il en existe certainement qui répondent à tous ces critères, mais avez-vous, en interne, un développeur web qui pourra le mettre en service, le maintenir et le rendre accessible ?
Bonjour,
Je serais plus circonspect que dominique au sujet de ce CMS.
Certes ils ont une jolie page sur l'accessibilité, en revanche on trouve sur leur site et sur les sites des références quelques énormités :
Des balises h2 cachées utilisées à la seule fin de spammer les moteurs de recherche, ce qui est particulièrement grave.
Une structure de titre plus que problématique ce qui montre à tout le moins un manque de compréhension du sujet.
Une magnifique image qui contient profusion de texte.
Beaucoup de conteners vides, innapropriés, ou des retour chariots utilisés pour caler le design.
Une structure de tabulation illogique...
Un manque d'alternative textuelle quand il le faut et d'autres inutiles ou innapropriées.
L'ensemble fait quand-même un chouia "néophyte", plein de bonne volonté mais très loin des ambitions qu'ils affichent.
Du coup mon conseil serait la prudence, à tout le moins leur demander de te montrer un site réellement accessible et/ou de recourir à un spécialiste pour contrôler leur travail.
Pour le moment si l'on doit se prononcer, aucun des sites fait avec ce CMS n'offre le minimum requis.
Jean-pierre
Je serais plus circonspect que dominique au sujet de ce CMS.
Certes ils ont une jolie page sur l'accessibilité, en revanche on trouve sur leur site et sur les sites des références quelques énormités :
Des balises h2 cachées utilisées à la seule fin de spammer les moteurs de recherche, ce qui est particulièrement grave.
Une structure de titre plus que problématique ce qui montre à tout le moins un manque de compréhension du sujet.
Une magnifique image qui contient profusion de texte.
Beaucoup de conteners vides, innapropriés, ou des retour chariots utilisés pour caler le design.
Une structure de tabulation illogique...
Un manque d'alternative textuelle quand il le faut et d'autres inutiles ou innapropriées.
L'ensemble fait quand-même un chouia "néophyte", plein de bonne volonté mais très loin des ambitions qu'ils affichent.
Du coup mon conseil serait la prudence, à tout le moins leur demander de te montrer un site réellement accessible et/ou de recourir à un spécialiste pour contrôler leur travail.
Pour le moment si l'on doit se prononcer, aucun des sites fait avec ce CMS n'offre le minimum requis.
Jean-pierre
Bonjour
En effet, Jean-Pierre, on se rejoint au moins sur le fait qu'aucun des sites présentés n'est accessible ainsi que sur la demande de voir des sites réellement accessibles.
Pour ce qui pourrait différencier nos opinions, je pense qu'il faut prendre en compte les impératifs des clients, qui, apparemment n'étaient pas intéressés par l'accessibilité.
D'autres parts, compte tenu de ce qu'on voit aujourd'hui de prétendu propre et accessible et vendu (très cher) comme tel, par rapport à ce qui est proposé ici, je suis pour encourager ces personnes plutôt que de les casser.
La démarche et l'esprit semblent être bien présents, le code est valide même s'il n'est pas parfait... Et la perfection n'est pas de ce monde. Essayons de ne pas trop nous montrer extrèmiste, ça ne ferait que nuire aux démarches pour rendre les sites accessibles, tout en restant, bien sûr prudent sur les avis qu'on peut donner.
D'ailleurs, si un membre de cette équipe de développeurs passe par ici et désire discuter avec nous, il sera le bienvenu.
Modifié par dominique (16 Mar 2006 - 09:44)
En effet, Jean-Pierre, on se rejoint au moins sur le fait qu'aucun des sites présentés n'est accessible ainsi que sur la demande de voir des sites réellement accessibles.
Pour ce qui pourrait différencier nos opinions, je pense qu'il faut prendre en compte les impératifs des clients, qui, apparemment n'étaient pas intéressés par l'accessibilité.
D'autres parts, compte tenu de ce qu'on voit aujourd'hui de prétendu propre et accessible et vendu (très cher) comme tel, par rapport à ce qui est proposé ici, je suis pour encourager ces personnes plutôt que de les casser.
La démarche et l'esprit semblent être bien présents, le code est valide même s'il n'est pas parfait... Et la perfection n'est pas de ce monde. Essayons de ne pas trop nous montrer extrèmiste, ça ne ferait que nuire aux démarches pour rendre les sites accessibles, tout en restant, bien sûr prudent sur les avis qu'on peut donner.
D'ailleurs, si un membre de cette équipe de développeurs passe par ici et désire discuter avec nous, il sera le bienvenu.
Modifié par dominique (16 Mar 2006 - 09:44)
bernard.s a écrit :
Nous n'aurons pas de développeur web au sein de notre équipe, il faut donc que ce soit un outil très facile à prendre en main!!!!
Salut,
En fait, ce que veut dire Dominique, à juste titre, c'est que l'outil est bien loin d'être suffisant, l'accessibilité d'un site web dépend de plusieurs niveaux d'implications :
- le développeur, et/ou l'outil qui produit le code du document (validité et rigueur, respect des normes)
- le designer (contrastes, tailles des caractères, des boutons, etc.)
- le responsable des contenus (compréhensibilité du texte, pertinence des liens (pas de "cliquez ici"), pertinence des textes alternatifs, etc.)
En bref, l'outil (le CMS) n'est qu'une étape dans tout un processus. La personne qui va se charger d'introduire le contenu a une importance aussi grande que l'outil choisi, et elle doit être formée afin de ne pas "ruiner" le travail fourni par l'outil.
Bonjour,
Nous sommes d'accord et je ne me classe pas, loin de là, dans la catégorie des extrémistes.
En revanche, je ne peux que relever le "flou artistique" sur leur présentation où un néophyte ne peut que comprendre que ce CMS produit un résultat accessible "par défaut" ce qui n'est pas vrai, loin de là.
Le relevé que je faisais des "erreurs" n'était destiné qu'à démontrer ce point.
Ceci étant, je ne doute pas de leur bonne volonté, même si l'utilistion d'une balise de titre pour spammer un robot de recherche me laisse une drôle de sensation...
Comme un autre détail sur la page dédié à l'accessibilité : là comme ailleurs sur leur site on entretient un flou artistique entre la normalisation des langages et l'accessibilité qui sont des choses très différentes.
La proximité entre "Normes W3C et sites accessibles à tous" et la petite animation flash, totalement innacessible elle, destiné à tester la validité xhtml est plus que spécieuse.
Si je n'y connais rien, je lis, je teste et je comprends que ce site est accessible... non ?
Bévue de débutant ?, irruption de considérations marketing bien comprises ? le mystère demeure.
En tout cas il n'est jamais fait mention nul part des excellentes remarques de Raphael sans lesquelles CMS accessible ne veut rien dire, mais tu à raison ils débutent vraisemblement dans ce domaine et il faut leur laisser le temps d'apprendre.
D'où ma moue un peut pincé et mon conseil à Bernard....
Jean pierre
a écrit :
Essayons de ne pas trop nous montrer extrèmiste, ça ne ferait que nuire aux démarches pour rendre les sites accessibles
Nous sommes d'accord et je ne me classe pas, loin de là, dans la catégorie des extrémistes.
En revanche, je ne peux que relever le "flou artistique" sur leur présentation où un néophyte ne peut que comprendre que ce CMS produit un résultat accessible "par défaut" ce qui n'est pas vrai, loin de là.
Le relevé que je faisais des "erreurs" n'était destiné qu'à démontrer ce point.
Ceci étant, je ne doute pas de leur bonne volonté, même si l'utilistion d'une balise de titre pour spammer un robot de recherche me laisse une drôle de sensation...
Comme un autre détail sur la page dédié à l'accessibilité : là comme ailleurs sur leur site on entretient un flou artistique entre la normalisation des langages et l'accessibilité qui sont des choses très différentes.
La proximité entre "Normes W3C et sites accessibles à tous" et la petite animation flash, totalement innacessible elle, destiné à tester la validité xhtml est plus que spécieuse.
Si je n'y connais rien, je lis, je teste et je comprends que ce site est accessible... non ?
Bévue de débutant ?, irruption de considérations marketing bien comprises ? le mystère demeure.
En tout cas il n'est jamais fait mention nul part des excellentes remarques de Raphael sans lesquelles CMS accessible ne veut rien dire, mais tu à raison ils débutent vraisemblement dans ce domaine et il faut leur laisser le temps d'apprendre.
D'où ma moue un peut pincé et mon conseil à Bernard....
Jean pierre
Merci à tous pour vos remarques, j'en prend note et je vais entrer en contact avec la société pour tester l'outil!
Jean-Pierre, pourrais-tu m'apporter quelques précisions sur quelques remarques tu as faites précedemment:
Je ne comprends pas très bien ce que tu as voulu dire par là. Pourrais-tu préciser stp!
Merci
Jean-Pierre, pourrais-tu m'apporter quelques précisions sur quelques remarques tu as faites précedemment:
jpv a écrit :
Une structure de titre plus que problématique ce qui montre à tout le moins un manque de compréhension du sujet
Une structure de tabulation illogique...
Je ne comprends pas très bien ce que tu as voulu dire par là. Pourrais-tu préciser stp!
Merci
Bonjour à tous,
je me présente, Julien, en charge du développement de NextCMS chez Nextweb.
vos remarques sur notre produit sont pertinentes, je vais essayer d'y repondre, en plusieurs posts, car c'est long
je ne sais pas quels sites ont été cités en exemple, mais effectivement, les sites produits à ce jour n'ont pas d'éxigences fermes en terme d'accessibilité, les clients n'ayant pas souhaité pousser la logique jusqu'au bout pour le moment.
Le site de l'agence et le site dédié NextCMS ne sont pas non plus poussés à fond, nous préférons nous concentrer sur les réalisations clients à ce stade.
en effet, le prix est celui facturé pour l'acquisition de l'outil. La création du site lui-même ( charte graphique, gabarits pages web et emailing, production Flash, ...) sont en supplément.
La validation de la conformité par un label d'accessibilité type accessiweb est également payant, puisque que ce n'est pas Nextweb qui effectue la prestation.
Pour arriver aux objectifs satisfaisant le niveau d'accessibilité souhaité, un surcoût est en général calculé en fonction de la masse de travail à effectuer, étant donné que le fait de rendre un site accessible dépasse de très très loin le cadre des CMS, donc bien entendu de NextCMS.
tout à fait, l'accessibilité n'est pas le seul facteur à prendre en compte. De notre coté, nous avons voulu proposer un outil simple à utiliser, rapide et efficace. L'exemple le plus parlant est l'upload de documents par drag&drop dont on peut voir l'illustration ici : http://www.nextcms.fr/fr/demonstration/bibiotheque-medias/
Modifié par nextweb (17 Mar 2006 - 20:44)
je me présente, Julien, en charge du développement de NextCMS chez Nextweb.
vos remarques sur notre produit sont pertinentes, je vais essayer d'y repondre, en plusieurs posts, car c'est long
dominique a écrit :
Aucun des sites présentés ne peut être considéré comme accessible, parce qu'ils ne répondent pas aux critères d'accessibilité... Ca ne veut pas dire qu'il ne sont pas capable de faire un site accessible.
je ne sais pas quels sites ont été cités en exemple, mais effectivement, les sites produits à ce jour n'ont pas d'éxigences fermes en terme d'accessibilité, les clients n'ayant pas souhaité pousser la logique jusqu'au bout pour le moment.
Le site de l'agence et le site dédié NextCMS ne sont pas non plus poussés à fond, nous préférons nous concentrer sur les réalisations clients à ce stade.
dominique a écrit :
Le prix de base n'est pas très élevé, toutefois, je suppose qu'il faudra prévoir, si vous souhaitez personnaliser graphiquement le site un budget beaucoup plus conséquent pour la mise en place de graphismes et charte graphique
en effet, le prix est celui facturé pour l'acquisition de l'outil. La création du site lui-même ( charte graphique, gabarits pages web et emailing, production Flash, ...) sont en supplément.
dominique a écrit :
Heuuuuuuuu ! un truc à vérifier, comme les sites visité ne peuvent pas être considérés comme accessibles, il est possible que l'accessibilité fasse l'objet d'une facturation complmentaire.
La validation de la conformité par un label d'accessibilité type accessiweb est également payant, puisque que ce n'est pas Nextweb qui effectue la prestation.
Pour arriver aux objectifs satisfaisant le niveau d'accessibilité souhaité, un surcoût est en général calculé en fonction de la masse de travail à effectuer, étant donné que le fait de rendre un site accessible dépasse de très très loin le cadre des CMS, donc bien entendu de NextCMS.
dominique a écrit :
Le choix d'un outil de publication sur le web ne s'arrête pas aux seuls critères de validité du code et à l'accessibilité, il faut que le cms réponde au plus près possible au cahier des charges que vous avez établi au préalable... A quoi servirait un outil valide sur lequel vous ne pourrez pas publier ?
tout à fait, l'accessibilité n'est pas le seul facteur à prendre en compte. De notre coté, nous avons voulu proposer un outil simple à utiliser, rapide et efficace. L'exemple le plus parlant est l'upload de documents par drag&drop dont on peut voir l'illustration ici : http://www.nextcms.fr/fr/demonstration/bibiotheque-medias/
Modifié par nextweb (17 Mar 2006 - 20:44)
suite de mon précédent post
Ayant été moi-même assez opposé à cette idée au départ, j'ai du me rendre compte d'une vérité : pour nos clients, majoritairement B2B, le référencement est primordial.
Petit exemple des "méthodes référencement" de certains concurrents que je ne citerai pas :
- utiliser la balise <noscript></noscript> pour masquer des listes de mots clés : un utilisateur qui navigue sans javascript verra cette liste s'afficher, ce qui est bien gênant quand même. Je pense que notre solution est plus correcte, étant donné qu'il s'agit bien de vrai contenu dans le corps de la page, avec de la sémantique possible (j'y reviens juste après...)
- ajouter, en bas de chaque page, un bloc "mots clés associés à cette page" contenant une 30aine de liens avec les mots et expressions qui vont bien, pointant vers une autre page du site : ca ne me semble pas très fin, et celà peut gener même le visiteur lambda qui n'a rien à faire de cette liste.
aucune de ces 2 méthodes n'est bonne, je pense qu'on est d'accord là-dessus. La notre n'est pas, en terme d'accessibilité, réellement meilleure, je l'avoue.
mais il y a des moments où il faut savoir trouver des compromis, puisque que c'est plus que rageant de perdre un marché car le prospect s'est laissé dire "oui, Monsieur, nous on a du référencement "caché" dans une superbalise ultra techno dernier cri; je traduis, la <noscript> qui va vous permettre de bien grimper dans les moteurs. Nextweb avec NextCMS ne vous propose pas cette formidable option, venez donc chez nous !" (c'est du vécu).
Pour en finir avec notre solution à cet épineux dilemme, je voudrais préciser que notre outil permet de rédiger du vrai texte, avec du balisage sémantique XHTML et tout et tout, et ne se limite pas à une série de mots clés dans un <h2>, même si c'est le réglage pas défaut de la solution. Il appartient à chacun ensuite d'assumer le contenu (spam ou pas) de cet "article invisible". De plus, je n'ai pas vérifié jusqu'au bout, mais en tout cas à l'écran, au print et pour PDA, il est possible de masquer ce contenu via les CSS. je suppose que pour un navigateur vocal ou plage braille cela fonctionne de la même façon. Le contenu de cet article invisible ne me semble donc aujourd'hui plus nuisible au site, ou du moins les inconvénients qu'il représente sont largement effacés par les bénéfices que tirent nos clients au niveau de leur référencement.
Un dernier mot : les clients actuels font principalement du B2B, avec forte concurrence sur leur marché.
nous sommes actuellement sur des projets de sites publics, où cette fonctionnalité de NextCMS ne sera a priori pas utilisée (sauf si le client le décide malgré nos recommandations, c'est bien son droit après tout) car le but du site n'est pas du tout le même.
je ne suis pas persuadé de comprendre la remarque, tout comme bernard.s qui a initié ce sujet.
je peux néanmoins apporter quelques précisions :
la page comporte 1 titre principal en <h1>
les sections (menu de navigation, zone actualités, zone de bas de page, ...) sont identifiées par des <h2>
le titre des éléments de contenu (articles, actus, formulaires, affichage de rss) sont des <h3>, puisqu'ils sont situés dans des sections <h2>
pour les coprs de texte, l'utilisateur de NextCMS a à sa disposition les <h4>,<h5> et <h6>, vu que le corps du texte appartient à un élément, repéré donc par un titre <h3>
celà me semble assez logique, mais j'ai peut-être loupé quelque chose, ou mal compris la remarque. Peux-tu stp m'en dire plus ?
ah, ces graphistes !
plus sérieusement, oui, je confesse que ce n'est pas le top, mais comme pour le référencement, il faut pouvoir faire ce que la concurrence fait.
je précise aussi que monter la même chose avec du vrai XHTML et un background CSS ne me pose aucun souci, mais nous ne voulons pas "tricher" : je m'explique : l'intégralité du contenu est intégré via le CMS avec l'éditeur wysiwyg incorporé. nous restons donc dans les les limites raisonnables du wysiwyg pour ne pas avoir un dialogue du genre
le client : "oui, mais vous vous aviez du texte en couleur, une typo de fou et un arrière plan dans ce bloc de texte ! je veux faire la même chose dans le wysiwyg"
nous : " pas de problème, vous apprenez la syntaxe css, les règles qui vont bien pour que l'image d'arrière plan soit affichée en intégralité même si le texte ne fait qu'une ligne (et que ca marche sur IE, hein !, ), puis vous appliquer tout çà dans le wysiwyg. "
NextCMS doit rester simple et facile à utiliser. encore un compromis forcé (mais je travaille activement à la résolution de ce genre de cas).
conteneurs vides : effectivement, quand je dois ajouter une image "décorative" (séparation, barre de couleur quelconque, ...) j'utilise parfois un <div> vide, qui via CSS prendra une couleur, un background, une hauteur en fonction du rendu à obtenir.
si tu as une meilleure solution à me proposer, je suis bien entendu preneur; mon but étant de proposer le meilleur outil possible à nos clients.
je ne suis pas sur de comprendre, mais si tu parles de l'indentation du code source, c'est vrai que c'est pas tabulé de haut en bas comme il faudrait, mais j'ai vu pire également. Je ne pense pas que ca ait de l'impact sur la qualité de l'expérience visiteur, donc ce n'est pas ma priorité (même si c'est pas grand chose à code pour que tout soit nickel comme les premiers fichiers html qu'on fait à la main).
j'ai bon ?
ah ces intégrateurs de contenu (après les graphistes, décidement) !
plus sérieusement encore une fois, l'outil propose les fonctionnalités (ALT pour les images, TITLE pour les images et liens, ....); après le fait qu'elles soient ou non utilisées, et de façon correcte de surcroit, n'est plus un problème lié à l'outil.
Je cherche en ce moment une solution pour présenter du contenu alternatif aux animations flash intégrées par le client dans le wysiwyg. C'est pas facile, mais je ne suis pas loin de la vérité
Je précise que pour les Flash hors CMS (header, menu de navig, etc...), c'est à dire ceux que l'utilisateur n'intègre pas via le wysiwyg, proposent déja un contenu alternatif XHTML (voir notre menu de navig sur http://www.nextweb.fr/ )
je ne pense pas que néophyte soit le terme adéquat
techniquement ( XUL, webservices, moteur PHP/SQL), je pense qu'on tient très bien la route
expérience utilisateur : drag&drop pour les upload, pour déplacer un élément d'une page à l'autre, chargement instantané des données (par de reload de l'interface), éditeur d'images (minimal, mais bon) intégré : je pense que l'utilisateur s'y retrouve bien et se sent à l'aise avec le système : en gros 2heures de formation suffisent pour maitriser l'outil
graphiquement : j'ai pas encore vomi
référencement : les résultats sont très bons : "cms w3c", "cms normes", "cms xul" sur google.fr par exemple.
accessibilité : sans doute énormément à apprendre et à faire. dans ce but, nous allons suivre une formation accessiweb (5jours) pour compléter les manques.
dans tous les domaines cités ci-dessus, nous avons appris au fur et à mesure à développer nos compétences. L'accessibilité est pour la majorité de la profession quelque chose de relativement nouveau, on va s'y mettre à fond comme pour tout le reste. Je pense qu'on n'est pas ceux à partir du plus loin dans cette nouvelle "course".
c'est tout à fait vrai. NextCMS offre les fonctionnalités pour rendre le contenu qu'il gère accessible. Mais uniquement le contenu géré par le CMS, pas l'ensemble du site. En je pense que l'accessibilité est bien plus difficile à satisfaire à l'extérieur des "éléments de contenu". pour moi, l'accessiblité est un travail conséquent, que l'on utilise un CMS ou pas.
Modifié par nextweb (17 Mar 2006 - 23:56)
jpv a écrit :
Des balises h2 cachées utilisées à la seule fin de spammer les moteurs de recherche, ce qui est particulièrement grave.
Ayant été moi-même assez opposé à cette idée au départ, j'ai du me rendre compte d'une vérité : pour nos clients, majoritairement B2B, le référencement est primordial.
Petit exemple des "méthodes référencement" de certains concurrents que je ne citerai pas :
- utiliser la balise <noscript></noscript> pour masquer des listes de mots clés : un utilisateur qui navigue sans javascript verra cette liste s'afficher, ce qui est bien gênant quand même. Je pense que notre solution est plus correcte, étant donné qu'il s'agit bien de vrai contenu dans le corps de la page, avec de la sémantique possible (j'y reviens juste après...)
- ajouter, en bas de chaque page, un bloc "mots clés associés à cette page" contenant une 30aine de liens avec les mots et expressions qui vont bien, pointant vers une autre page du site : ca ne me semble pas très fin, et celà peut gener même le visiteur lambda qui n'a rien à faire de cette liste.
aucune de ces 2 méthodes n'est bonne, je pense qu'on est d'accord là-dessus. La notre n'est pas, en terme d'accessibilité, réellement meilleure, je l'avoue.
mais il y a des moments où il faut savoir trouver des compromis, puisque que c'est plus que rageant de perdre un marché car le prospect s'est laissé dire "oui, Monsieur, nous on a du référencement "caché" dans une superbalise ultra techno dernier cri; je traduis, la <noscript>
qui va vous permettre de bien grimper dans les moteurs. Nextweb avec NextCMS ne vous propose pas cette formidable option, venez donc chez nous !" (c'est du vécu).Pour en finir avec notre solution à cet épineux dilemme, je voudrais préciser que notre outil permet de rédiger du vrai texte, avec du balisage sémantique XHTML et tout et tout, et ne se limite pas à une série de mots clés dans un <h2>, même si c'est le réglage pas défaut de la solution. Il appartient à chacun ensuite d'assumer le contenu (spam ou pas) de cet "article invisible". De plus, je n'ai pas vérifié jusqu'au bout, mais en tout cas à l'écran, au print et pour PDA, il est possible de masquer ce contenu via les CSS. je suppose que pour un navigateur vocal ou plage braille cela fonctionne de la même façon. Le contenu de cet article invisible ne me semble donc aujourd'hui plus nuisible au site, ou du moins les inconvénients qu'il représente sont largement effacés par les bénéfices que tirent nos clients au niveau de leur référencement.
Un dernier mot : les clients actuels font principalement du B2B, avec forte concurrence sur leur marché.
nous sommes actuellement sur des projets de sites publics, où cette fonctionnalité de NextCMS ne sera a priori pas utilisée (sauf si le client le décide malgré nos recommandations, c'est bien son droit après tout) car le but du site n'est pas du tout le même.
jpv a écrit :
Une structure de titre plus que problématique ce qui montre à tout le moins un manque de compréhension du sujet.
je ne suis pas persuadé de comprendre la remarque, tout comme bernard.s qui a initié ce sujet.
je peux néanmoins apporter quelques précisions :
la page comporte 1 titre principal en <h1>
les sections (menu de navigation, zone actualités, zone de bas de page, ...) sont identifiées par des <h2>
le titre des éléments de contenu (articles, actus, formulaires, affichage de rss) sont des <h3>, puisqu'ils sont situés dans des sections <h2>
pour les coprs de texte, l'utilisateur de NextCMS a à sa disposition les <h4>,<h5> et <h6>, vu que le corps du texte appartient à un élément, repéré donc par un titre <h3>
celà me semble assez logique, mais j'ai peut-être loupé quelque chose, ou mal compris la remarque. Peux-tu stp m'en dire plus ?
jpv a écrit :
Une magnifique image qui contient profusion de texte.
ah, ces graphistes !
plus sérieusement, oui, je confesse que ce n'est pas le top, mais comme pour le référencement, il faut pouvoir faire ce que la concurrence fait.
je précise aussi que monter la même chose avec du vrai XHTML et un background CSS ne me pose aucun souci, mais nous ne voulons pas "tricher" : je m'explique : l'intégralité du contenu est intégré via le CMS avec l'éditeur wysiwyg incorporé. nous restons donc dans les les limites raisonnables du wysiwyg pour ne pas avoir un dialogue du genre
le client : "oui, mais vous vous aviez du texte en couleur, une typo de fou et un arrière plan dans ce bloc de texte ! je veux faire la même chose dans le wysiwyg"
nous : " pas de problème, vous apprenez la syntaxe css, les règles qui vont bien pour que l'image d'arrière plan soit affichée en intégralité même si le texte ne fait qu'une ligne (et que ca marche sur IE, hein !,
), puis vous appliquer tout çà dans le wysiwyg. "NextCMS doit rester simple et facile à utiliser. encore un compromis forcé (mais je travaille activement à la résolution de ce genre de cas).
jpv a écrit :
Beaucoup de conteners vides, innapropriés, ou des retour chariots utilisés pour caler le design.
conteneurs vides : effectivement, quand je dois ajouter une image "décorative" (séparation, barre de couleur quelconque, ...) j'utilise parfois un <div> vide, qui via CSS prendra une couleur, un background, une hauteur en fonction du rendu à obtenir.
si tu as une meilleure solution à me proposer, je suis bien entendu preneur; mon but étant de proposer le meilleur outil possible à nos clients.
jpv a écrit :
Une structure de tabulation illogique...
je ne suis pas sur de comprendre, mais si tu parles de l'indentation du code source, c'est vrai que c'est pas tabulé de haut en bas comme il faudrait, mais j'ai vu pire également. Je ne pense pas que ca ait de l'impact sur la qualité de l'expérience visiteur, donc ce n'est pas ma priorité (même si c'est pas grand chose à code pour que tout soit nickel comme les premiers fichiers html qu'on fait à la main).
j'ai bon ?
jpv a écrit :
Un manque d'alternative textuelle quand il le faut et d'autres inutiles ou innapropriées.
ah ces intégrateurs de contenu (après les graphistes, décidement) !
plus sérieusement encore une fois, l'outil propose les fonctionnalités (ALT pour les images, TITLE pour les images et liens, ....); après le fait qu'elles soient ou non utilisées, et de façon correcte de surcroit, n'est plus un problème lié à l'outil.
Je cherche en ce moment une solution pour présenter du contenu alternatif aux animations flash intégrées par le client dans le wysiwyg. C'est pas facile, mais je ne suis pas loin de la vérité
Je précise que pour les Flash hors CMS (header, menu de navig, etc...), c'est à dire ceux que l'utilisateur n'intègre pas via le wysiwyg, proposent déja un contenu alternatif XHTML (voir notre menu de navig sur http://www.nextweb.fr/ )
jpv a écrit :
L'ensemble fait quand-même un chouia "néophyte", plein de bonne volonté mais très loin des ambitions qu'ils affichent.
je ne pense pas que néophyte soit le terme adéquat
techniquement ( XUL, webservices, moteur PHP/SQL), je pense qu'on tient très bien la route
expérience utilisateur : drag&drop pour les upload, pour déplacer un élément d'une page à l'autre, chargement instantané des données (par de reload de l'interface), éditeur d'images (minimal, mais bon) intégré : je pense que l'utilisateur s'y retrouve bien et se sent à l'aise avec le système : en gros 2heures de formation suffisent pour maitriser l'outil
graphiquement : j'ai pas encore vomi
référencement : les résultats sont très bons : "cms w3c", "cms normes", "cms xul" sur google.fr par exemple.
accessibilité : sans doute énormément à apprendre et à faire. dans ce but, nous allons suivre une formation accessiweb (5jours) pour compléter les manques.
dans tous les domaines cités ci-dessus, nous avons appris au fur et à mesure à développer nos compétences. L'accessibilité est pour la majorité de la profession quelque chose de relativement nouveau, on va s'y mettre à fond comme pour tout le reste. Je pense qu'on n'est pas ceux à partir du plus loin dans cette nouvelle "course".
jpv a écrit :
Du coup mon conseil serait la prudence, à tout le moins leur demander de te montrer un site réellement accessible et/ou de recourir à un spécialiste pour contrôler leur travail.
Pour le moment si l'on doit se prononcer, aucun des sites fait avec ce CMS n'offre le minimum requis.
c'est tout à fait vrai. NextCMS offre les fonctionnalités pour rendre le contenu qu'il gère accessible. Mais uniquement le contenu géré par le CMS, pas l'ensemble du site. En je pense que l'accessibilité est bien plus difficile à satisfaire à l'extérieur des "éléments de contenu". pour moi, l'accessiblité est un travail conséquent, que l'on utilise un CMS ou pas.
Modifié par nextweb (17 Mar 2006 - 23:56)
dominique a écrit :
En effet, Jean-Pierre, on se rejoint au moins sur le fait qu'aucun des sites présentés n'est accessible ainsi que sur la demande de voir des sites réellement accessibles.
croisez les doigts pour qu'on concrétise nos contrats en cours pour des sites institutionnels
dominique a écrit :
Pour ce qui pourrait différencier nos opinions, je pense qu'il faut prendre en compte les impératifs des clients, qui, apparemment n'étaient pas intéressés par l'accessibilité.
oui, comme expliqué plus haut : b2b > référencement par exemple.
NextCMS est avant tout une technologie, et pour moi l'accessibilité va bien au delà de cet aspect.
dominique a écrit :
La démarche et l'esprit semblent être bien présents, le code est valide même s'il n'est pas parfait... Et la perfection n'est pas de ce monde.
effectivement, l'esprit et la philosophie sont bien présents, et c'est parfois difficile à digérer de devoir sacrifier certaines choses pour ne pas se faire "démolir" par la concurrence. Nous essayons de trouver les solutions les plus élégantes qui soient, et dans tous les cas les clients sont prévenus des utilisations détournées de certaines fonctionnalités (référencement caché).
Nous essayons d'être très transparent à ce niveau, mais c'est parfois dur : petit exemple :
nous avons annoncé NextCMS v3 début de cette année, avec des fonctionnalités comme le glisser déposer pour l'upload de fichiers, le déplacement d'éléments de contenu d'une page à l'autre.
très peu de temps après, un concurrent communique à son tour sur le "glisser déposer". en fait, il s'agit d'une véritable intox, car celà représente dans leur outil la possibilité de glisser déposer une chaine de texte dans leur éditeur wysiwyg à partir de word par exemple.
dur à avaler non ?
tout çà pour dire qu'on va au maximum de la transparence, mais qu'on ne peut pas fermer toutes les portes non plus ( vous voulez du flash > allez chez la concurrence. vous voulez des super images avec de la typo XYZ > allez chez la concurrence). une histoire de compromis, comme toujours.
pour finir ma série de réponses...
exactement, comme dit plus haut, pour moi le CMS représente sans doute la plus petite partie à travailler pour que la chose soit accessible.
le vrai travail se situe au niveau global du site ( dans le cas d'un CMS, les différents gabarits).
ce que je peux dire, c'est que à l'heure actuelle, NextCMS fournit les fonctionnalités pour rendre le contenu (cad les articles) accessibles, à part le contenu alternatif au Flash évoqué plus haut, ainsi que la gestion des accronymes (je travaille à leur intégration dans le wysiwyg).
deux choses très différentes certes, mais étroitement liées dans leur mise en oeuvre. pour que les outils puissent faire leur office de rendu accessible, il faut qu'ils puissent lire un contenu standard pour éviter les erreurs d'interprétation.
comme évoqué plus haut, ce flash est intégré via le wysiwyg, et la solution pour spécifier du contenu alternatif va arriver sous peu. on pourra donc à ce stade spécifier du XHTML alternatif.
y en a bien qui osent le glisser déposer de texte word
blague à part, notre CMS n'est pas la solution accessible idéale, mais je pense que tout le monde ici est OK pour dire que le CMS est quasi insignifiant dans la chaine menant à l'accessibilité, d'où les démarches (de formation par exemple) que nous avons entrepris pour acquérir le savoir nécessaire pour produire du site accessible, que ce soit avec ou sans le CMS.
Je pense cependant que l'on peut dire que le contenu généré par le CMS (les articles, ...) est lui accessible si l'on utilise les fonctionnalités présentes (texte alternatif pour les images, titres pour images et liens) et à venir (contenu alternatif au flash, accronymes).
C'est à ce titre que nous qualifions NextCMS de CMS accessible, puisqu'il propose ces fonctionnalités.
Le reste se situe dans la conception du site, avec ou sans CMS, et une telle réalisation ne nous a pas été commandée à ce stade. Cela va changer prochainement (croisons les doigts pour les sites publics en cours de négo ) et effectivement, cette prestation est facturée puisqu'elle ne dépend pas du CMS.
l'accessibilité n'est pas notre unique argument de vente pour NextCMS.
de l'avis des utilisateurs, le produit est simple, intuitif et performant. on produit du code valide et conforme aux standards, on utilise pas de javascript pour les menus ou les plans de site, ce qui est déja pas mal vu les autres produits sur le marché.
on ne débute pas vraiment, mais ce qui est sur, c'est qu'on a tous (pas seulement chez Nextweb) besoin d'apprendre tous les jours pour suivre.
on utilise des technos innovantes (XUL, webservices, ...) qui nous permettent de proposer des choses nouvelles aux clients.
pour finir, et par curiosité et absolument sans agressivité de ma part, connais-tu une solution qui n'ai pas l'air "néophyte", avec une équipe "qui débute" et à qui on doit "laisser le temps d'apprendre" ?
je suis toujours très interessé par ce qu'il y a de mieux que ce qu'on propose.
je me relirai un peu plus tard, j'ai sans doute fait pas mal de fautes, mais je suis bien fatigué là
Dans l'attente de vos réponses et commentaires, je vous souhaite à tous une bonne soirée.
Julien
Modifié par nextweb (18 Mar 2006 - 00:05)
raphael a écrit :
En fait, ce que veut dire Dominique, à juste titre, c'est que l'outil est bien loin d'être suffisant, l'accessibilité d'un site web dépend de plusieurs niveaux d'implications :
.....
En bref, l'outil (le CMS) n'est qu'une étape dans tout un processus. La personne qui va se charger d'introduire le contenu a une importance aussi grande que l'outil choisi, et elle doit être formée afin de ne pas "ruiner" le travail fourni par l'outil.
exactement, comme dit plus haut, pour moi le CMS représente sans doute la plus petite partie à travailler pour que la chose soit accessible.
le vrai travail se situe au niveau global du site ( dans le cas d'un CMS, les différents gabarits).
ce que je peux dire, c'est que à l'heure actuelle, NextCMS fournit les fonctionnalités pour rendre le contenu (cad les articles) accessibles, à part le contenu alternatif au Flash évoqué plus haut, ainsi que la gestion des accronymes (je travaille à leur intégration dans le wysiwyg).
jpv a écrit :
.... on entretient un flou artistique entre la normalisation des langages et l'accessibilité qui sont des choses très différentes.
deux choses très différentes certes, mais étroitement liées dans leur mise en oeuvre. pour que les outils puissent faire leur office de rendu accessible, il faut qu'ils puissent lire un contenu standard pour éviter les erreurs d'interprétation.
jpv a écrit :
La proximité entre "Normes W3C et sites accessibles à tous" et la petite animation flash, totalement innacessible elle, destiné à tester la validité xhtml est plus que spécieuse.
comme évoqué plus haut, ce flash est intégré via le wysiwyg, et la solution pour spécifier du contenu alternatif va arriver sous peu. on pourra donc à ce stade spécifier du XHTML alternatif.
jpv a écrit :
Si je n'y connais rien, je lis, je teste et je comprends que ce site est accessible... non ?
Bévue de débutant ?, irruption de considérations marketing bien comprises ? le mystère demeure.
y en a bien qui osent le glisser déposer de texte word
blague à part, notre CMS n'est pas la solution accessible idéale, mais je pense que tout le monde ici est OK pour dire que le CMS est quasi insignifiant dans la chaine menant à l'accessibilité, d'où les démarches (de formation par exemple) que nous avons entrepris pour acquérir le savoir nécessaire pour produire du site accessible, que ce soit avec ou sans le CMS.
Je pense cependant que l'on peut dire que le contenu généré par le CMS (les articles, ...) est lui accessible si l'on utilise les fonctionnalités présentes (texte alternatif pour les images, titres pour images et liens) et à venir (contenu alternatif au flash, accronymes).
C'est à ce titre que nous qualifions NextCMS de CMS accessible, puisqu'il propose ces fonctionnalités.
Le reste se situe dans la conception du site, avec ou sans CMS, et une telle réalisation ne nous a pas été commandée à ce stade. Cela va changer prochainement (croisons les doigts pour les sites publics en cours de négo ) et effectivement, cette prestation est facturée puisqu'elle ne dépend pas du CMS.
jpv a écrit :
En tout cas il n'est jamais fait mention nul part des excellentes remarques de Raphael sans lesquelles CMS accessible ne veut rien dire, mais tu à raison ils débutent vraisemblement dans ce domaine et il faut leur laisser le temps d'apprendre.
l'accessibilité n'est pas notre unique argument de vente pour NextCMS.
de l'avis des utilisateurs, le produit est simple, intuitif et performant. on produit du code valide et conforme aux standards, on utilise pas de javascript pour les menus ou les plans de site, ce qui est déja pas mal vu les autres produits sur le marché.
on ne débute pas vraiment, mais ce qui est sur, c'est qu'on a tous (pas seulement chez Nextweb) besoin d'apprendre tous les jours pour suivre.
on utilise des technos innovantes (XUL, webservices, ...) qui nous permettent de proposer des choses nouvelles aux clients.
pour finir, et par curiosité et absolument sans agressivité de ma part, connais-tu une solution qui n'ai pas l'air "néophyte", avec une équipe "qui débute" et à qui on doit "laisser le temps d'apprendre" ?
je suis toujours très interessé par ce qu'il y a de mieux que ce qu'on propose.
je me relirai un peu plus tard, j'ai sans doute fait pas mal de fautes, mais je suis bien fatigué là
Dans l'attente de vos réponses et commentaires, je vous souhaite à tous une bonne soirée.
Julien
Modifié par nextweb (18 Mar 2006 - 00:05)
Bonjour
@Julien : Tout d'abord merci de tes réponses et d'avoir encaissé avec beaucoup d'élégance les critiques "abruptes" que j'ai faites, c'est suffisemment rare pour être signalé...
Je réponds en deux temps, d'abord sur mes remarques de fond, critiques quelquefois dures mais que je suis obligé de faire.
Dans le second post je répondrais évidemment sur toutes les autres questions et remarques qui sont très intéressantes.
Juste une remarque : Le fait que les prestations liées à l'accessibilité doivent faire l'objet d'une prestation supplémentaire n'est pas spécifié dans vos tarifs.
Je ne suis pas certain que ce soit la bonne manière d'aborder une relation client car dans les faits le tarif initial, si je comprends bien, c'est une sorte de "ticket d'entrée" sur lequel va venir se rajouter des frais de développement de gabarits et des prestations additionnelles.
Les sites que nous avons visités sont ceux cités dans vos références et le votre.
Je maintiens l'ensemble des mes remarques sur le "flou artistique" et je voudrais m'en expliquer :
Nous sommes dans une période charnière pour l'accessibilité dont les thèmes diffusent maintenant largement au delà de la communautée de spécialistes.
L'accessibilité est un domaine difficile à aborder car le chemin est pavé de malentendus et de faux semblants.
Dés lors que l'on commence à parler de ces thèmes il est crucial d'être extrèmement clair faute de quoi on va laisser s'infiltrer des idées fausses et dangereuses.
Bien sur la standardisation des langages est un pré-requis, en revanche il faut dés que l'on en parle préciser deux choses importantes :
1. L'utilisation des normes de langage n'offre aucun début de commencement de rien du tout quant à l'accessibilité elle-même.
De la même façon qu'on ne juge pas le travail d'un maçon à la qualité du ciment qu'il utilise, et même si c'est essentiel, on ne juge pas l'accessibilité d'un site à la normalisation des langages.
Même si l'on considère que la normalisation des langages bénéficie à la structuration du contenu ce n'est pas un effet de la spécification mais de son application raisonnée.
Par exemple, en utilisant h2 pour spammer vous passez la validation technique mais en revanche vous êtes, stricto sensu, totalement hors de la norme que vous détournez.
Je ne parle là que de la norme technique d'utilisation de xhtml et de rien d'approchant en terme d'accessibilité qui de ce point de vue est délibérément ignorée.
2. WCAG n'est pas une spécification et les recommandations ne sont pas des normes.
Cest extrèmement important d'être clair la dessus pour tuer l'idée que WCAG est validable par un processus automatique du même type qu'une validation de langage. Cette idée n'à aucun sens pour WCAG.
Le discours tenu sur votre site accrédite pourtant ces deux idées.
deux choses très différentes certes, mais étroitement liées dans leur mise en oeuvre.
Je persiste à penser que le jeu dialectique de la page présentant la validité du code xhtml comme "démonstration" de l'accesibilité est un procédé spécieux et dangereux.
En terme de pédagogie c'est catastrophique et en terme de perception des compétences de nextCMS c'est tragique.
Si cette dialectique est une réponse cironstanciée à la concurence c'est que vous vous trompez de concurrents : ceux là n'ont aucun avenir sur ce marché.
La compétence à attendre pour produire du xhtml est techniquement voisine du zéro absolu c'est dire simplement : "regardez je suis expert sur un truc qui s'apprends en une heure et qui est à la portée de n'importe quel webmaster de base" , il y à beaucoup plus de compétence dans la technique de soupe de tags...
Je parle là aussi, pour être très clair, de l'aspect purement technique de l'application de xhtml et absolument pas de ce qu'il faut en faire ce qui n'à rien à voir avec la validation elle-même.
Là aussi pour caricaturer ce que vous dites avec cette page c'est quelque chose comme "regardez comme nous écrivons bien, la preuve : il n'y à aucune faute d'hortographe".
C'est bien mais ça ne nous dit rien sur la qualité de ce qui est écrit.
(Bon, oui, je sais, de ma part, l'exemple de l'hortographe est particulièrement amusant...
)
Si il y à une compétence à valoriser ce n'est pas celle là, mais celle de l'utilisation de CSS associé au concept de séparation de la structure, du contenu et de la présentation.
Certes c'est beaucoup plus difficile à expliquer surtout en terme de discours commercial, mais ce n'est pas impossible loin de là et c'est extrèmement positif en terme de relation client.
Ayant été moi-même assez opposé à cette idée au départ, j'ai du me rendre compte d'une vérité : pour nos clients, majoritairement B2B, le référencement est primordial.
...
Petit exemple des "méthodes référencement" de certains concurrents que je ne citerai pas :
Là aussi je ne peut qu'être dur : Le spam indexing c'est la plaie du web.
En créant ce bruit de fond vis à vis des moteurs de recherche vous créez exactement le même phénomène que l'invasion de fausse monnaie dans un système économique : au delà d'un certain seuil c'est l'ensemble du système qui s'effondre.
Nous avons vécu cette catastrophe dans les années 2000 où l'utilisation criminelle des métadonnées du document (keyword et description) a définitivement enterré cette brique essentielle du web.
Essayez de penser à ça : après les métadonnées ce que vous êtes en train d'attaquer maintenant c'est le langage lui-même. Ca ne vous effraie pas ?
Il n'y à aucun argument qui justifie ce genre de techniques agressives de référencement.
Là aussi vous vous trompez de concurrents : ceux qui emploient ce genre de techniques ne sont pas des concurrents ce sont des ennemis.
On ne peut que les condamner et espérer que les moteurs développent des techniques de détection fiable de ces "astuces de la mort qui tue" et puisses éradiquer définitivement les sociétés qui y ont recours.
Google envoie des signes forts depuis quelques temps : déférencement massif des 300 clients d'une agence de positionnement celèbre en novembre 2004, en janvier dernier le tumultueux banissement du site d'un constructeur automobile et l'accroissement vertigineux du nettoyage des indexs lors des dernières google dance.
Au delà, c'est aussi une simple question de conscience : le fait qu'il existe des voleurs de poule ne nous autorise pas à piller les poulaillers.
Enfin, et je parle avec l'expérience de la centaine de sites sur lesquels j'ai eu à connaitre depuis 98 : le positionnement vertical (première page sur deux ou trois clés) est strictement équivalent voir inférieur en terme de qualité et de ROI par rapport au référencement naturel où l'on cumule des positions intermédiaires sur des "expressions de recherche", si tant est que ce soit associé avec une politique de communication par échanges pertinents de liens, alimentation du contenu, développements de partenariats et publicité intelligente.
Par ailleurs c'est quand même plus intéressant et valorisant pour le prestataire et le client que l'échange sous le manteau d'astuces "honteuses" heu... pardon d'expertise SEO
.
Voilà, j'en ai terminé de ce qui me gène chez nextCMS, je me suis permis d'être un peu abrupt voire un chouia brutal mais le ton de tes messages m'on permis de penser que je pouvais me le permettre...
Je consacrerais le temps nécessaire demain dans la journée pour répondre à tes autres remarques et questions en essayant de me faire pardonner cette critique frontale par les réponses les plus complètes.
jean-pierre
Modifié par jpv (18 Mar 2006 - 04:22)
@Julien : Tout d'abord merci de tes réponses et d'avoir encaissé avec beaucoup d'élégance les critiques "abruptes" que j'ai faites, c'est suffisemment rare pour être signalé...
Je réponds en deux temps, d'abord sur mes remarques de fond, critiques quelquefois dures mais que je suis obligé de faire.
Dans le second post je répondrais évidemment sur toutes les autres questions et remarques qui sont très intéressantes.
a écrit :
Je ne sais pas quels sites ont été cités en exemple.
...
C'est à ce titre que nous qualifions NextCMS de CMS accessible, puisqu'il propose ces fonctionnalités (i.e description des images, titrage ect).
...
Cette prestation (ie l'accessibilité) est facturée puisqu'elle ne dépend pas du CMS.
...
Juste une remarque : Le fait que les prestations liées à l'accessibilité doivent faire l'objet d'une prestation supplémentaire n'est pas spécifié dans vos tarifs.
Je ne suis pas certain que ce soit la bonne manière d'aborder une relation client car dans les faits le tarif initial, si je comprends bien, c'est une sorte de "ticket d'entrée" sur lequel va venir se rajouter des frais de développement de gabarits et des prestations additionnelles.
Les sites que nous avons visités sont ceux cités dans vos références et le votre.
Je maintiens l'ensemble des mes remarques sur le "flou artistique" et je voudrais m'en expliquer :
Nous sommes dans une période charnière pour l'accessibilité dont les thèmes diffusent maintenant largement au delà de la communautée de spécialistes.
L'accessibilité est un domaine difficile à aborder car le chemin est pavé de malentendus et de faux semblants.
Dés lors que l'on commence à parler de ces thèmes il est crucial d'être extrèmement clair faute de quoi on va laisser s'infiltrer des idées fausses et dangereuses.
Bien sur la standardisation des langages est un pré-requis, en revanche il faut dés que l'on en parle préciser deux choses importantes :
1. L'utilisation des normes de langage n'offre aucun début de commencement de rien du tout quant à l'accessibilité elle-même.
De la même façon qu'on ne juge pas le travail d'un maçon à la qualité du ciment qu'il utilise, et même si c'est essentiel, on ne juge pas l'accessibilité d'un site à la normalisation des langages.
Même si l'on considère que la normalisation des langages bénéficie à la structuration du contenu ce n'est pas un effet de la spécification mais de son application raisonnée.
Par exemple, en utilisant h2 pour spammer vous passez la validation technique mais en revanche vous êtes, stricto sensu, totalement hors de la norme que vous détournez.
Je ne parle là que de la norme technique d'utilisation de xhtml et de rien d'approchant en terme d'accessibilité qui de ce point de vue est délibérément ignorée.
2. WCAG n'est pas une spécification et les recommandations ne sont pas des normes.
Cest extrèmement important d'être clair la dessus pour tuer l'idée que WCAG est validable par un processus automatique du même type qu'une validation de langage. Cette idée n'à aucun sens pour WCAG.
Le discours tenu sur votre site accrédite pourtant ces deux idées.
a écrit :
jpv a écrit :
.... on entretient un flou artistique entre la normalisation des langages et l'accessibilité qui sont des choses très différentes.
deux choses très différentes certes, mais étroitement liées dans leur mise en oeuvre.
Je persiste à penser que le jeu dialectique de la page présentant la validité du code xhtml comme "démonstration" de l'accesibilité est un procédé spécieux et dangereux.
En terme de pédagogie c'est catastrophique et en terme de perception des compétences de nextCMS c'est tragique.
Si cette dialectique est une réponse cironstanciée à la concurence c'est que vous vous trompez de concurrents : ceux là n'ont aucun avenir sur ce marché.
La compétence à attendre pour produire du xhtml est techniquement voisine du zéro absolu c'est dire simplement : "regardez je suis expert sur un truc qui s'apprends en une heure et qui est à la portée de n'importe quel webmaster de base" , il y à beaucoup plus de compétence dans la technique de soupe de tags...
Je parle là aussi, pour être très clair, de l'aspect purement technique de l'application de xhtml et absolument pas de ce qu'il faut en faire ce qui n'à rien à voir avec la validation elle-même.
Là aussi pour caricaturer ce que vous dites avec cette page c'est quelque chose comme "regardez comme nous écrivons bien, la preuve : il n'y à aucune faute d'hortographe".
C'est bien mais ça ne nous dit rien sur la qualité de ce qui est écrit.
(Bon, oui, je sais, de ma part, l'exemple de l'hortographe est particulièrement amusant...
)Si il y à une compétence à valoriser ce n'est pas celle là, mais celle de l'utilisation de CSS associé au concept de séparation de la structure, du contenu et de la présentation.
Certes c'est beaucoup plus difficile à expliquer surtout en terme de discours commercial, mais ce n'est pas impossible loin de là et c'est extrèmement positif en terme de relation client.
a écrit :
jpv a écrit :
Des balises h2 cachées utilisées à la seule fin de spammer les moteurs de recherche, ce qui est particulièrement grave.
Ayant été moi-même assez opposé à cette idée au départ, j'ai du me rendre compte d'une vérité : pour nos clients, majoritairement B2B, le référencement est primordial.
...
Petit exemple des "méthodes référencement" de certains concurrents que je ne citerai pas :
Là aussi je ne peut qu'être dur : Le spam indexing c'est la plaie du web.
En créant ce bruit de fond vis à vis des moteurs de recherche vous créez exactement le même phénomène que l'invasion de fausse monnaie dans un système économique : au delà d'un certain seuil c'est l'ensemble du système qui s'effondre.
Nous avons vécu cette catastrophe dans les années 2000 où l'utilisation criminelle des métadonnées du document (keyword et description) a définitivement enterré cette brique essentielle du web.
Essayez de penser à ça : après les métadonnées ce que vous êtes en train d'attaquer maintenant c'est le langage lui-même. Ca ne vous effraie pas ?
Il n'y à aucun argument qui justifie ce genre de techniques agressives de référencement.
Là aussi vous vous trompez de concurrents : ceux qui emploient ce genre de techniques ne sont pas des concurrents ce sont des ennemis.
On ne peut que les condamner et espérer que les moteurs développent des techniques de détection fiable de ces "astuces de la mort qui tue" et puisses éradiquer définitivement les sociétés qui y ont recours.
Google envoie des signes forts depuis quelques temps : déférencement massif des 300 clients d'une agence de positionnement celèbre en novembre 2004, en janvier dernier le tumultueux banissement du site d'un constructeur automobile et l'accroissement vertigineux du nettoyage des indexs lors des dernières google dance.
Au delà, c'est aussi une simple question de conscience : le fait qu'il existe des voleurs de poule ne nous autorise pas à piller les poulaillers.
Enfin, et je parle avec l'expérience de la centaine de sites sur lesquels j'ai eu à connaitre depuis 98 : le positionnement vertical (première page sur deux ou trois clés) est strictement équivalent voir inférieur en terme de qualité et de ROI par rapport au référencement naturel où l'on cumule des positions intermédiaires sur des "expressions de recherche", si tant est que ce soit associé avec une politique de communication par échanges pertinents de liens, alimentation du contenu, développements de partenariats et publicité intelligente.
Par ailleurs c'est quand même plus intéressant et valorisant pour le prestataire et le client que l'échange sous le manteau d'astuces "honteuses" heu... pardon d'expertise SEO
.Voilà, j'en ai terminé de ce qui me gène chez nextCMS, je me suis permis d'être un peu abrupt voire un chouia brutal mais le ton de tes messages m'on permis de penser que je pouvais me le permettre...
Je consacrerais le temps nécessaire demain dans la journée pour répondre à tes autres remarques et questions en essayant de me faire pardonner cette critique frontale par les réponses les plus complètes.
jean-pierre
Modifié par jpv (18 Mar 2006 - 04:22)
Bonjour
pas de problème, tant que les remarques sont fondées, pas de raison d'entrer en conflit
en plus, je pense avoir montré dans mes précédents post que tout ce qui n'était pas la la droite ligne philosophique et idéologique de l'accessibilité avait une raison d'être pour nous.
d'ailleurs je pense que le caractère accessible n'est de loin pas la seule facette attrayante de NextCMS, et de loin pas la seule sur laquelle nous communiquons : simplicité, intuitivité, performance, puissance, ...
pour dissiper ce mal entendu, je pense qu'il faut clairement expliquer que http://www.nextcms.fr/ ne fait que vendre un outil, et pas une prestation. Le prestataire de service est http://www.nextweb.fr/ et aucun prix ne figure sur le site puisque que par définition la création de site et prestations annexes (dont la mise en oeuvre de l'accessibilité) sont devisées client par client ( en fonction de la masse de travail, pas de la tête du client ), puisque c'est une prestation personnalisée à chaque fois.
pour illustrer mon exemple : si chez Adobe tu achètes un Photoshop, ils ne te précisent pas : "il vous faut une personne qui sache maitriser l'outil et qui soit bon, Photoshop ne dessinera pas pour lui". Donc en supplément de Photoshop, il faut quelqu'un (qui coute de l'argent en plus) pour l'utiliser.
pour NextCMS, qui est l'outil, il faut une prestation complémentaire pour faire le front-office.
je pense que pas mal de choses peuvent être clarifiées en tenant compte de la distinction Nextweb = prestataire / NextCMS = outil.
tout à fait, mais il était ici question de l'outil NextCMS, et pas sur la capacité de NextWeb à produire un site accessible.
pour reprendre mon exemple : pour le graph, Photoshop (ou Gimp, ou fireworks, je n'ai pas d'actions chez adobe ) c'est mieux que paint, ca offre plus de possibilités, de facilité et le résultat est plus pro.
NextCMS c'est pareil vis-à-vis de l'accessibilité : c'est un outil qui permet de démarrer sur de bonnes bases, pour les éléments qu'il gère (en aucun cas les templates de page ne sont crées par le CMS lui-même, là c'est Nextweb (au sens prestataire) qui rentre en action).
Encore faut-il après que l'on souhaite utiliser cet outil dans l'optique 100% accessibilité, ce qui, je le redis, n'est pas encore arrivé compte tenu de nos clients, de leur marché, de leur budget,etc.
là où ce tag est utilisé (position dans le document), je ne pense pas qu'il y ait d'incohérence sémantique. Pour le contenu de ce tag, l'outil n'en est pas responsable. et comme évoqué plus haut, il est possible via l'outil de mettre autre chose que du <h2>, par exemple tout un article en xhtml sémantique et tout. nous devions offrir ce genre de fonctionnalité, même si ca ne me plait pas beaucoup vis à vis de ce que je pense de l'accessibilité.
je pense l'avoir était en disant précedement que NextCMS n'est qu'une technologie, je le qualifie ici d'outil. j'ai dit que les 99% de l'accessibilité n'ont rien à voir avec le CMS, mais qu'au moins NextCMS assure ce 1%, ce que beaucoup d'autres outils ne font pas.
pour les 99% restant, ben c'est le prestataire qui rentre en jeu. Nous travaillons d'ailleurs à une mise à disposition à d'autres prestataires de l'outil nextCMS.
NextCMS n'a pas de compétences, c'est un outil. il dispose de fonctionnalités. (j'insiste sur ce point, mais je pense que ca peut lever quelques ambiguités : NextCMS != Nextweb)
NextCMS ne permet pas de créer de site web, il faut nécessairement un prestataire (nous ou un autre avec notre solution revendeurs/partenaires).
on ne choisit pas les concurrents que l'on "affronte". petit exemple relativement récent :
Une institution strasbourgeoise fait un appel d'offre pour un site quelconque.
Contraintes sur le cahier des charges : respecter les normes W3C ( (HTML ou XHTML et CSS, dont rien d'exigeant on est d'accord), l'accessibilité viendra dans un second temps. Mise à disposition d'un outil de gestion de contenu et d'emailing.
bref, nous répondons, avec la propo création de site + mise à disposition de NextCMS
nous arrivons en finale (5 à 6 prestataires consultés au départ) et malheuresement le backoffice du CMS du concurrent en question était plus soigné que le notre à cette époque.
nos fonctionnalités et l'ergonomie de notre outil étaient bien meilleures (je connais très bien ce produit concurrent, ce n'est pas un opensource non plus), mais voilà, ca s'est joué sur çà lors de la démo (le concurrent ayant bien sur clamé haut et fort qu'ils savaient faire du standard W3C)
le concurrent a donc réalisé la presta : 1ère page : 79 erreurs au validateur W3C.
alors bien sur maintenant ils doivent être grillés (jusqu'à ce qu'ils corrigent éventuellement le tir) pour les marchés de cette institution, mais bon, j'avoue que ca me reste en travers de la gorge.
NB : ce site est en ligne depuis octobre, et rien n'a été corrigé, et sans doute que rien ne le sera.
bien sur que ca ne suffit pas, mais c'est la base minimum pour se comprendre. pour transposer l'exemple du site institutionnel cité + haut, c'est comme de remettre une dissertation avec une faute toutes les 2 lignes : c'est dur à lire et à comprendre.
et rien que celà entrave l'accessibilité du contenu selon moi.
pour moi, un quota raisonnable est une faute toutes les 3 lignes
nous valorisons énormément cet aspect des choses (y compris les styles alternatifs, print, etc...) auprès des clients lors de nos démos. sur le papier celà me semble assez compliqué à expliquer.
on en profite d'ailleurs toujours pour tendre une perche en faveur de l'accessibilité complète (celle qui ne dépend pas du CMS).
et effectivement, les clients sont très réceptifs à celà.
oui, tout à fait, je ne suis on ne peut plus d'accord, mais la réalité est la suivante, nos 2 options actuellement :
- on ne propose pas ce genre de solution : la concurrence peut s'engouffrer dans la faille, certes infondée. après nous argumentons, le concurrent argumente. parfois ca passe, parfois pas. les concurrents ont la facheuse tentance à être très forts dans ce genre de discours.
- on la propose, en mettant en garde que c'est pas bien dans l'absolu, etc...
nous avons choisi la seconde solution, suite aux déceptions que nous avons du subir quand nous ne proposions pas cette fonctionnalité.
par ailleurs, je le reprécise, (je sens bien que c'est surtout le <h2> qui te gène), il est tout à fait possible d'écrire du vrai texte, structuré, sémantique, parfaitement intelligible. C'est en fait un "article masqué", dont le contenu ne regarde que celui qui le rédige.
bien entendu que j'aimerai ne pas avoir à proposer du tout ce genre de solution.
mais une chose est claire chez nous, le référencement se fait dans cette façon (par ordre d'importance) :
- le contenu des éléments visibles est primordial : nous aidons nos clients à rédiger leur textes pour avoir les bons mots clés, occurences et expressions.
- le titre de la page (<title>)
- l'url de la page
- keywords et description
- référencement caché
en parallèle de çà, nous utilisons :
- la structure de la page (contenu principal en haut, menus de navig et éléments accessoires en bas)
- google sitemaps
Modifié par nextweb (20 Mar 2006 - 12:25)
"jpv" a écrit :
Tout d'abord merci de tes réponses et d'avoir encaissé avec beaucoup d'élégance les critiques "abruptes" que j'ai faites, c'est suffisemment rare pour être signalé
pas de problème, tant que les remarques sont fondées, pas de raison d'entrer en conflit
en plus, je pense avoir montré dans mes précédents post que tout ce qui n'était pas la la droite ligne philosophique et idéologique de l'accessibilité avait une raison d'être pour nous.
d'ailleurs je pense que le caractère accessible n'est de loin pas la seule facette attrayante de NextCMS, et de loin pas la seule sur laquelle nous communiquons : simplicité, intuitivité, performance, puissance, ...
"jpv" a écrit :
Juste une remarque : Le fait que les prestations liées à l'accessibilité doivent faire l'objet d'une prestation supplémentaire n'est pas spécifié dans vos tarifs.
Je ne suis pas certain que ce soit la bonne manière d'aborder une relation client car dans les faits le tarif initial, si je comprends bien, c'est une sorte de "ticket d'entrée" sur lequel va venir se rajouter des frais de développement de gabarits et des prestations additionnelles.
pour dissiper ce mal entendu, je pense qu'il faut clairement expliquer que http://www.nextcms.fr/ ne fait que vendre un outil, et pas une prestation. Le prestataire de service est http://www.nextweb.fr/ et aucun prix ne figure sur le site puisque que par définition la création de site et prestations annexes (dont la mise en oeuvre de l'accessibilité) sont devisées client par client ( en fonction de la masse de travail, pas de la tête du client
), puisque c'est une prestation personnalisée à chaque fois.pour illustrer mon exemple : si chez Adobe tu achètes un Photoshop, ils ne te précisent pas : "il vous faut une personne qui sache maitriser l'outil et qui soit bon, Photoshop ne dessinera pas pour lui". Donc en supplément de Photoshop, il faut quelqu'un (qui coute de l'argent en plus) pour l'utiliser.
pour NextCMS, qui est l'outil, il faut une prestation complémentaire pour faire le front-office.
je pense que pas mal de choses peuvent être clarifiées en tenant compte de la distinction Nextweb = prestataire / NextCMS = outil.
"jpv" a écrit :
L'utilisation des normes de langage n'offre aucun début de commencement de rien du tout quant à l'accessibilité elle-même.
De la même façon qu'on ne juge pas le travail d'un maçon à la qualité du ciment qu'il utilise, et même si c'est essentiel, on ne juge pas l'accessibilité d'un site à la normalisation des langages.
tout à fait, mais il était ici question de l'outil NextCMS, et pas sur la capacité de NextWeb à produire un site accessible.
pour reprendre mon exemple : pour le graph, Photoshop (ou Gimp, ou fireworks, je n'ai pas d'actions chez adobe
) c'est mieux que paint, ca offre plus de possibilités, de facilité et le résultat est plus pro.NextCMS c'est pareil vis-à-vis de l'accessibilité : c'est un outil qui permet de démarrer sur de bonnes bases, pour les éléments qu'il gère (en aucun cas les templates de page ne sont crées par le CMS lui-même, là c'est Nextweb (au sens prestataire) qui rentre en action).
Encore faut-il après que l'on souhaite utiliser cet outil dans l'optique 100% accessibilité, ce qui, je le redis, n'est pas encore arrivé compte tenu de nos clients, de leur marché, de leur budget,etc.
"jpv" a écrit :
Par exemple, en utilisant h2 pour spammer vous passez la validation technique mais en revanche vous êtes, stricto sensu, totalement hors de la norme que vous détournez
là où ce tag est utilisé (position dans le document), je ne pense pas qu'il y ait d'incohérence sémantique. Pour le contenu de ce tag, l'outil n'en est pas responsable. et comme évoqué plus haut, il est possible via l'outil de mettre autre chose que du <h2>, par exemple tout un article en xhtml sémantique et tout. nous devions offrir ce genre de fonctionnalité, même si ca ne me plait pas beaucoup vis à vis de ce que je pense de l'accessibilité.
"jpv" a écrit :
Cest extrèmement important d'être clair la dessus pour tuer l'idée que WCAG est validable par un processus automatique du même type qu'une validation de langage. Cette idée n'à aucun sens pour WCAG.
je pense l'avoir était en disant précedement que NextCMS n'est qu'une technologie, je le qualifie ici d'outil. j'ai dit que les 99% de l'accessibilité n'ont rien à voir avec le CMS, mais qu'au moins NextCMS assure ce 1%, ce que beaucoup d'autres outils ne font pas.
pour les 99% restant, ben c'est le prestataire qui rentre en jeu. Nous travaillons d'ailleurs à une mise à disposition à d'autres prestataires de l'outil nextCMS.
"jpv" a écrit :
En terme de pédagogie c'est catastrophique et en terme de perception des compétences de nextCMS c'est tragique.
NextCMS n'a pas de compétences, c'est un outil. il dispose de fonctionnalités. (j'insiste sur ce point, mais je pense que ca peut lever quelques ambiguités : NextCMS != Nextweb)
NextCMS ne permet pas de créer de site web, il faut nécessairement un prestataire (nous ou un autre avec notre solution revendeurs/partenaires).
"jpv" a écrit :
Si cette dialectique est une réponse cironstanciée à la concurence c'est que vous vous trompez de concurrents : ceux là n'ont aucun avenir sur ce marché.
on ne choisit pas les concurrents que l'on "affronte". petit exemple relativement récent :
Une institution strasbourgeoise fait un appel d'offre pour un site quelconque.
Contraintes sur le cahier des charges : respecter les normes W3C ( (HTML ou XHTML et CSS, dont rien d'exigeant on est d'accord), l'accessibilité viendra dans un second temps. Mise à disposition d'un outil de gestion de contenu et d'emailing.
bref, nous répondons, avec la propo création de site + mise à disposition de NextCMS
nous arrivons en finale (5 à 6 prestataires consultés au départ) et malheuresement le backoffice du CMS du concurrent en question était plus soigné que le notre à cette époque.
nos fonctionnalités et l'ergonomie de notre outil étaient bien meilleures (je connais très bien ce produit concurrent, ce n'est pas un opensource non plus), mais voilà, ca s'est joué sur çà lors de la démo (le concurrent ayant bien sur clamé haut et fort qu'ils savaient faire du standard W3C)
le concurrent a donc réalisé la presta : 1ère page : 79 erreurs au validateur W3C.
alors bien sur maintenant ils doivent être grillés (jusqu'à ce qu'ils corrigent éventuellement le tir) pour les marchés de cette institution, mais bon, j'avoue que ca me reste en travers de la gorge.
NB : ce site est en ligne depuis octobre, et rien n'a été corrigé, et sans doute que rien ne le sera.
"jpv" a écrit :
regardez comme nous écrivons bien, la preuve : il n'y à aucune faute d'hortographe"
bien sur que ca ne suffit pas, mais c'est la base minimum pour se comprendre. pour transposer l'exemple du site institutionnel cité + haut, c'est comme de remettre une dissertation avec une faute toutes les 2 lignes : c'est dur à lire et à comprendre.
et rien que celà entrave l'accessibilité du contenu selon moi.
pour moi, un quota raisonnable est une faute toutes les 3 lignes
"jpv" a écrit :
Si il y à une compétence à valoriser ce n'est pas celle là, mais celle de l'utilisation de CSS associé au concept de séparation de la structure, du contenu et de la présentation.
nous valorisons énormément cet aspect des choses (y compris les styles alternatifs, print, etc...) auprès des clients lors de nos démos. sur le papier celà me semble assez compliqué à expliquer.
on en profite d'ailleurs toujours pour tendre une perche en faveur de l'accessibilité complète (celle qui ne dépend pas du CMS).
et effectivement, les clients sont très réceptifs à celà.
"jpv" a écrit :
Là aussi je ne peut qu'être dur : Le spam indexing c'est la plaie du web.
oui, tout à fait, je ne suis on ne peut plus d'accord, mais la réalité est la suivante, nos 2 options actuellement :
- on ne propose pas ce genre de solution : la concurrence peut s'engouffrer dans la faille, certes infondée. après nous argumentons, le concurrent argumente. parfois ca passe, parfois pas. les concurrents ont la facheuse tentance à être très forts dans ce genre de discours.
- on la propose, en mettant en garde que c'est pas bien dans l'absolu, etc...
nous avons choisi la seconde solution, suite aux déceptions que nous avons du subir quand nous ne proposions pas cette fonctionnalité.
par ailleurs, je le reprécise, (je sens bien que c'est surtout le <h2> qui te gène), il est tout à fait possible d'écrire du vrai texte, structuré, sémantique, parfaitement intelligible. C'est en fait un "article masqué", dont le contenu ne regarde que celui qui le rédige.
"jpv" a écrit :
On ne peut que les condamner et espérer que les moteurs développent des techniques de détection fiable de ces "astuces de la mort qui tue" et puisses éradiquer définitivement les sociétés qui y ont recours.
bien entendu que j'aimerai ne pas avoir à proposer du tout ce genre de solution.
mais une chose est claire chez nous, le référencement se fait dans cette façon (par ordre d'importance) :
- le contenu des éléments visibles est primordial : nous aidons nos clients à rédiger leur textes pour avoir les bons mots clés, occurences et expressions.
- le titre de la page (<title>)
- l'url de la page
- keywords et description
- référencement caché
en parallèle de çà, nous utilisons :
- la structure de la page (contenu principal en haut, menus de navig et éléments accessoires en bas)
- google sitemaps
Modifié par nextweb (20 Mar 2006 - 12:25)
Bonjour,
@Julien :
Chose promise chose du...
Je ne poursuivrai pas le débat sur les fonctionnalités de référencement, ce n'est pas le lieu.
En revanche je persiste : un contenu caché à destination du référencement, quelque soit sa nature, est à proscrire et pas seulement pour des raisons d'éthiques :
C'est formellement interdit par la charte de tous les moteurs de référencement.
Cela trompe les moteurs de recherche mais aussi tout dispositif de recherche documentaire qui pourrait être utilisé pour accéder plus rapidement à l'information.
Enfin si ces textes demeurent cachés aux lecteurs d'écrans ce n'est pas le cas pour les navigateurs en mode texte sur lequel ils viendront polluer inutilement la lecture de la page.
Pour le reste de mes remarques sur l'accessibilité :
Le sujet de l'accessibilité des CMS est un sujet crucial comme le repète régulièrement à juste titre l'ami Laurent Denis.
Si le code html est généralement correct on va retrouver pas mal de problèmes au niveau de la structure, de la pertinence du balisage et des alternatives.
Dans ces défaillances, la question de l'utilisateur et des fonctionnalités qu'on lui fournit est évidemment le ventre mou d'un CMS dés lors et c'est bien normal que l'utilisateur est supposé produire du contenu sans connaissance particulière.
Nous somme là dans une problématique absolument identique à celle des traitements de texte : toutes les fonctionnalités existent et on continue inlassablement à faire des titres en grossissant la police et en changeant la couleur.
Sur ce point je suis d'accord avec toi, c'est l'utilisateur qui fera l'accessibilité de ses contenus publiés.
Mais, et c'est bien le fond de ma critique sur la présentation de nextCMS : cette idée particulièrement importante n'est jamais présentée sur le site, au contraire, la dialectique que vous employez peut faire croire que c'est l'outil qui va "faire" l'accessibilité.
Et c'est bien dommage parce que cela alimente un "mythe" du même ordre que celui du recours à des outils automatiques de validation ou encore pire les outils de transformation et dont il est bien difficile de se débarrasser.
Je ne critique donc pas les fonctionnalités de nextCMS mais la "philosophie" du produit qui en tentant de gérer des antagonismes finis par brouiller le message initial.
Pour les critiques de détails sur les front-end que j'ai visité, je reste surpris d'un certaine nombre de chose, en dehors de la problématique conception/utilisateur, je les reprends une par une avec tes remarques :
Si, je suis désolé de le dire mais ceci :
Ce n'est pas un titre, c'est tout. En loccurence la valeur sémantique attachée à cet élément est fondamentalement détournée.
Mais bien sur, remplacer l'élément h innaproprié par un p ferait sans doute un peut "amateur" par rapport au référencement expert et optimisé
Ce n'est pas ce qui est important, ce qui est important à comprendre c'est qu'en présentant cette possibilité comme une fonctionnalité de nextCMS vous dites ceci :
"Cacher du texte et utiliser un détournement de balisage pour optimiser le référencement est une pratique normale et ne pose pas de problème en terme d'accessibilité".
C'est absolument faux : c'est anormal et cela nuit gravement à l'accessibilité.
Je comprends bien votre problème par ailleurs mais bon il faut choisir son camp et même si l'accessibilité est avant tout l'art du compromis, celui là n'est pas acceptable.
Un exemple parmis d'autres : sur la page référence clients du site nextcms nous trouvons cette hiérarchie de titre :
Ce qui n'est pas satisfaisant, ce n'est pas un simple "accident" car on trouve pas mal d'autre exemple de ce genre dans les sites en référence.
Je précise quand même que le problème de la hiérarchie des titres dans un CMS est effectivement un problème compliqué...
Bien sur on ne peut pas controler ce que fait un utilisateur qui à loisir d'inclure des images dans son contenu et que vous n'êtes effectivement pas responsable de ça.
En revanche, vous êtes absolument responsable de ce qui est fait sur le site de nextCMS et cette image est très problématique : c'est l'exemple de ce qu'il ne faut jamais faire en matière d'accessibilité.
D'ou mon incompréhension.
Là aussi vous choisissez un compromis dangereux qui est de dire "regardez avec nextCMS vous pouvez faire des effets graphiques sur du texte, c'est simple vous faites une image, ça ne pose pas de problème en terme d'accessibilité".
Là aussi c'est absolument faux.
Le client ne devrait pas avoir à poser cette question parcequ'il ne devrait pas voir ce genre d'image sur un site qui parle d'accessibilité.
CE ne sont sans doute que des détails mais j'ai trouvé quelque fois des choses étranges :
Bon, c'est sans doute collatéral à l'utilisateur j'en conviens.
Non, je parle de l'ordre de tabulation sur la page elle-même, par exemple sur la page de nextCMS la tabulation débute sur le fil d'ariane, file au contenu, puis au menu à gauche, descends en bas de page et remonte au menu principal.
C'est très pertubant, par exemple pour un utilisateur qui ne peut pas utiliser de souris.
La tabulation doit respecter un ordre logique et naturel, c'est un élément très important.
Par exemple, dans le cas de nextCMS, vous avez choisis d'organiser le flux en contenu>menu mais pour la représentation graphique vous faites : menu>contenu.
Ce n'est pas un soucis dans la mesure où vous êtes capable de proposer une méthode aux utilisateur privés de souris pour navigeur de manière cohérente dans cette structure : soit par tabindex (ce qui posera de très gros problèmes d'implémention) soit au minimum en implémentant des liens d'évitements.
Oui, la gestion des alternatives textuelles ne peut être résolue que par la pédagogie..
Mais là aussi, ce qui m'à choqué c'est que sur votre site qui devrait avoir valeur d'exemple on à des problèmes d'alternatives absentes ou redondantes.
Et là aussi c'est bien dommage parcequ'il y à par ailleurs un bon traitement des alternatives pertinentes.
C'est une très bonne idée mais préparez vous à devoir faire pas mal de compromis sur les compromis actuels...
Jean-pierre
Modifié par jpv (28 Mar 2006 - 09:46)
@Julien :
Chose promise chose du...
Je ne poursuivrai pas le débat sur les fonctionnalités de référencement, ce n'est pas le lieu.
En revanche je persiste : un contenu caché à destination du référencement, quelque soit sa nature, est à proscrire et pas seulement pour des raisons d'éthiques :
C'est formellement interdit par la charte de tous les moteurs de référencement.
Cela trompe les moteurs de recherche mais aussi tout dispositif de recherche documentaire qui pourrait être utilisé pour accéder plus rapidement à l'information.
Enfin si ces textes demeurent cachés aux lecteurs d'écrans ce n'est pas le cas pour les navigateurs en mode texte sur lequel ils viendront polluer inutilement la lecture de la page.
Pour le reste de mes remarques sur l'accessibilité :
Le sujet de l'accessibilité des CMS est un sujet crucial comme le repète régulièrement à juste titre l'ami Laurent Denis.
Si le code html est généralement correct on va retrouver pas mal de problèmes au niveau de la structure, de la pertinence du balisage et des alternatives.
Dans ces défaillances, la question de l'utilisateur et des fonctionnalités qu'on lui fournit est évidemment le ventre mou d'un CMS dés lors et c'est bien normal que l'utilisateur est supposé produire du contenu sans connaissance particulière.
Nous somme là dans une problématique absolument identique à celle des traitements de texte : toutes les fonctionnalités existent et on continue inlassablement à faire des titres en grossissant la police et en changeant la couleur.
Sur ce point je suis d'accord avec toi, c'est l'utilisateur qui fera l'accessibilité de ses contenus publiés.
Mais, et c'est bien le fond de ma critique sur la présentation de nextCMS : cette idée particulièrement importante n'est jamais présentée sur le site, au contraire, la dialectique que vous employez peut faire croire que c'est l'outil qui va "faire" l'accessibilité.
Et c'est bien dommage parce que cela alimente un "mythe" du même ordre que celui du recours à des outils automatiques de validation ou encore pire les outils de transformation et dont il est bien difficile de se débarrasser.
Je ne critique donc pas les fonctionnalités de nextCMS mais la "philosophie" du produit qui en tentant de gérer des antagonismes finis par brouiller le message initial.
Pour les critiques de détails sur les front-end que j'ai visité, je reste surpris d'un certaine nombre de chose, en dehors de la problématique conception/utilisateur, je les reprends une par une avec tes remarques :
jpv a écrit :
Des balises h2 cachées
nextweb a écrit :
je ne pense pas qu'il y ait d'incohérence sémantique
Si, je suis désolé de le dire mais ceci :
Gestion contenu XML XUL, NextCMS : gestion de contenu W3C et respectant les normes de l’accessibilité des sites publics. Systeme gestion de contenu. Outil simple et ergonomique.
Adminstrer son site internet sans connaissances informatiques. Référencement optimisé et expert.Ce n'est pas un titre, c'est tout. En loccurence la valeur sémantique attachée à cet élément est fondamentalement détournée.
Mais bien sur, remplacer l'élément h innaproprié par un p ferait sans doute un peut "amateur" par rapport au référencement expert et optimisé
Ce n'est pas ce qui est important, ce qui est important à comprendre c'est qu'en présentant cette possibilité comme une fonctionnalité de nextCMS vous dites ceci :
"Cacher du texte et utiliser un détournement de balisage pour optimiser le référencement est une pratique normale et ne pose pas de problème en terme d'accessibilité".
C'est absolument faux : c'est anormal et cela nuit gravement à l'accessibilité.
Je comprends bien votre problème par ailleurs mais bon il faut choisir son camp et même si l'accessibilité est avant tout l'art du compromis, celui là n'est pas acceptable.
jpv a écrit :
Une structure de titre plus que problématique ce qui montre à tout le moins un manque de compréhension du sujet.
nextweb a écrit :
je ne suis pas persuadé de comprendre la remarque, tout comme bernard.s qui a initié ce sujet.
Un exemple parmis d'autres : sur la page référence clients du site nextcms nous trouvons cette hiérarchie de titre :
h1 Références clients
h2 Références clients
h3 Nos clients utilisent NextCMS
h2 Sous-menu
h2 Inscription newsletter
h2 Menu principalCe qui n'est pas satisfaisant, ce n'est pas un simple "accident" car on trouve pas mal d'autre exemple de ce genre dans les sites en référence.
Je précise quand même que le problème de la hiérarchie des titres dans un CMS est effectivement un problème compliqué...
jpv"
Une magnifique image qui contient profusion de texte.[/quote a écrit :
[quote=nextweb]
ah, ces graphistes
Bien sur on ne peut pas controler ce que fait un utilisateur qui à loisir d'inclure des images dans son contenu et que vous n'êtes effectivement pas responsable de ça.
En revanche, vous êtes absolument responsable de ce qui est fait sur le site de nextCMS et cette image est très problématique : c'est l'exemple de ce qu'il ne faut jamais faire en matière d'accessibilité.
D'ou mon incompréhension.
nextweb a écrit :
le client : "oui, mais vous vous aviez du texte en couleur, une typo de fou et un arrière plan dans ce bloc de texte ! je veux faire la même chose dans le wysiwyg"
Là aussi vous choisissez un compromis dangereux qui est de dire "regardez avec nextCMS vous pouvez faire des effets graphiques sur du texte, c'est simple vous faites une image, ça ne pose pas de problème en terme d'accessibilité".
Là aussi c'est absolument faux.
Le client ne devrait pas avoir à poser cette question parcequ'il ne devrait pas voir ce genre d'image sur un site qui parle d'accessibilité.
nextweb a écrit :
conteneurs vides : effectivement, quand je dois ajouter une image "décorative" (séparation, barre de couleur quelconque, ...) j'utilise parfois un <div> vide, qui via CSS prendra une couleur, un background, une hauteur en fonction du rendu à obtenir.
CE ne sont sans doute que des détails mais j'ai trouvé quelque fois des choses étranges :
<p>
</p>
<p>
<br />
</p
<p><b></b></p>
<p> </p>
<hr>
Bon, c'est sans doute collatéral à l'utilisateur j'en conviens.
jpv a écrit :
Une structure de tabulation illogique...
nextweb a écrit :
je ne suis pas sur de comprendre, mais si tu parles de l'indentation du code source, c'est vrai que c'est pas tabulé de haut en bas comme il faudrait, mais j'ai vu pire également.
Non, je parle de l'ordre de tabulation sur la page elle-même, par exemple sur la page de nextCMS la tabulation débute sur le fil d'ariane, file au contenu, puis au menu à gauche, descends en bas de page et remonte au menu principal.
C'est très pertubant, par exemple pour un utilisateur qui ne peut pas utiliser de souris.
La tabulation doit respecter un ordre logique et naturel, c'est un élément très important.
Par exemple, dans le cas de nextCMS, vous avez choisis d'organiser le flux en contenu>menu mais pour la représentation graphique vous faites : menu>contenu.
Ce n'est pas un soucis dans la mesure où vous êtes capable de proposer une méthode aux utilisateur privés de souris pour navigeur de manière cohérente dans cette structure : soit par tabindex (ce qui posera de très gros problèmes d'implémention) soit au minimum en implémentant des liens d'évitements.
jpv a écrit :
Un manque d'alternative textuelle quand il le faut et d'autres inutiles ou innapropriées.
a écrit :
ah ces intégrateurs de contenu (après les graphistes, décidement) !
Oui, la gestion des alternatives textuelles ne peut être résolue que par la pédagogie..
Mais là aussi, ce qui m'à choqué c'est que sur votre site qui devrait avoir valeur d'exemple on à des problèmes d'alternatives absentes ou redondantes.
Et là aussi c'est bien dommage parcequ'il y à par ailleurs un bon traitement des alternatives pertinentes.
a écrit :
accessibilité : sans doute énormément à apprendre et à faire. dans ce but, nous allons suivre une formation accessiweb (5jours) pour compléter les manques.
C'est une très bonne idée mais préparez vous à devoir faire pas mal de compromis sur les compromis actuels...
Jean-pierre
Modifié par jpv (28 Mar 2006 - 09:46)