L’accessibilité, peut-on s’en foutre parce que ça coûte ?

Tout a commencé par un commentaire désabusé d’un certain QuentinC, lors d’une discussion sur le forum d’Alsacréations, au départ très badine. QuentinC, internaute  « directement concerné » par l’accessibilité, fait l’amer constat que selon lui, l’accessibilité des sites Web n’a pas franchement progressé depuis 5 ou 6 ans (on devine au travers du message qu’il est utilisateur de lecteur d’écran). Prenant comme exemple un échange infructueux avec l’équipe du Site du Zéro, il en conclut même que, pour les professionnels, l’accessibilité c’est bien, mais on s’en fout.

Cette opinion (qui n’est évidemment pas celle de QuentinC, mais celle qu’il ressent de la part de certains professionnels) a suscité quelques réactions. Sophie Drouvroy a ouvert le feu avec son article « L’accessibilité, on s’en fout de plus en plus ? ». Nicolas Hoffmann (« L’accessibilité, on s’en fout de plus en plus ? Moi, non. ») et Stéphane Deschamps (« Défaitisme et accessibilité ») ont suivi. Les commentaires ont également alimenté le débat, et c’est de cette manière j’y ai contribué. Jusqu’à ce commentaire de alfrdd (verbatim) :

Si ça coûte cher.
J’en ai un peu ras le cul de voir les mensonges sur ce sujet.

Oui y’a pas mal de truc qui, intégrés dans un process, sont indolores financièrement.

Non, assurer la bonne accessibilité à tous les types de handicap d’un site web complexe n’est pas gratuit, et le coût sera supérieur au 10% de visiteurs concernés.

Moi je veux bien le web Mickey Mouse ouvert à tous, mais à la fin du mois j’ai trois bouches à nourrir et mes clients ne veulent pas payer l’accessibilité. Point final.

Cet avis, pour brutal qu’il soit, est à mon sens très intéressant, car il est une parfaite illustration du malaise et du malentendu qui règnent entre ceux qui ont décidé de ne plus s’en foutre, et les autres. Il est assez dense pour que j’aie ressenti le besoin de publier le présent billet plutôt que d’y répondre directement sur le blog de Sophie. Examinons-en les arguments, point à point. Et comme d’évidence alfrdd défend la position d’un développeur sous contrat, c’est sous cet angle que je vais les analyser.

Note préliminaire : Loin de moi l’envie de démonter alfrdd. Il n’y a rien de personnel là-dedans, et j’espère qu’il le comprendra. Je salue d’ailleurs sa franchise, et son courage d’aller exprimer une opinion aussi polémique sur un blog dédié à l’accessibilité.

« Si ça coûte cher. J’en ai un peu ras le cul de voir les mensonges sur ce sujet »

Oui, l’accessibilité a un coût. Si l’on a parfois écrit ou dit que cela n’en avait pas, au mieux c’est une approximation, au pire de la mauvaise foi. Et ça ne sert les intérêts de personne. Alors regardons les choses en face, sans langue de bois.

Problème non négligeable : il est quasiment impossible d’isoler ce coût dans un projet Web. Braillenet a consacré toute un Forum Européen (en 2011) au thème « Coûts et bénéfices de l’accessibilité », et force est de constater que la somme des intelligences mobilisées n’a pas vraiment apporté de réponse claire à la question de ce que ça coûte, et de ce que ça rapporte. Peut-être simplement parce qu’il n’y a pas de règle transposable à toutes les situations. Dans mon expérience, même deux projets similaires ayant engagé des moyens comparables, avec des objectifs identiques, peuvent obtenir des résultats radicalement différents.

Parlons alors de coûts typiques. Quels sont-ils ? Pour la plupart, et alfrdd reconnaît que certains sont « indolores », ils sont déjà intégrés aux coûts intrinsèques à un développement Web. Ils sont imperceptibles lorsqu’on se contente d’appliquer une compétence spécifique. Comme par exemple lorsqu’on fait le (bon) choix d’un élément P plutôt qu’un DIV peu informatif sur la structure ; ou d’un texte de remplacement d’image un peu plus parlant que « image ». Je compare souvent l’accessibilité à l’orthographe : si on sait comment il faut écrire, on ne perd pas de temps à réfléchir ni à corriger. Bien sûr, cela a coûté des années d’étude et de pratique ; mais elles sont (devraient) être constitutives de la compétence basique d’un professionnel de l’écrit. C’est pareil avec le code, et l’accessibilité.

