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.

18 réflexions au sujet de « L’accessibilité, peut-on s’en foutre parce que ça coûte ? »

  1. Tu as bien fait de souligner le problème de la maîtrise du sujet de la part des prestataires susceptibles d’implémenter l’accessibilité dans les projets Web : effectivement, il n’est pas rare d’en croiser qui parlent d’accessibilité à tort et à travers, finissant ainsi par perdre toute légitimité à ce sujet, avec le risque de faire un peu d’ombre aux prestataires sérieux et réellement compétents et, surtout, d’alimenter cette étrange impression que l’accessibilité ne serait que du vent.

    Bref, nous autres, acteurs du Web voulant jouer un rôle dans l’accessibilité, n’aurons pas fini d’en baver…

  2. Petit jeu : qu’est-ce qui ne vas pas dans ces deux phrases ?

    « Non, assurer la bonne sécurité à tous les types de transactions d’un site web complexe n’est pas gratuit, et le coût sera supérieur au 100% d’utilisateurs concernés. »

    « Moi je veux bien le web Mickey Mouse sécurisé, mais à la fin du mois j’ai trois bouches à nourrir et mes clients ne veulent pas payer la sécurité. Point final. »

  3. L’argument du client qui ne paie pas pour de la sur-qualité : ça vient certainement du fait que les professionnels pensent que c’est de la sur-qualité et le sous-entendent à haute voix devant le client, non ?

    Toutes ces discussions entre professionnels du web n’ont que peu de sens. Dire que des professionnels essaient encore de convaincre d’autres professionnels que c’est leurs clients qui ne veulent pas d’un site accessible… Leur ont-ils au moins expliqué clairement, ou ont-ils plutôt gentiment dit qu’on pouvait le faire mais que ça n’était pas indispensable ?

    Je reste un junior dans le domaine, mais je cherche et je conserve toutes les meilleures ressources sur le sujet, et quand j’en ai trouvé une qui fonctionne je m’en sers ensuite autant que possible dans tous les projets – que le client ait souhaité de l’accessibilité ou non. Ça n’est qu’un petit pas, mes productions sont rarement accessibles, mais je fais de mon mieux pour m’améliorer et construire des sites de qualité.

    Ça ne coûte en général que de la bonne volonté, et un peu d’intérêt pour la matière.

    1. Sur le principe, 200% d’accord, c’est même ma façon de travailler et de voir les choses.

      En pratique, attention à un cas précis : la gestion de l’existant. Genre, t’as 200 vidéos sur l’ancien site à mettre en conformité, attention les coûts 🙂

      Ceci dit, pour en revenir à ce que tu dis, c’est entre autres pour ça que je « milite » activement depuis des années pour que les intés/devs aient des repères simples pour que la base de l’accessibilité leur soit accessible si j’ose dire. En ce sens, j’aime bien l’approche Opquast First Step : « faites ça d’abord avant de faire intervenir un expert ».

      1. Effectivement, cette façon de travailler a ses limites, ça n’est pour moi qu’une mise en bouche : je n’ai aucune formation en accessibilité et c’est ma façon de me former – en plus des lectures intéressantes ( dont j’ai commenté votre compte-rendu la semaine passée, par exemple ).

        Je ne suis pas « un expert », une mise en conformité d’un site existant avec les WCAG2 ou Acessiweb serait un parcours presque insurmontable pour moi. Cependant en enrichissant mes pratiques au fur et à mesure, j’améliore continuellement ce que je produis.

        Et chaque chose que j’apprends repousse d’autant le besoin de faire appel à un expert, et contribue inévitablement à réduire le coût de l’accessibilité sur mes projets.

        Chaque pierre posée participe de la construction de l’édifice.

      2. Pour la gestion de l’existant, on est quand même moins contraints en tant que concepteurs car ça fait partie des rares cas soumis à dérogation dans le cadre d’une labellisation (Accessiweb en tout cas).

        Même si l’idéal est de rendre le maximum de contenu accessible, dans les faits c’est le genre de cas qui peut faire exploser l’addition :o)

        1. En ce qui concerne la gestion de l’existant, il y a, certes, la possibilité de se baser sur les procédures de déclaration de conformité partielle ; mais, ce serait botter en touche, si j’ose dire, d’autant plus que l’exemple des 200 vidéos ne justifie pas vraiment de dérogation pour des raisons de coûts de développement, comme Olivier l’a brillamment démontré. En revanche, si l’on parle de 200 documents PDF dépourvus de la moindre alternative en HTML, le coût de leur mise en accessibilité n’est pas négligeable, outre qu’une telle mise en accessibilité ne met pas à l’abri de pépites en la matière (Jean-Pierre, si tu nous lis… 😉 ), auquel cas la tentation de la dérogation est encore plus grande, voire justifiable.

          Si la possibilité d’une déclaration de conformité partielle est offerte par les WCAG 2.0, il faut également regarder la date de mise en ligne des contenus existants pour lesquels on est tenté d’appliquer une dérogation : le RGAA, sauf erreur de ma part, ne permet pas trop de largesses en matière de dérogation par rapport aux dates liées à l’applicabilité des obligations légales d’accessibilité…

          1. Le RGAA ne définit pas de date, effectivement, mais plutôt la notion de charge excessive, d’obsolescence, etc. Et d’ailleurs c’est aussi le cas avec AccessiWeb, même si pour simplifier, dans les débuts, la date de parution du référentiel (10 juin 2010) était prise comme référence. Mais le temps avançant, cette date n’est plus forcément très pertinente.
            Ce qu’il faut regarder réellement c’est: ce contenu est-il effectivement consulté? A-t-il valeur d’archive, ou de « contenu chaud »? Dans le second cas, on ne pourra pas déroger (même pour un contenu ancien). Dans le premier (même un contenu récent peut être concerné, tel un communiqué de presse dont la durée de vie est relativement courte) on va mettre en place un dispositif que j’appelle « accessibilité à la demande »: on indique clairement le caractère non accessible du contenu; et on propose un moyen simple, accessible, et gratuit, de demander une version accessible. Ainsi on trouve le bon compromis entre l’utilité et le coût: on le fait pour une raison bien identifiée (une demande utilisateur directe) et on ne s’épuise pas à rendre accessibles des contenus qui n’intéressent personne…
            Vouloir tout faire c’est bien, à condition que ça n’assèche pas le budget ou les ressources pour un travail de fond sur le site, qui profitera à plus de monde!

      3. @Nico: En tant que développeur, le coût de mise en conformité des 200 vidéos sera… nul! En effet, tout ce qu’il faut en faire sera de l’ordre de la contribution (sous-titres, audio descriptions, transcriptions…). La seule responsabilité du développeur en la matière est de rendre la chose possible. En général ça consiste à prendre un lecteur qui gère les sous-titres, et à créer en back-office le champ d’upload pour le fichier .srt et .mp3 (on peut pas dire que ce soit tuant… à moins d’avoir choisi un CMS inflexible. Et là, c’est bien fait pour vous). Et si on ne trouve pas de lecteur gérant ces fonctionnalités (faut vraiment pas beaucoup chercher… mais, admettons) on a toujours la possibilité de gérer des versions sous-titrées et audio-décrites des vidéos.
        Aparté: les sous-titres sont une des rares manifestations « voyantes » de l’accessibilité. Du coup j’ai pas mal de clients qui en sont assez friands (hormis bien sûr tous les avantages en termes d’indexation des contenus, meilleur accès aux étrangers, image « pro », etc.) car ça rend leur effort visible. Et pour vraiment pas cher (quelques millièmes ou centièmes du coût de fabrication de la vidéo).
        C’est encore plus flagrant avec la LSF (pourtant significativement plus chère, mais toujours une fraction du coût de la vidéo), qui pour le coup est très très visible, avec un coté spectaculaire qui ne laisse pas indifférent.

      4. A propos de Steps: je trouve aussi que c’est une riche idée, et une tentative intelligente de réduire les coûts.
        Elle a cependant une limite (mais tout comme la doc, la formation ou toute autre forme de transfert de compétence): si le gars (ou la fille — spéciale dédicace à Audrey VL) veut pas, bah i (ou a) veut pas. J’ai récemment eu à faire avec des gens formés, avec une bonne réputation, accompagnés dès les specs et les maquettes, maîtrisant bien le CMS, et avec, tiens-toi bien: l’obligation contractuelle et réglementaire de tenir le niveau AA. Le client a même payé pour l’accompagnement accessibilité, c’est dire s’il était motivé. Au final, malgré les multiples alertes, précos, et autres audits intermédiaires, on se retrouve avec des bourdes de débutants genre liens-images aux alt vides (« ah mais y a des title, donc c’est bon, non? C’est pas ce que tu nous as dit? »). Et une liste longue comme le bras de non-conformités qu’on laissera dans le site parce que « l’outil ne le permet pas et on ne l’a pas budgété ». Et le client ne peut que lâcher du lest, car on lui explique que de toute façon, c’est comme ça et pas autrement (oui, moi aussi je croyais que les clients avaient tout pouvoir…).
        Bah, contre ça, moi je sais plus trop quoi faire, j’avoue…

        1. Franchement, un dev inté infoutu de coder correctement alors qu’il est accompagné par des experts, là, y a rien à faire. Sur les CMS que j’utilise, ils sont tous suffisamment flexibles pour pouvoir réagir et adapter.

          Punaise, moi qui rêverait d’avoir un expert accessibilité en accompagnement sur des projets, ‘connaissent pas la chance qu’ils ont ceux-là. ^^

          Pour ma part, les rares fois où j’ai eu un accompagnement (référencement notamment), t’inquiète que j’ai écouté attentivement et j’ai absorbé les conseils. 🙂

          1. Et moi je rêve d’avoir en face un mec comme toi, qui au lieu de tirer la tronche et de négocier la moindre ano, se jette dans le code avec l’enthousiasme d’un jeune chien! 😉 [clin d’oeil]

          2. « Punaise, moi qui rêverais d’avoir un expert accessibilité en accompagnement sur des projets » : bah alors, ton boss a-t-il toujours la tête ailleurs ? 😉

        2. @Olivier : Votre discours ne fait qu’accentuer mon impression que ça n’est que très rarement le client que ne veut pas d’un site accessible, mais beaucoup plus fréquemment le développeur ( ou inté, CP, etc..) qui ne voit que des contraintes compliquées par méconnaissance.

          Je ne me fatigue pas souvent à convaincre mon patron ou mes clients à aller vers l’accessibilité : je leur explique clairement, et je fais mon possible – peu importe la réaction.

          C’est un vaste chantier que d’apprendre les bases de l’accessibilité, j’ai beaucoup de « mauvais réflexes » à effacer, mais ça ne me fait pas peur et ça m’attire plutôt.

          Je garde l’impression, en relisant votre commentaire, qu’une masse grouillante de dév et d’inté n’en ont simplement pas envie, ou sont trop impressionnés par l’ampleur des lectures à prévoir.

          Un peu comme si un garagiste refusait de réparer une Porsche parce qu’il ne connait pas ce genre de mécanique.

          On les appelle quand même des professionnels ?

          1. Professionnels ? Ils le sont, dans la mesure où ils sont rémunérés pour le travail qu’on leur demande. Cela n’empêche pas, pour autant, de s’interroger sur l’absence ou non d’attitude professionnelle… 😉

  4. Ah non ! moi je préfère largement claquer 50 patates dans un logo tout bling-bling avec message subliminal véhiculé par des couleurs flashy et des animaux stylisés dont la signification n’est perceptible que par mon directeur marketing, plutôt que dans l’accessibilité dont on ne sait même pas au juste à qui ça sert puisque c’est pour tout le monde ! (joke)

Répondre à Tanguy Lohéac Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *