Blog - Britoweb - Tag - accessibilité site web

Accessibilité des sites Web de Luc Van Lancker : note de lecture

Victor Brito — Mon, 22 Sep 2008 22:42:00 +0200

Les éditions Eni viennent de publier Accessibilité des sites Web - Mise en œuvre des directives WCAG 1.0, de Luc Van Lancker.

Ceux qui se soucient déjà d'accessibilité n'apprendront pas grand'chose en lisant ce livre. Néanmoins, il convient parfaitement aux webmestres, intégrateurs, développeurs et autres acteurs du Web qui souhaient s'initier à l'accessibilité du Web. Il prend soin, en effet, de présenter les différents handicaps qu'on peut rencontrer parmi les internautes potentiels, ainsi que les différentes aides techniques (là-dessus, il est dommage que l'auteur ne dise rien sur les synthèses vocales pour les systèmes autres que Windows, comme VoiceOver pour Mac OS X, sans oublier les outils d'accessibilité proposés par des navigateurs comme Opera).

Ensuite, chaque chapitre abordant le vif du sujet est illustré d'exemples permettant d'appréhender les techniques d'accessibilité, avec transcription de ce que peut lire une synthèse vocale (en l'occurence, Jaws). Toutefois, quelques erreurs et inexactitudes se glissent çà et là : l'élément q devient cite et le fait que les synthèses ignorent les feuilles de styles est inexact : si elles ignorent le choix des couleurs et des arrière-plans, par exemple, elles peuvent, en revanche, tenir compte d'une déclaration CSS comme display: none, sans oublier qu'on peut tout à fait produire une feuille de style destinée aux synthèses vocales et aux plages braille, grâce aux médias aural (speech en CSS 2.1) et braille, respectivement (encore faut-il que les aides techniques implémentent ces types de média et les propriétés CSS qui leur sont spécifiques, cela s'entend toujours ).

La fin de l'ouvrage récapitule les points de contrôle de WCAG 1.0, les critères Accessiweb et ceux du RGAA et compare, surtout, quelques validateurs d'accessibilité, pour mieux démontrer que la plupart de ces derniers peuvent ne valider que du vent et que rien ne vaut les vérifications manuelles. Pour finir, on trouvera quelques mots sur les moyens de certifier un site accessible, notamment la procédure en vigueur pour l'obtention du label Accessiweb.

Savoir en quelle langue est rédigé le contenu : l'exemple des sites multilingues

Victor Brito — Sat, 06 Sep 2008 18:34:00 +0200

Le blog officiel pour webmasters de Google a publié le mois dernier un billet sur la manière de commencer un site multilingue. Ce billet prodigue des conseils pratiques du point de vue du référencement. Toutefois, il y a un conseil supplémentaire à ajouter et qui rend bien service non seulement aux moteurs de recherche dans leurs tris, mais aussi à certaines aides techniques, comme les synthèses vocales, afin d'éviter que ces dernières ne lisent le contenu comme une vache espagnole) : déclarer dans le code source (qu'il soit généré ou en dur) la langue de chaque page du site.

Pour cela, en HTML, il suffit de renseigner l'attribut lang dans l'élément racine html. Pour une page HTML rédigée en français, on aura :

<html lang="fr">

En XML, c'est l'attribut xml:lang qui joue ce rôle.

On peut égalemet envoyer une en-tête HTTP indiquant la langue de la page, ce qui, en HTML, est effectué comme suit :

<meta http-equiv="Content-Language" content="fr">

En XHTML, on n'oubliera pas, bien entendu, le principe de fermeture de tous les élements, y compris les éléments vides :

<meta http-equiv="Content-Language" content="fr" />

Il est également possible d'envoyer une telle en-tête au moyen d'un langage de programmation côté serveur, comme PHP :

<?php
header ('Content-Language: fr');
?>

Qui dit site multilingue dit site susceptible de fournir un même contenu (page, catégorie, article, billet, brève…) en plusieurs langues. Le HTML offre un balisage suffisamment riche pour signaler à l'agent utilisateur (dont les robots des moteurs de recherche) que la page actuellement consultée est disponible en d'autres langues. Pour le cas d'une URL comme http://fr.exemple.com/1, on peut fournir le code suivant :

<link rel="alternate" href="http://en.exemple.com/1" hreflang="en" lang="en" title="English version of the page" />
<link rel="alternate" href="http://es.exemple.com/1" hreflang="es" lang="es" title="Versión española de la página" />

Parallèlement, l'utilisateur humain doit être renseigné de ces équivalences :