Maintenant, ce n’est pas vraiment sur le code « à la main » que l’on va avoir le plus de difficultés et de coûts. Mettre une balise <label> sur du code que l’on produit soi-même coûte quelques secondes au plus. En revanche, si cela doit se faire dans un composant de framework, ou dans un module intégré à un CMS, c’est une autre histoire… Et c’est d’ailleurs souvent un argument qui m’est opposé pour ne pas inclure une reco : « l’outil ne le permet pas ». Ok, mais dans ce cas pourquoi a-t-on choisi celui-ci, et pas un qui le permet ? La réalité est loin d’être simple, bien sûr, et on ne choisit pas (et on ne devrait pas choisir, d’ailleurs) un CMS ou un framework uniquement en fonction de son accessibilité. Néanmoins, l’offre est assez étoffée aujourd’hui pour qu’on puisse concentrer ses efforts sur des outils qui font leur part du job. Et si l’on s’est spécialisé sur un environnement au point de ne pas pouvoir facilement en changer, alors soit c’est un mauvais choix, et il va falloir réagir et en changer, et vite ; soit on est tellement fort sur ce produit qu’on a tout intérêt à travailler à son amélioration, sous peine de le voir distancé par des concurrents. Oui, c’est un coût ; mais du type de ceux qui préservent les revenus futurs.

Autre source de coûts identifiables : les contenus alternatifs, pour les contenus média ou documents téléchargeables. Mais ces coûts relèvent de la contribution, du point de vue des développeurs ils sont inexistants. La seule mission des développeurs, sur ces aspects, est d’en rendre l’insertion possible, en choisissant des lecteurs ou formats adaptés, et en configurant les pages et interfaces d’administration de façon adéquate ; opérations normalement incluses au prix de vente si le client a demandé un « site accessible ». Si non, rien ne vous empêche d’intégrer quand même un certain nombre de choses gratuites (le bon lecteur vidéo, les champs de contribution déjà présents par défaut, que vous vous dispenserez de supprimer) en le vendant comme de la « valeur ajoutée », et c’est pour moi c’est cadeau M’sieurs-Dames.

Du point de vue des développeurs, il reste un autre motif de coût, et c’est celui que souligne alfdd.

« Non, assurer la bonne accessibilité à tous les types de handicap d’un site web complexe n’est pas gratuit »

Ici c’est la notion de « site web complexe » qui m’intéresse. Je ne saurais la définir précisément, mais je sais ce qui n’est pas un site complexe : un site de contenus, un site institutionnel, des formulaires classiques, sont tout sauf complexes du point de vue du code client. Or c’est bien le lieu où se joue l’accessibilité : le code HTML, CSS et JavaScript. Un site de contenu peut être une machinerie phénoménalement alambiquée en back, cela ne transparaitra pas dans le navigateur où l’on va jouer avec une vingtaine de balises, au plus, et des interactions simples qui ne dépasseront pas le menu déroulant, le carrousel et le message d’erreur. Toutes choses pour lesquels les patterns sont très récurrents, et par conséquent connus, documentés et résolus du point de vue accessibilité. Le seul enjeu est alors de choisir une bibliothèque bien fichue. Bonne nouvelle : certaines des plus répandues le sont, et notamment jQuery qui a bénéficié d’un travail spécifique sur l’accessibilité des composants de jQuery-UI. Reste à implémenter le composant correctement. Bref, la base du boulot de développeur.

Parlons alors des sites vraiment complexes pour l’accessibilité. Ils vont inclure des composants avec un fort degré d’interaction avec l’utilisateur, qui vont constituer des interfaces riches. La difficulté viendra éventuellement du caractère composite des interfaces, car pris isolément chaque pattern primaire, comme on l’a vu, a été étudié et traité dans au moins une bibliothèque majeure.

