Accessibilité et SEO : amies ou ennemies ?

Fréquemment, les notions d’accessibilité et de SEO (Search Engine Optimization, Optimisation pour les moteurs de recherche) sont présentées comme des domaines connexes de la qualité web. Plus précisément, les promoteurs de l’accessibilité du web font valoir le fait qu’un site accessible aura un bon référencement. C’est un argument fort en faveur de l’investissement sur l’accessibilité d’un site, puisque cette action devrait permettre d’économiser des frais d’optimisation de référencement. D’ailleurs, lorsque je forme des spécialistes de SEO à l’accessibilité, ils me confirment que 80% des critères d’accessibilité correspondent à des bonnes pratiques de SEO. Perception empirique bien sûr, mais assez partagée par mes interlocuteurs.

On pourrait se satisfaire de ce plébiscite. Mais qu’en est-il des 20% manquants ? Est-ce qu’ils sont totalement neutres ? Ou cachent-ils au contraire une opposition de pratiques ? Cet article propose d’explorer les limites de cette association a priori vertueuse de l’accessibilité et du référencement.

Notes préliminaires

En fait de SEO, on parle ici d’optimisation du code pour les moteurs de recherche. Ce qui correspond exactement au rayon d’action des webdesigners et développeurs web. L’activité d’un expert en référencement englobe bien plus de types d’interventions, essentiellement hors page, comme le décrit très bien l’article « Why SEO comes first » (en anglais). Par souci de simplification, cet article raccourcit « l’optimisation du code pour les moteurs de recherche » en « SEO ».

Comme le suggère le nom de ce blog, mon champ de spécialité est l’accessibilité. J’ai une connaissance superficielle des pratiques SEO, glanées au travers de mes expériences projet, d’interactions avec les spécialistes du SEO, et de quelques lectures. Les puristes trouveront certainement quelques erreurs ou approximations insupportables. Si c’est le cas, ruez-vous sur le formulaire de commentaires, il est là pour ça !

C’est vrai qu’accessibilité et référencement, c’est un peu pareil

On peut voir l’accessibilité comme une action visant à rendre un contenu web compréhensible au travers d’un logiciel d’analyse de texte. En effet, un lecteur d’écran, utilisé notamment par les personnes malvoyantes ou non-voyantes, analyse le contenu de l’écran, et le restitue, soit sous forme vocale, soit sous forme d’écriture Braille. Dans le cas d’un contenu web, le lecteur d’écran parcourt une copie de la page web, telle que la présente le navigateur une fois qu’il l’a lui-même interprétée. Le lecteur d’écran déroule la page dans l’ordre du code source, et interprète ce qu’il y trouve. En ce sens, on retrouve le principe de fonctionnement d’un robot d’indexation (les agents logiciels qui parcourent le web et rapportent leurs trouvailles aux bases de données des moteurs de recherche). Du reste, on retrouve souvent l’adage « Google est aveugle », pour illustrer cette similitude de fonctionnement.

Attends, c’est encore mieux que ça

Si Google est aveugle, il se trouve qu’il est également sourd, démuni de perception spatiale, dépourvu de souris, insensible aux couleurs et mouvements, pas très à l’aise avec les images, les vidéos, les animations de toutes sortes, pas très outillé question CSS et JavaScript… bref, Google cumule quasiment toutes les situations de handicap qu’on puisse imaginer dans le cadre de l’utilisation du web. A côté de cela, c’est un visiteur qu’il vous faut chouchouter, vu le potentiel de copains qu’il peut ramener sur vos pages… il est donc clair que les aménagements d’accessibilité, visant à s’adapter à toutes les situations utilisateurs, favoriseront le travail d’indexation. L’usage cohérent et approprié de structures de textes telles que des titres de pages, des titres de sections, des balises sémantiques (c’est-à-dire porteuses d’une information implicite), aideront le robot à avoir une vision plus précise du rôle des différents morceaux de texte. Des alternatives aux contenus visuels et sonores, des éléments de description textuelle pertinents, compenseront ses limites sensorielles. Toutes choses également nécessaires pour les utilisateurs qui n’accèdent pas aux contenus de la page dans leurs dimensions graphique et auditive.

Donc Google et un utilisateur handicapé, c’est pareil ?

C’est là que ça se gâte. Car si un lecteur d’écran et un robot d’indexation ont des modes d’action similaires, leurs besoins sont différents, et donc la façon optimale de les satisfaire n’est pas forcément la même.

Un utilisateur humain devra être en mesure de comprendre n’importe quel élément de la page, et l’utiliser pour réaliser les tâches qu’il a choisies de réaliser. Pour le servir correctement, tous les éléments doivent lui être intelligibles, et actionnables au besoin, quel que soit le mode de restitution dont il dispose. Il faudra également éliminer les informations parasites, qui vont encombrer le contenu et en réduire l’efficacité.

