Développement Web

Fil des billets - Fil des commentaires

samedi 26 septembre 2009

L'élément img est mal nommé...

L'élément img est mal nommé: il ne reflète pas vraiment sa fonction en pratique.

À la suite d'un échange l'autre jour avec un collègue, je me suis dit que je devrais poster un petit billet en récapitulant les conclusions. J'y avais alors développé une réflexion sur la nature de l'élément img tel que je la perçois. J'en avais d'ailleurs déjà dit quelques mots sur la liste de diffusion Accesstech en avril 2008.

Dans la recommandation du W3C, il est précisé que The IMG element embeds an image in the current document at the location of the element's definition. Il est peu probable, au vu de l'état actuel de la recommandation HTML5, que cette manière de présenter les choses changent.

Cependant, elle reflète une vision très centrée sur les navigateurs graphiques (sans jeu de mots...). En effet, quand le document contenant un élément img est parcouru par un outil de consultation non graphique, comme un lecteur d'écran par exemple,ce n'est évidemment pas l'image qui est restituée, mais bien son « alternative » fournie par les attributs alt et éventuellement longdesc.

Or une alternative n'est pas une « roue de secours » si l'image n'est pas présente : c'est bien une autre manière de présenter l'information. Cette information est une donnée hors contexte; c'est « quelque chose » que le rédacteur a voulu transmettre à son lectorat. Il a opté pour ce faire pour une publication Web par le truchement du langage HTML.. Dans ce processus de mise en forme de l'information, il a été amené à faire un choix éditorial en sélectionnant, à un moment donné, un mode de présentation: texte seul ou contenu graphique. Mais à la base, c'est bien d'une information unique dont il s'agit. Si par exemple il souhaite exposer l'évolution des ventes de réfrigérateurs de son entreprise, il aura le choix entre une présentation tabulaire ou un graphique (les deux solutions ne s'excluant pas mutuellement).

Un tableau favorise les utilisateurs dont le mode d'esprit est analytique, tandis qu'un graphique est plus facile à interpréter par les utilisateurs dont le fonctionnement mental est plus synthétique. Pourquoi ne pas franchir le pas et admettre que les deux formes de présentation de l'information sont réellement équivalentes?

L'élément img apparaît alors comme un moyen simple et élégant de fournir les deux mises en forme de l'information simultanément. Cela revient à ne plus considérer l'attribut src comme « plus nécessaire » que l'attribut alt. Après tout, ils jouent un rôle symétrique pour un navigateur graphique:

  • quand src est présent mais pas alt, c'est l'image qui est affichée, soit le contenu pointé par src;
  • quand alt est présent mais pas src, c'est le contenu textuel qui est affiché.
Par conséquent, la signification de l'élément img peut être réévaluée: ce n'est plus seulement le moyen d'insérer une image dans un document HTML; c'est aussi bien plus, dans la mesure où c'est un élément qui permet de fournir une information donnée sous deux formats différents simultanément.

jeudi 18 octobre 2007

Accessibilité et qualité