<p><a href="http://en.exemple.com/1" hreflang="en" lang="en" title="English version of the page" >English</a> - <a href="http://es.exemple.com/1" hreflang="es" lang="es" title="Versión española de la página" >Español</a></p>

Comme le montrent les deux derniers exemples, en cas de changement de langue au sein d'une même page, il faut aussi renseigner la langue de la portion de contenu en langue étrangère (avec le même attribut lang, ou xml:lang dans le cas du XML), sous peine qu'un synthèse vocale ne la lise comme si elle était rédigée dans la langue principale du contenu, autrement dit comme une vache espagnole.

Pour approfondir

Voici une suggestion de liens permettant d'approfondir les propos de ce billet :

Un annuaire de sites accessibles

Victor Brito — Wed, 03 Sep 2008 21:26:00 +0200

Le site Handicap Zéro propose, parmi ses rubriques, un annuaire des sites accessibles.

Il s'agit d'un annuaire original non seulement pour la thématique abordée (les sites accessibles), mais surtout pour le fait que le formulaire de soumission d'un site n'est pas destiné aux webmasters qui souhaitent référencer leurs sites dans les annuaires : en effet, si la première partie du formulaire ressemble à un formulaire classique de soumission d'un site à un annuaire Web, la seconde partie, en revanche, invite l'utilisateur à noter le site proposé (de 0 à 5) et à commenter son expérience en matière d'accessibilité.

Autrement dit, c'est un très bon outil pour quiconque cherche des exemples de sites accessibles (pour chaque site référencé, on peut consulter les notes et commentaires laissés par les utilisateurs ; il y a même un classement des sites les mieux notés). En revanche, côté référencement, il est à améliorer : en effet, les liens qui pointent vers les sites référencés ne sont pas des liens en dur ; qui pis est, il s'agit de redirections 302, ce qui signifie que les sites référencés ne bénéficient pas de lien retour depuis l'annuaire. Dommage !

Si votre site n'est pas accessible, la justice pourra vous le rappeler

Victor Brito — Thu, 28 Aug 2008 22:41:00 +0200

Bon nombre de concepteurs de sites, d'agences Web et de clients d'agences Web n'ont pas encore pris la pleine mesure de l'importance de l'accessibilité du Web au plus grand nombre d'utilisateurs, quels que soient les handicaps rencontrés. Peut-être se disent-ils que, puisque rien, pas même une loi, ne les y oblige, ils peuvent ignorer certaines catégories d'utilisateurs en toute impunité, pour ainsi dire. Et pourtant…

Des propriétaires et autres responsables de sites Web ont déjà connu le banc des accusés d'une cour de justice et ont même été condamnés pour le délit suivant : leurs sites Web n'étaient pas accessibles à certains utilisateurs souffrant de handicaps physiques.

Le premier cas connu d'un procès se soldant par une condamnation pour inaccessibilité d'un site est celui intenté par Bruce Maguire, un internaute australien non voyant, envers le Comité d'Organisation des Jeux Olympiques de Sydney, qui, en 2000, fut condamné à dédommager Bruce Maguire, moyennant 20 000 dollars australiens. C'est ce que rapporte Webyboom, qui renvoie à l'analyse de Joe Clark.

Tout récemment, la NFB a gagné un procès contre Target.com, une chaîne de supermarché en ligne (une synthèse de ce procès est disponible), procès intenté à la suite d'une plainte initiale déposée par Bruce Sexton. Le jugement est édifiant :

La justice vient de les condamner, notamment, à mettre le site en conformité avec les recommandations de la NFB, d'ici au 28/02/2009 ; à financer sur 3 ans l'intervention de la NFB sur le site (pour 170 000 $, plus les frais de formation) ; et à verser jusqu'à 7 000 $ de réparations par plaignant, pour un total pouvant atteindre 6 millions de dollars. À ajouter à ces amendes, bien entendu les frais d'avocats, probablement conséquents, et surtout, à court terme, les dégâts commerciaux causés par cette publicité négative. Pour caricaturale qu'elle soit, l'image de la grande méchante world-company cynique, qui mégotte sur l'investissement pour permettre l'accès aux aveugles, est facile à véhiculer. Et elle le sera sans nul doute.

À cela il faut ajouter que Target devra verser 20 000 dollars à une association à but non lucratif créée par Bruxe Sexton, dans le but d'ouvrir un centre d'entraînement et de rééducation pour aveugles en Californie.

