Référencement, Design et Cie

L'accessibilité, longtemps négligée, commence à avoir le vent en poupe : on vante ses avantages en matière d'interropérabilité, de référencement, de réduction des coûts... en oubliant parfois de mentionner que les directives d'accessibilité (les WCAG) visent avant tout les personnes handicapées, comme le rappelle judicieusement Catherine Roy dans un commentaire qui m'a interpellé.

L'accessibilité n'est pas équivalentes à la notion de "Web pour tous", même si elle y participe. Le texte d'introduction des WCAG le précise bien : "ces recommandations expliquent comment rendre les contenus web accessibles aux personnes handicapée (...) Le but premier des ces recommandations est de promouvoir l'accessibilité. Toutefois, le fait de suivre ces recommandations rendra également le web plus simple d'accès pour tous les utilisateurs". Les WCAG visent donc un public spécifique.

Même chose concernant le référencement et l'accessibilité : si de nombreuses recommandations des WCAG favorisent un bon référencement, ce n'est pas le but initial des WCAG, et un certain nombre de recommandations n'ont rien à voir avec le référencement ou l'interropérabilité, ce qui montre bien qu'elles sont destinées en priorité à des utilisateurs particuliers.

Il y a bien une convergence entre accessibilité, interroperabilité, et même référencement, on pourrait dire une certaine "transversalité". Mais chacune de ces disciplines poursuit des buts qui lui sont propres, tout en s'inscrivant dans le cadre plus général de l'accès pour tous.

Ce billet poursuit la série sur les rapports entre les recommandations Accessiweb et le référencement :

Critère 9.1 : Est-ce que la structuration de l'information est cohérente par rapport au contexte général du site ?

La structuration de l'information est nécessaire à la bonne compréhension par les utilisateurs de celle-ci. Elle peut également être un atout pour les moteurs. Un contenu bien structuré, utilisant un langage simple et clair, des titres informatifs, faisant bon usage des techniques de "front loading" aura tendance à être naturellement optimisé pour les moteurs.

Critère 9.2 : La page web est-elle structurée de manière cohérente ?

Le code HTML comporte un certain nombre de balises dites "sémantiques" car porteuses de sens : <h1> à <h6> pour les titres, <p> pour les paragraphes, <em> et <strong> pour les emphases, <ul> et <ol> pour les listes, etc. Ces balises sont prises en compte par les navigateurs, ainsi que par les aides à la navigation, mais sont également prises en compte par les moteurs. Les mots-clés présents dans un titre balisé comme tel se verront par exemple reconnaître un poids plus fort que si ce titre avait balisé avec un simple <div>, balise qui n'est pas porteuse de sens.

Critère 9.3 : Y a-t-il un plan du site ?

Le plan du site favorise l'accès à l'information pour les utilisateurs comme pour les moteurs, en fournissant des liens directs vers les pages profondes du site. Le plan améliore donc l'indexabilité du site, et participe à la redistribution du PageRank.

Critère 10.1 : Le contenu de la page est-il séparé de sa présentation ?

La séparation du contenu et de la présentation force à écrire un code HTML propre et des contenus bien structurés au lieu de produire une "soupe de tags" où les balises sont choisies pour leur rendu plutôt que pour leur signification, ce qui est plutôt bon pour les moteurs de recherche. Le code s'en trouve également allégé, ce qui pour certaines pages lourdes permet de voir davantage de contenu indexé.

Critère 10.2 : Avec les feuilles de style désactivées, l'information est-elle toujours présente ?

Tout comme le critère 10.1, la non-dépendance aux feuilles de style force à créer des contenus logiquement et sémantiquement structurés, ce qui reste un avantage du point de vue de l'accessibilité comme du référencement.

Critère 11.2 : Les textes associés aux champs de formulaires donnent-ils leur fonction exacte ?

Des intitulé explicites sont un avantage du point de vue de l'usabilité comme du référencement puisque ceux-ci auront une tendance naturelle à contenir des mots-clés.

Critère 12.3 : Existent-ils des barres de navigation qui facilitent l'accès pour la navigation interne dans le site ?

Les barres de navigation ou "chemins de fers", en plus de permettre un repérage et une navigation faciles au sein d'un site participent également à son référencement, en fournissant des liens aux robots d'indexation, et en comportant des mots-clés explicites, par exemple "Catalogue > Habillement > Homme > Chemises".

Critère 13.2 : "Si une redirection automatique est présente, s'effectue-t-elle sans l'intermédiaire d'un script ?"

Il est parfois nécessaire de rediriger automatiquement un utilisateur. Plusieurs solutions techniques existent, que ce soit au niveau serveur, par une balise meta refresh, ou par javascript. Les redirections à base de javascript posent problème : le navigateur utilisé peut ne pas interpréter javascript, et les moteurs ne l'interprètent de toute façon pas. Les balises meta refresh sont très peu appréciées des moteurs. Les redirection serveurs sont donc préférables à tout point de vue, avec s'il s'agit d'une redirection permanente une redirection de type 301, et s'il s'agit d'une redirection temporaire une redirection de type 302.

Critère 13.4 : "Y a-t-il une alternative équivalente au script qui déclenche l'ouverture de nouvelles fenêtres ? "

Il est parfaitement possible de créer des popups accessibles aux utilisateurs et aux moteurs, en utilisant des liens href "enrichis" d'un évènement onclick. Le contenu de la page en popup sera ainsi référencé.

Critère 13.6 : "Lorsqu'un fichier peut être téléchargé, y a-t-il des formats alternatifs équivalents ?"

Si les moteurs indexent une variété de plus en plus grande de fichiers, tous les formats ne leur sont pas accessibles. Et dans le cas où le format leur est accessible, comme le PDF, il n'est pas forcément souhaitable que l'utilisateur accède directement au document hors du contexte du site. On a donc tout intérêt à proposer ce type de contenus également dans une version HTML quand cela est possible, ce qui augmentera le potentiel de visibilité du site.

Critère 13.8 : "La présentation de la page est-elle réalisée sans détourner certaines balises de leur fonction d'origine ?"

Comme évoqué pour les critère 9.2 et 10.1, les balises HTML ne devraient être utilisée que pour leur signification et non pour leur rendu. Respecter la fonction d'origine des balises assure non seulement une meilleure accessibilité des contenus web, mais également un traitement optimal de ces contenus par les moteurs de recherche.

Voila qui clôt cette série de trois billets consacrée aux points de contact entre critères Accessiweb et référencement. J'espère que cette trilogie aura permis de faire comprendre que si les deux disciplines ne servent pas exactement les même objectifs, celles-ci affichent quand même une similarité dans la méthode, et convergent sur de nombreux points.

Suite de mon billet d'hier sur les rapports entre les recommandations Accessiweb et le référencement :

Critère 2.3 : Y a t-il une balise NOFRAME ?

Disons-le tout de suite : utiliser des frames (cadres) est une très mauvaise idée tant au niveau de l'ergonomie que du référencement. Si toutefois on persiste à les utiliser, la balise noframe permet de fournir aux moteurs de recherche un contenu alternatif qui sera indexé.

Critère 2.4 : Le contenu de la balise NOFRAME est-il pertinent ?

Un frameset ne comprenant souvent aucun contenu propre, une balise noframe correctement renseignée devrait comprendre un paragraphe décrivant globalement le contenu du site, un texte expliquant que le site utilise normalement les frames, et une liste de liens vers les différentes pages du site.

Critère 4.1 : Est-il possible de récupérer les informations fournies dans les supports multimédias d'une autre manière ?

Les moteurs de recherche web ne savent lire ni les vidéos, ni les fichiers audio. Comme pour les images (critère 1.1), il faut donc fournir un équivalent textuel à ces fichiers. Selon le contexte, il pourra s'agir d'un transcript ou d'une description du contenu multimedia. Ces contenus textes comprendront naturellement des mots-clés pertinents, qui amélioreront la trouvabilité des éléments multimédias et du site en général.

Critère 5.6 : Dans un tableau de mise en forme, le contenu est-il correctement ordonné ?

Le contenu situé haut dans le code a tendance à se voir accorder une importance plus grande par les moteurs. Or certaines mises en page à base de tableaux font que le contenu se situe dans le code après des éléments plus accessoires pour le référencement, comme des éléments de navigation. Il faut donc veiller à une utilisation judicieuse des tableaux de mise en page, et limiter le recours aux tableaux imbriqués, qui ont tendance à destructurer l'information. Mieux encore : passez à une mise en page intégralement gérée par CSS.

