Un petit tableau intéressant sur http://www.campaignmonitor.com/css/ Il indique les compatibilités CSS, HTML, etc avec les principaux clients mail sur poste (Outlook, Windows Mail, Mac Mail, Entourage, Thunderbird, AOL, Notes 6, Eudora) ou online (Yahoo, Gmail, Live Mail, Hotmail, AOL Web, .Mac Web).

Vu sur : blog.alsacreations.com

Affilinet avait racheté Cibleclick en 2005. En novembre dernier, la migration s'est faite vers la plateforme d'Affilinet, de façon plutôt brutale et peu satisfaisante par les annonceurs (400 000 en Europe), qui y perdent beaucoup.

D'abord, ils perdent tout l'historique des soldes précédents. Du coup beaucoup d'entre eux craignent de ne jamais être payé, faute de pouvoir prouver ces soldes, et de perdre le fil de leur chiffre d'affaires. Mais surtout, le changement de plateforme produit une baisse de l'ordre de 40% (selon les affiliés) des taux de clics enregistrés, pour une audience qui ne change pas. Affilinet explique cette baisse (estimé selon eux à 3%) par le changement des règles de comptage. Notamment, désormais, les clics sur une bannière ne sont comptabilisés que sur les sites déclarés pour la campagne (ceci afin d'empêcher qua la bannière d'un annonceur se trouve sur un site domageable pour son image). C'est du moins ainsi qu'Affilinet explique la baisse de traffic : certains affiliés ne respecteraient aps les règles du jeu.

Une hotline surtaxée a été mise à disposition des affiliés, qui demeurent plutôt mécontents. Mais ont-ils le choix ?

L'objectif des microformats est d'inclure dans la structure (en autre CSS) des pages HTML du sens aux éléments.

Par exemple, quand sur le site d'un société, une actualité précise un évènement. Il pourrait être intéressant que l'internaute, intéressé par l'évènement puisse d'un clique l'insérer à son agenda. Hélas, avec le HTML / CSS, cela n'est pas réalisable...

