Avant-propos: Cet article, rédigé par Jean-Pierre Villain, est la copie conforme de son article original publié sur le site de Qelios. Il est dupliqué ici afin de l’ouvrir aux commentaires, cette fonctionnalité n’étant pas disponible sur ce site (pour le moment, ça va changer très vite…).
Avec la publication de WCAG 2.0 et les prémices d’une certaine maturité des producteurs de contenus Web, l’accessibilité sort petit à petit de l’enfance pour entrer dans une période pré-adolescente bouillonnante d’idées. L’un de ces courants d’idée nous propose, depuis quelques temps, d’aborder l’accessibilité sous l’angle de la qualité.
Rendons à César ce qui appartient à Elie Sloim qui, en France, en fut le précurseur au travers de Témesis et Opquast, appuyé sur un talent oratoire qui lui vaudrait sans nul doute plusieurs nominations aux césars des évangélistes s’ils existaient.
La communauté d’idée créée autour de Paris Web a largement contribué à servir de laboratoire et de caisse de résonnance à cette approche dont la récente création du groupe W3qualité en est une des incarnations.
A dire vrai, ce débat n’est pas véritablement nouveau et a même été au cœur de l’élaboration de WCAG comme des différentes méthodes d’application qui en sont issues. Mais, même si l’accessibilité est à l’évidence un domaine lié à la qualité, il convient d’aborder cette question avec beaucoup de prudence.
Dison le tout net, il n’y a rien de particulier qui me dérange dans la qualité, ou du moins ce qu’on m’en dit et ce que j’en lis, car j’ai un gros défaut, je ne suis pas un expert de la qualité, mon truc à moi, c’est l’accessibilité. C’est sans doute la raison pour laquelle je vais me permettre l’affront, dans cet article, de considérer la qualité uniquement sous l’angle de l’amélioration. Ce n’est pas par volonté de nuire, c’est juste un angle de vue utile à mon propos
La page d’accueil du groupe W3qualité nous offre le résultat d’un exercice apparemment périlleux en nous proposant quatre définitions de la qualité web.
Deux d’entre elles, celles de David Lafon et d’Elie Sloim, m’ont particulièrement interpellé car elles bornent, dans un raccourci fulgurant, le cœur de mes réflexions.
Celle d’Elie, à l’image de son domaine de compétence, est la plus académique et la seule à nous offrir un point de contact réel avec l’accessibilité quand il écrit qu’il s’agit de satisfaire (pour un service en ligne), des exigences implicites ou explicites. Le point de contact avec l’accessibilité étant tout entier contenu dans l’exigence implicite, idée qui constituera un point central de cette contribution.
Il est également le seul à établir une différence claire entre la gestion d’un processus qualité, qui consiste à « évaluer, améliorer et garantir la qualité » et la « qualité web » elle-même. Distinction particulièrement importante, car nous verrons comment les exigences liées à l’accessibilité impactent fortement la manière dont on va y associer un processus qualité.
En revanche, celle de David est très représentative d’une sorte de malentendu qui tend, de mon point de vue, à confondre deux choses assez différentes.
En effet, David nous explique que pour lui la qualité web est définie par la fameuse feuille de route que l’on retrouve sur toutes les pages accessibilité des sites méritants. C’est un peu vrai et beaucoup faux, si j’ose dire. Certes un site qui offre la possibilité à ses utilisateurs de le consulter en tout lieu avec n’importe quel moyen et indépendamment de ses capacités physiques ou mentales est indéniablement de meilleure qualité qu’un site consultable uniquement sous IE dans de bonnes conditions d’éclairage. Mais, pour autant, un site satisfaisant en tous points ces objectifs peut être qualitativement proche du néant absolu.
L’accessibilité ne se prononce pas sur la qualité des contenus ou des dispositifs (et c’est, à cet égard, un indicateur déplorable),elle ne fait que vérifier que tout ce qui doit être accessible, contenus et fonctionnalités, est effectivement accessible. En outre, il n’est pas rare, c’est même très habituel, que l’accessibilité provoque des conflits avec certains domaines de la qualité. L’exemple le plus frappant est l’utilisation de certains dispositifs ergonomiques, comme les menus déroulants, qui peuvent compliquer à l’excès les adaptations nécessaires aux exigences implicites d’accessibilité.
On ne le répètera jamais assez : un contenu nul est parfaitement accessible s’il est identiquement nul pour tout le monde, quels que soient ses moyens d’accès, sa langue, sa culture et ses capacités physiques ou mentales.
C’est une des choses les plus compliquées à expliquer lorsque vous formez des professionnels qui sont venus là pour rendre le monde meilleur et à qui vous expliquez que « meilleur » en accessibilité veut juste dire que tout le monde peut en profiter, rien de plus, mais surtout rien de moins.
Cela ne veut pas dire que l’accessibilité doit être une ascèse castratrice mais simplement qu’à force de vouloir trop en faire on prend le risque de moins en faire. Il n’y a pour moi rien de plus désolant qu’un site où l’accessibilité à tous a été sacrifiée à l’amélioration à quelque uns, sans même qu’on s’en rende compte.
Explicite ou pertinent ?
Dans le référentiel AccessiWeb, nous avons un critère (AW 6.1 ) qui nous demande d’évaluer les intitulés de lien. La rédaction de ce critère nous parle de liens « explicites », ce n’est pas un hasard : faire des liens explicites c’est de l’accessibilité, faire des liens pertinents, c’est autre chose.
On peut considérer, à juste titre, qu’un lien pertinent est assez souvent explicite et donc, par voie de conséquence, accessible ; la tentation est alors grande de se donner comme objectif de faire des liens pertinents. Oui, mais attention ! La pertinence des liens impacte d’autres domaines, comme le référencement, l’ergonomie ou l’utilisabilité. Si le contexte et les moyens permettent de prendre en compte ces domaines (on est alors dans une perspective globale de qualité), l’exigence sur la pertinence des liens est raisonnable. En revanche, si ces domaines ne sont ou ne peuvent pas être pris en compte, elle devient déraisonnable et peut même conduire à des absurdités comme, et c’est très habituel, un title « lien d’accès à la rubrique machin » sur tous les liens de navigation d’un menu ou encore un émouvant «lien ouvrant le site truc »: c’est-à-dire des liens très pertinents parfaitement débiles. Reporté à l’ensemble d’un projet, il y a là un des ressorts essentiels qui plombent beaucoup d’équipes, mal formées ou mal accompagnées, vite dépassées par l’ampleur de la tâche : on en demande trop, dans un contexte inapproprié, à des gens qui n’en n’ont pas forcément la compétence.
Ce qu’il ne faut jamais perdre de vue, c’est que le surcroît de qualité (fonctionnalité, ergonomie, référencement, performance…) que génère éventuellement l’accessibilité est, in fine, un simple effet de bord, une conséquence heureuse mais ce n’est pas un aspect fondamental de ce domaine.
L’accessibilité, précurseur de la qualité
Prenons un exemple plus original : considérerons un distributeur de billet de métro (ceux avec la molette) et considérons une tâche : acheter à l’unité un billet de métro. Si je fais de l’accessibilité je ne vais pas me préoccuper de la réalisation de la tâche elle-même mais simplement vérifier qu’elle est possible pour tout le monde. Je vais, par exemple, évaluer le comportement de la molette et vérifier qu’elle ne requiert pas une dextérité trop importante ou encore m’assurer que l’enchainement sélection + validation est correct. Mais mon travail va s’arrêter là et, si la tâche requiert tellement de manipulation que tout le monde préfère s’adresser au guichet, je continuerai à la considérer comme accessible.
Maintenant, si je m’intéresse à la qualité de ce processus, je vais chercher à faire en sorte que l’expérience utilisateur soit la meilleure possible, je vais donc travailler sur l’efficacité du processus (par exemple, faire en sorte que l’opération la plus courante soit réalisable en un minimum d’action) : je sélectionne l’option « achat d’un billet de métro à l’unité » et, ensuite, je valide tout jusqu’au paiement. Mon processus est optimisé, meilleur, plus rapide, plus sécurisé, j’ai fait de la qualité (version ergonomie ou utilisabilité au choix).
Mais ce surcroit de qualité à un préalable : la capacité de la molette à sélectionner correctement la première option au moins. C’est en ce sens que l’on peut considérer l’accessibilité comme un précurseur de la qualité.
La tentative actuelle de fondre l’accessibilité dans une approche globale de qualité comporte un risque méthodologique qui pourrait nous amener à considérer qu’un lien accessible est un lien pertinent avec ce que ça peut comporter comme surcroit d’efforts, de complexité, de coût en termes de formation ou de maintenance ; par exemple, lorsqu’il s’agit de veiller à la pertinence des centaines ou des milliers de liens d’un site entier.
Finalement, la meilleure définition que je pourrais donner de l’accessibilité est de dire qu’elle est une exigence implicite de qualité et, pour ceux qui me connaisse bien, avec une forte propension à ne retenir de cette définition que le terme exigence, version gros et petit gourdin.
Ce qui nous rapproche d’un autre domaine que David ajoute dans sa liste des sous-domaines de la qualité, je cite : « standards, accessibilité, performances, sécurité, fonctionnalités, ergonomie et référencement ».
Cet autre domaine, c’est la sécurité qui, de tous les domaines précédemment cités, est celui qui en est le plus proche, au point d’en être quasiment indissociable sur certains aspects. Il y a bien peu de différence, en effet, entre la présence d’un attribut alt sur une image et la présence d’un dispositif d’accès sécurisé.
Accessibilité et sécurité, même combat
Un processus d’accès sécurisé est un préalable incontournable et non négociable ; ça fonctionne ou pas et peu importe si le meilleur processus d’accès sécurisé donne accès à la pire application du monde. L’amélioration de l’application, ce n’est pas le boulot de l’expert en sécurité car il n’en a ni la vocation, ni les moyens et, encore moins, la compétence.
Elie se souvient sans doute de vieilles conversations au sujet du meilleur modèle méthodologique pour encadrer l’accessibilité. Nous en avions envisagés certains qui restent pour moi les meilleurs modèles et qui sont ceux utilisés en sécurité alimentaire où l’objectif est de s’assurer de l’absence de bactéries dangereuses, pas de savoir si le produit est bon au goût, flatteur à l’odorat et bankable en PLV.
Cela fait une grande différence avec d’autres domaines comme le référencement, la performance, l’ergonomie, l’expérience utilisateur qui sont des domaines tout entier dévolus à l’amélioration.
L’impact, en terme de méthodologie me parait capital : en tant que spécialiste de l’accessibilité, je n’ai que faire de l’amélioration même si j’y participe ; je n’ai que faire de l’expérience utilisateur même si j’en suis le moteur ; je n’ai que faire de la performance même si j’en suis un rouage essentiel ; et, finalement, je n’ai que faire de la qualité même si j’en suis un des précurseurs.
Vision un peu caricaturale, j’en conviens, surtout pour ceux qui me connaissent et subissent quelquefois mon intransigeance paranoïaque quant aux bénéfices utilisateurs lorsque je cherche la petite bête sur la pertinence d’une alternative d’image porteuse d’information.
Notre premier travail c’est d’abord de garantir que tout le monde a accès aux mêmes informations et aux mêmes fonctionnalités, ce qui est résumé dans notre domaine par la notion « d’accès à l’information ».
C’est à la fois la base du domaine, sa limite, et l’essence de sa complexité car l’accès à l’information c’est comme une savonnette : lorsque vous croyez la tenir elle est déjà en train de rebondir sur le mur d’en face.
Explicite ou pertinent les deux visages de l’accès à l’information
Savez-vous pourquoi, quand il s’agit d’une image, on parle de pertinence et, quand il s’agit d’un lien, d’intitulé explicite : lorsqu’une image contient une information essentielle à la compréhension, c’est une image porteuse d’information et je suis, du point de vue de son alternative, dans une position non négociable : l’information est ou n’est pas dans l’alternative. Ma marge de progression est nulle, il n’y a pas d’amélioration possible et une alternative d’image porteuse d’information est d’autant plus pertinente qu’elle est réduite à la seule information essentielle à la compréhension du contenu auquel elle est associée.
Pour les liens, c’est très différent : prenons, par exemple, la rubrique « logiciels » d’un site avec un lien intitulé « Trillian Astra 5.0.0.35» précédé du titre « Messagerie instantanée ».
Du point de vue de l’accessibilité, cet intitulé de lien est parfaitement explicite. Tous mes utilisateurs ont bien la même information : lorsque je vais cliquer sur ce lien, je vais afficher un contenu relatif à ce logiciel, fin de l’histoire. Je ne sais pas trop, à vrai dire, ce que contient réellement la page cible, mais ce n’est pas très grave : le lien est suffisamment explicite. Mais, en revanche, la marge de progression est énorme ! L’intitulé peut être amélioré en apportant des informations complémentaires, par exemple « Télécharger le logiciel de messagerie instantanée Trillian Astra 5.0.0.35 » ; c’est bien meilleur pour tout le monde (y compris pour les moteurs de recherche) ; le lien est pertinent. Mais cette amélioration ne me concerne pas, je n’y ai même pas réfléchi : je ne suis déjà plus là (je fais partie, il est vrai, des experts économes…)
Si cette distinction peut paraitre exagérément subtile pour la plupart de ceux qui s’intéressent à l’accessibilité, elle est, pour certains d’entre nous, particulièrement importante car une immense partie de notre travail consiste à moduler nos exigences : gros gourdin sur les alternatives d’images porteuses d’information, moyen gourdin sur les intitulés de lien, gros gourdin sur une absence de titrage du contenu, petit gourdin (riquiqui pour ce qui me concerne) sur les intitulés de ces mêmes titres.
Regardez attentivement un contenu web rendu accessible par des techniciens débutants, regardez les alternatives d’images, regardez les intitulés de liens et vous verrez très précisément ce processus d’amélioration à l’œuvre : des alternatives d’images polluées d’informations inutiles et des liens pertinents jusqu’à l’excès, au point finalement d’impacter l’accessibilité de manière indirecte en créant beaucoup de bruit pour rien, c’est-à-dire pour beaucoup de temps et beaucoup d’argent.
Si vous reprenez cet exemple transposé à l’ensemble des problématiques, le gain en terme de performance peut s’avérer faire simplement la différence entre un site accessible économique et améliorable et un site couteux, amélioré, mais qui doit faire face à des problèmes de maintenance ingérables ou qui génère des conflits avec des domaines proches sur les plates-bandes desquels nous aurions été nous aventurer imprudemment.
Envisager l’accessibilité sous l’angle de l’amélioration est un réflexe quasi pavlovien et toute la complexité est de bien comprendre ce qui nous est d’abord demandé avant d’envisager d’améliorer quoi que ce soit.
Et, d’ailleurs, ça tombe bien parce qu’améliorer des intitulés de liens, des titres, des intitulés d’étiquette de formulaire, des fonctionnalités, une charte graphique, la lisibilité des contenus… c’est de l’ergonomie, de l’utilisabilité, du référencement, du marketing, et ce n’est pas mon métier.
Par contre, évidemment, dans le cadre d’un projet version dream team et qui a les moyens de ses ambitions, alors là, champagne ! Tous autour d’une table à jouer aux 7 familles des critères : dans la famille SEO, je demande les liens ; dans la famille utilisabilité, je demande les formulaires ; dans la famille accessibilité, je demande les images porteuses d’informations…. Chacun amène son expertise : fais gaffe avec les title de liens, oublie pas de rajouter « erreur sur le formulaire » dans le title de la page… On croise nos recos, on redistribue les charges, on mutualise les formations dans une ambiance festive de nouveau monde…
Attention toutefois à ne pas laisser croire que cette approche « qualité web » est la panacée car elle à un préalable incontournable : des moyens très importants, beaucoup de compétences et une gestion des objectifs complexe qui doit faire la différence entre l’exigence non négociable des alternatives d’images porteuses d’information et l’amélioration progressive de la pertinence des liens. Faute de quoi, il est probable que l’absence de l’une rende la qualité de l’autre très relative pour certains utilisateurs.
A l’inverse, une approche strictement centrée sur les problématiques d’accessibilité offre la garantie minimum que tous les utilisateurs ont bien accès à la même chose, bonne ou pas. Il y a une vraie nécessité d’améliorer nos méthodes mais il ne faudrait pas trop vite en conclure qu’il s’agit de les remplacer par des méthodes d’amélioration.
Dans la vraie vie
Cela fait 13 ans que je « fais le métier » et mon quotidien, c’est plutôt des équipes d’intégration ou de développement sous pression dans des bureaux surpeuplés que des réunions multidisciplinaires où le projet est évoqué sous l’angle des synergies transverses et, pour être honnête, je ne m’en plains pas du tout, bien au contraire.
Ceci explique peut-être cela, mais pour quelqu’un comme moi, issu de l’école traditionnelle genre auditxx audity=auditx+y ,quand on attaque un site à la bombe thermobarique (pour reprendre une métaphore militaire récente sans doute destiné à devenir un best-seller), il faut aller vite, limiter les pertes et achever les blessés. Si dans les soutes d’un site web je parle du référencement, c’est surtout pour apprendre aux troupes à résister à l’invasion des titles inutiles et achever, sans états d’âme, les alternatives débiles aux images plutôt que de leur apprendre à danser la Google dance. Et si les commandos SEO y voit à redire, on discute, on négocie, on trouve des compromis : gros gourdin pour les images porteuses d’information, petit gourdin pour les images de déco, gros gourdin pour les liens de navigation, petit gourdin pour les liens de pagination, mais gourdin quand-même. Je suis responsable de l’utilisateur, il me fait confiance, et je prends ça très au sérieux…
Mais bon je n’ai pas trop, à vrai dire, l’habitude de faire dans la dentelle même si je suis viscéralement un homme de compromis…
La communauté bruisse d’idées toutes plus fascinantes les unes que les autres : évaluation rapide à visée formative, accessibilité sautillante (oops pardon, agile), remplacer les restitutions doctrinales par de l’épistolaire numérique, adopter une approche user centric enhancement, s’abonner à «design for all », accompagner la conduite du changement… sous le gazouillis incessant du hashtag #A11Y : qualité, quality, qualität, qualitat…
Il est normal, sain et important, que toutes ces idées apparaissent en accompagnement de la démocratisation, tant espérée et tant attendue, de l’accessibilité du Web. Elles constituent, à n’en pas douter, le ferment indispensable aux nouveaux enjeux de ce qu’il est communément convenu d’appeler l’industrialisation du Web. Mais, attention à ce que ces innovations nécessaires ne cèdent pas à la tentation de redéfinir l’accessibilité sous l’angle exclusif de domaines proches et, pourtant, si différents.
Car, si l’utilisateur peut survire à un site ergonomiquement nul à l’utilisabilité défaillante, au référencement déliquescent et aux performances préhistoriques, pour lui, la seule amélioration qui vaille c’est, d’abord, de s’assurer que toutes les images-liens aient une alternative explicite ; pour le reste, il peut attendre…
Dans quelques temps, j’inaugure ma 46ème session de formation AccessiWeb, 4 ou 500 professionnels formés, yeux dans les yeux. La situation a bien changé par rapport à l’époque où il fallait d’abord expliquer que l’attribut alt n’avait pas été inventé pour le référencement : c’est mieux, beaucoup mieux, incomparable même, mais ce n’est pas encore ça. Le compte n’y est pas, mon utilisateur ne peut toujours pas participer pleinement à la fête, il est guest mais dans un coin reculé du dance floor…
Dans une autre vie, j’ai fait dans la discothèque et des gens qui ne peuvent pas danser dans une boite, ben, forcément, ça casse l’ambiance et si on leur dit que, bientôt, grâce à une approche agile du chachacha, ils pourront danser, il faut bien faire attention à ce que cela ne consiste pas à ce qu’ils dansent assis sur une chaise, faute de quoi, je ne suis pas certain de faire recette.
Prenons l’idée qui consiste « dans certaines situations » à remplacer une approche basée sur l’utilisation d’un audit exhaustif par une évaluation rapide. Sur le fond, je n’ai rien contre même si je suis plus porté sur l’audit complet rapide que l’évaluation rapide incomplète. Mais bon, pourquoi pas, à la condition première d’insister sur le niveau très élevé des compétences nécessaires. Des gens capables de piloter un projet accessibilité sur la seule foi d’une évaluation rapide, j’en connais quelques-uns, une poignée, et l’évolution des plateformes, des technologies et des usages ne fait que compliquer encore plus la tâche. Si vous pouvez vous faire accompagner par l’un des rares experts capables de gérer ces « certaines situations », vous pouvez utiliser une ou des évaluations rapides mais, en revanche, dans le cas inverse, vous allez dans le mur ; tôt ou tard, un problème, mal anticipé ou pas détecté suffisamment tôt, se révèlera impossible ou trop couteux à réparer.
Prenons l’idée qui consiste à dire que la recherche d’une conformité totale est, finalement, contre-productive, idée abondamment illustrée par un concept bien connue des qualiticiens : la sur-qualité ; même si je préfère, pour ma part et pour ce qui nous concerne, parler de tolérance aux défauts. Il y a, à vrai dire, une vraie réflexion à avoir sur les sujets épineux du zéro défaut et de la mesure de conformité et le sens que cela doit prendre dans un projet. Mais si vous considérez simplement que l’objectif de conformité totale est déraisonnable et qu’en conséquence 75% de conformité est un très bon résultat, vous êtes dans l’erreur. 99% de conformité ne sert à rien si les 1% manquants empêche d’y accéder. Certes, le site est amélioré, il est de meilleure qualité mais tout le monde ne peut pas y accéder.
Le Web évolue très vite et nous sommes, depuis que le WhatWG a rué dans les brancards, les spectateurs privilégiés d’un véritable changement de paradigme où les technologies deviennent versatiles dans un souci d’adaptations permanentes aux usages et à la cohorte de plateformes toutes aussi différentes les unes que les autres. Ce mouvement de fond est en train de tout balayer sur son passage et nous sommes d’autant plus en en première ligne que nous avons l’habitude d’être la dernière roue du carrosse.
J’avais l’habitude de dire, à la grande époque de WCAG 1.0, pendant le « couple of weeks » de 10 ans de WAI (je dis ça avec beaucoup de tendresse) qu’être un développeur confronté à l’accessibilité, c’était comme être parachuté en plein désert avec un couteau suisse pour construire une piscine olympique. Et même si le couteau suisse s’est pas mal amélioré depuis WCAG 2.0, en 2012, en plus de la construire, on leur demande de la remplir.
Nous ne pouvons plus, à l’ évidence, faire de l’accessibilité comme dans les années 2000 ; nous devons adapter nos méthodes, bien comprendre l’interprétation que nous avons du rôle de WCAG, des niveaux, de la mesure de conformité, quitte, si nécessaire, à attaquer nos outils, méthodes et référentiels, au pic à glace, façon puzzle, pour les rendre plus intelligents.
Une partie de ce travail est en cours et les réflexions sur le pragmatisme, la progressivité et tout ce que nous pouvons tirer ou apprendre de domaines proches ne peut que nous être profitables.
Mais il y a un préalable à tout cela ; si l’accessibilité est probablement soluble dans la gestion de projet qualité du département Web d’un grand compte, dans la filiale experte d’une SSII, dans la création d’un poste d’expert qualité Web, dans un accompagnement au long cours richement doté, il faut faire bien attention de ne pas accoucher d’un joli concorde méthodologique réservé à l’élite.
Notre premier objectif, et le seul dont nous soyons réellement redevable, est de s’assurer, avant toute chose, que tout le monde puisse participer à la fête ; des méthodes plus progressives et centrées sur les besoins essentiels des utilisateurs concernés par l’accessibilité du web pourraient répondre à ce besoin de fondations solides et pérennes, elles restent à inventer.
Bon, je crois que je vais me jeter à l’eau :
J’ai eu la chance de lire cet article avant sa publication. Comme je l’ai indiqué à jean-Pierre, nous en discutons en privé depuis des années, et enfin, c’est écrit publiquement. L’oscar 😉 que Jean-pierre m’a gentiment attribué est lié au fait que je soumets mes idées publiquement et que ce que j’écris depuis dix ans est en ligne et que je n’en renie pas une ligne. Jusqu’à présent, impossible d’échanger publiquement avec Jean-Pierre, qui m’a souvent signifié son désaccord, mais en privé. Là, c’est bien, c’est public, et les idées méritent d’être discutées, partagées, échangées.
Alors, oui, sur le fond, l’approche présentée est une option possible. Oui, le travail exclusif sur l’accessibilité a du sens. Oui, dans un certain nombre de cas, l’accessibilité devra être une priorité absolue.
Maintenant, s’il s’agit de demander ce qui va se passer dans la vraie vie, je prédis depuis longtemps que tôt ou tard la démarche accessibilité va se dissoudre dans la démarche de management de la qualité web. Chez tous mes clients, c’est très exactement ce qui se passe, et cela se passe au moment où le client se rend compte que son site ne sera pas à 100% accessible (selon WCAG). C’est un deuil, mais le basculement vers la démarche d’amélioration de la qualité est immédiat, pertinent, gratifiant, et bien loin de laisser l’accessibilité de côté, l’embarque et la rend positive et pragmatique.
Alors, oui, on peut travailler sur des tas de méthodes qui partiront de WCAG (déploiement, critères toxiques, risques, first step…). Oui, on peut décider qu’en cas d’arbitrage, ce sont les critères accessibilité qui auront le dernier mot. Mais pour commencer, nous ne pourrons faire ça au niveau industriel que pour les critères d’accessibilité vérifiables. Pour le reste, il nous faudra des experts, et dans l’industrie, on essaye de ne les appeler que dans certains cas précis : pendant la conception et en cas de litige juridique. Pour moi, les experts doivent disparaitre, et les critères dont on ne peut pas dire instantanément qu’ils sont invalides ne sont pas utilisables en production. Imagine-t-on des spécifications automobiles disant un truc du genre : « la colonne de direction devra être raisonnablement solide ? ». Non, dans l’industrie, tout ce qui peut être mesuré directement sur le produit devient une spécification ou une donnée numérique, et tout ce qui ne peut pas l’être bascule sur le processus de production (management, formation, etc.), c’est à dire de l’assurance qualité.
Il serait bon qu’on arrête de faire croire que le déploiements d’experts accessibilité sur des trucs complexes est une possibilité à grande échelle et que les développeurs pourront un jour être formés à déterminer si la description d’une image est pertinente dans tel ou tel contexte. C’est un peu triste, mais WCAG ne peut pas faire ce qu’on lui demande. Ce n’est pas un outil industriel. il est possible d’en tirer des outils industriels de certification, de spécification, de vérification, mais dès que nous sommes en train de faire ça, nous acceptons de fait le lancement d’une démarche d’amélioration de la qualité. Ce n’est plus une démarche accessibilité, c’est une démarche d’amélioration de la qualité appliquée à l’accessibilité. C’est moche, mais c’est comme ça. Dire le contraire, ce serait aussi stupide que d’affirmer que l’émergence de la fonction qualité dans l’automobile s’est fait au détriment de la sécurité, de la conformité, du développement durable, etc.
Par ailleurs, une fois qu’on est en mode « je veux que mon site réponde aux attentes fondamentales de tous les utilisateurs ». L’ajout d’autres critères hors WCAG n’est pas une option, c’est une obligation si le non respect de ceux-ci présente une gravité importante. et ça, on peut se prononcer en contexte. Je peux vous dire que dans les critères qualité et qui ne sont pas les WCAG, il y en a qui sont d’une gravité extrême (sécurité, performance, et même ergonomie).
L’auteur évoque « des méthodes plus progressives et centrées sur les besoins essentiels des utilisateurs concernés par l’accessibilité du web [qui] pourraient répondre à ce besoin de fondations solides et pérennes ». De mon côté, je me permets de reformuler la phrase contenue dans l’article et j’affirme qu’il faut se pencher sur « des méthodes plus progressives et centrées sur les besoins essentiels des utilisateurs ».
Franchement, je ne trouve pas une seule raison qui me conduirait à me pencher sur » les besoins essentiels des utilisateurs concernés par l’accessibilité du web » plutôt que sur « les besoins essentiels des utilisateurs ».
Moi, j’ai choisi, ce sera fromage ET dessert.
Bonjour Elie,
pour avoir pas mal échangé avec JPV sur le sujet, comme tu t’en doutes, je me sens autorisé à répondre sans craindre de trahir sa pensée.
Le message du billet soit, d’une manière ou d’une autre, « ne faites pas de qualité web », mais plutôt: « la qualité web, oui, mais ce n’est possible que si les exigences non négociables d’accessibilité (entre autres) sont satisfaites ». Ce n’est pas non plus « l’accessibilité et rien d’autre », mais plutôt « parmi les exigences non négociables, il y a celles de l’accessibilité (et je vous parle de cela car c’est ce que je connais) ». En lisant ton commentaire, j’ai le sentiment qu’il y a à l’évidence un malentendu.
L’alerte (si on peut appeler ça comme ça) de JPV porte sur un risque préoccupant à vouloir tout englober dans une démarche de progression qui occulterait trop les fondamentaux. Ce risque c’est d’oublier que certaines choses doivent être faites avant tout. Certaines concernent la sécurité, d’autres l’ergonomie, etc., et pour ce qui nous concerne ici, l’accessibilité. Et qu’ensuite, il sera question d’améliorer, et là, on passe la main. Tout en gardant un oeil vigilant sur les copains qui peuvent tout péter derrière notre dos, bien souvent sans le faire exprès d’ailleurs.
Si on parle ici des « utilisateurs concernés par l’accessibilité du web », versus « utilisateurs » tout court, c’est bien parce qu’il y a un besoin réel de défendre ces utilisateurs, les grands laissés pour compte de la société en général, et du web en particulier. Je ne vais pas m’aventurer sur la pente glissante de l’explication sociologique du phénomène, mais il existe, et il est révoltant. Donc il faut des gens pour défendre cette frange de la population dont, appelons un chat un chat, les « bien portants » aimeraient ne pas avoir à se préoccuper, si ce n’est une fois l’an lors du Téléthon. Appelle-moi idéaliste, croisé, paladin, ou Suzan si ça te chante (bon, là, je cite un film, hein, ce n’est pas un appel du tout, du tout), bref, moque-toi de moi si tu le souhaites, mais pour ma part, si j’ai choisi cette voie de l’accessibilité, c’est pour mener ce combat, avec mes armes à moi. Et je sais qu’on est tous issu de cet idéal, nous autres gens du métier. Ce que JPV et moi on espère, c’est que nos frères d’armes ne baissent pas les bras. On n’est déjà pas bien nombreux…
Je voudrais vraiment lever toute ambiguïté : il est hors de question que je lâche le morceau concernant l’accessibilité. Je vais continuer à travailler sur les méthodes de déploiement de l’accessibilité, et à sensibiliser, comme depuis 2004.
Lorsque j’affirmais en 2006 ou 2007 qu’il fallait utiliser les méthodes de management de qualité pour déployer intelligemment WCAG, c’est à dire sans forcément tenir compte des niveaux A, AA, et AAA, je me faisais taper dessus. Vraiment. C’était tabou. Ca va mieux.
Que ce soit en 2007, en 2012, et si je peux en 2015, je m’oppose et je m’opposerai à l’idée que les défenseurs de la qualité Web seraient des ennemis de l’accessibilité. Si certains utilisent les référentiels et les méthodes qualité Web et laissent passer des erreurs dramatiques en accessibilité, les référentiels n’y sont pour rien (ça fait dix ans qu’on laisse passer des énormités avec WCAG).
Un expert accessibilité qui demande à ce qu’on travaille pour tout le monde n’est pas un idéaliste : c’est un professionnel. Un qualiticien qui demande à ce qu’on pense à tout le monde n’est pas un croisé ou un évangéliste : c’est un professionnel. Et quand il faut prendre des décisions dans le monde professionnel, le boulot des décideurs est de faire des arbitrages. Que chacun (ergonomes, référenceurs, experts accessibilité, spécialistes e-commerce, marketeux, graphistes, DSI…) affute ses arguments professionnels. Si d’aventure des spécialistes du management de la qualité peuvent faciliter les arbitrages au coup par coup ou globalement, si possible sur la base d’indicateurs ou d’éléments factuels, il me semble qu’il ne faut pas s’en priver.
Les méthodes qui seront développées dans le domaine de l’accessibilité, notamment autour des risques ou de l’automatisation ne seront pas exclusives, au contraire, elles pourront s’appliquer à l’ergonomie, à la sécurité, à la performance. En ce sens, l’accessibilité peut être un laboratoire pour le management de la qualité Web.
C’est un chimiste qui te le dit : je ne sais pas si l’accessibilité est soluble dans la qualité, mais le management de la qualité Web est un bon catalyseur (accessoirement il ne faut pas se précipiter – haha)
L’un des « charmes » de l’écrit est que l’on peut facilement se perdre dans une spirale de quiproquos, surtout avec des interlocuteurs passionnés, et je crois qu’en voici une très jolie. Je le précise pour les lecteurs qui ne nous connaîtraient pas: Elie et moi on s’apprécie et se respecte, tant personnellement que professionnellement (je m’avance un peu mais je ne pense pas avoir tort!), donc ce qui pourrait être pris pour du désaccord profond est forcément mal interprété, ou plus nuancé que ce que quelques lignes de blog peuvent traduire. Si mon commentaire a induit quelque doute que ce soit sur ton intégrité professionnelle et tes intentions, toutes mes excuses (et si on te cherche des crosses suite à cela, dis-le moi, j’irai leur péter la gueule à la récré ;o)).
Mon envolée lyrique sur les raisons profondes qui m’ont poussé vers l’accessibilité visait uniquement à justifier une posture qui consiste à prioriser les utilisateurs ayant besoin de l’accessibilité, par rapport aux autres (c’est mon coté chevalier blanc). Il me semble qu’il y a besoin de gens qui endossent cette tâche.
Il y aura ponctuellement des cas où les besoins (j’écris bien besoins, et non intérêts ou confort) de ces utilisateurs devront être satisfaits avant d’autres. Je sais que sur le fond on ne pourra jamais réellement et honnêtement justifier de prioriser un choix pro-SEO ou ergo sur un critère d’access incontournable. Du moins sans assumer le fait de délibérément désavantager les utilisateurs en situation de handicap. Du coup, je suis assez serein en général lorsque je dois défendre mon point de vue.
Le souci, et c’est ce qui justifie pleinement les méthodes que JPV appelle de ses voeux, est qu’on n’est pas toujours bien certain de ce qui est nécessaire ou pas, réellement et sans langue de bois, aux utilisateurs de l’accessibilité. De fait, si on a un doute, on sera en difficulté, d’autant « qu’en face » il y a des arguments séduisants, même s’ils ne sont pas toujours aussi solides qu’ils veulent le laisser croire. C’est pourquoi nos méthodos globales doivent donner à ceux qui les utilisent assez de force et de certitudes pour faire les vrais bons choix, et pas ceux que les sirènes des différents domaines ont réclamés avec plus de talent ou de conviction.
Pour participer à la bonne ambiance des lieux je voudrais préciser quelques points.
Il n’est pas dans mes intentions d’opposer une démarche d’accessibilité « exclusive » à une vision plus globale de qualité Web ce qui, sur le fond, n’aurait pas beaucoup de sens. Mon propos est fondé sur la conviction qu’on ne peut pas mettre sur le même plan tous les domaines liés à ce qui nous est présenté comme la qualité Web.
Et parmi ces domaines j’en isole deux : la sécurité et l’accessibilité parce que dans ces domaines il ne s’agit pas de performer mais de garantir. Et de la même manière qu’on ne peut pas transiger avec les fondamentaux de la sécurité, on ne devrait pas pouvoir transiger avec les fondamentaux de l’accessibilité.
Une image porteuse d’une information essentielle doit avoir une alternative pertinente, ce n’est pas une bonne pratique, un critère de performance ou un objectif d’amélioration. Cela ne veut pas dire que tout WCAG est logé à la même enseigne mais que si l’on aborde l’accessibilité sous cet angle on pourra se poser les bonnes questions.
Je ne suis pas tout à fait certain que la question de savoir si tous les développeurs peuvent ou ne peuvent pas être formés à la pertinence des alternatives d’images est une bonne question. Tous les mécaniciens ne sont pas formés à l’électronique embarquée et pourtant toutes les voitures roulent plutôt bien.
Je ne suis tout à fait certain que l’indétermination supposée de la plupart de nos critères soit un frein à la mesure. On mesure, on classe et on jauge des tas de choses indéterminées, le savoir, la cuisine, le temps qu’il fait suffisamment bien pour pouvoir choisir nos écoles, nos restaurant et nos lieux de vacances avec un niveau de garantie acceptable.
En revanche je suis d’accord sur le fait qu’on ne pourra pas déployer des « experts » dans tous les projets Web, ce serait idiot, déployons plutot des techniciens spécialisés comme il y a des secrétaires de rédaction, des électronicien automobiles,
des ingénieur béton. Et le niveau de technicité requis dans notre domaine pour la gestion courante d’un contenu, honnêtement, c’est pas du BAC+3 et 2 ans d’expérience c’est du J+5 et quelque mois d’expérience.
« Les experts doivent disparaitre », si je peux me permettre, est un joli slogan mais c’est un peu court je préfère dire comme mon camarade de jeu que l’expertise dans ce domaine est primordiale mais qu’elle est simplement mal employée.
Je ne suis pas certain non plus que WCAG ne peut pas faire ce qu’on lui demande je préfère penser que nous n’avons pas encore trouvé la bonne manière, les bonnes méthodes pour l’utiliser.
Nicolas dit dans son commentaire qu’il faut viser « moins haut » je me permettrais de corriger en disant qu’il ne faut surtout pas viser moins haut, il faut simplement viser mieux.
Cela passe sans doute par des interrogations de fond sur l’état de l’art et surtout par la mise en place de méthodes plus rationnelles, plus pragmatiques,mieux adaptées et mieux adaptables.
Mais cela passe aussi et surtout par le fait que tout le monde comprenne bien qu’une alternative d’image porteuse d’une information essentielle ce n’est pas une option améliorable, ce n’est pas une option c’est tout.
Mon propos est fondé sur la conviction qu’on ne peut pas mettre sur le
même plan tous les domaines liés à ce qui nous est présenté comme la
qualité Web.
Et parmi ces domaines j’en isole deux : la sécurité et
l’accessibilité parce que dans ces domaines il ne s’agit pas de
performer mais de garantir.
Saleté de Disqus (mais je m’égare)
Je voulais dire :
> Mon propos est fondé sur la conviction qu’on ne peut pas mettre sur le
même plan tous les domaines liés à ce qui nous est présenté comme la
qualité Web.
> Et parmi ces domaines j’en isole deux : la sécurité et
l’accessibilité parce que dans ces domaines il ne s’agit pas de
performer mais de garantir.
Hé bien franchement, tu nous aurais dit ça plus simplement, j’aurais compris du premier coup. 😉
« ..Dans ces domaines il ne s’agit pas de performer mais de garantir. »
Fourgonnette que c’est limpide…
Comme quoi, parfois on s’escrime des heures durant à tenter d’expliquer ce qui tient au final en une phrase…
C’est ça aussi, le talent!
Me fait bien plaisir que tu ai compris….
Ce n’est pas toujours évident d’être aussi simple sans être ipso facto catalogué au mieux comme un dogmatique rigide ou au pire comme un fondamentaliste échappé d’un asile ouzbek.
Et puis, tu es bien placé pour savoir qu’évidemment ce n’est pas aussi simpliste, c’est bien ce qui fait la richesse de notre métier non ?
Garantir… Tout de suite les grands mots ! 😉 il me semble qu’on ne peut garantir la sécurité et l’accessibilité d’un site à 100%. On peut seulement garantir le fait d’avoir appliqué la norme ou la réglementation en la matière à un moment donné. Et même si un site est « garanti 99% sécure et accessible » à la livraison, le maintien de ce taux implique un monitoring permanent. Il faut donc également que le client ait les moyens de cette garantie…
« Garanti à 99% », on n’est pas loin de l’oxymore… Si c’est garanti, c’est forcément à 100%, sinon, ce n’est pas garanti. Tu imagines la scène? « Mes freins ont lâché, pourtant la voiture est neuve. » — « ah mais monsieur, les freins sont garantis à 99%, pas de chance, vous avez tenté de freiner pendant le 1% non garanti ».
Blague à part, ce qu’il faut retenir du billet: il faut se donner les moyens, au niveau du projet, de satisfaire les critères qui font que les utilisateurs, tous, sont en capacité d’utiliser le site. Pas forcément de manière optimale (ça, c’est le propos de la qualité web), mais que les prérequis techniques de l’accessibilité soient là. Ce n’est pas évident de déterminer quels sont ces prérequis, même si on parle le WCAG couramment. Il se trouve que le projet MIPAW vise à déterminer ce qui ne peut pas être mis de coté ou pris à la légère. Ça limite grandement l’effet de mur, et rend envisageable une approche graduelle qui ne sacrifie pas les besoins de l’utilisateur face à ceux de l’équipe projet.
Après, c’est sûr qu’il y a du travail pour maintenir au niveau tout ce qui doit l’être, mais en soi ce n’est pas une approche spécifique pour l’accessibilité, ou la sécurité, par rapport à d’autres facteurs critiques telles que la disponibilité serveur ou les temps de réponse. La gestion des risques est justement là pour définir les mécanismes de détection et de mesure, les seuils de déclenchement, et les actions correctives associées. En mettant cela en place, on se donne les moyens de maintenir le niveau, et échapper aux coups de gourdin…
(note: réinsertion manuelle d’un commentaire posté initialement le 22/01/2012, disparu suite à un problème d’import)
« Garanti à 99% », on n’est pas loin de l’oxymore… Si c’est garanti,
c’est forcément à 100%, sinon, ce n’est pas garanti. Tu imagines la
scène? « Mes freins ont lâché, pourtant la voiture est neuve. » — « ah
mais monsieur, les freins sont garantis à 99%, pas de chance, vous avez
tenté de freiner pendant le 1% non garanti ».
Blague à part, ce qu’il faut retenir du billet: il faut se donner les
moyens, au niveau du projet, de satisfaire les critères qui font que les
utilisateurs, tous, sont en capacité d’utiliser le site. Pas forcément
de manière optimale (ça, c’est le propos de la qualité web), mais que
les prérequis techniques de l’accessibilité soient là. Ce n’est pas
évident de déterminer quels sont ces prérequis, même si on parle le WCAG
couramment. Il se trouve que le projet MIPAW vise à déterminer ce qui ne peut pas
être mis de coté ou pris à la légère. Ça limite grandement l’effet de
mur, et rend envisageable une approche graduelle qui ne sacrifie pas les
besoins de l’utilisateur face à ceux de l’équipe projet.
Après, c’est sûr qu’il y a du travail pour maintenir au niveau tout ce
qui doit l’être, mais en soi ce n’est pas une approche spécifique pour
l’accessibilité, ou la sécurité, par rapport à d’autres facteurs
critiques telles que la disponibilité serveur ou les temps de réponse.
La gestion des risques est justement là pour définir les mécanismes de
détection et de mesure, les seuils de déclenchement, et les actions
correctives associées. En mettant cela en place, on se donne les moyens
de maintenir le niveau, et échapper aux coups de gourdin…
(note: réinsertion manuelle d’un commentaire posté initialement le 23/01/2012, disparu suite à un problème d’import. Auteur initial: Pascal Weber, de Mandibul)
=D Quand je dis qu’on ne peut garantir qu’à 99% c’est qu’on n’imagine
pas toujours les conditions extrêmes qu’un visiteur est capable
d’inventer pour se retrouver en situation d’inaccessibilité ! Si je
reprends ton exemple de freins garantis à 100%, que répondre à celui qui
roule à 130 km/h sur une pente à 14% complètement boueuse et qui tente
désespérément de freiner ? On ne peut garantir à 100% que dans les
situations d’usage prévues et éprouvées. Pour le reste, on peut
simplement dire « en théorie ça devrait aussi marcher ». Mais je suis
entièrement d’accord : en ce qui concerne les situations éprouvées la
garantie doit être de 100%
(note: réinsertion manuelle d’un commentaire posté initialement le 23/01/2012, disparu suite à un problème d’import)
Distinction très judicieuse, en effet. C’est un des aspects les plus
difficiles à faire comprendre à ceux qui découvrent (clients inclus)
l’accessibilité que je qualifierais de non-fonctionnelle: on ne
s’intéresse pas explicitement à ce que fait l’utilisateur, mais
on met en place les conditions techniques qui doivent permettre tous
les modes d’accès envisageables, en essayant d’inclure toutes les
typologies connues, qu’elles soient techniques ou comportementales. La
grande idée des WCAG en version 2, c’est justement de séparer les
principes des techniques. Les principes restent vrais pour l’éternité
car ils définissent les besoins profonds (par exemple comprendre un
contenu visuel sans le voir); tandis que les techniques en indiquent les
modalités (par exemple renseigner l’attribut alt d’un élément IMG).
Du coup la couche « modalités » est flexible et s’adapte aux technos
considérées, avec cette possibilité infiniment précieuse de les faire
évoluer dans le temps sans tout réécrire.
Je digresse un peu, mais pour en revenir à ton commentaire:
effectivement, le cas du type qui surfe via des balles de ping-pong
virtuelles, en les envoyant avec sa wii-mote sur un clavier projeté sur
son plafond, n’est pas spécifiquement pris en charge. En revanche, on
doit s’assurer que les entrées basées sur le principe du clavier, touche
par touche, sans possibilité de les combiner, doit être pris en charge.
Là on est typiquement dans la sécurisation de l’accès au contenu, et
non dans l’ergonomie ou l’amélioration.
(note: réinsertion manuelle d’un commentaire posté initialement le
23/01/2012, disparu suite à un problème d’import. Auteur initial: Pascal
Weber, de Mandibul)
Yes ! Très intéressant cette approche par couches. Comme nombre de cms
fonctionnent à présent sur la base de plugins, d’objets, de modèles etc
cela devient effectivement beaucoup plus simple de maintenir un site :
faut-il désormais ajouter telle balise sur les images ? -> Je modifie
le modèle d’affichage des images et mon site est ok ! Cool.
=D Quand je dis qu’on ne peut garantir qu’à 99% c’est qu’on n’imagine pas toujours les conditions extrêmes qu’un visiteur est capable d’inventer pour se retrouver en situation d’inaccessibilité ! Si je reprends ton exemple de freins garantis à 100%, que répondre à celui qui roule à 130 km/h sur une pente à 14% complètement boueuse et qui tente désespérément de freiner ? On ne peut garantir à 100% que dans les situations d’usage prévues et éprouvées. Pour le reste, on peut simplement dire « en théorie ça devrait aussi marcher ». Mais je suis entièrement d’accord : en ce qui concerne les situations éprouvées la garantie doit être de 100% 😉
Distinction très judicieuse, en effet. C’est un des aspects les plus difficiles à faire comprendre à ceux qui découvrent (clients inclus) l’accessibilité que je qualifierais de non-fonctionnelle: on ne s’intéresse pas explicitement à ce que fait l’utilisateur, mais on met en place les conditions techniques qui doivent permettre tous les modes d’accès envisageables, en essayant d’inclure toutes les typologies connues, qu’elles soient techniques ou comportementales. La grande idée des WCAG en version 2, c’est justement de séparer les principes des techniques. Les principes restent vrais pour l’éternité car ils définissent les besoins profonds (par exemple comprendre un contenu visuel sans le voir); tandis que les techniques en indiquent les modalités (par exemple renseigner l’attribut
altd’un élémentIMG). Du coup la couche « modalités » est flexible et s’adapte aux technos considérées, avec cette possibilité infiniment précieuse de les faire évoluer dans le temps sans tout réécrire.Je digresse un peu, mais pour en revenir à ton commentaire: effectivement, le cas du type qui surfe via des balles de ping-pong virtuelles, en les envoyant avec sa wii-mote sur un clavier projeté sur son plafond, n’est pas spécifiquement pris en charge. En revanche, on doit s’assurer que les entrées basées sur le principe du clavier, touche par touche, sans possibilité de les combiner, doit être pris en charge. Là on est typiquement dans la sécurisation de l’accès au contenu, et non dans l’ergonomie ou l’amélioration.
Yes ! Très intéressant cette approche par couches. Comme nombre de cms fonctionnent à présent sur la base de plugins, d’objets, de modèles etc cela devient effectivement beaucoup plus simple de maintenir un site : faut-il désormais ajouter telle balise sur les images ? -> Je modifie le modèle d’affichage des images et mon site est ok ! Cool.
A mon niveau (je ne suis ni qualiticien ni expert accessibilité 🙂 ), je constate que le discours de l’accessibilité a évolué (je schématise très très vulgairement) : on est passé d’un discours très « intégriste » (au mieux extrêmement pointu) à une vision bien plus pragmatique. Tout comme le discours sur la conformité absolue d’ailleurs… (et comme beaucoup d’autres discours en matière de web)
Quand à la méthodologie parfaite, je pense qu’elle reste à inventer, je constate que (pour l’avoir pratiquée), l’approche niveau A/AA/AAA a énormément d’inconvénients (frustration, constat d’échec, difficulté, mise en pratique épouvantable, etc.). Actuellement, je pencherais plutôt pour une montée en compétences des équipes et un accompagnement de l’expert, pas par mode ou par dogme, simplement pour des réalités pratiques et pragmatiques (et pour la pratiquer également, je constate que c’est bien plus agréable).
Plus généralement, je pense que l’accessibilité DOIT être vulgarisée et revenir dans les bases : l’expert ne doit pas disparaître, mais le meilleur expert est celui qui sait se rendre accessible… surtout quand le sujet en question est l’accessibilité (gag !).
A l’expert de s’occuper des trucs compliqués d’experts, et à lui d’amener des solutions, c’est son boulot d’expert : trouver des solutions à des problèmes compliqués de son domaine.
Une remarque pleine de bon sens m’a fait tiquer à Paris-web, sur une conférence sur le sous-titrage (pour ne pas la citer) : – comment fait-on dans tel cas (cas particulier un peu compliqué) pour sous-titrer ? – mettez déjà des sous-titres, on se démerdera avec.
L’auteur de cette réponse n’imagine pas la portée de son propos : « décomplexez-vous, faites quelque chose, ça sera toujours mieux que rien ». A mon avis, ce genre de remarque est vraiment une bonne chose : « arrêtez de viser la perfection, tentez déjà une base, on verra après pour y améliorer ».
L’accessibilité, la qualité (et le reste) devraient s’en inspirer : peut-être viser moins haut, mais déjà arriver à faire quelque chose (et c’est un ex-intégriste du code qui dit cela).
Je plussoie.
Nicolas, je suis totalement en phase avec toi concernant tant l’articulation de l’expertise avec les composantes du projet – je travaille d’ailleurs dans ce sens depuis toujours. De même que sur la nécessité de fournir à ceux qui n’ont pas la possibilité (ou la volonté) d’acquérir ou d’utiliser l’expertise, des outils permettant d’assurer le service minimum; et après on peut travailler sur l’amélioration. C’est l’un des corollaires du billet de JPV. Encore faut-il savoir ce qu’est ce minimum… La bonne nouvelle, c’est que des travaux en cours permettront de le définir de façon rationnelle, transcendant sans les contredire les référentiels actuels (qui, quoiqu’on en dise, restent une référence éminemment précieuse). En tous cas c’est le but.
Sur le pragmatisme croissant du domaine, je partage également ton avis. Cela peut révéler deux tendances: soit le domaine murit, s’industrialise, se rationnalise, bref, devient adulte, et ça c’est bien. Soit on tend à lâcher l’affaire, et « pragmatisme » devient juste un synonyme acceptable pour « paresse ». A ce sujet je vous conseille vivement la lecture de cet article de Derek Featherstone sur le pragmatisme (en anglais): http://simplyaccessible.com/article/pragmatism-transcripts/. Ces deux tendances existent sans doute, à nous tous de résister à la tentation du coté obscur…
Voir la très bonne conférence d’Elie et Laurent aussi, toujours à Paris-Web :
http://www.paris-web.fr/2011/conferences/accessibilite-soyons-agiles.php
… qui dit exactement ça.
Oh, je sais, je l’ai suivie, et je ne me suis pas caché d’approuver à 100% cette vision que je partage totalement !
Merci les gars pour ces commentaires et débats si riches.
Il est vrai qu’à la première lecture de l’article de JPV, j’y voyais franchement une différence de vue fondamentale dans l’approche de conduire l’accessibilité dans les projets par rapport à ce que propose Temesis à longueur de conférences Paris Web, W3Café and Co, c’est à dire, pour faire court, du pragmatisme, du lâcher prise, de l’empathie, tout ça un peu en opposition avec le gourdin de JPV et son ironie sur l’accessibilité « sautillante »…
In fine, je pense bien sûr que JPV et Élie se « battent », peut être chacun à leur manière, à faire avancer l’accessibilité en France.
Pour ma part, en tant que « débutant » dans ce secteur (je n’ai ni 13 ans ou 7 ans d’expérience), je constate que l’accessibilité dans les projets est encore méconnue voire inconnue. Combien de fois ai-je pu rencontrer de responsables de projets dans le secteur public, insérant la mention du respect au RGAA et avouant in fine qu’ils ne savent pas du tout en quoi ça consiste et ont fait un bête copier/coller du modèle de cahiers des charges mis à leur disposition.
Je n’ai pour ma part jamais rencontré de projets pouvant se permettre (budgétairement parlant) d’engager une dream team pour gérer tous les sujets (accessibilité, SEO, Expérience utilisateur, etc.).
D’ordre général, j’ai le sentiment que l’accessibilité repose sur une personne, soit un prestataire, soit une personne en interne compétente en la matière, ayant eu assez d’appétence pour suivre une courte formation, voire mieux, être expert Accessiweb par exemple.
Le manque de sensibilisation de base est un véritable frein à la prise en compte de l’accessibilité dans les projets ; c’est malheureusement à l’image de la prise en compte du Handicap dans notre société et dans la vie « de tous les jours », hors du web.
Il faut trouver des méthodes et pourquoi pas « agiles » pour faire avancer le sujet.
Aborder l’accessibilité comme levier de la qualité parle aux personnes qui ne connaissent pas le sujet.
Faire des analogies avec le quotidien comme par exemple, des rampes d’accès à l’entrée de bâtiments servant aussi bien aux personnes handicapées qu’aux mamans revenant des courses avec leur bébé dans la poussette aident à faire comprendre certaines choses. Je ne sais pas si c’est du « Design for all » mais c’est clairement un plus dans la qualité.
J’ai la même motivation qu’Olivier quant à essayer de réparer (à mon niveau) les injustices causées par la non prise en compte de l’accessibilité, laissant toute une frange de personnes sur le bord de la route alors qu’on a les moyens de les faire voyager confortablement, mais c’est clair que les handicapés, ils n’ont pas à prendre le même moyen de transport que les autres puisqu’on leur fournit des ambulances (http://www.pixelperdu.net/2012/01/05/vis-ma-vie-de-sourde-episode-10/)…
Ironie mise à part, je pense que la route est encore longue et que pour l’instant, le sujet de l’accessibilité, même s’il a dû clairement s’améliorer ces dernières années, repose encore sur une poignée (au regard de l’ensemble des personnes travaillant dans les métiers du web) de gens motivés qui ont chacun leur approche pour faire avancer le sujet dans le bon sens.
« Il se trouve que le projet MIPAW vise à déterminer ce qui ne peut pas être mis de coté ou pris à la légère. Ça limite grandement l’effet de mur, et rend envisageable une approche graduelle qui ne sacrifie pas les besoins de l’utilisateur face à ceux de l’équipe projet. »
Attention comme je l ai dit lors du séminaire accessiweb MIPAW ne réduit en rien l effet mur. En effet, ce qui constitue les besoins de base de l utilisateur peut tout à fait être d une difficulté de mise en œuvre très important pour l équipe projet.
Un exemple parmis d autre : la mise à dispo de contenu en langue des signes, essentiel pour les personnes sourdes, très difficile à mettre en place de manière industrielle.
MIPAW n est donc pas a utiliser tel que, il s agit plutot d un outil permettant de définir un indicateur d accessibilité ou de manière complémentaire à d autres élément pour un déploiement progressif tenant compte des impératifs projets
L’idée de base de MIPAW est de hiérarchiser l’implémentation en fonction des besoins de l’utilisateur (déterminé via la notion d’accès à l’information). On n’est donc plus en face d’une masse informe de critères qui mélangent de l’essentiel et de l’amélioration.
Ce qu’on va minimiser ce n’est pas le mur (les niveaux reste intacts) mais son impact sur le projet, de ce point de vue ça ne fait pas de différence avec les approches progressives actuelles. La grande différence réside dans le facteur utilisé pour hiérarchiser les critères.
En l’état de l’art on adopte des stratégies qui consistent essentiellement à faire le maximum de choses en fonction des ressources projets disponibles. Mais dans cette approche, certes louable, le résultat est souvent insatisfaisant du point de vue de l’utilisateur : on en fait beaucoup mais mal.
En proposant des phases d’approches successives de WCAG basées sur une prise en charge progressive des besoins utilisateurs on suppose que les méthodologies qui pourraient être élaborées seront plus efficaces et plus rentables.
Plus efficace parce qu’à chaque phase successive le gain utilisateur est réel, adapté et mesurable. En outre, les niveaux d’exigence et la gestion des défauts sont facilités, on sait ce sur quoi l’exigence doit être maximale.
Plus rentable parce qu’en utilisant un rapport entre les contraintes et les besoins on peut avoir une gestion plus fine et plus efficace des ressources projets.
Mais, naturellement, les problèmes posés par l’industrialisation restent aussi compliqués, à la condition qu’on ne confonde pas des difficultés à industrialiser avec des difficultés à mobiliser les ressources nécessaires. L’INA par exemple à industrialisé l’indexation de ces contenus via une armée de documentalistes et des logiciels intelligents. Il n’y a pas de problème à industrialiser la production de LSF, il n’y a qu’une question de moyens.
Pour une grande part, WCAG a déjà traité ce problème, la LSF est AAA et le sous-titrage en direct AA pour prendre ces deux exemples sur lesquels les ressources sont difficiles à mobiliser.
MIPAW pourrait être utilisé tel quel de la même manière qu’on gère des implémentations 100% WCAG, ses seuls apports seront alors de rendre la progressivité cohérente avec les besoins de l’utilisateur et de proposer une mesure représentative du niveau réel d’accessibilité, ce qui serait déjà pas mal.
Au-delà, le but est surtout de pouvoir élaborer différentes méthodologies sur une base commune en ayant en permanence une mesure très fine des progrès et des écarts par rapport aux besoins réels de l’utilisateur.