Critère 6.1 : L'intitulé des liens fait-il moins de 80 caractères ?

Des intitulé de liens relativement courts favorisent l'accessibilité mais forcent également à rédiger des liens à la fois denses et pertinents, chose appréciée par les moteurs.

Critère 6.2 : Les liens sont-ils explicites ?

Les moteurs tiennent fortement compte des intitulés des liens pointant vers une page pour juger de la pertinence de cette page. Des liens explicites aident donc au positionnement, du fait des mots-clés qu'ils contiennent. Si vous vendez des vêtements en ligne par exemple, préférez "Notre catalogue de vêtements" à "Produits".

Critère 6.5 : Chaque intitulé de lien identique amène t-il vers la même destination ?

Cette recommandation participe aux liens explicites évoqués plus haut, et aide encore davantage à positionner la page liée sur les mots-clés présents dans l'intitulé du lien.

Critère 6.7 : Y a-t-il moins de 40 liens actifs dans la page, hors liens nécessaires à la navigation ?

Un nombre réduit de liens sur une page a tendance à augmenter la quantité de PageRank transférée à chacune des pages liées, ce qui favorise le référencement. Attention cependant, il ne faudrait pas tomber dans le travers qui serait de construire son site autour du PageRank : d'une part le site doit être pensé pour l'utilisateur en priorité (tout en tenant compte de référencement), d'autre part des liens nombreux aident les moteurs à indexer le site en profondeur.

Critère 7.1 : Si un script nécessite une alternative pour être accessible, l'information donnée par cette alternative est-elle équivalente à l'information fournie par le script ?

Javascript n'étant pas interprété par les moteurs, toute information affichée par un script ne sera pas lue par les moteurs de recherche. Une version alternative accessible (en HTML) de cette information garantie que celle-ci sera bien indexée.

Critères 7.2 : Des actions peuvent-elles être accomplies même si le périphérique pour lequel elles sont prévues est désactivé ?

La non-dépendance aux périphériques (souris, clavier, écran...) renforce l'indexabilité de la page par les moteurs : un moteur sait interpréter un lien href, mais ne va pas cliquer, et il ne dispose pas non plus d'écran.

Critère 8.2 : L'attribut LANG est-il présent au début du code source de la page pour identifier clairement la langue utilisée ?

Cet attribut en spécifiant la langue d'une page peut l'aider à se positionner pour les requêtes restreintes à une langue donnée. Il est aussi probable que cet attribut soit utilisé à des fins sémantiques, pour une analyse plus fine des contenus.

Critère 8.3 : Des éléments de description de la page sont-ils présentes en début de code source ?

Les balises meta description et meta keywords apportent des informations utiles aux moteurs puisque porteuses de sens. Le charset permet un affichage correct du titre des pages et de leur description dans les pages de résultats des moteurs de recherche. Ces éléments participent donc à la bonne prise en compte de vos pages par les moteurs.

Critère 8.5 : Le contenu de la balise TITLE est-il explicite ?

La balise <title> est pour les moteurs de recherche un des critères les plus importants pour juger de la pertinence d'une page. La balise <title> doit décrire précisément l'objet de la page dans un langage à la fois clair et riche en expressions-clés.

Critère 8.6 : Le contenu de la balise TITLE est-il différent d'une page à l'autre ?

Le point 8.5 prévoyant un <title> explicite, chaque page du site devrait donc posséder un <title> qui lui est propre. Cette diversité de titres augmentera de façon significative les possibilités de positionnement dans les moteurs de recherche, du fait de la variété des mots-clés y figurant.

Accéder à la troisième partie de l'article

Comme le laissait pressentir mon dernier billet, je vous propose d'étudier en détail dans une série de billets les 36 critères Accessiweb ayant une relation directe avec le référencement. Il ne s'agit pas de voir l'accessibilité sous le seul angle du référencement : l'accessibilité s'adresse avant tout aux utilisateurs, et c'est là son objectif principal. L'objet de cet étude est davantage de mettre en évidence la convergence dans la méthode entre les deux démarches, les moteurs de recherche pouvant être vus comme des utilisateurs particuliers, avec des handicaps technologiques.