Un moteur de recherche vise à caractériser une page par des mots-clés. Pour le satisfaire au mieux, il faudrait l’amener à comprendre quels sont les mots-clés les plus pertinents pour décrire cette page. Un expert SEO travaillera donc à mettre en avant les mots-clés qu’il aura choisis comme étant ceux pertinents pour amener les internautes sur sa page.

Souvent ces deux objectifs conduiront à un résultat proche. Mais pas toujours. Imaginons une page où l’on vend un voyage aux Maldives, et examinons les choix que pourraient faire nos experts Robert Accessibilité et René SEO, tous deux chargés d’optimiser la même page en fonction de leurs missions respectives.

Quelques exemples de divergences possibles

Les titres de section

Robert Accessibilité et René SEO savent tous deux que les titres de section sont importants : l’utilisateur humain peut s’appuyer dessus pour naviguer plus rapidement dans la page ; le robot d’indexation va considérer les mots dans ces titres comme plus importants, plus saillants. Robert va donc choisir des titres qui décrivent efficacement chaque section. Mais René va choisir des titres qui donnent à manger au robot du « Voyage aux Maldives ». On pourrait donc avoir pour Robert :

  • Description
  • Hébergement
  • Formalités

Et pour René :

  • Voyage aux Maldives : Description
  • Voyage aux Maldives : Hébergement
  • Voyage aux Maldives : Formalités

Pas très grave à première vue, mais si René SEO gagne le bras de fer en réunion de stratégie de contenu, certes, Google sera très enclin à penser que cette page a quelque chose à voir avec un voyage aux Maldives. En revanche, notre pauvre utilisateur va se cogner beaucoup d’informations parasites, qui vont dégrader son expérience de navigation.

Les images de décoration

On va retrouver une problématique similaire pour les images de décoration. On parle ici de toutes les images qui n’apportent pas d’information supplémentaire à ce que l’on trouve déjà dans le texte. Ce sera le cas notamment des images destinées à vous faire baver d’envie, et à chercher machinalement où se trouve votre carte bancaire.

Pour Robert Accessibilité, pas de doute, ces images ont beau être superbes, elles n’ont pas vocation à fournir une information qui n’est pas déjà dans le texte. Allez hop, alternative vide, et l’utilisateur lui dit merci.

Pour René SEO, c’est pas la même histoire. Les alternatives aux images sont des opportunités de caser du mot-clé, de façon invisible et tout-à-fait légitime du point de vue du moteur de recherche. Et puis, allons-y, on a en plus l’attribut title, l’aubaine !

Si René suit sa ligne de conduite, il va donc chercher à tout prix à fourrer du « Voyage aux Maldives » dans un maximum d’images. Mais l’utilisateur humain, chouchou de Robert, va grincer des dents en subissant à longueur de page des répétitions de l’expression « Voyage aux Maldives ».

Les liens d’interface

A ce stade, si René SEO a obtenu gain de cause, Google doit se douter que cette page a sûrement un rapport avec l’idée de voyage aux Maldives. Mais on peut encore aller plus loin. Car pour que la densité de mots-clés choisis soit encore plus grande, une fois qu’on en a augmenté la quantité, on va chercher à réduire la proportion d’autres mots-clés potentiels. Et donc chercher à éliminer au maximum tout ce qui ne parle pas strictement de voyage aux Maldives.

Imaginons qu’un panneau de recherche détaillée puisse être affiché ou masqué en cliquant sur une zone de la page. Robert Accessibilité pourra exiger un lien « Afficher la recherche détaillée », qui se transformera en « Masquer la recherche détaillée » une fois actionné. Mais pour René SEO, ce lien entre en concurrence avec les autres liens, tout en ayant le même poids. Les mots « recherche détaillée », de faible valeur en termes de référencement, seront pourtant analysés par le moteur de recherche comme aussi descriptif que « Voyage aux Maldives » qu’on trouvera dans d’autres liens. René SEO s’en offusquera, et poussera pour que le texte soit placé dans un élément neutre (un DIV par exemple), que l’on dotera d’une détection de clic souris. Robert Accessibilité en avalera sa grille d’audit, néanmoins cette approche est logique du point de vue SEO, car on limite ainsi l’importance de mots non descriptifs.