Certains y verront deux exemples d'une manie anglo-saxonne pour les procès intentés pour un oui ou pour un non et se diront que cette manière de « dérive » ne se produira jamais en France. Qu'ils se détrompent ! Bon nombre de pays adoptent des législations qui facilitent, voire imposent, l'accessibilité des services aux handicapés, jusques et y compris dans le domaine du Web. La France n'est pas totalement étrangère à ce mouvement, de par la loi du 11 février 2005, dont l'article 47 prévoit la conformité des sites Web des administrations et autres services de l'État, des collectivités locales et des établissements publics aux critères d'accessibilité du contenu du Web, notamment ceux du RGAA, qui a vu le jour pour atteindre ce but. Et le Plan Handicap Visuel (des extraits du communiqué de presse sont rapportés sur le blog) n'exclut pas l'hypothèse de sanctions à mettre en œuvre en cas de non-respect de la loi.

Et si l'on développe le site Web d'une société privée ou d'une association qui ne s'occupe pas de handicap ?, dira-t-on. Même si la loi vise principalement les services publics, il ne faut jamais dire qu'on sera toujours à l'abri d'un procès pour inaccessibilité. Après tout, c'est une question de discrimination ; et comme la loi en dit quelque chose et que nul n'est censé ignorer la loi…

Bref, ça ne coûte (presque) rien de rendre un site Web accessible, surtout si l'on y songe dès les premiers instants de la conception du projet de site Web ; en tout cas, ça coûte beaucoup moins que s'il fallait passer par la case tribunal.

Utilisation de technologies obsolètes et détournement de balisage : l'exemple du formulaire d'inscription du Grenelle du Très Haut Débit

Victor Brito — Mon, 25 Aug 2008 19:56:00 +0200

Tristan Nitot est très remonté contre le formulaire d'inscription en ligne du site du Grenelle du Très Haut Débit : dans un billet publié tout à l'heure, il rapporte qu'il lui est impossible d'utiliser le formulaire d'inscription en ligne et découvre, non sans consternation, que l'inscription en ligne est optimisée pour IE 7 !

Le fait que le formulaire d'inscription est optimisé pour un seul navigateur (et, qui plus est, pour une seule version dudit navigateur) est un manque flagrant d'accessibilité : quand bien même Internet Explorer serait le navigateur le plus répandu et quand bien même la version 7 tendrait à dépasser, cette année, la version 6, il ne faut jamais oublier qu'il existe bon nombre d'utilisateurs suffisamment bien informés et éclairés sur les nouvelles technologies pour naviguer sous d'autres navigateurs, comme Firefox ou Opera, voire adopter un système d'exploitation autre que Windows, où Internet Explorer est, bien entendu, inexistant.