Un premier billet dans cette catégorie pour aborder deux thèmes qui me tiennent à cœur.
Voici quelques jours, sur l'excellent forum de l'excellent site Alsacreations, un sujet a été posté, initialement consacré à la création d'une Liste synthèse des critères d'accessibilité Accessiweb et  du R.G.A.A. (le Référentiel Général d'Accessibilité des Administrations). Puis, comme cela arrive souvent, il y a une dérive.
J'ai contribué à cette dérive en faisant un petit historique de la prise en compte de l'accessibilité en France (tel que je le vois).  En voici la teneur :

Je crois qu'il n'est jamais complètement inutile de faire un peu d'histoire. La méthode d'application AccessiWeb (comme les autres d'ailleurs) est arrivée à un moment où la majeure partie des développeurs et décideurs n'avaient jamais entendu parler d'accessibilité numérique, a fortiori sur le Web. Placer dès le début la barre haute en proclamant que l'accessibilité doit faire partie d'un processus global dès la conception, ç'aurait été souffler dans un violon. Ça ne fait pas de bruit, et les gens au mieux vous regardent avec de grands yeux en se demandant ce que vous êtes en train de faire. Écrire une méthode d'application des WCAG était donc un moyen simple, adapté à la cible de l'époque et plus généralement à son contexte, pour essayer de commencer à améliorer les choses en tâchant de faire prendre conscience du problème à un maximum de gens, par diffusion principalement.

Depuis, la profession s'est... professionnalisée. Parallèlement, les notions de qualité se sont de plus en plus diffusées dans l'industrie. La problématique de l'insertion de l'accessibilité dans une démarche plus large ne pouvait pas, à mon avis, être posée avant la conjonction de ces deux constats :

  1. la qualité est un processus global à mettre en oeuvre dès la conception d'un produit, jusqu'à sa livraison finale voire au-delà ;
  2. un site Web est un produit et non pas simplement un flyer de marabout que des étudiants distribuent à la sortie du métro (oui, j'exagère un peu, mais au fond qu'était-ce qu'un site vitrine voici une demi-douzaine d'années ?).

Dès qu'il a été reconnu que le développement d'un site était un processus industriel et non plus seulement l'aimable amusement de week-end d'une poignée de geeks boutonneux, la voie était pavée pour que l'accessibilité soit prise en compte telle qu'elle aurait dû l'être. Ou plutôt, car on ne sait jamais de quoi demain sera fait, telle que nous concevons aujourd'hui qu'elle doit l'être.

Je crois que nous n'en sommes qu'au début de cette deuxième phase. Les grilles d'application comme AccessiWeb étaient parfaitement adaptées au contexte d'il y a quelques années. Elles sont encore adaptées quand il s'agit de dresser un état des lieux afin de faire prendre conscience de l'existence d'un problème. Maintenant, le terrain est mûr du côté de l'industrie pour que les conceptions évoluent -passer du simple constat d'(in)accessibilité à un instant donné, sanctionné ou non par un label (un instantané), à la correction (maintenance corrective...) par l'application d'une démarche d'amélioration continue dans la durée, dont l'accessibilité est un aspect (en même temps qu'un des moyens).

J'ajouterais aujourd'hui un complément (c'est d'ailleurs le propre des compléments que d'être ajoutés :-)), en développant la dernière phrase : le terrain est mûr du côté de l'industrie pour que les conceptions évoluent -passer du simple constat d'(in)accessibilité à un instant donné, sanctionné ou non par un label (un instantané), à la correction (maintenance corrective...) par l'application d'une démarche d'amélioration continue dans la durée, dont l'accessibilité est un aspect (en même temps qu'un des moyens).

Une démarche qualité se conçoit comme un processus d'amélioration continue. Rien n'est jamais coulé dans le bronze, et traquer les inévitables imperfections (non conformités) pour les corriger fait partie (avec la maintenance préventive) de ce processus. Je dirais plus, c'est un des meilleurs moyens d'impliquer le personnel dans une telle démarche -implication sans laquelle elle perd tout sens.

Si l'on applique une démarche qualité à un développement Web, tout au long du processus de la conception à la mise en production, alors je pense que la prise en compte de l'accessibilité a un important rôle à jouer, notamment comme élément moteur de cette démarche. C'est ce que j'entendais par être un des moyens de cette démarche. En effet,

  • Une prise en compte progressive des contraintes liées à l'accessibilité dans le projet permet une appropriation sans trop d'efforts de la part des intervenants. Une démarche d'amélioration continue permet par exemple, dans un premier temps, de convaincre les intervenants de libeller de manière explicite les intitulés de liens qu'ils placent et de rédiger des alternatives textuelles convenables aux éléments graphiques, puis dans un deuxième temps de travailler sur la structure de l'information dans la page ou revoir les formulaires, etc (ce n'est qu'un exemple, les objectifs intermédiaires dépendent bien évidemment du site considéré).
  • L'accessibilité trouve sa place à toutes les étapes de la chaîne de production: du designer au développeur en passant par le rédacteur de contenu, tous sont concernés à un moment ou un autre. Il s'agit donc d'une thématique toute trouvée pour fédérer une équipe autour d'un projet qualité, une sorte de fil rouge pour que chacun prenne conscience qu'il fait partie d'un processus global.
  • À un niveau plus individuel, hors de la dynamique de groupe, la prise en compte de l'accessibilité permet de responsabiliser chacun des intervenants tout au long du processus de production, en lui faisant prendre conscience que ce qu'il reçoit de l'étape précédente a des conséquences sur ce qu'il peut produire, et que ce qu'il réalise conditionne l'intégrité de la suite du processus.

La prise en compte de l'accessibilité est donc effectivement un aspect d'une démarche qualité dans un processus de développement Web, mais c'est aussi un moyen pour les responsables de projet de fédérer leur équipe autour d'un but commun, tout en impliquant leurs collaborateurs personnellement, quelles que soient leurs responsabilités individuelles dans le processus. Cette prise en compte, en s'inscrivant dans une optique d'amélioration continue, permet de surcroît de « récompenser » les intervenants en leur montrant que chacune de leurs réalisations, même minime, est suivie d'un effet positif, et de maintenir ainsi intacte la motivation initiale.