Le microformat propose donc de structurer la présentation HTML de tel sorte que l'internaute puisse d'un clique l'insérer dans son agenda au jour correspondant, à l'heure dite, au lieu, ... tous les éléments étant reconnu automatiquement. le contenu de la page HTML ou (d'une partie) serait ainsi structurée et utilisable par d'autres logiciels.

Le principe pour ce faire est assez simple puisque l'idée est de "s'appuyer" sur la structuration CSS ou de la compléter afin de permettre cette reconnaissance par le browser et la possibilité d'ouvrir l'information à d'autres logiciels tout en conservant la puissance structurelle de la donnée.

Actuellement, plusieurs classes sont disponibles :

• Personnes et Organisations : hCard
• Calendriers et Evénements : hCalendar
• Opinions, Evaluations et Critiques : VoteLinks, hReview
• Réseaux Sociaux : XFN
• Licences : rel-license
• Tags, Mots-clés, Catégories : rel-tag
• Listes et Outlines : XOXO

L'avantage que je vois à ce principe est d'apporter une structuration plus forte du contenu ("donner du sens au contenu") formater en HTML. Le HTML est un formidable langage universel qui a permis l'émergence d'Internet mais présente de nombreux défauts puisque n'étant qu'un langage de mise en page. Ce format serait en quelque sorte un format XML universel, établi et reconnu appliqué au HTML/CSS.

Sur la page d'accueil du site du Centre Pompidou (www.centrepompidou.fr), le fameux musée d'art contemporain parisien, on trouve ça :

Ce qui invite les visiteurs à sélectionner soit leur langue de lecture, soit d'accèder au site dédié aux personnes handicapées.

Respectivement :

• www.centrepompidou.fr/Pompidou
• www.handicap.centrepompidou.fr

Je pense que cette décision peut relancer le débat sur les sites accessibles. Faut-il créer des sites entièrement accessibles ? Même si ce choix peut parfois limiter l'utilisation de certaines technologies ou alourdir le temps d'intégration. Ou peut-on considérer comme acceptable de développer un site "accessible" conjointement à un site "normal".

Dans les 2 cas on pourra trouver des avantages et des inconvénients :

I : Un site unique

• une seule URL, on évite une pré-homepage
• on ne répète pas les contenus
• on ne considère pas les visiteurs handicapés comme étant à part

II : Deux sites

• le site "normal" peut bénéficier de toutes les technologies, flash, ajax, javascript, sans aucun problème. On peut mettre facilement en place des visionneuses d'images, des videos, sans avoir à en décrire le contenu.
• le site "accessible" est réellement accessible, car développé uniquement dans cette optique, sans "bidouilles". Comme dans le site du Centre Pompidou, on peut utiliser nativement une police à corps très grand, des couleurs très contrastées, mettre en place des videos de traduction par le langage des signes, etc. Choses qu'on ne mettrait jamais en place sur un site accessible classique.

Pour ma part, je pense que ce choix dépend principalement du site. Pour un site gouvernemental, le visiteur ne doit pas avoir à choisir, tous les citoyens doivent accéder aux mêmes information, de manière égale. Pour un site commercial, pour lequel certaines technologies, comme Flash, peuvent apporter un plus dans l'ergonomie, je ne trouve pas choquant de proposer aux internautes handicapés de visiter un site parallèle, qui leur est dédié, même s'il est moins graphique. Je pense qu'il vaut mieux un second site moins attractif que pas d'accès du tout, si le site est full flash, ou derrière un menu interactif.

Je tiens à préciser que je ne cherche à choquer personne, et que je suis ouvert à d'autres arguments en faveur de chacun des deux choix.

Chose promie, chose due !!!

Voici mon premier post sur ce blog pour évoquer l'accessibilité des sites internet.
La définition de l'accessibilité est la suivante (selon Tim Berners-Lee, directeur du W3C et inventeur du World Wide Web) :
« Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales. »

De nombreux sites internet évoquent ce sujet, donnent les différentes "rêgles" à appliquer pour créer un site accessible, des outils ont été créés pour facilité le développement et la validation des sites Web accessibles, des formations sont disponibles pour devenir EXPERT en accessibilié du Web...

On rencontre de nombreux sites faisant "l'éloge" de l'accessibilité en disant que c'est important, indispensable...
En effet, l'accessibilité d'un site web améliore l'accès des handicapés bien sûr, mais de tous les utilisateurs en permettant une meilleure visibilité du site (référencement amélioré par l'utilisation des nommages alternatifs par exemple) et une meilleure organisation logique et fonctionnelle de l'information.
Il existe néanmoins quelques idées reçues sur les sites accessibles comme "Les sites accessibles sont moches" ou "l'accessibilité, c'est pour les aveugles". J'ai trouvé un site qui donne "10 raisons expliquant pourquoi les clients n’ont que faire de l’accessibilité"

Pour les plus courageux : voir le site internet
Pour les moins courageux, voici un récapitulatif de ces 10 raisons :

• Raison 1 : C'est la loi mais il n'y a pas d'exemple à suivre
• Raison 2 : Il n'y a aucun avantage immédiat
• Raison 3 : L'accessibilité est vendue comme un problème technique
• Raison 4 : Le handicap n'est pas une chose à laquelle les clients veulent penser
• Raison 5 : Nous ne créons plus, nous maintenons
• Raison 6 : Cela ne fait pas partie de la méthodologie de test
• Raison 7 : L'accessibilité, ça a l'air d'être un sacré rabat-joie
• Raison 8 : Personne ne se plaint
• Raison 9 : Elle exige un engagement
• Raison 10 : Il n'y a aucun leader à suivre

SMIL (Synchronized Multimedia Integration Language) est un langage de programmation préconisé par le W3C pour l'accessibilité des contenus audio/vidéo.

L'objectif est de permettre de voir une vidéo et de lire en même temps le texte qui est dit dans la vidéo.

Pour cela, il faut donc restituer ce qui est dit dans la vidéo sous forme de texte, un langage (SMIL) qui permette de dire à quel moment est dit une phrase et un logiciel coté client (realplayer ou GRiNS ou Quicktime) pour visualiser tout ca.

Pour aller plus loin, voici un bon tutorial : Aristote

