Blog - Britoweb - Tag - accessibilité

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>

Google Documents et les navigateurs : de l'inaccessibilité dans l'air

Victor Brito — Tue, 24 Jun 2008 21:54:00 +0200

Dans le cadre de mes activités professionnelles, je suis appelé à utiliser Google Documents, notamment pour consulter des plannings affichés sous forme de tableur. S'agissant d'une application en ligne, j'utilise mon navigateur préféré qu'est Opera. Quelle n'est pas ma consternation lorsque, tout en haut de la page affichant ce que je veux consulter, je lis un message d'avertissement.

Le message d'avertissement dit ceci : Actuellement, vous consultez Google Documents en mode HTML normal. Utilisez un navigateur pris en charge pour modifier et partager des documents en temps réel. Les termes « utilisez un navigateur pris en charge » forment un lien pointant la page du Centre d'aide de Google Documents sur la configuration système requise, qui dit ceci :

Si vous accédez à Internet au moyen d'un ordinateur sous Windows, Macintosh ou Linux, Google Documents fonctionnera avec les navigateurs suivants :

Internet Explorer 6.0+ pour Windows

Firefox 1.07+

Safari 3.1+

Google Documents n'est pas pris en charge et ne fonctionnera sans doute pas avec :

Firefox 3

Versions de Safari antérieures à la 3.0

Internet Explorer (Mac) ou Internet Explorer 4 (Windows)

Opera

Mozilla

Netscape

Quel que soit le type de navigateur, vous devez :

activer les cookies

activer JavaScript

Que l'on oublie Internet Explorer 4, Internet Explorer Mac ou Netscape, passe encore ; mais, qu'on exclue les utilisateurs d'Opera et, surtout, ceux de Firefox 3 (dont la version finale est sortie la semaine dernière), c'est à la limite du comble, qu'on ait ou non oublié de mettre à jour la notice du support. Et que dire de ceux qui veulent consulter leurs documents en tableurs en ligne depuis leur portable (où l'on peut aisément tomber sur un navigateur figurant sur la liste des exclus ou dont le support de Google Documents ne dit mot) ?

Bref, c'est dommage que Google Documents pèche par manque d'accessibilité du point de vue logiciel, d'autant plus qu'il s'agit d'une application très intéressante pour ce qu'elle propose, et ce en n'ignorant pas qu'il existe des formats ouverts et interopérables comme ODF.

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.

Pétition pour l'accessibilité numérique des services publics

Victor Brito — Fri, 09 May 2008 16:44:00 +0200

Dans la législation française figure la loi numéro 2005-102 du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées. L'article 47 de ladite loi dit ceci :

Les services de communication publique en ligne des services de l'État, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées.

L'accessibilité des services de communication publique en ligne concerne l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation. Les recommandations internationales pour l'accessibilité de l'internet doivent être appliquées pour les services de communication publique en ligne.

Un décret en Conseil d'État fixe les règles relatives à l'accessibilité et précise, par référence aux recommandations établies par l'Agence pour le développement de l'administration électronique, la nature des adaptations à mettre en oeuvre ainsi que les délais de mise en conformité des sites existants, qui ne peuvent excéder trois ans, et les sanctions imposées en cas de non-respect de cette mise en accessibilité. Le décret énonce en outre les modalités de formation des personnels intervenant sur les services de communication publique en ligne.

Or, trois ans après, le décret d'application de cet article se fait toujours attendre.

Afin de faire pression sur les pouvoirs publics, signons la pétition pour l'accessibilité numérique des services publics ! Elle est une initiative de Vincent Aniort et d’Aurélien Levy, tous les deux experts en accessibilité, et de Franck Galey webmestre du site web-pour-tous.

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.

Spip 1.9 de Michel-Marie Maudet, Anne-Laure et Dominique Quatravaux : note de lecture

Victor Brito — Sun, 09 Mar 2008 16:09:00 +0100

Les éditions Eyrolles publient Spip 1.9, de Michel-Marie Maudet, Anne-Laure et Dominique Quatravaux.

Ce livre n'est pas une nouveauté toute fraîche, puisqu'il est publié depuis un an. Mais, il a le mérite non seulement d'être clair pour le grand public qui ne maîtrise pas nécessairement les moyens de création d'un site, mais aussi de promouvoir des logiciels libres (non seulement Spip, le CMS constituant le sujet de ce livre ; mais aussi Open Office, en expliquant les avantages du format ouvert de la suite bureautique de Sun sur un format propriétaire comme celui de Microsoft) et d'insister sur la nécessité de rendre un site Web accessible au plus grand nombre, exemples et témoignages à l'appui.

Bref, on ne peut qu'admirer une telle démarche pédagogique.

Une nouvelle démarche accessibilité ?

Victor Brito — Fri, 15 Feb 2008 11:55:00 +0100

L'accessibilité doit-elle ne consister qu'à atteindre des résultats de conformité à des directives du W3C ? Élie Sloïm, un des contributeurs d'Openweb, répond par la négative. Il dit même plus : se contenter d'une telle démarche est une erreur.

Il s'en explique dans deux articles d'Openweb sur les nouveaux défis de l'accessibilité numérique.

Dans le premier article, il s'attarde sur la vision actuelle (et erronée, selon lui) de l'accessibilité. Le W3C a publié depuis 1999 plusieurs documents sur l'accessibilité, dont certains contiennent des directives. Dans certains pays, la législation lui a emboîté le pas en s'inspirant de ces directives quand elle ne les transposait pas : la section 508 aux États-Unis en est la preuve la plus illustre. Cela a conduit à interpréter ces directives (qui, à la base, sont des recommandations) comme des objectifs à atteindre pour être estampillé site accessible.

Cette vision de l'accessibilité ne tient pas compte de la complexité de l'accessibilité (comment, par exemple, vérifier qu'un site est accessible du point de vue de la clarté de son contenu ?) ni des démarches à adopter pour parvenir à l'accessibilité. C'est pourquoi le second article fournit quelques éléments pour la mise au point d'une nouvelle démarche et d'une nouvelle vision de l'accessibilité, en partant du principe que tout problème éventuellement rencontré par un internaute est à traiter comme un risque. Par conséquent, la nouvelle démarche doit s'inscrire dans un processus de prévention et de gestion des risques liés à l'accessibilité, sans négliger la démarche d'amélioration continue. L'article établit une comparaison entre cette nouvelle démarche et la gestion des risques dans l'industrie alimentaire : dans ce dernier domaine, la gestion des risques est obligatoire ; mais, il est stupide voire contre-productif de décréter que la nourriture des cantines est exempte de dangers. De même, il est admissible qu'un site public ne soit pas à 100 % accessible, mais moins acceptable que la démarche n'ait même pas été lancée.

Pour plus de détails, je vous recommande la lecture de ces deux articles.

Pour rappel, vous pouvez consulter sur Britoweb un article sur les moyens techniques pour l'accessibilité du contenu du Web.