Admettons que vous soyez dans ce cas de figure. Déjà, estimez-vous heureux ! Vous travaillez sur l’un des aspects les plus intéressants du développement Web (car reconnaissons que la mise en page HTML/CSS, même avec quelques bidouilles en JavaScript, on en fait vite le tour, question stimulation intellectuelle). Si on vous a confié ce job, c’est que vous n’êtes pas le premier venu. Ensuite, je serais surpris que vous soyez partis d’une discussion sur un coin de genou pour coder votre interface de la mort qui tue. Il y a forcément eu un travail conséquent en amont, que ce soit pour définir les schémas d’interaction utilisateur, l’ergonomie, le design, et toutes ces choses qui font qu’une interface est vraiment géniale à utiliser (et d’ailleurs, plus elle est géniale, plus elle sera simple, fonctionnellement, en principe). Dans ce modèle, la partie code est très minoritaire en charge, ce n’est que l’exécution technique de concepts travaillés à la source – processus qui coûte très cher, n’en doutons pas, mais le client est prêt à payer pour cela, parce que cela en vaut la peine. Alors l’effort supplémentaire pour coder accessible, il n’est pas si difficile que ça à faire avaler. D’autant que cela va rester raisonnable rapporté au coût d’ensemble ; et reproductible, donc moins cher la prochaine fois.

« 10% de visiteurs concernés »

Si le coût de l’accessibilité ramené à un projet est difficile à cerner, celui du nombre d’internautes concernés est carrément hors de portée.

D’abord parce qu’on ne peut pas « tracer » les utilisateurs de technologies d’assistance. Tout se passe entre le navigateur et l’utilisateur, donc à part coller des spywares ou sonder directement les gens, on ne peut pas vraiment savoir quelles technologies d’assistance sont utilisées, ni à quelles fins.

Ensuite parce que les statistiques de prévalence du handicap ne nous renseignent que trop peu. Le handicap sur la Toile n’a pas les mêmes origines ni les mêmes contours que le handicap dans la vie physique. Ne pas avoir l’usage de ses jambes ne gêne en rien la navigation Web. Mais si être daltonien peut passer inaperçu dans la vie de tous les jours, sur le Web il arrivera parfois que cela pose un problème. De fait nombre de « handicaps numériques » ne sont même pas répertoriés comme handicaps physiques : défauts de coordination de la main, troubles de la concentration, dyslexie, épilepsie photosensible, migraines… et j’en passe.

D’autre part ça ne nous dit rien sur la proportion de personnes handicapées qui, effectivement, naviguent sur le Web. On sait plus ou moins que les personnes handicapées sont en moyenne deux fois plus équipées, en valeur, en matériel informatique (aussi parce que les aides techniques valent bonbon), et c’est tout. On ne sait pas, par exemple, combien ont tout bêtement abandonné l’idée de surfer, voire d’utiliser un ordinateur, face à la difficulté et au coût que cela représente. On ne sait pas non plus combien font contre mauvaise fortune bon cœur, et surfent malgré les difficultés, sans pour autant se considérer comme handicapés. Si vous êtes en entreprise, faites un tour dans les bureaux ; détectez ceux qui ont le nez collé à un écran 15 pouces, ou qui inclinent la tête quand vous leur parlez. Ils ne sont parfois pas conscients que la difficulté qu’ils éprouvent au quotidien, et qu’ils estiment normale, relève du handicap (et que surtout, ils peuvent être aidés par la technologie).

Et puis enfin, et surtout, on peut prendre le chiffre qu’on veut, de 1 à 60% (c’est celui qu’a retenu l’étude Microsoft-Forrester (en anglais) comme proportion potentielle chez les adultes en âge de travailler). Ça ne devrait pas justifier le bien-fondé de l’accessibilité. Comme je l’ai raconté dans l’article Le vrai bénéfice de l’accessibilité, l’accessibilité peut non seulement changer la vie, et elle peut aussi la sauver. A quel seuil décide-t-on que, bon allez, on va faire l’effort ?