Critère 1.1 : Chaque élément graphique possède-t-il une alternative textuelle ?

Les moteurs sont avant tout des machines à indexer du texte, et sont incapables de lire le contenu d'une image. Les attributs alt permettent de fournir un contenu texte alternatif aux éléments graphiques, pour les utilisateurs comme pour les moteurs.

Critère 1.2 : Pour chacune des images de la page ayant une alternative, les textes dans l'attribut ALT sont-ils appropriés par rapport au contexte dans lequel l'image se trouve ?

Le référencement vise à favoriser l'accessibilité à l'information. On pourrait aussi parler de"trouvabilité". L'information convoyée par l'image peut varier selon le contexte, et l'image peut dans certain cas ne convoyer aucune information : c'est le cas des images purement décoratives. Un attribut Alt non pertinent constituerait autant de bruit supplémentaire pour les moteurs. L'attribut Alt doit donc être adapté afin d'augmenter le rapport signal/bruit des pages.

Critère 1.4 : Pour chacune des images de la page, les textes dans l'attribut ALT font-ils moins de 60 caractères ?

L'objectif de cette recommandation est purement ergonomique. Toutefois, un des bénéfices de sa mise en oeuvre concerne le référencement, puisque elle force à décrire le contenu en un minimum de mots-clés, ce qui favorise la trouvabilité du site (et de l'image) sur ces mot-clés.

Critère 1.5 : Les commentaires associés à chacune des zones réactives d'une image map sont-ils pertinents ?

L'information graphique convoyée par une image map peut être textuelle, elle peut aussi être abstraite ou symbolique. Des attributs alt décrivant précisément chaque zone permettent aux moteurs de se faire une idée du contenu de la page contenant l'image map et des pages liées.

Critère 1.8 : Pour chacune des images texte de la page, le contenu de son alternative est-il au moins équivalent au texte inscrit dans l'image ?

Comme expliqué pour le critère 1.1, les moteurs étant incapables de lire les images, l'attribut alt doit au minimum reprendre le texte de l'image, en le précisant éventuellement. Par exemple pour une image sur un site de vêtements affichant "catalogue", utiliser comme attribut alt "notre catalogue de vêtements" ce qui favorise le référencement et la compréhension du lien vu ou entendu hors de son contexte visuel normal.

Critère 1.9 : Il convient de remplacer un texte sous forme d'image par un texte mis en forme. Cette règle est-elle respectée ?

Si les attributs alt permettent de fournir une alternative textuelle aux images, il est préférable pour les utilisateurs comme pour les moteurs d'utiliser du texte mis en forme via CSS : ce texte sera plus facilement manipulable par les utilisateurs et mieux pris en compte par les moteurs.

Critère 1.10 : Quand une image nécessite une description détaillée, un commentaire texte lui est-il associé ?

L'attribut alt est parfois insuffisant pour décrire une image qui demande une explication plus détaillée. En lui adjoignant un commentaire texte, vous fournissez davantage de contenu riche en mots-clés aux moteurs, ce qui améliore encore la trouvabilité du site. Du point de vue du référencement, le texte dans la page est cependant préférable à l'attribut longdesc.

Critère 1.11 : Si une description détaillée de l'image est présente, son contenu est-il pertinent ?

La description de l'image se doit d'être précise : qu'est-ce qui est représenté ? Quelle est l'idée transmise ? les différents éléments affichés ? En répondant à ces questions, vous écrirez naturellement un texte riche en mots-clés, et donc bénéfique pour votre référencement.

Critère 1.12 : Pour chacune des images liens, le texte contenu dans l'attribut ALT donne-t-il la fonction du lien ?

Les moteurs de recherche prennent en compte les intitulés des liens pointant vers une page pour juger de la pertinence de cette page par rapport à un mot-clé donné. C'est pourquoi il est important que les liens sous forme d'images soient dotés d'un attribut alt décrivant le contenu de la page liée.

Accéder à la seconde partie et à la troisième partie de l'article.

