Depuis longtemps les tenants des bonnes pratiques et du respect des standards en sont persuadés, mais sans trop oser le crier sur les toits. Mais quand Google les indique explicitement dans son guide à l’usage des webmaster … le faisceau de présomptions se resserre.
Dans le blog officiel de Google dédié aux webmasters, est paru le 12 novembre un article en réponse à la question : « quelles sont les quelques simples pratiques avec lesquelles je peux améliorer les performances de mon site sur Google [en]« .
Cet article propose en téléchargement un guide au format pdf intitulé Search Engine Optimization Starter Guide [en].
Ceux qui utilisent le projet Opquast pour suivre leurs sites pourront faire un lien direct entre les conseils de Google et quelques bonnes pratiques
Créez des titres de page uniques et précis
Create unique, accurate page titles
Rendez la navigation sur votre site plus facile
Make your site easier to navigate
Ecrivez mieux vos textes d’ancres
Write better anchor text
Utilisez les balises de titre de façon appropriée
Use heading tags appropriately
Optimisez votre usage des images
Optimize your use of images
Faites un réel usage du fichier robot.txt
Make effective use of robots.txt
Bien sûr, l’on pourrait aller encore beaucoup plus loin en établissant la relation entre les bons conseils de Google et les recommandations du référentiel général de l’accessibilité pour les administrations (RGAA), et les Directives pour l’accessibilité des contenus Web (WCAG) du W3C… pour se rendre compte que :
oui, réellement, les règles applicables à l’accessibilité des sites et à leur optimisation sur les moteurs de recherche, convergent.
Une adaptation personnelle du thème blogtxt pour Wordpress, incluant sa traduction en français et en espagnol et quelques aménagements.
Enfin, j’ai trouvé le thème WordPress qui me convient, et qui devrait aussi faire le bonheur de ceux qui, comme moi, privilégient les fonctionnalités par rapport aux fantaisies graphiques.
Blog.txt remplit avec prestance toutes mes attentes de base :
- conformité aux standards W3C
- entièrement traduisible par fichier .pot
- compatibilité avec la version 2.8 de WordPress
- compatibilité avec les quelques extensions que j’utilise
et puis, il y a les « petits plus » :
Un panneau d’administration qui permet :
- de choisir le type d’apparence (deux ou trois colonnes)
- de sélectionner les polices utilisées par section
Quelques petits Widgets:
- malins, pour afficher un ‘retour page d’accueil’ … sauf sur la page d’accueil
- ou un peu améliorés par rapport à ceux du noyau de base WordPress
Une feuille de style ‘print’ qui prend en compte uniquement le contenu des articles.
Le thème original est disponible sur le site de l’auteur Blog.txt ou dans le répertoire des thèmes wordpress.
Une adaptation personnelle :
A partir de cet original j’ai réalisé de légères adaptation, dont vous pouvez télécharger le package complet (fichier compressé au format zip) blogtxt :
- traduction française complète (panneau d’administration et interface visible par les visiteurs) (fichier fr_FR.po et fr_FR.mo inclus dans le package)
- traduction espagnole complète (panneau d’administration et interface visible par les visiteurs) (fichier es_ES.po et es_ES.mo inclus dans le package)
- ajout de l’extension Math Comment Spam Protection dans le code de saisie des commentaires (nécessite l’installation du plugin Math Comment Spam Protection pour fonctionner)
- ajout d’un fil d’ariane en tête de page avec l’extension Breadcrumb NavXT (nécessite l’installation de cette extension pour fonctionner)
- suppression dans les feuilles de style de l’attribut « uppercase » présent dans les titres du menu de navigation (il me semble que c’est une erreur en terme de lisibilité et d’accessibilité de forcer une capitalisation des caractères au travers de la feuille de style)
- utilisation de l’extrait de l’article (quand il est explicitement saisi) comme chapô
L’utilisation des balises « acronyme » <acronym> et « abréviation » <abbr> est plus délicate qu’on pourrait le penser de prime abord. Mais si les entendions avec un logiciel de revue d’écran ?
Ce n’est peut être pas trop utile que je rajoute mon grain de sel … car je crois que tout est assez bien détaillé sur l’article et les commentaires de html zen garden
Je vais juste essayer d’illustrer le propos par un exemple sonore de ce qu’un utilisateur de Jaws peut entendre d’un paragraphe incluant des acronymes et des abréviations. Ce n’est bien sûr qu’un exemple, qui dépend du paramétrage appliqué au logiciel par l’utilisateur (verbosité et options html).
En Ile de France les transports en commun sont gérés par différents organismes, RATP, RER, STIF. Mais pour ceux qui préfèrent encore utiliser la voiture et voudraient connaître le trafic sur l’A1 il est conseillé de consulter les infos. routières.
Ce paragraphe est codé comme suit :
<p>En Ile de France les transports en commun sont gérés par différents organismes, <abbr title="Réseau Autonome de Transports">RATP</abbr>, <abbr title="Réseau Express Régional">RER</abbr>, <acronym title="Syndicat des Transports d’Île-de-France">STIF</acronym>. Mais pour ceux qui préfèrent encore utiliser la voiture et voudraient connaître le trafic sur l'<abbr title="Autoroute">A</abbr>1 il est conseillé de consulter les <acronym title="informations">infos.</acronym> routières.</p>
Lu par Jaws, avec son paramétrage de base, l’utilisateur entend ceci (dans le paramétrage de base les acronymes et les abréviations ne sont pas développés) :
Si l’utilisateur de Jaws a activé, dans les options html, le développement des acronymes et des abréviations il entend ceci :