La dure vie d’évangéliste passionné

Aujourd’hui comme souvent ces derniers temps, je suis dans le TGV, je vadrouille dans la petite France métropolitaine pour diffuser la bonne parole. Voilà donc le résumé d’une journée typique d’évangéliste de l’accessibilité et des bonnes pratiques.

Aujourd’hui comme souvent ces derniers temps, je suis dans le TGV, je vadrouille dans la petite France métropolitaine pour diffuser la bonne parole. Voilà donc le résumé d’une journée typique d’évangéliste de l’accessibilité et des bonnes pratiques.

Un peu d’histoire

Je suis entré par la petite porte dans le développement web, par le truchement d’Internet Assistant pour Word 95, osons le dire. J’ai donc regardé mon traitement de texte écrire pour moi un lien d’un fichier vers l’autre, et j’étais épaté de voir, là, sous mes yeux, un bout du web fait par moi tout seul avec deux clics ! Ah, enthousiasme naïf de la jeunesse [1] ! J’ai vite vu que ce n’était pas si difficile, et que même un non-technicien comme j’étais alors s’en sortirait sans problème en tapant directement le code.

Et nous voilà huit ans plus tard, quelques langages plus loin, et j’en suis toujours à taper du HTML. Rien ne change— tout change. « Tu vas t’ennuyer », disait Jean-Noël, au début. Je ne fais plus "simplement" du HTML, et je ne m’ennuie pas encore. Entretemps j’ai découvert que le web est le point de recontre de toutes mes passions :

  • le graphisme (j’aime le joli, le plaisir formel/sensuel)
  • le design (ne surtout pas le confondre avec le précédent : un bon design répond à un besoin d’adéquation de la forme aux besoins de l’utilisateur en tenant compte des spécificités du produit)
  • la communication (au sens large d’échange)
  • l’anglais (les informations sont souvent plus fraîches et plus poussées en anglais, c’est comme ça, il n’y a rien à critiquer, l’anglais est la langue internationale du siècle, comme le latin et le français avant elle...)
  • l’informatique (un reste d’approche matheuse de l’existence, sans doute)

Des horaires de galérien ?

Lever à 5h30. L’avenir appartient à ceux qui se lèvent tôt et habitent en banlieue ! Aucun sacrifice n’est trop important pour les croisés, la cause est noble, etc etc. Allez, je vous donne la vraie raison, si vous la voulez : j’ai trop peur de rater mon train pour me permettre un retard... Le TGV part à 9 heures, arrive à 11. Me voilà à Lyon après trois heures de transports, RER compris, pour une demie-journée de formation.

Le temps de prendre un repas avec mon chef de projet en charge de l’accessibilité du système d’information [2], et il est déjà 13 heures trente, l’heure de la rencontre avec les stagiaires du jour. Nous voilà partis pour trois heures de suite à bâtons rompus, d’enseignements théoriques sur les bonnes pratiques (notamment la séparation contenu/forme/comportement), les bons réflexes à avoir (validation du code, le voeu pieu du jour), et surtout, de vraies questions pratiques.

Trois heures qui passent toujours trop vite, et à nouveau il me faudra trois heures pour rentrer chez moi.

Vu de l’extérieur, on pourrait penser que le jeu n’en vaut qu’à peine la chandelle : se lever à cinq heures et demie pour rentrer à huit heures du soir chez soi, subir six heures de transports pour moitié moins de temps "rentable". Stéphanie le remarquait encore hier : « Mais... tu es vraiment obligé d’y aller ? »

Une rentabilité indirecte

J’ai déjà participé à des formations sur l’accessibilité, et à chaque fois j’ai été surpris par le décalage entre les consignes relayées par les formateurs et la réalité de l’exercice. Bien sûr, une contrainte des formations est le temps réduit dont on dispose : il vaut mieux alors dispenser les meilleures règles à appliquer, en espérant que les stagiaires sauront les transposer au mieux en tenant compte de leurs contraintes particulières.

En pratique, j’ai fini par ancrer chacune de mes remarques dans un contexte réel. Par exemple, chaque fois que je détaille l’usage normal des formulaires HTML, sans Javascript, etc, j’ai toujours la même réaction de la part des stagiaires : « oui mais mon patron veut une image, ici, et pas un bouton ». Il faut donc accompagner le stagiaire (et son patron, par contumace) dans une approche technique différente de ce à quoi ils sont habitués... et montrer malgré tout comment on peut mettre sans souci une image à la place d’un bouton (« le type="image" est notre ami ! »).

Là où l’expérience est la plus stimulante, c’est quand un développeur web ne peut absolument pas se passer d’une fonctionnalité qu’il a développée, par exemple parce qu’elle réduit le temps d’interaction de ses utilisateurs avec l’application web, et ce faisant augmente leur productivité. Prenons un cas que j’ai vu récemment : trois listes déroulantes se suivent, un choix dans la première permet de peupler la deuxième, et un choix dans la deuxième permet de peupler la troisième, le tout à base d’attributs onchange avec tout ce que ça comporte de complications [3].

Allez lui expliquer qu’il faut des formulaires sans javascript, avec des boutons "go" entre chaque liste, il vous répondra avec raison qu’il double le temps d’interaction de ses utilisateurs avec l’application : de trois clics, ils sont passés à six.

Je lui ai donc proposé une approche encore plus poussée en Javascript que ce qu’il prévoyait [4], ainsi un utilisateur handicapé disposera d’un pictogramme lui permettant de désamorcer les fonctionnalités avancées, chaque liste se verra accompagnée d’un bouton de validation du choix, et on posera sur le navigateur du visiteur un cookie pour lui éviter de devoir chaque fois repréciser ses choix ergonomiques [5].