Et ce n'est pas tout. En jetant un rapide coup d'œil au code source de la page du formulaire d'inscription, on constate que le doctype utilisé (HTML 4.01 transitionnel) est tronqué (l'URL de la DTD n'y figure pas), ce qui signifie qu'IE (à partir de la version 6) bascule en mode Quirks : autrement dit, il se comporte comme IE 5.5 pour le modèle de boîte (inclusion des marges intérieures et des bordures dans la largeur et la hauteur des blocs, quoi qu'en dise le modèle de boîte standard) et les marges automatiques (qui sont alors ignorées, obligeant à recourir à text-align: center, une propriété CSS qu'IE interprète mal, en l'appliquant aux éléments de bloc, alors que cette propriété ne permet que de centrer du contenu au fil du texte). Bref, cela n'est pas sans rappeler la directive 11.2 des WCAG 1.0 : Avoid deprecated features of W3C technologies. (en français : Éviter d'utiliser les options des technologies du W3C qui ne sont plus supportées.). En outre, on constate que la mise en page est à l'ancienne, sous forme de tableaux, une pratique que la directive 5.3 des WCAG 1.0 demande d'éviter : Do not use tables for layout unless the table makes sense when linearized. (en français : Ne pas utiliser les tables pour la mise en page, à moins qu'elles n'aient un sens lorsqu'elles sont déchiffrées en mode linéaire.).

Et je ne parle pas de l'absence de l'attribut alt dans l'image du bandeau d'en-tête ni de l'absence d'association explicite des champs de contrôle du formulaire et de leur intitulé… Bref, consternant, comme le dit si bien Tristan Nitot.

Images riches en contenu : l'exemple des archives en ligne du Times

Victor Brito — Sat, 19 Jul 2008 17:24:00 +0200

En lisant les derniers billets publiés de Formats-Ouverts.org, je suis tombé sur celui annonçant l'ouverture en ligne des archives du Times.

Les archives en ligne du Times couvrent deux siècles de parution, de 1785 à 1985. Elles proposent, pour tout article recherché, l'affichage, sous forme d'image, de la page de la version papier où ledit article était originellement publié.

Qui dit image dit problème d'accessibilité pour les non-voyants et pour les utilisateurs d'un navigateur qui n'affiche pas les images (navigateur texte ou navigateur graphique configuré pour ne pas les afficher). En analysant le code source de la page affichant l'image en question, on remarque que cette dernière est affichée dans un élément iframe. Le code source de l'URL appelée par l'iframe montre que l'élément img appelant l'image comporte bien l'attribut alt ; mais, le texte contenu dans cet attribut n'est pas pertinent, en ce sens qu'il ne décrit pas, fût-ce brièvement, l'image : en effet, le texte dit Click and drag the image to move around the page (en français : Cliquez sur l'image et faites-la glisser pour vous déplacer dans la page), se référant à une fonctionnalité qui n'est utilisable que si JavaScript est activé. Qui plus est, l'élément img comporte un attribut title superflu, puisqu'il reprend le même texte que l'attribut alt. Comme si cela ne suffisait pas, les non-voyants n'ont aucun moyen d'accéder au contenu de la page, puisque l'attribut longdesc est absent, ce qui aurait permis de fournir une URL décrivant longement la mise en page de la page du Times consultée (elle peut, en effet, comporter des illustrations ou des gravures, dont une reproduisant les armoiries et la devise de l'Angleterre dans l'exemple fourni par la capture d'écran plus haut) et transcrivant le contenu de la page.

D'ailleurs, à propos de contenu, étant donné qu'il s'agit de mettre à la disposition du public des articles d'anciens numéros, donc du contenu textuel, pourquoi ne pas les afficher en dur dans le code HTML généré ? Cette dernière solution aurait l'avantage (quand même elle imposerait un travail fastidieux, s'agissant de deux siècles d'archives, dont les plus anciennes obéissent à des pratiques typographiques abandonnées depuis) de rendre ces archives accessibles à tous, tout en remplissant le critère 1.9 d'Accessiweb (Chaque image texte doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée ?) ainsi que le point de contrôle 3.1 des WCAG 1.0 (When an appropriate markup language exists, use markup rather than images to convey information. ; en français : Quand un langage de balisage approprié existe, utiliser des balises plutôt que des images pour convoyer l'information.).

Contenu en Flash : prévoir encore et toujours un contenu de substitution

Victor Brito — Mon, 07 Jul 2008 21:36:00 +0200

Ces derniers jours, des articles ont pullulé sur le Web annonçant un meilleur référencement du contenu en Flash. Or, cet enthousiasme est à relativiser.

D'une part, l'indexation en soi des fichiers Flash ne pose plus de problème, du moins pour Google. Cette requête, qui utilise une commande particulière pour restreindre la recherche aux fichiers Flash, en apporte la preuve.

D'autre part, le blog pour webmasters de Google indique que les améliorations sont plutôt restreintes, comme le résume Neoma Interactive :

Google n'indexe pas les images ;

le robot ne détecte que les textes présents dans l'animation ;

il ne prend pas en compte les données XML, il en va donc des données textuelles en XML ;

plus généralement Google n'indexe pas les contenus externes aux fichiers SWF, comme d’autres .swf, du .txt, du .mp3, ou du .flv, etc. Voilà c'est plus simple ;

enfin (à mon sens le plus important !) le moteur n’indexe pas les fichiers swf lancés par javascript depuis les pages Web (la majorité des sites full-flash en gros).

Comme le dit Olivier Andrieu : Ne nous emballons pas… notamment en cas d'utilisation de SWFObject, une bibliothèque JavaScript bien répandue (qui a le mérite de ne pas négliger l'accessibilité, tout en tenant compte de l'éventuelle absence de mise à jour de la version du lecteur Flash installé côté client).

Bref, quelle que soit l'évolution des capacités des robots des moteurs de recherche, il faudra encore et toujours prévoir un contenu de substitution au Flash. Et la manière la plus simple (et la plus efficace) est de le faire en HTML, comme suit :

<object type="application/x-shockwave-flash" width="100" height="200">
  <param name="movie" value="mon-fichier-flash.swf" />
  <param name="wmode" value="transparent" />
  <p>Ce paragraphe sera affiché par le navigateur si ce dernier ne peut prendre en charge le Flash
  et sera lu par les robots des moteurs de recherche, qu'ils lisent un peu le Flash ou pas.
  Bien entendu, ce paragraphe, pour être efficace du point de vue de l'accessibilité, devra fournir l'équivalent 
  du contenu affiché par le Flash.</p>
</object>

Mise à jour de contenu « en temps réel » et accessibilité : l'exemple de Yahoo! Sport

Victor Brito — Sun, 22 Jun 2008 15:54:00 +0200

Depuis deux semaines, l'actualité sportive est dominée par l'Euro 2008. Pour en suivre les matchs, il n'est pas nécessaire de s'asseoir devant un poste de télévision, que ce soit chez soi, chez des amis ou au café le plus proche : en effet, sur le Web, il est non seulement possible de lire des articles rapportant les résultats, mais aussi de suivre les matchs « en direct », ce que propose notamment Yahoo! Sport.

Or, suivre un match « en direct » sur le Web n'est pas sans poser quelques problèmes d'ordre technique. S'il s'agit d'une retransmission digne de celle de la télévision, il y a le problème du format vidéo à adopter et du support du plug-in nécessaire pour visionner la vidéo si elle est intégrée à la page Web, sans oublier la bande passante mise à l'épreuve par la diffusion en flux continu.

Yahoo! Sport, pour sa part, fait abstraction de la vidéo, qui est remplacée par des commentaires à chaud, sous forme textuelle. Dans ce cas, le problème technique se résume à la mise à jour du contenu « en temps réel » : plus la page est appelée à être rafraîchie, plus le serveur est sollicité et plus son temps de réponse peut varier s'il y a une forte demande (cas d'un site à fort trafic). Ajax, de par le principe même de la requête asynchrone, permet de contourner la difficulté en ne rechargeant que les commentaires et épargnant ainsi la bande passante. Afin que l'utilisateur ne soit pas perturbé par l'ajout de nouveaux commentaires sans action de sa part, un bloc (qui comporte un gif animé symbolisant le chargement d'une page) lui indique en temps réel dans combien de temps (en secondes) la mise à jour automatique s'effectuera (elle s'effectue toutes les 30 secondes).

En revanche, dès qu'on désactive JavaScript, le bloc en question montre toujours le gif animé et la mention MAJ, mais n'indique plus dans combien de temps le rafraîchissement du contenu s'effectuera.

Et pour cause : il n'y a plus de rafraîchissement automatique. Ce qui veut dire que cette opération est effectuée côté serveur : la preuve, le code source ne mentionne aucun élément meta de type refresh, ce qui est déjà une bonne chose du point de vue de l'accessibilité. Mais, mis à part l'utilisation de la fonction d'actualisation implémentée par le navigateur, il n'existe, pour toute alternative à ce que fait Ajax, qu'un lien hypertexte, en dur, qui pointe vers l'ancre où se trouvent les commentaires et qui n'est autre que la mention « MAJ ». Mais, ce lien (et surtout sa fonction) n'est pas facile à repérer du premier coup : moi-même j'ai cru, au départ, qu'il n'y en avait pas ! De plus, il est accompagné d'un attribut title qui fait doublon avec son contenu textuel.

Certes, Ajax permet de soulager le serveur et d'économiser de la bande passante pour la fonction dont il est question sur ce billet ; mais, même si l'on prévient du prochain rechargement partiel de la page, il serait mieux de fournir un lien permettant de désactiver (ou de réactiver) la mise à jour périodique automatique. Même si les commentaires de match publiés sur Yahoo! Sport sont courts, on ne peut deviner, en effet, combien de temps l'utilisateur a besoin pour les lire et suivre l'évolution du match : un utilisateur qui lit lentement sera plus facilement perturbé par le rafraîchissement automatique, sans oublier les utilisateurs se servant d'un lecteur d'écran (synthèse vocale ou plage braille).

Bref, l'exemple de Yahoo! Sport est un véritable cas d'école pour ce qui concerne l'accessibilité d'un contenu du Web mis à jour à intervalles très rapprochés, voire en temps réel.

Référentiel Accessiweb version 1.1

Victor Brito — Tue, 10 Jun 2008 16:01:00 +0200

La nouvelle version du référentiel d'Accessiweb est sortie hier, événement rapporté, entre autres, par Matthieu Faure sur Blog accessibilité.

Les principales nouveautés de la nouvelle version du référentiel publié par l'association BrailleNet se résument ainsi :

Le référentiel AccessiWeb v1.1 se décline en 2 listes permettant une utilisation adaptée au profil de l'utilisateur :

AccessiWeb v1.1 [Général] : liste courte de critères dont la formulation permet une compréhension par le plus grand nombre. Le profil de l'utilisateur de cette liste correspond à celui des managers, des consultants, des chefs de projet et du grand public de manière générale.

AccessiWeb v1.1 [Déployé] : liste étendue de tests en totale correspondance avec les critères de AccessiWeb v1.1 [Général] (ie, à chaque critère correspond un ensemble de tests). La formulation de ces tests est plus technique. Le profil de l'utilisateur de cette liste correspond à celui des experts en accessibilité, des spécialistes, des chercheurs, des professeurs en université et écoles, des webmasters, des développeurs et des évaluateurs de l'accessibilité des sites Web.

Le référentiel AccessiWeb v1.1 comporte un glossaire. Ainsi, les intitulés des critères et tests - qui contiennent parfois des mots ou des expressions nécessitant une définition (mot technique, expression spécifique…) - sont compréhensibles de la même manière par tous.

Chacune des 13 thématiques du référentiel AccessiWeb v1.1 débute par une recommandation pour développer de manière accessible.

Un nombre limité de critères ont leur champ d'application modifié dans certains cas particuliers listés dans le glossaire.

Le Guide AccessiWeb a été mis à jour. En plus d'une fiche par critère, il contient à présent :

les manuels d'aide à l'évaluation : ces manuels expliquent comment évaluer l'accessibilité d'un site Web par l'analyse de son code source ou en utilisant les outils d'évaluation en ligne pour Internet Explorer et Firefox,

les tables de correspondance vers les autres référentiels sur l'accessibilité du Web : ces tables permettent d'évaluer le niveau d'accessibilité d'un site Web pour différents référentiels à partir du référentiel AccessiWeb v1.1.

Accessiweb 1.1 comporte 95 critères pour le volet général et 243 tests pour le volet déployé, le tout réparti en 13 thématiques :

images,
cadres,
couleurs,
multimédia,
tableaux,
liens,
code exécutable,
éléments obligatoires,
structuration de l'information,
présentation de l'information,
formulaires,
navigation,
consultation.

Pour finir, voici une liste de liens permettant d'en savoir plus, de consulter le texte de ce référentiel et de le comparer avec la précédente version ou avec d'autres directives comme les WCAG ou le RGAA :

Le RGAA publié avant l'été

Victor Brito — Sat, 07 Jun 2008 15:44:00 +0200

Rapporté par un billet de Tentatives accessibles, le Plan Handicap Visuel, présenté par le Ministère du Travail, ne dit a priori rien sur l'accessibilité du Web, du moins dans ses cinq mesures-phares.

Je dis bien a priori, puisque le communiqué de presse apporte des détails intéressants, y compris sur le RGAA et le décret d'application de la loi du 11 février 2005.

Principales orientations du Plan Handicap Visuel

L'intégration sociale personnes déficientes visuelles exige d'accéder aux moyens de communication du 21ème siècle

Enfin, nous rendrons réellement accessibles les sites internet des services publics comme l'a prévu la loi du 11 février 2005.

Pour cela, un référentiel technique sera publié avant l'été et une concertation aura lieu à la fois au niveau des commissions départementales prévues par la loi et au niveau communautaire sur la mise en œuvre concrète de cette mesure. La réflexion portera notamment sur les éventuelles sanctions à mettre en œuvre en cas de non respect de la loi. Ce dispositif sera mis en œuvre dès la fin 2008.

Axe 3 - Vivre pleinement sa citoyenneté

Objectif 7 - Accéder aux modes de communication du 21ème siècle

Mesure 22

Mettre internet au service de l'autonomie des personnes déficientes visuelles

Calendrier de l'objectif 7

Automne 2008 : Adoption d'une disposition législative organisant la diffusion de programmes audiodécrits par les éditeurs de services de télévision et améliorant l'accessibilité d'Internet

Précisions sur la mesure 22

Contexte

L'article 47 de la loi du 11 février 2005 introduit en France une nouvelle obligation à la charge des administrations, collectivités locales et services publics : rendre accessibles leurs sites internet à tous, notamment aux personnes handicapées.

Il prévoit que cette mise en accessibilité doit être effectuée dans les trois ans suivant la publication de la loi par référence aux normes internationales (Web Accessibility Initiative, ou WAI). Ainsi, un référentiel est en cours d'élaboration (Référentiel Général d'Accessibilité des administrations) qui reprend les 65 points de contrôle prévus par cette norme.

Le processus de validation accompagnant le RGAA est innovant : la certification ne sera plus effectuée par un organisme et sur demande, mais automatiquement, à partir de modalités de tests prédéfinies dans le référentiel lui-même. Chaque point de contrôle du référentiel fait donc l'objet d'un ou plusieurs tests de validation très précis, qui permettent à l'équipe responsable d'un site internet de vérifier et d'améliorer elle-même l'accessibilité de celui-ci.

Mais ce référentiel doit encore être rendu opposable à l'ensemble des services publics, à travers la publication d'un décret.

Objectif

Plusieurs objectifs sont à atteindre pour la période 2008-2011 :

Publier le décret d'application de la loi du 11 février 2005 relative à l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées,

Élargir le mandat des commissions territoriales prévues par l'article 46 de la loi de 2005 pour l'accessibilité des services de communication des collectivités territoriales,

Développer l'accessibilité des personnes handicapées visuelles à Internet.

Mesures

Animer le groupe de travail communautaire existant dans le cadre du Référentiel Général d'Accessibilité des administrations afin de rendre opposables les recommandations pour les normes WAI ;

Mettre en place le dispositif de sanctions prévu par la loi à l'encontre des responsables de services de communication publics en ligne non accessibles aux personnes handicapées ;

Assurer la publication du décret sur l'accessibilité des sites internet des services publics pris en application de la loi du 11 février 2005, ainsi que son référentiel technique (arrêté) avant la fin du mois de juillet 2008 ;

Développer l'accessibilité des personnes handicapées visuelles à Internet, à l'occasion de la transposition de la directive 2007/65/CE du 11 décembre 2007 dite directive « Services de médias audiovisuels ».

Calendrier

Juillet 2008 : publication du décret sur l'accessibilité des sites internet des services publics et de son référentiel technique (arrêté),

Deuxième semestre 2008 : élargir le mandat des commissions territoriales,

2008-2011 : animation du groupe de travail communautaire, transposition de la directive 2007/65/CE.

Enfin, le tableau de financement du Plan n'indique aucun coût pour la mise en œuvre de la mesure 22.

Le communiqué de presse est consultable au format PDF.

Conclusion : une bonne nouvelle.

Peu d'accessibilité nuit au référencement : l'exemple du site du Larousse

Victor Brito — Mon, 26 May 2008 14:56:00 +0200

Dans un de mes précédents billets, intitulé Référencement et accessibilité selon Google, je rapportais des conseils prodigués par le blog pour webmasters de Google en matière d'accessibilité, lesquels conseils prouvaient que référencement et accessibilité étaient deux domaines interdépendants.

Une autre preuve peut être apportée par le contraire : un site peu accessible est mal optimisé pour le référencement.

Il y a quelques jours, Jean-François Naud a publié sur son site Le Web accessible un article rapportant que la page d'accueil de Larousse.fr est très peu accessible. Même s'il s'agit d'un court audit, le constat est assez édifiant (pour plus de détails, je vous invite à consulter l'article de Jean-François Naud).

En lisant cet article, je l'ai vite rapproché du billet d'Olivier Andrieu sur l'encyclopédie en ligne de Larousse, qui fait la remarque suivante :

Larousse arrivera-t-il également à apparaître aussi bien que son concurrent Wikipédia dans les pages de résultats de Google ? Au vu de la faible optimisation (quasi inexistante en fait, au vu du code HTML des pages) de ses pages Web pour les moteurs de recherche, la partie n'est pas gagnée d'avance…

Conclusion : une fois encore, une page Web accessible est déjà une page suffisamment optimisée pour être référencée sans problème par les moteurs de recherche.

La déclaration de revenus en ligne est inaccessible

Victor Brito — Fri, 02 May 2008 16:30:00 +0200

C'est à partir d'aujourd'hui que les contribuables, s'ils le souhaitent, peuvent déclarer en ligne leurs revenus de 2007. C'est aussi aujourd'hui que, pour ma part, j'ai choisi de m'acquitter de ce devoir. Étant donné que je déclare en ligne pour la première fois, je remplis le formulaire d'abonnement, utilisant mon navigateur préféré (Opera). Mais, quelle n'est pas ma surprise lorsque je valide la première étape de ce formulaire !

Je tombe sur un message m'avertissant d'un problème de configuration lié à mon navigateur, visiblement détecté.

Voici ce que me dit ce message :

Le type de navigateur que vous utilisez ne vous permet pas de vous abonner aux services en ligne.
Pour consulter les configurations compatibles, cliquez sur le lien ci-dessous.

Je clique sur le lien, intitulé Configuration requise, et tombe sur une liste, agrémentée çà et là d'un tableau.

Les navigateurs acceptés sont les suivants :

pour Windows 98, Windows Millenium et Windows 2000 :
- Internet Explorer 5.5 et 6,
- les navigateurs utilisant le moteur de rendu Gecko (Firefox, Netscape 9 et Seamonkey) ;
pour Windows XP :
- Internet Explorer 6 et 7,
- les mêmes navigateurs utilisant Gecko que ci-dessus ;
pour Windows Vista :
- Internet Explorer 7,
- les mêmes navigateurs utilisant Gecko que ci-dessus ;
pour la distribution Linux Mandriva :
- les mêmes navigateurs utilisant Gecko que ci-dessus ;
pour Mac OS X :
- Firefox 2,
- Netscape 9 (sauf pour Mac OS X version 10.3),
- Seamonkey 1.1 (la version 1.0 n'est acceptée que pour Mac OS X version 10.4),
- Camino (la version 1.5 est la version minimale acceptée pour Mac OS X version 10.5).

Bref, cette liste exclut les utilisateurs d'Opera, ainsi que les utilisateurs d'un Mac qui se contentent du navigateur fourni par défaut, à savoir Safari. Quant aux utilisateurs d'une distribution de Linux autre que Mandriva, je me demande s'ils sont d'emblée refoulés, même s'ils utilisent Firefox. Et que dire des utilisateurs de Konqueror ? En outre, la liste mentionne la toute dernière version de Netscape, un navigateur dont le développement a été arrêté et dont le support n'est plus assuré depuis le premier février dernier ; heureusement qu'il n'est pas question d'Internet Explorer 5 pour Mac !

À cela il faut ajouter que le navigateur doit accepter les cookies et que JavaScript doit être activé. Bref, de quoi ne pas rassurer l'utilisateur qui se montre paranoïaque vis-à-vis de ce qu'il croit, à tort ou à raison, être comme une intrusion plus ou moins suspecte dans son poste et désactive, par conséquent, ces deux paramètres.

Et je ne parle pas du formulaire de déclaration de revenus, qui, visiblement, abuse du verbe cliquer et oublie d'associer les cases à cocher et autres champs de saisie au texte correspondant. Autrement dit, je souhaite bien du courage aux contribuables aveugles tentés de déclarer leurs revenus en ligne, ainsi qu'à ceux qui seront chargés de rendre ce service en ligne de l'administration fiscale conforme au RGAA.

Référencement et accessibilité selon Google

Victor Brito — Tue, 15 Apr 2008 21:40:00 +0200

Référencement et accessibilité d'un site Web ne vont pas l'un sans l'autre. Les critères dans ces deux domaines, comme le dit à juste titre Olivier Andrieu, sont le plus souvent très proches.

C'est pourquoi le blog pour webmasters de Google vient de publier un billet intitulé Webmaster tips for creating accessible, crawlable sites.

Ce billet se concentre sur les conseils suivants :

s'assurer que tout le contenu important est atteignable,
s'assurer que le contenu est lisible,
s'assurer que le contenu est disponible dans l'ordre de lecture,
ne pas craindre la redondance pour apporter du supplément à tout le contenu visuel.

Le billet rappelle ainsi que l'on atteint du contenu au moyen de liens hypertextes et que ces derniers doivent avoir une cible qui soit une véritable URL, plutôt que d'être vides et de dépendre d'un événement JavaScript.

Un contenu lisible doit l'être de tous ; et ce billet rappelle les handicaps dont souffre Googlebot, le robot d'indexation de Google, même si des fichiers Flash sont présents dans l'index de Google : Du contenu caché derrière des animations en Flash ou du texte généré au sein du navigateur par du JavaScript exécutable demeure opaque pour Googlebot, ainsi que pour la plupart des utilisateurs aveugles. C'est une fois de plus la preuve qu'un site complètement en Flash ou en Ajax aura du mal à être référencé.

Par ordre de lecture, le billet entend qu'une imbrication de tableaux rend difficile la mise en relation de bouts de texte d'une façon logique et privilégie donc le recours aux CSS et à des éléments div logiquement organisés.

Quant au contenu visuel, Google rejoint les différentes directives d'accessibilité existantes et va même plus loin que la recommandation d'ajouter des équivalents textuels : le texte entourant une image doit être suffisamment étoffé pour fournir le contexte d'utilisation de cette dernière.

Enfin, ce billet conclut qu'en suivant ses conseils, vous découvrirez surtout avec plaisir que, comme effet secondaire positif, votre site devient mieux indexé.