C’est d’autant plus énervant qu’on dépense par ailleurs des sommes considérables pour faire des coins arrondis et des dégradés dans des navigateurs qui ne le méritent pas, ou à faire de zoulis effets animés qui n’épatent que le webmaster et son beau-frère-qui-fait-des-sites-dans-son-garage (« tenez, je veux le même »).

Où est la « bonne » priorité ? Servir tous les navigateurs (et les moteurs de recherche) ? Ou tous les utilisateurs ? Mon choix résulte de ce fait tout simple : même coincé avec un navigateur hors d’âge, un utilisateur non concerné a toujours la possibilité, techniquement, de s’en sortir (genre, trouver une autre machine, c’est pas ce qui manque). Un utilisateur qui ne voit pas, tu peux lui mettre du matos de ouf avec toutes les extensions de Jaws, si l’alternative d’image n’est pas là, elle n’y est pas, point, sa machine ne pourra pas l’inventer. C’est là qu’est notre responsabilité, en tant que producteur de contenus.

Alors, franchement, 1, 10, ou 100% : on s’en fout. C’est pas le problème.

« Moi je veux bien le web Mickey Mouse ouvert à tous »

Ça tombe bien, c’est comme ça qu’il a été pensé ! Je ne vais pas vous ré-infliger la fameuse citation de Géo Trouvetou – pardon, Tim Berners-Lee, mais le Web est né intrinsèquement universel et donc accessible, il serait bon de ne pas l’oublier. S’il est devenu le Web Picsou, voire le Web des Frères Rapetou, il ne tient qu’à ceux qui le font de lui redonner de belles oreilles (NB : si toi aussi tu étais abonné à Mickey Magazine, tape dans tes mains).

« Mes clients ne veulent pas payer l’accessibilité »

Les clients, ils paient pour quoi, au juste ? Pour un site qui marche et qui satisfait leurs objectifs business. Rien à carrer, dans le fond, que la bonne pratique numéro 42 soit chatouillée, ou que le critère surnommé « DTQ la citation en ligne » soit satisfait. Ils   rémunèrent des professionnels pour ça, et attendent implicitement qu’ils les conseillent sur la meilleure façon d’atteindre ces objectifs via leur site. Si l’accessibilité y aide, ça leur va très bien.

Donc ils ne paient pas plus pour l’accessibilité que pour la sécurité de base, l’ergonomie minimale, une maintenabilité élémentaire, et une orthographe juste correcte. Ni plus, ni moins. Ils paient ce qu’on leur dit que cela coûte. Si on leur explique qu’un « site accessible » est un pléonasme, parce que l’accessibilité n’est ni une option ni une fonctionnalité qu’on ajoute ou qu’on retire, on ne crée pas une situation ambigüe où le client peut être conduit à faire un mauvais choix.

Ils paient aussi pour que le site ne comporte pas de bug majeur ou simplement gênant. Or un problème d’accessibilité, c’est juste un bug relatif à un cas d’usage particulier, qui n’a pas moins d’importance que les autres. Un site non accessible (ou pas assez) n’est donc pas fini de débugger, et ne mérite pas d’être livré, ni facturé.

Mais le problème, en fait, est que la plupart des clients inscrivent l’accessibilité au cahier des charges, parce qu’il faut bien le faire… les prestataires la mettent dans leur réponse, parce qu’il faut bien remporter le marché. Mais au final, ni le client ni le prestataire ne savent vraiment de quoi il retourne. Et au moment de la livraison, l’accessibilité est poussée du pied sous le tapis des délais, parce que ça arrange tout le monde… sauf les utilisateurs.

« À la fin du mois j’ai trois bouches à nourrir »

Si une assistante de direction était nulle en orthographe, elle aurait beaucoup de mal à trouver du travail, tant c’est une compétence basique que l’on ne peut pas négliger. Pour nourrir sa famille, elle aurait plutôt intérêt à se mettre au niveau… ou à changer de métier.