Après quelques mois de cet exercice, je peux confirmer que votre réseau ne s’étendra réellement hors des geeks pour englober les praticiens d’une façon plus générale qu’après avoir rencontré de visu les personnes concernées. Elles hésitent alors moins à vous contacter pour des questions très ponctuelles et éminemment appliquées.

Voilà le vrai bénéfice, difficilement quantifiable, et qui dépasse de loin ce que vous aurez pu dire pendant les trois heures où votre auditoire a été physiquement présent : une relation à long terme a pu commencer à s’établir, et avec cette rencontre, la glace est rompue. Les stagiaires, une fois retournés dans leur bureau, vont oser vous appeler, et surtout ils oseront vous demander de les aider à mieux faire. Tout est gagné, à ce moment-là. Ça vaut bien le coup de se lever tôt, non ?

Notes

[1À lire sur le ton de Jean Rochefort !

[2Tâchez de le dire sans respirer, vous allez voir, avec un peu d’entrainement c’est tout-à-fait possible...

[3Voir Pan sur les doigts (on ne le citera jamais assez), pour bien comprendre qu’il n’y a pas que des utilisateurs équipés de souris. Tenez, à l’instant où je tape ces mots, dans le train, je n’ai pas de souris, et le trackpad est épuisant, je préfère manipuler mes applications au clavier.

[4Hé oui, c’est possible : faire encore plus de javascript et rendre l’application intrinsèquement plus accessible...

[5Je tenterai de mettre en ligne un exemple de cette méthode ultérieurement, n’hésitez pas à me rappeler à l’ordre quand je ne tiens pas mes engagements, je ne m’en offusquerai pas. Pour résumer, je m’appuie sur le DOM pour associer aux listes le comportement attendu, et je désactive la fonctionnalité après que l’utilisateur a précisé qu’il ne souhaite pas ladite fonctionnalité.

Commentaires

  • Le jeu en vaut la chandelle, effectivement !

    C’est toujours intéressant de voir les personnes que je forme aux standards découvrir (souvent avec horreur) qu’elles vont devoir casser pas mal de leur existant, puis se rendre compte quelques heures (ou jours) plus tard, que la nouvelle version de leur code est 10 fois plus légère, plus sémantique, plus accessible, et - ce qui les touche plus directement - 10 fois plus simple à maintenir par la suite !

    Dernier exemple en date, un titre qui était fait via plusieurs tableaux imbriqués, des tags <font> et des images pour obtenir un effet de superposition du texte au dessus d’un simple trait, et qu’on a transformé en un simple <h3> avec exactement le même effet visuel !!! 😉

    Répondre à Nicolas Hoizey

  • Jean-no (26 septembre 2005)

    Huit ans plus tard, tu ne t’ennuies toujours pas, c’est bien 😉. Je mets l’HTML au programme de mes cours (plutôt consacrés à la programmation Lingo/Director) chaque année, parce que c’est bien le seul langage qui a des répercutions immédiates et immédiatement compréhensibles : on tape bgcolor="red" et hop, la page entière est peinte en rouge, alors que quand on a de la peinture en pot et un mur à peindre, c’est plus long et le résultat est moins beau. D’ailleurs c’est ce qui m’embête avec les évolutions vers XML, PHP (que j’adore pourtant) etc. : tout ça rend le web compliqué, et l’utilisateur débutant perd sa capacité à peindre sa page en rouge en tapant une ligne.

    Un vieux cours html/css/js que j’ai fait pour les étudiants des arts déco...

    Répondre à Jean-no

  • Stéphane (26 septembre 2005, en réponse à Jean-no)

    Huit ans plus tard, tu ne t’ennuies toujours pas, c’est bien 😉

    Hé hé, moque-toi :)

    D’ailleurs c’est ce qui m’embête avec les évolutions vers XML, PHP (que j’adore pourtant) etc. : tout ça rend le web compliqué, et l’utilisateur débutant perd sa capacité à peindre sa page en rouge en tapant une ligne.

    Oui, mais en même temps, tu peux toujours lui dire que toute la mise en forme passe par les styles, donc <body style="background:red;"></body>. C’est à peine plus long, et au final ça peut permettre d’introduire assez vite et assez simplement les notions de séparation fond/forme, non ?

    (et en prime ça introduit les CSS, et après on n’a plus à qu’à expliquer comment les stocker à part, le plus gros est déjà fait...)

    Répondre à Stéphane

  • Anonyme (3 octobre 2005, en réponse à Stéphane)

    Oui bien sûr. Mais j’ai l’impression que les ingénieurs essaient de reprendre le pouvoir sur le web. Peut-être que je suis parano. Je sais pas.

    Répondre à Anonyme

  • Stéphane (3 octobre 2005, en réponse à Anonyme)

    C’est un point de vue intéressant.

    En fait je crois que l’industrialisation d’un certain nombre de processus (comme diraient les cadres) conduit à plus de formalisme, ne serait-ce que parce que les équipes de développement sur un site, même côté client, sont maintenant d’une taille appréciable. Il faut donc :

    • parler la même langue
    • séparer les compétences (design vs production de code, donc CSS vs HTML, pour simplifier très grossièrement)
    • normaliser tout ça pour moins se prendre la tête sur le rendu final par le navigateur (voir les avancées du DOM en javascript, par exemple).

    En fait je n’ai pas l’impression, tout de même, d’assister à la revanche des ingés sur les graphistes. J’ai plutôt l’impression qu’au final, on a les moyens techniques aujourd’hui de faire des sites plus fun qu’il y a quelques années, avec des moyens rudimentaires même s’ils ont un peu évolué.

    Mais je suis peut-être, quant à moi, trop optimiste :)

    Répondre à Stéphane

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)