La proposition de nouvelle version des Web Content Accessibility Guidelines ne fait pas l'unanimité : Joe Clark défend son point de vue dans un article enflammé sur A List Apart, intitulé "To hell with WCAG 2".

Grâce aux efforts conjoints de Monique Brunel, Aurélien Levy et Jean-Pierre Villain, Une traduction de l'article a été effectuée, permettant aux francophones de contribuer au débat.

Pour ma part, je n'ai pas encore eu le temps d'examiner ces guidelines en détail. Il me semble cependant que leur formulation est très peu claire, ce qui est dommage, car risque d'aboutir soit à un rejet, soit à des conflits d'interprétation. Dommage également que cette polémique intervienne au moment où l'on observe un interêt croissant pour l'accessibilité : les concepteurs web ont suffisament de difficultés pour assimiler les WCAG dans leur première version. Cette seconde version quasi-définitive risque d'ajouter encore plus de confusion...

En complément à mon précédent billet, j'ai ajouté une rubrique "qualité d'écriture et typographie" à mon annuaire. J'en ai également profité pour mettre à jour la rubrique "Accessibilité et ergonomie". Bonne lecture !

Le document "Core techniques for Web Content Accessibility Guidelines" fournit de précieuses indications pour améliorer la lisibilité des textes sur le web. N'ayant pu trouver une version en français de ce document, je vous livre une traduction par mes soins de la section relative au style d'écriture :

"Les suggestions suivantes devraient participer à améliorer la lisibilité de votre contenu pour tous, notamment pour les gens ayant des difficultés de lecture ou des handicaps cognitifs (...).