Exemple de vidéo synchronisé avec le texte (Pour lire cette vidéo, vous devez avoir RealPlayer et aller dans Outils > Préférences > Contenu et cocher les cases concernant l'accessibilité)

Dans un précédent billet, nous présentions d’une manière générale le label Accessiweb de l’association BrailleNet. Voici maintenant quelques informations plus technique.

Définition : (Extrait du site accessiweb.org)

{{Ce label est une méthode d'application des recommandations internationales du WAI: les WCAG 1.0. Il comprend 2 éléments indissociables : une liste de 92 critères AccessiWeb et une méthodologie d'évaluation. }}

Dans ce poste, je vais détailler les 92 critères, un prochain post parlera de la méthode d'évaluation.
Il y a trois niveaux de respect de ces critères :

• Bronze : 55 critères
• Argent : + 23 critères
• Or : + 14 critères
  

Ces critères sont divisés en 13 catégories :

• Eléments graphiques
• Cadres (frame)
• Couleurs
• Multimédia
• Tableaux
• Liens
• Scripts
• Eléments obligatoires
• Structuration de l'information
• Présentation de l'information
• Formulaires
• Aide à la navigation
• Contenus accessible

Voici un résumé des critères (ou téléchargez une version excel de tous les critères - 66ko):


Niveau Bronze :

Eléments graphiques : avoir un équivalent texte (ALT) approprié de moins de 60 caractères pour les images (IMG, AREA, MAP, SHAPE, …). L’équivalent texte doit donner la fonction du lien (si il y a un lien sur l’image)
Cadres (frame) : remplir par des contenus pertinents les balises NAME, NOFRAME, TITLE. Pas plus de 3 cadres par page. Les scrollings de tous les cadres doivent être définis à « automatique ».
Couleurs : les informations données par les couleurs doivent être lisible en noir et blanc (attention aux contrastes).
Multimédia : fournir un contenu textuel équivalent (en RTF, TXT ou HTML) aux éléments multimédia (vidéos, sons, …). Il faut que l’équivalent texte soit synchronisé avec la lecture de la vidéo (utilisation du langage SMIL).
Tableaux : utiliser les tableaux pour présenter des tableaux de valeurs (pas pour faire une présentation graphique). Saisir les balises SUMMARY, CAPTION, HEADER.
Liens : l’intitulé des liens doit être explicite et de moins de 80 caractères. Utiliser l’attribut TITLE et donner plus d’information que l’intitulé du lien tout en faisant également moins de 80 caractères. Les intitulés identiques doivent pointer sur la même page. Il ne faut donc pas mettre le lien « Lire la suite », mais un intitulé spécifique à l’article.
Scripts : sans langage de script (sans javascript par exemple), on doit pouvoir faire exactement la même chose qu’avec. Il faut donc une alternative qui donne les mêmes possibilités. Ex : pour les formulaires le contrôle de saisi coté client en javascript doit également être fait du coté serveur.
Eléments obligatoires : Saisir les éléments DOCTYPE, LANG, TITLE (différent pour chaque page). Signaler dans le lien les changements de langues.
Structuration de l'information : structurer l’information de manière cohérente (identique à l’affichage sur l’écran avec une lecture de haut en bas de gauche à droite). Utilisation des H1, H2, … pour les titres.
Présentation de l'information : séparer le contenu de la présentation. En désactivant les feuilles de style le site doit rester visible et les informations affichées dans le même ordre.
Formulaires : saisir les éléments LABEL, ID, FOR. Ajouter un équivalent texte sur l’image submit (le cas échéant)
Aide à la navigation : Placer le menu principal toujours au même endroit
Contenus accessibles : pas de rechargement automatique de la page, pas de redirection automatique par script, pas de popup non sollicité. Afficher le poids et l’extension de tous les fichiers en téléchargement. Faire un lien vers un site pour télécharger un logiciel permettant la lecture du fichier (adobe pour les PDF, …).

Niveau Argent :

Eléments graphiques : pas d’image texte (titre de la page, titre de chapitre, menu, …, doivent être en texte).
Cadres (frame) : remplir par des contenus pertinents les balises LONGDESC
Couleurs : -
Multimédia : -
Tableaux : lorsqu’un titre dépasse 15 caractères, utiliser l’attribut ABBR.
Liens : -
Scripts : -
Eléments obligatoires : décrire le contenu de la page (META, CHARSET).
Structuration de l'information : ajouter un plan du site, une page d’aide à la navigation un moteur de recherche interne, le tout atteignable sur toutes les pages du même endroit sur la page.
Présentation de l'information : les polices et les tableaux doivent utiliser les dimensions relatives. Avoir au moins une des polices sans empattement (Times New Roman sur PC et Time Roman sur MAC).
Formulaires : utiliser LEGEND et FIELDSET pour les blocs d’information de même nature. Organiser les informations de manière logique.
Aide à la navigation : faire des liens invisibles « Passer au menu », « Passer au contenu » pour permettre d’aller directement à la lecture de ces éléments.
Contenus accessibles : ne pas détourner le fonctionnement des balises de leur fonction original (BLOCKQUOTE pour une citation, UL pour une liste. De manière générale, ne pas utiliser les balises (B, CENTER, BASEFONT, APPLET, DIR, FONT, ISINDEX, MENU, S, STRIKE et U) et les attibuts (ALIGN, BGCOLOR, HEIGHT...) qui sont définis comme non valide dans la dernière version du HTML.

Niveau Or :

Eléments graphiques : Les tailles des images doivent être limitées pour ne pas provoquer des ascenseurs inutiles.
Cadres (frame) : -
Couleurs : -
Multimédia : -
Tableaux : -
Liens : pas plus de 9 catégories par niveau d’arborescence et pas plus de 40 liens par page (y compris les liens du menu).
Scripts : -
Eléments obligatoires : -
Structuration de l'information : la page de résultats d’un moteur de recherche doit afficher le nombre maximum de réponses par page, le nombre total de réponses, les liens suivant/précédent.
Présentation de l'information : -
Formulaires : -
Aide à la navigation : Présence d’un fil d’Ariane, de raccourcis clavier pour les liens importants (page d’accueil, page d’aide, plan du site, moteur de recherche, glossaire, contact). Il faut également si plusieurs liens sont l’un à coté de l’autre les séparer par exemple avec le caractère « | ». Le poids des pages HTML doit être inférieur à 70ko.
Contenus accessibles : Fournir un format alternatif aux fichiers en téléchargement peu accessible (PDF -> RTF). Utiliser les balises ACRONYM et ABBR pour les abréviations (pour la première utilisation dans la page). Pas d’écriture en majuscule pour les éléments de texte. Une page doit faire au maximum 3 hauteurs d’un écran 1024x768.

J'en avais parlé dans un commentaire sur Asirra, mais je me rend compte qu'un post serait plutôt nécessaire sur cette question.

C'est que je découvre que certains cahiers des charges pour des refontes de sites web administratifs réclament des CAPTCHA pour sécuriser leurs blogs ou leurs zone de commentaires.
Pour information, un captcha (completely Automated Public Turing test to Tell Computers and Humans Apart) est une image déformée faite de chiffres et de lettres qu'un utilisateur doit recopier dans un champ texte pour prouver qu'il est bien un homme (on estime, souvent à tort, qu'un robot ne saurait pas déchiffrer ces mots).

Certain captchas déforment les lettres avec des fonds tellement tarabiscotés que même un humain parfois ne déchiffre que péniblement ce qu'il doit recopier. Depuis 2005 pourtant, le W3C a alerté sur le problème posés par ces captcha pour les malvoyants. Pafois des systèmes sonores existent, mais c'est rare et compliqué. Il est donc suggéré diverses méthodes pour mettre fin à ce système (peu protecteur au demeurant). L'une des plus intéressante est le recours à des questions logiques tournantes. Une question aléatoire est posée, dont la réponse est évidente pour un homme, mais pas pour une machine :

• Combien font 2 et 2 (en chiffre) ?
• Quelle est la couleur du cheval blanc d'Henri IV ?
• Quel est le prénom de Louis de Funès ?
• Ecrivez 5 en toutes lettres :
• Quelles est la couleur d'une orange ?

Ces questions simples sont conformes WAI, et sont certainement plus efficaces, plus confortables, voire plus amusantes que les hideux Captcha. vous aussi, bannissez donc les captcha, et inventez vos questions les plus absurdes qui dérouteront les moteurs de recherche.

cf. http://www.w3.org/TR/2005/NOTE-turingtest-20051123/ en anglais,
http://www.yoyodesign.org/doc/w3c/turingtest-20051123/ en français.

"L'accessibilité" des sites internet désigne leur capacité à être visités par des personnes handicapées, et notamment (voire exclusivement) par des mal voyants ou des aveugles qui utilisent alors des logiciels spécialisés qui lisent le contenus de la page visitée. Pour que ces logiciels fonctionnent correctement, il faut cependant que la page web soit conçue selon certaines normes, définies et répertoriées par le W3C au travers de son projet WAI (Web Accessibility Initiative) créé en 1996. (par exemple mettre un texte alernatif sur les images, surtout celes qui sont cliquables, ne pas construire sa page en tableaux mais plutôt en layers, etc).

Le public concerné étant plutôt restreint (1,7 millions de personnes en France sont mal voyantes ou aveugles), les entreprises se soucient peu en général de cette accessibilité de leurs sites. C'est pourquoi un texte législatif est venu contraindre les administrations à avoir des sites "accessibles" (que ce nom est mal choisi), par l'entremise de l’Agence pour le Développement de l'Administration Electronique (ADAE). L'ADAE travaille en lien avec le centre de ressources et de recherche Accessiweb créé par l'association BrailleNet sur la base de la norme internationale WCAG1.0. Des lors, Accessiweb devient un label français sanctionnant les sites "accessibles", via ses certifications bronze, argent et or (selon le degré d'application des normes WAI).

Avec ses homologues espagnol (Fundosa Teleservicios) et belge (Web Ona), ils ont signé la création jeudi dernier d'un label commun baptisé Euracert. Pour l'obtenir, il faudra d'abord accéder au label national, obtenu après une phase d'audit pendant laquelle les organismes de certification vérifient que le site respecte les recommandations internationales W3C/ WAI. Puis il faudra ajouter un peu d'argent pour obtenir le label européen. Ainsi, en France, le label bronze Accessiweb coûte 1900 euros. Il faudra ajouter 600 euros pour obtenir le label Euracert. Il sera valable deux ans, pendant lesuqles un audit est réalisé tous les six mois tandis qu'en parallèle, un canal de plaintes est ouvert afin que les internautes puissent signaler l'ajout d'un contenu non accessible.

Encore des coûts et des contraintes, qui ne séduiront certainement pas les entreprises, soit disant encouragées à travailler en ce sens. On ne recense en effet à ce jour que 3% des sites européens accessibles (reste à savoir si ces 3% désignent les sites ayant acheté un label ou ceux qui répondent effectivement aux normes WAI). 20 sites seulement en France ont acquis le label d'Accessiweb.Et le surtcoût pour réaliser ou adapter un site en acessibilité dépasse souvent 20% du budget normal. Enfin, l'Euracert n'est pas encore vraiment Européen, mais ne concerne que les trois pays signataires. Disons que c'est un premier pas vers un label unique.

Vous l'avez sans doute remarqué, les contenus FLASH, Active X ou applets java sous IE7 (tout tag 'applet', 'object' ou 'embed') sont curieusement protégés sur votre navigateur IE7 par un cadre grisé qui vous demandera "cliquez pour activer et utiliser ce contrôle". Dans le cas d'un diaporama où l'utilisateur n'a pas à interagir avec l'objet, cela ne pose aucun problème (pour le moment !), mais si vous avez fait un menu en Flash, ou un graphe boursier en applet java, vous constatez qu'il faut d'abord activer l'objet en cliquant dessus avant de pouvoir lui donner des consignes avec la souris.

Et comme moi, vous vous êtes sûrement dit : "Mais qu'est-ce que c'est que cette nouveauté de nous compliquer la vie chez Microsoft !?"

En fait, pour des raisons assez incroyables de procès que nous évoquerons plus bas, Microsoft a préféré modifier la façon dont son navigateur gère ces tags, qui ne doivent plus être traités par lui.
C'est l'origine de cette "désactivation" pas défaut, qui en fait une sorte de "objet non pris en charge par le navigateur, mais en fait si".

Du coup il faut modifier l'inclusion de vos objets dans vos pages. Voici comment faire :

Lire la suite >>