(Note : sur cet exemple, Robert et René seraient sans doute réconciliés par l’usage d’un élément bouton, comme le décrit très bien cet article de Babylon Design : Sus au <a href= »# »>. Mais ce sera pour un autre billet.)

Et d’autres encore

On a vu trois exemples très banals de choix de conception, où accessibilité et SEO n’auront pas les mêmes priorités, et donc pas les mêmes décisions. Il en est bien d’autres : titres de liens, balises de renforcement et d’emphase à la pelle, multiplication de liens soi-disant de navigation, textes plus ou moins habilement masqués… De nombreuses bonnes raisons de se méfier de cet amalgame un peu trop rapide, un peu trop fréquent, entre accessibilité et SEO.

Ok, mais alors on fait quoi avec tout ça ?

Il semblerait que de manière générale, une page accessible soit très correctement indexée. Mais avec les mots-clés qu’elle contient effectivement, qui ne sont pas forcément ceux que l’on souhaite, dans l’idéal, pour la décrire du point de vue d’un moteur de recherche.

A l’inverse, une page optimisée purement pour les moteurs de recherche, peut léser un utilisateur, non pas en termes d’accès à l’information, mais en termes de pertinence du contenu.

Je dirais que plutôt que le SEO, l’accessibilité favorise donc « l’indexabilité » d’une page ou d’un site, c’est-à-dire sa lisibilité pour un outil d’indexation. En revanche cela ne signifie pas forcément qu’elle soit optimisée pour sa « trouvabilité » par un moteur de recherche sur des mots-clés choisis. (et là, mon quota de mots inventés est épuisé pour cet article).

Donc, sur certains points d’achoppement, le choix de favoriser Robert ou René peut se ramener au choix entre favoriser l’utilisateur humain ou Google. Or, on l’a vu, il est tentant de bichonner Google et consorts, considérant qu’ils nous ramèneront beaucoup plus de monde, et donc beaucoup plus de revenus potentiels. La bataille est injuste, René SEO a l’argument qui tue. Mais Robert ne devrait pas désespérer. Il a pour lui ce fait simple et pourtant trop souvent négligé : c’est lui qui s’occupe vraiment des vrais gens, qui achètent vraiment des produits avec de l’argent réel. Le trafic pour le trafic n’a pas de sens en soi dans la plupart des modèles économiques, sauf si on vend de la bande passante… Ce qui compte c’est la conversion de l’acte de navigation en acte d’achat.

Donc René et Robert vont devoir défendre leurs points de vue respectifs en évaluant non pas le bénéfice de chacun, mais le point d’équilibre des deux : trop de SEO créera certes plus de trafic, mais moins de conversions, tandis que la pure accessibilité fait prendre le risque d’un moindre trafic, tout en préservant ses chances de ne pas déplaire. Il s’agira donc pour l’un et l’autre de trouver le bon compromis entre pousser dans un sens sans pénaliser l’autre, et inversement.

Pour ma part, mon choix de spécialisation (et même de vie, hein, n’ayons pas peur des mots), m’incite à penser qu’aucun des artifices décrits ci-dessus n’a une influence suffisante sur le trafic pour valoir le coup. Mais c’est bien entendu à confronter avec des données objectives, choses très difficiles à constituer tant en SEO qu’en accessibilité. Ce sera donc généralement une affaire d’opinions.

Quoiqu’il en soit, il est vital de garder à l’esprit le fait que ce qui, in fine, assure le succès d’un produit ou contenu vendu sur le web, n’est pas le trafic généré, ni la qualité de l’expérience utilisateur, aussi démente soit-elle. C’est la qualité intrinsèque de ce produit, qui résulte d’un mix entre sa valeur et son coût, perçus pour l’acheteur. Sur ce point, l’accessibilité ne détériore pas cette qualité intrinsèque, tandis que le SEO peut la dégrader, pour certains utilisateurs au minimum. C’est peut-être sur cet argument que Robert Accessibilité aura gain de cause…

Et vous, quel est votre point de vue sur ce rapprochement? De quelles expériences de convergence ou de divergence pouvez-vous témoigner?

25 thoughts on “Accessibilité et SEO : amies ou ennemies ?

  1. À ta place, j’aurais remplacé « indexabilité » par référencement (en effet, une URL référencée est une URL qui est indexée par les moteurs de recherche, chose qu’on peut vérifier au moyen de la requête site:URL) et « trouvabilité » par positionnement. Comme quoi, il n’y a pas besoin d’inventer des mots qui ne sont pas le dico, comme diraient Les Inconnus. ;-)

    Méticulage de mouches à part, ce billet rappelle que, malheureusement, certaines préconisations émises par les experts en référencement vont parfois à l’encontre du bon sens. Il m’est arrivé de tomber sur un profil de ce genre qui m’a imposé une hiérarchie de titres de section non pertinente débutant par un h2 suivi d’un h1, par exemple, par obsession du référencement. Je connais même un intégrateur freelance qui a eu affaire, parmi ses clients, à une agence Web dont l’équipe dédiée au référencement est allée jusqu’à préconiser d’utiliser un élément h7 (oui, oui, tout le monde a bien lu et je rappelle que l’élément h7 ne fait partie d’aucun standard HTML) pour baliser telle partie de page !

    Bref, même si j’ai touché au référencement avant d’embrasser l’accessibilité, sans hésitation je suis Robert. ;-)

    • Merci Rob… pardon, Victor, pour ces anecdotes édifiantes. Il est clair que certains référenceurs trop zélés seraient prêts à vendre père, mère, et Tim Berners-Lee pour un meilleur Pagerank.
      Dans mes exemples, je me suis attaché à présenter des situations où il peut y avoir discussion, car on est sur des critères qui comportent une part de subjectivité. La pertinence d’un titre de section peut donner lieu à débat. Avec un brin de mauvaise foi, on peut défendre la version de René, car si elle n’est pas optimale pour l’utilisateur, elle n’est pas non plus totalement incorrecte. C’est sur ce genre de situation que l’expert accessibilité doit faire preuve d’une connaissance approfondie des besoins de l’utilisateur pour argumenter ses choix. En revanche, un H7, ou un H2 mal placé seront clairement disqualifiés par le référentiel (en tout cas, par RGAA et Accessiweb ), donc ça nécessite d’enfreindre sciemment des critères, ce qui est une autre paire de manches.
      Pour ce qui est des termes inventés: ce que j’essaye de décrire ici, ce sont des caractéristiques intrinsèques à la page, indépendamment de leur effet sur les performances SEO. Un peu comme la vitesse maximale et l’accélération d’une voiture, qui sont des éléments de description de l’objet, pas de sa capacité à gagner des courses (même s’il y a un lien). « Référencement » ne me convenait pas, car comme décrit dans l’article sur le SEO en lien dans le billet, cela recouvre bien d’autres aspects que la seule optimisation du code: création de liens entrants, gestion de la publicité,diffusion via les réseaux sociaux, etc. De même que « positionnement », qui dans ma compréhension des choses, est le résultat de la démarche, pas une caractéristique descriptive de la page. Donc, je tiens à ces deux termes, qui bien que hors dico, me semblent appropriés pour décrire les effets d’une mise en accessibilité et d’une optimisation du code pour les moteurs de recherche.

    • Merci Yann. C’est intéressant car cela illustre mon propos: on y trouve facilement des exemples de bonnes pratiques qui vont à l’encontre de bonnes pratiques d’accessibilité. Exemples? La n° 5: « Les termes présents dans l’alternative textuelle des images sont également présents dans le contenu de la page ». En général, en accessibilité, on évitera de répéter dans les alternatives des termes déjà présents dans le texte, car cela créé des répétitions inutiles, et pénibles à la longue en lecture vocale. La 11: « Le contenu visé pour le référencement est mis en exergue (strong ou em) ». Pour l’accessibilité, on ne mettra en exergue que les termes qui le « méritent » dans le contenu, et ce n’est pas forcément ceux visés pour le référencement.
      Donc si les deux listes de bonnes pratiques, SEO et accessibilité, viennent à être utilisées sur un projet, on devra gérer des contradictions. Ma crainte est que l’accessibilité en pâtisse, d’où ce billet en forme d’alerte.
      Idée pour Opquast: en plus des listes individuelles, des combinaisons de listes? Du genre: si accessibilité ET SEO sont des objectifs du projet, quelle liste est la liste résultante du croisement des deux?

      • On en vient donc à l’objet du billet ;-)

        Dans le cas précis n°5, non, il n’y a pas d’incompatibilité entre la BP SEO et WCAG. Un contenu textuel sur la rose (cultivar) X dans la boutique d’un pépiniériste en liste a de forte chance d’être illustré… par une photographie de la rose X. Je vois mal en quoi le fait de reprendre dans l’alternative le terme clé du contenu « X » serait un problème d’accessibilité ? (Je peux refaire le même avec les Maldives, si besoin).

        Le cas de la n°11 : étant donné l’impact infinitésimal, pour ne pas dire asymptotique à zéro, du balisage EM et STRONG en matière d’accessibilité, le risque de problème est déjà plus que limité, pour ne pas dire nul. Ensuite, comme dans l’exemple précédent, un contenu bien construit fera coïncider « les termes les plus importants » (mais ça n’est plus ça en HTML5, zut) et les mots clés ;-)

        Je comprends cette alerte, qui traduit une inquiétude attendue et légitime. Mais d’une part, Opquast ne travaille pas en créant des checklists antagonistes (le fait que je sois l’un des principaux auteurs de la checklist SEO devrait tout de même rassurer un peu, non ? ;-) ). D’autre part, il est temps de différencier certaines mauvaises pratiques à courte vue en SEO avec l’intégration du SEO dans la gestion qualité. Là, on sera en terrain solide, y compris côté accessibilité.

        • Bonjour,

          Pour reprendre le cas précis de la SEO N°5, isolée et sortie du contexte de la liste elle peut paraitre raisonnable, ou en tout ces relativement indifférente du point de vue de l’accessibilité.
          En revanche remise en perspective, notamment avec les des règles associées on obtient quelque chose de relativement curieux tout de même :
          SEO 1 « Chaque image ou élément non textuel est dotée d’une alternative textuelle  »
          Avec la précision qu’il s’agit de  » Placer des mots-clefs dans la page en dehors du texte directement visible par les visiteurs. » ce qui est pour le moins étrange du point de vue de l’accessibilité, sauf à considérer certains utilisateurs comme des visiteurs du soir ;).
          SEO 4 « La longueur des alternatives textuelles est inférieure ou égale à 80 caractères »
          Avec la recommandation « Le cas échéant, recourir à un automatisme du CMS pour tronquer les contenus automatiquement insérés comme alternative » ce qui est particulièrement, comment dire, surprenant.
          SEO 5 enfin « Les termes présents dans l’alternative textuelle des images sont également présents dans le contenu de la page. »
          Donc si je comprends bien en associant SEO 1 + 4 + 5 j’obtiens donc des images systématiquement décrites avec comme objectif principal la présence de mots clés, alternatives tronquées si nécessaire à 80 caractères.

          Faute de confier le référencement à des experts en accessibilité je doute beaucoup qu’on obtienne quelque chose de basiquement potable en terme d’accessibilité

          Ce qui me chagrine le plus d’ailleurs c’est que c’est exactement ce qu’on expliquait dans les années 90 quand on croyait que le alt était un attribut d’indexation.

          Du coup je vois pas bien le progrès et le rapprochement SEO/Access…

          • Très intéressant.
            Dans la mesure où je ne me sens ni d’un côté ni de l’autre, ni fan du seo ni exégète des règles d’accessibilité, je me penche la phrase suivante :

            « [..]en associant SEO 1 + 4 + 5 j’obtiens donc des images systématiquement décrites avec comme objectif principal la présence de mots clés, alternatives tronquées si nécessaire à 80 caractères. »

            Pour moi, il y a deux risques réels :
            1 Le risque que cette affirmation soit vraie en contexte, c’est à dire qu’effectivement, les images sont toutes décrites (ok) avec des mots-clés et des alternatives tronquées. Je pense qu’en fait, ça va se produire de temps en temps. Pas tout le temps, mais ça va se produire.
            2 Le risque que quand cela se produise, cela pose un vrai problème d’accessibilité à certains utilisateurs.

            Pour le premier risque, je pense qu’il va souvent être avéré si on n’y fait pas attention, mais les référentiels d’accessibilité sont aussi là pour ça, pour empêcher les conneries, en somme.
            Pour le deuxième, il me semble que les cas de vraies pertes d’information vont être rares. En revanche, nous sommes d’accord, cela peut constituer une nuisance en contexte de vocalisation, notamment.

            Bien, finalement, je dois choisir, et franchement, je ne sais pas. L’arbitrage n’est pas si évident que ça. Et pour arbitrer ce genre de choses, je ne demanderais ni à un consultant SEO, ni à un expert accessibilité. J’appellerais des amis non-voyants et PAS expert accessibilité NI consultants SEO, et je leur dirais :
            T’as vu, il y a plusieurs images systématiquement décrites avec comme objectif principal la présence de mots clés, et des alternatives tronquées si nécessaire à 80 caractères. Tu trouves ça gênant, pénible, insupportable?
            Et selon leur réponse, je prendrais ma décision. Les experts, les référentiels, c’est chouette. les utilisateurs, c’est mieux.

          • Elie, je pense que tu résumes très bien la problématique que la combinaison de listes de bonnes pratiques porte en germe. Dans de très nombreux cas, tout ira bien, dans d’autres, non. Ces cas seront plus rares mais ils existeront, la loi de Murphy s’appliquant en tous points de l’espace et du temps. Je pense qu’il y a un vrai travail de fond à mener sur la robustesse des référentiels croisés.
            Pour la méthode de décision que tu proposes: elle peut débloquer une interrogation ponctuellement. Mais elle pose deux problèmes assez rédhibitoires.
            D’abord la fiabilité: on aura comme résultat les préférences des personnes consultées, qui ne sera pas toujours la meilleure pour tout le monde. Même en élargissant l’échantillon à l’extrême, on n’aura pas forcément de réponse claire. Les enquêtes de WebAIM auprès des utilisateurs de lecteurs d’écran montrent une disparité de réponses trop grande pour en déduire une règle.
            Ensuite, l’industrialisation. Tu es dans une situation luxueuse où tu as accès à des utilisateurs en décrochant ton téléphone. Pour l’immense majorité des webmasters, c’est hors de portée. D’autre part, on parle ici d’un seul critère parmi une centaine, si on doit répliquer ce modèle à l’échelle d’un projet pour tous les critères, on n’aura du mal à justifier l’investissement. D’où le besoin, d’ailleurs, de règles solides qui permettent au webmaster d’être autonome.

        • Pour la photo de la rose, on est dans le même cas qu’une photo d’une personne dont la fiche détaillée nous donne tout ce qu’on doit savoir. En access, une alternative vide est correcte, une alternative non vide de type « photo de Truc Bidule » ne sera pas incorrecte. Du point de vue de l’utilisateur, ce n’est pas utile, sauf dans des situations qui ne relèvent pas de l’accessibilité à proprement parler (par exemple: indexation d’images, génération automatique de fiches, etc.). On est dans l’amélioration fonctionnelle (au sens: je rajoute des fonctions), pas dans l’accessibilité. Et c’est très bien! Simplement ne mélangeons pas les genres. Le point de départ de l’article, c’est: collègues de l’accessibilité, ne faites pas croire à vos interlocuteurs que Accessibilité est équivalent à SEO à 100%. Il y a des nuances, et c’est sur ces nuances que j’ai voulu mettre le doigt.
          Pour la BP 11: on est d’accord, mais il faut avoir ton recul et ta connaissance intime du sujet pour faire correctement cet arbitrage. Or, vous êtes combien à ton niveau? J’en compte 3 en France à part toi. Tous les autres travaillent avec ce qu’ils ont, à savoir les référentiels, et sur cette base brute, ça coince.
          Si les balises d’emphase sont aussi mal exploitées en accessibilité, c’est aussi un peu peut-être parce qu’on les a détournées de leur vocation première, et sacrifiées au Dieu Spider? Va savoir… Toujours est-il que dans les situations utilisateurs où ça devrait marcher du point de vue access, l’intervention SEO aura généré un biais, et c’est rageant.
          Et 100% en phase avec ta conclusion. C’est comme pour les chasseurs. Un mauvais expert, il voit un problème, hop, il tire! Alors qu’un bon expert, il voit un truc, hop, il tire…

  2. Ahem.

    Titres de section : René SEO est un peu brutal. Avec quelques progrès en SEO (par exemple en lisant Opquast et ses diverses listes), il produira des titres comportant des mots clés tout en étant plus pertinents d’une manière générale pour l’utilisateur, et au passage plus optimaux pour l’accessibilité en plaçant l’information clé en début de segment de texte. Disons par exemple, très grossièrement pour illustrer l’idée : « Description des Maldives », « Hébergement aux Maldives » et « Formalités de voyage aux Maldives ».

    Images décoratives. Tsss, allons, allons. Ne tombons pas dans la caricature, même si on la rencontre effectivement. C’est une question de qualité du SEO, pas de SEO en soi. (Même si j’aurais aimé un critère là-dessus dans… Opquast-SEO, mais ce sera pour sa prochaine version).

    Liens d’interface. Ah, non, là, pour le coup. « Le libellé de chaque hyperlien décrit sa fonction ou la nature du contenu vers lequel il pointe. » BP Opquast SEO N°32. Et puis « Les menus sont utilisables sans extension (flash…) ou activation de langages (CSS ou JavaScript..). », idem BP n°65. Donc pas de détour crapuleux par javascript pour s’arranger avec un libellé de lien ;-)

    Robert et René gagneront à lire une certaine check-list.

    Désolé, mais je n’ai pas m’en empêcher, tellement c’était un appel criant ;-)

    • Bon je vais en rajouter une couche mais pour les images, nous somme bien d’accord que la fiche SEO 1 indique comme solution technique :
      « Renseigner l’attribut ALT de chaque élément IMG, AREA, INPUT type image, APPLET »
      Du coup la crainte que cette directive soit appliqué à la lettre me parait relativement raisonnable :)

    • Ne t’excuse pas pour ton intervention, au contraire! Un débat est toujours plus intéressant qu’une opinion isolée.
      Tu as raison de relever le caractère caricatural de l’ami René. Je note que tu reconnais aussi que le bonhomme se rencontre au coin des projets malgré tout. Celui-là est plus pernicieux que le vrai gros bourrin, tel que signalé par Victor. Car ses positions sont défendables, même du point de vue accessibilité, en tirant sur l’élastique. Le but de cet article est de dire aux chargés d’accessibilité pas trop sûrs de leur art, qu’il y a matière à se méfier sur les cas limites qui n’en ont pas l’air.
      Tu fais référence à des BP d’Opquast, que je n’avais pas consultées pour rédiger cet article. Je ne suis pas sûr que tous les René du Web s’appuieront dessus non plus. Je ne connais pas le paysage des référentiels SEO et ne saurais donc dire ce qui est utilisé ou pas en la matière, sur le terrain.
      Que tu sois au cœur du truc, tend bien entendu à me rassurer. Malgré tout je ne suis pas totalement convaincu de l’innocuité des alternatives évitables, ou des titres un peu grassouillets. Quel est le bénéfice utilisateur? Je n’en vois pas (peut-être à tort), en revanche j’imagine assez bien la gêne. C’est sans doute une toute petite gêne, mais sur des situations aux limites (et c’est ce dont parle l’article), cette gêne sera réelle. Mon pari est que cette gêne n’est pas compensée par le bénéfice SEO, car finalement, le rôle de l’optimisation du code tendra à être négligeable par rapport à l’action globale de référencement, qui commence d’abord et avant tout par un contenu de valeur pour l’utilisateur. Je prétends que cette valeur augmente avec une bonne accessibilité (plus utilisabilité, ergonomie, patati patata). Mais que c’est moins sûr pour l’optimisation du code pour Google.
      Merci en tous cas pour ta contribution, ravi que le sujet crée débat!

    • (note: réinsertion manuelle d’un commentaire posté initialement le 15/12/2011, disparu suite à un problème d’import)
      Ne t’excuse pas pour ton intervention, au contraire! Un débat est toujours plus intéressant qu’une opinion isolée.
      Tu as raison de relever le caractère caricatural de l’ami René. Je note que tu reconnais aussi que le bonhomme se rencontre au coin des projets malgré tout. Celui-là est plus pernicieux que le vrai gros bourrin, tel que signalé par Victor. Car ses positions sont défendables, même du point de vue accessibilité, en tirant sur l’élastique. Le but de cet article est de dire aux chargés d’accessibilité pas trop sûrs de leur art, qu’il y a matière à se méfier sur les cas limites qui n’en ont pas l’air.
      Tu fais référence à des BP d’Opquast, que je n’avais pas consultées pour rédiger cet article. Je ne suis pas sûr que tous les René du Web s’appuieront dessus non plus. Je ne connais pas le paysage des référentiels SEO et ne saurais donc dire ce qui est utilisé ou pas en la matière, sur le terrain.
      Que tu sois au coeur du truc, tend bien entendu à me rassurer. Malgré tout je ne suis pas totalement convaincu de l’innocuité des alternatives évitables, ou des titres un peu grassouillets. Quel est le bénéfice utilisateur? Je n’en vois pas (peut-être à tort), en revanche j’imagine assez bien la gêne. C’est sans doute une toute petite gêne, mais sur des situations aux limites (et c’est ce dont parle l’article), cette gêne sera réelle. Mon pari est que cette gêne n’est pas compensée par le bénéfice SEO, car finalement, le rôle de l’optimisation du code tendra à être négligeable par rapport à l’action globale de référencement, qui commence d’abord et avant tout par un contenu de valeur pour l’utilisateur. Je prétends que cette valeur augmente avec une bonne accessibilité (plus utilisabilité, ergonomie, patati patata). Mais que c’est moins sûr pour l’optimisation du code pour Google.
      Merci en tous cas pour ta contribution, ravi que le sujet crée débat!

  3. Oui, en effet, beaucoup de points d’accessibilité répondent à des optimisations de référencement naturel. Et oui, il arrive que parfois les deux aient des préconisations qui diffèrent et qu’un arbitrage soit nécessaire.
    Mais ceci n’est pas propre au couple accessibilité/SEO. Un site web est appelle de nombreuses expertises qui ont souvent des périmètres se chevauchant. Mais l’accessibilité et le SEO sont peut-être les deux qui ont le plus de points communs.
    Ensuite, tout est une question d’arbitrage et de prise en compte, par chaque expert, des spécificités des autres métiers.
    Sans vouloir trop prêcher pour ma paroisse, c’est aussi là que le gestionnaire de la qualité joue un rôle.

    Enfin, pour répondre à la question sur le retour d’expérience pour ma part, c’est très positif. Je travaille depuis quelques années avec une experte référencement qui ne préconise jamais un « SEO de brute » mais pense utilisateur avant tout.
    C’est possible, ça existe et c’est un bonheur ! :)

    • On est d’accord. Il y a effectivement besoin d’une instance d’arbitrage entre les différents domaines, et la qualité peut jouer ce rôle, en ayant une vue d’ensemble. Je précise que si cet article rend un parti pris très clair pour l’accessibilité, dans les faits, tout projet doit en partie sa réussite ou son échec à la qualité de ses compromis.
      Je ne l’ai pas vérifié formellement, mais tu as probablement raison concernant SEO et accessibilité. L’idée de réaliser 75% du travail sur l’une en faisant l’autre est de fait très séduisante! Mais ça m’intéressait d’étudier justement les points de discordance, qui vont justifier qu’on y consacre plus de réflexion que les points communs, assez bien connus aujourd’hui.

  4. Merci pour le partage, il est vrai que de plus en plus les sites sont conçus pour les moteurs de recherche et non plus pour les utilisateurs. Il n’y a qu’à voir la majorité des sites Google qui ne sont pas accessibles…..

  5. Bonsoir Olivier,
    Article intéressant !
    Cela me rappelle un souvenir lié à un gros projet Web de refonte mené en 2007. Plusieurs experts (SEO, accessibilité, ergonomie) étaient conviés pour apporter son point de vue et (même prêcher pour sa paroisse un peu). Je me souviens qu’il fallait sérieusement argumenter comme dans un débat politique sauf qu’on était super poli et qu’on ne s’engueulait pas (dans un débat politique, on est trop passionnel). On passait le plus clair de son temps à trouver le bon compromis sur les points discordants entre SEO René et Accessibilité Robert (au passage, j’aurais préféré que vous citiez plutôt Tom et Jerry, au niveau son, on s’emmêle moins les pinceaux. Héhé faut penser au lecteur. Je vois Tom comme le monstrueux Google et Jerry l’accessibilté, ou l’inverse ? Euh je crois que je vais réviser ce dessin animé et je digresse là, ce n’est pas pour faire du SEO sur Tom et Jerry…). Plutôt que de se taper dessus comme Tom et Jerry, ce qui est vraiment passionnant est la joute verbale, très stimulante intellectuellement surtout si l’ »adversaire SEO est un fin. Il m’est arrivé d’avoir passé plus d’une heure à défendre le TITLE des pages côté accessibilité..
    Et je pense qu’à l’heure actuelle, le TITLE des pages, le Hx, l’intitulé des liens et d’autres points discordants feront encore couler beaucoup d’encre. Ce qui importe est la prise en compte du contexte du site sans jamais perdre de vue le confort de l’utilisateur et non du spider et trouver le bon compromis qui sied à ce contexte précis. Donc j’ai envie de dire que c’est un peu cas par cas, je trouve…
     
    Tiens, je viens de penser à l’instant à un super couple Spiderman SEO et Wonderwoman Accessibilité, c’est pas mal non ? Allez, je vais rêver de ces héros des temps modernes….

    • Merci Annabel pour votre suggestion concernant les noms des protagonistes. Je vais donc remiser également les Roger et Raymond que j’avais en réserve pour d’autres profils, et en trouver qui soient plus différenciés.
      Pour Spiderman et Wonder Woman… Spiderman tissant le web, Wonder Woman détournant les attaques anti-standards de ses bracelets magiques… très séduisant… mais le problème est que cela me rappelle immanquablement une blague impliquant également l’Homme Invisible (et que je ne répéterai pas ici pour éviter d’être interdit aux moins de 16 ans). Ce qui serait une métaphore formidable pour l’utilisateur! Mais vu la teneur de la blague, je crois que je vais m’en tenir aux héros de dessins animés pour enfants (et leurs parents)…
      A très bientôt sur Accessiblog!

  6. Pingback: Accessibilité et SEO : amies ou ennemies ? | Accessiblog.fr | Accessibilité numérique | Scoop.it

  7. Pour moi, tant que les deux disciplines sont pratiquées en « White hat », elles ne sont pas incompatibles, elles se nourrissent même : effectivement, une page très mal accessible part avec un handicap (gag !) question référencement. Pas forcément un handicap majeur, mais un handicap tout de même.

    Reste qu’en suivant juste de bonnes pratiques accessibilité (comprenez sans chercher le référencement à tout prix), j’ai pu constater que le référencement de mes photos était particulièrement bon.

  8. Ça me rappelle qu’à une époque, je croyais encore que l’indexation de Google correspondait à la pertinence, la qualité et la crédibilité d’un contenu – et que la raison principale à cet état de fait était la satisfaction de l’utilisateur. Étais-je naïf ?

    Je ne pense pas. On oublie un peu vite que l’objectif des moteurs de recherche est de proposer des résultats qui correspondent à la demande des utilisateurs – et c’est en faisant ça que Google est devenu Google.

    Donc, à priori, penser son site pour l’utilisateur (sa satisfaction : l’assouvissement de sa quête) devrait être le meilleur levier pour sortir dans les résultats des moteurs de recherche.

    Dans le même état d’esprit, le web est nativement accessible et réactif (désolé, je suis intégrateur :p) : ce sont nos interventions qui entravent cette nature douce et agréable !

    Je suis pour le web bio, élevé au grain et en plein air !

    PS : Concernant l’échange sur les checklists OPQUAST, elles ne m’ont jamais paru incompatibles. En suivant la checklist SEO puis la checklist accessibilité, on a optimisé sa page pour les moteurs et pour l’utilisateur. Un peu comme la cascade en CSS (je suis toujours intégrateur °_°).

  9. Pingback: La morale et le black hat | François Deléglise

  10. Pingback: La morale et le référencement | François Deléglise

  11. Il faut être honnête… Le but d’un référenceur est d’utiliser l’accessibilité pour rendre sa page indexable.
    Le contenu devant être également indexable, donc diminuer voire supprimer toute les technologies bloquantes. Donc oui, pour des raisons différentes, les buts de rendre une page accessible est commune !

    Là où des divergences peuvent apparaitre : c’est que l’expert SEO va vouloir placer des mots-clefs qui vont paraitre répétitif !

  12. Pingback: Accessibilité et bénéfices induits: petite mise au point | Accessiblog.fr

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>