1. Efforcez-vous de produire des titres et des intitulés de liens à la fois clairs et précis. En particulier, utilisez des intitulés de liens courts, qui gardent leur sens quand ils sont lus hors-contexte ou dans une série de liens (Certains utilisateurs naviguent en sautant de lien en lien, n'écoutant que les intitulés de ceux-ci). Utilisez des titres informatifs afin que les utilisateurs puissent scanner votre page pour accéder rapidement à l'information, au lieu d'être contraints à une lecture linéaire.
2. Enoncez d'entrée le sujet principal d'une phrase ou d'un paragraphe (Ceci est appelé "front-loading"). Cela aidera les gens qui lisent en diagonale, mais aussi les utilisateurs de synthèse vocale. Ces utilisateurs scannent le contenu, en sautant de titre en titre, et de paragraphe en paragraphe, en écoutant juste assez de mots pour déterminer si le bloc d'information (titre, paragraphe, lien etc.) les intéresse. Si l'idée principale d'un paragraphe est situé en son milieu ou à sa fin, ces utilisateurs seront contraints d'écouter la quasi-totalité du document avant de trouver ce qu'ils cherchent. En fonction des attentes des utilisateurs et de leur connaissance du sujet, des fonctionnalités de recherche peuvent également faciliter l'accès plus rapide à l'information.
3. Limitez chaque paragraphe à une idée principale.
4. Evitez l'argot, les jargons, et l'usage de mots familiers pris dans un sens différent, à moins que que ce sens ait été défini préalablement dans votre document.
5. Favorisez l'usage des mots communs. Par exemple, utilisez "débuter" plutôt que "préluder".
6. Préférez l'usage de la forme active à celui de la forme passive.
7. Evitez les structures de phrases inutilement complexes."

Plutôt que de parler dans l'abstrait des bénéfices d'un code HTML à la fois conforme, structuré, et accessible, et plutôt que de mettre mon site à nu, je vous propose d'expérimenter le rendu de celui-ci sur divers configurations materielles et logicielles :

D'abord sur Lynx, un navigateur en mode texte, puis sur Firefox, doté d'une feuille de style personnalisée pour malvoyants, sur Blazer, un navigateur pour PDA sous Palm OS, sur Symbian OS, un système d'exploitation pour smartphones, sur Openwave, un OS compatible Wap et XHTML-MP, sur Internet Explorer pour Windows Mobile, et enfin sur Jaws (Mp3, 935 ko), un navigateur vocal fréquemment utilisé par les non-voyants.

Les experiences de navigation peuvent varier selon les plateformes. L'apparence graphique du site peut changer. Mais dans tous les cas, le contenu reste accessible, chose qui n'aurait pas été forcément possible si le site avait été construit un dépit des bonnes pratiques.

L'accessibilité est souvent abordée sous l'angle du handicap et des configurations obsolètes. Mais le test des terminaux mobiles montre que les recommandations du W3C gardent tout leur valeur dans ce contexte : tous les systèmes n'interprètent en effet pas javascript, tandis que les liens d'évitement facilitent la navigation même pour les utilisateurs valides, du fait de la faible résolution des écrans.

Hier avait donc lieu le premier "Naked Day". Sceptique à propos de l'opération, je n'y ai pas participé. Mais j'étais cependant curieux des réactions des utilisateurs, et j'ai parcouru l'ensemble des commentaires sur les sites y participant grâce à la liste de Monique.

Franchement, je me demande si l'accessibilité n'est pas juste une mode pour certains : je me suis ainsi vu refuser l'accès à un site d'un participant sous pretexte que "'Internet Explorer c'est de la merde" (sic). Moi qui croyait naivement que l'accessibilité, c'était un accès pour tous, indépendament de sa configuration materielle, logicielle ou de ses handicaps...

Mais revenons aux commentaires des utilisateurs. Après avoir écrémé l'orgie de trackbacks, les commentaires "j'y participe aussi", et les plaisanteries, que reste-t-il ? Finalement pas grand chose. Quelques commentaires que j'ai pu relever sur les divers sites participants :

• "Problème avec le css de ton theme ?"
• "Pas con... mais un peu déroutant quand même... ;-)"
• "Outch le choc! :)"
• "Est-ce dû au dépouillement du jour, est-ce moi qui ne voit plus clair à force de regarder des sites tout nus... je ne trouve pas le lien pour faire un trackback :-["
• "J'adore ! Ça me rappelle ma jeunesse, l'époque où le web était plus rapide que le Minitel. J'attends avec impatience la journée Gopher."
• "Je savais pas que ça existait, une journée où on déshabille nos sites de leurs CSS. C’est drôle. Beau petit concept."
• "Conseil : dans le code HTML, positionner le titre et le corps en haut, et la sidebar en bas, parce que ça dérange la navigation (oui oui le Naked Day sert à ça)."
• "Si je peux me permettre je trouve cette action totalement ridicule, imposer ca à un site on est plus en démocratie, c'est une dictature la."
• "Et ben il est pas mal du tout ton blog tout nu ! Tes colonnes restent bien en place c'est cool ca" (Nda : Quoi ! une mise en page par tableaux !)
• "Ah oui d'accord bah ca fait peur quand même, je le préfère quand même dans son état normal"

Finalement, le Naked Day c'est comme les flashmobs : on en parle beaucoup sur l'instant mais ça ne laisse pas de traces dans la durée...

Demain 5 avril aura lieu la première édition du Annual Naked Day, initié par Dustin Diaz dans le but de promouvoir les bénéfices d'un balisage sémantique et d'une bonne structuration HTML. Les webmasters sont donc invités à déshabiller leur site en désactivant leur feuille de style.

L'intention est louable, mais je reste sceptique sur l'interêt pédagogique d'imposer à l'utilisateur un site sans styles. Concernant ce blog par exemple, le style participe à son usabilité, tout en étant désactivable pour l'utilisateur qui en aurait besoin :

Le choix des largeurs des blocs permet d'avoir des lignes de texte de longueur réduite, améliorant la lisibilité. Sans style, les blocs de texte occuperaient toute la largeur de l'écran, rendant la lecture plus difficile.

La mise en page en 2 colonnes facilite la navigation, puisque les éléments de navigation sont plus proches du contenu et donc plus accessibles. L'utilisateur moyen semble d'ailleurs s'attendre à ce que la navigation interne soit sur le coté, pas en bas de page.

Le choix d'une police sans serification (Verdana) participe également à la lisibilité. Or les polices par défaut des navigateurs sont le plus souvent des polices avec serification, comme le Times, qui sont généralement considérées comme moins adaptées à la lecture sur écran.

Enfin, le choix des couleurs (saturation, contrastes) outre l'apport esthétique (qui améliore l'usabilité perçue) apporte un plus grand confort de lecture, le contraste maximal n'étant pas toujours préférable.