Pour un développeur, la situation est différente. On peut être une bille, et pourtant trouver un job facilement, et même le conserver. Je le sais : je l’ai été ! Sans formation ni expérience dignes de ce nom, on m’a placé sur des projets délicats, avec un tarif flatteur, en se disant que t’façons, j’allais finir par y arriver. Il y a une constante pénurie de ressources, partie parce que le secteur tourne malgré la crise, partie parce que pas tant de jeunes diplômés que ça acceptent de faire un travail plutôt chiant si on regarde bien. Et donc, pour garder un job qui paie malgré tout plus que la moyenne (débutants, allez postuler pour un emploi de dessinateur industriel ou de comptable, pour voir), nul besoin de déployer un arsenal très affûté. Codez en baissant la tête, et ça ira.

Mais à force de bourrer le mou à tout le monde, il arrivera un moment où l’accessibilité sera une compétence différenciante ; puis, enfin ! une compétence basique. C’est le sens de l’histoire. Gare alors à ceux qui ne la maîtrisent pas. D’après vous, quelle différence y a-t-il, pour un acheteur, entre Issy-les-Moulineaux et Pondichéry ? Aucune, à part le tarif journalier des développeurs. Et quand on ne peut pas lutter sur les prix, on doit se battre sur la qualité. Tous ceux qui pourront faire valoir quelque chose en plus, pourront conserver plus longtemps un avantage sur les confrères moins chers du bout du monde. Pour les autres… sincèrement, bonne chance.

Et pour finir, un secret révélé

Je vais vous confier un secret. Un sale, crapoteux même, petit secret.

Depuis le début de cet article, je me suis esquinté la santé à tenter de démontrer que le coût, s’il n’est pas nul, n’est pas aussi élevé qu’on pourrait le croire ; que, de toute façon, ce n’est pas le bon critère quand on parle d’accessibilité ; et qu’enfin, même si on s’en tient aux aspects strictement économiques, tout développeur a intérêt à embrasser la cause de l’accessibilité, ne serait-ce que par opportunisme.

Je peux avoir tout faux, mais ça fait quand même une paire d’années que je traine dans ce milieu, que je l’observe et tente de le comprendre. Et comme généralement mon avis est celui que je partage le plus volontiers, je vais partir du principe que j’ai raison.

Il reste néanmoins un problème : bien qu’il soit parfaitement logique, force est de constater que cet argumentaire se fait dérouiller par la réalité avec une déconcertante facilité. Une infime minorité de développeurs se préoccupe d’accessibilité, et une stupéfiante majorité de sites est inaccessible. Qu’est-ce qui cloche alors ?

Eh bien, ce raisonnement a une faille fatale : il part du principe que le développement est un processus basé sur la rationalité. Or, et c’est ça le hideux secret : ce n’est pas le cas. Et c’est pourquoi je soutiens que, venant d’un développeur, l’argument du coût de l’accessibilité est hypocrite. Développer, c’est prendre une foule de micro-décisions, sur des bases qui ne tiennent pas la route. On choisit une balise, un pattern, un composant, non pas pour son ratio coût-bénéfice savamment calculé et affiné par des boucles de mesure rétroactives. Non! On les choisit parce que sur le moment ça parait bien ; ou parce qu’on a toujours fait comme ça ; ou parce que Kevin, le nouveau, est un gros geek, et c’est ça qu’il a mis sur son site perso ; ou parce que le nom tape la classe ; ou parce que le site qui en parle est super beau ; ou tout autre critère plus ou moins bidon. Mais il est excessivement rare que l’on fasse une véritable analyse de la valeur de chacune des décisions prises. On n’est d’ailleurs pas jugé sur la pertinence de ses choix, mais plutôt sur le nombre de lignes pissées à la journée, ou le nombre de bugs résolus, ou la capacité à livrer avant la date qui déclenche la facturation. Et de fait, peu de développeurs sont en position et en capacité d’avoir une hauteur de vue suffisante pour faire des choix rationnels, prenant en compte toutes les dimensions d’un problème.

C’est comme ça. Et ça n’est pas près de changer.

Sauf si on arrête de s’en foutre.