L'absence de style contribuerait donc à mon humble avis à dégrader l'usabilité pour la majorité des utilisateurs, allant à l'encontre des objectifs de l'opération.

Et vous, qu'en pensez-vous ?

Les webmasters adeptes des standards du web et des bonne pratiques ont parfois du mal à trouver une entreprise partageant la même vision. De leur coté, les web agencies qui ont intégré les standards dans leur production éprouvent également parfois des difficultés à recruter des personnes compétentes.

C'est pour que tout ce petit monde puisse enfin se rencontrer que la communauté Alsacréations a développé un service d'offres et de recherche d'emplois. Le service est très simple d'utilisation et permet même de s'abonner via RSS.

Une très bonne initiative, bravo Alsa :)

Les nuages de mots, ou "tag clouds" sont à la mode. On peut en voir ici ou là, et nombreux sont les blogs qui arborent leurs propres nuages de tags.

Aussi interessants soient-il en matière de visualisation, les nuages de mots pourraient éventuellement voir leur accessibilité et leur sémanticité améliorées :

• Le point 10.5 des WCAG et la fiche 176 du référentiel Opquast recommandent que les liens adjacents soient séparés par au moins un caractère imprimable ou une image, pour éviter que 2 liens consécutifs soient interprétés comme un seul et même lien. Mettre en place cette directive améliorerait l'accessibilité des nuages.
• Les mots composant un nuage sont finalement une liste non ordonnée. Pourquoi donc ne pas utiliser le balisage adequat <ul> ? La mise en oeuvre de cette balise réglerait également le problème des liens adjacents évoqué au dessus.
• Le poids des mots est représenté habituellement par la taille des caractères, éventuellement par les couleurs. Il ne s'agit que de présentation, et définir la taille des textes via CSS ne transmet aucune information d'ordre sémantique. Pourquoi ne pas utiliser les 3 niveaux d'emphases que permet le HTML : texte normal, emphase simple <em> et emphase forte <strong> ?
• Les grands nuages de mots peuvent représenter une quantité importante de liens, rendant leur lecture pénible dans les navigateurs vocaux. L'intégration de liens d'évitement permettrait aux utilisateurs de tels navigateurs de "sauter" le nuage.

Alors que les Web Content Accessibility Guidelines dans leur version 1.0 conseillent de tester la lisibilité des couleurs en se basant sur deux valeurs -la différence de brillance perçue et la différence de couleur- La version 2.0 des WCAG suggère un nouvel algorithme un peu différent, basé sur une valeur unique : le "ratio de contraste de luminosité" (luminosity contrast ratio).

L'algorithme est abondamment analysé dans cet article de Juicy Studio, qui fournit également un outil d'évaluation de ce ratio.

A comparer avec Color Contrast Analyzer mentionné il y a quelques temps dans ce billet.

Accessiweb, le centre de ressources et de recherche sur l'accessibilité du Web, a publié il y a quelques jours son guide à destination des webmasters soucieux de l'accessibilité de leurs sites et applications web.

Ce guide constitue une aide précieuse, en détaillant et illustrant les points de contrôle, les moyens d'évaluation, et les solutions possibles. Seuls les critères de niveau bronze sont pour l'instant abordés. Les prochaines versions devraient par la suite traiter de tous les niveaux de validation.

A lire, une interview de Laurent Denis dans NetEconomie. On y parle bien sûr d'Opquast, des standards et de l'accessibilité en tant que processus.

Extraits :

"En considérant ainsi l'accessibilité comme une sur-couche applicative sur le site, on multiplie souvent les dispositifs d'accessibilité plus ou moins complexes, coûteux à développer, et à l'efficacité souvent partielle"

"Les interfaces de navigation dynamiques sont par exemple très à la mode, sur la foi d'un postulat esthétique : un menu déroulant est souvent réputé dynamiser "magiquement" la page, la rendre "cool" et séduire ainsi l'utilisateur conquis. Je peux, certes, me précipiter sur ce choix esthétique et réaliser un tel menu en XHTML CSS valide. Mais voilà que j'oublie l'utilisateur. Je cours tout d'abord le risque de parasiter son expérience de navigation avec une esthétique qui n'a peut-être rien d'essentiel ou de remarquable à ses yeux."