Le W3C a publié le 27 mars 2012 un « early draft » d’une méthode harmonisée d’évaluation des sites web. Bonne nouvelle, en apparence, mais on y trouve une petite phrase de rien du tout, qui pourrait bien s’avérer lourde de conséquences.
Voici l’abstract du document (en anglais):
This document specifies an internationally harmonized methodology for evaluating the accessibility conformance of websites to the Web Content Accessibility Guidelines (WCAG) 2.0. It defines an approach for conformance evaluation in different contexts, including self-assessment and third-party evaluation. It is applicable to any website, including web applications and websites for mobile devices, and is independent of any particular evaluation tools, web browsers, and assistive technologies.
This document is a supporting resource for WCAG 2.0 and does not replace or supersede it in any way. It addresses the need for a standardized approach for evaluating entire websites after their development as opposed to evaluating individual collections of web pages during their development, which is equally important to ensure website accessibility. This work is part of W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications.
Conformément aux bonnes habitudes prises avec WCAG2, cette méthodologie se veut indépendante du type de site, de la méthode d’audit, et des différents outils utilisés pour évaluer.
A noter que le document cible spécifiquement l’évaluation des sites déjà développés, et non ceux en cours de développement.
Les utilisateurs assidus d’Accessiweb ou du RGAA ne seront pas totalement dépaysés par la technique d’échantillonnage (étape 3). Les étapes 4 (auditer l’échantillon) et 5 (rendre compte des résultats) n’étant pas achevées à ce jour, il n’est pas possible de déterminer à ce stade si nos référentiels nationaux avaient déjà bon sur ces phases également.
La phrase qui m’a passablement troublé (étape 1.e): W3C/WAI provides a set of publicly documented Techniques for WCAG 2.0 but other techniques may be used too
. En français: W3C/WAI fournit un ensemble de documents publics sur les Techniques pour WCAG 2.0 mais d’autres techniques peuvent être utilisées également
. En clair, les fameuses Techniques sur lesquels s’appuient nos référentiels, et que nous étudions et suivons tels les évangiles de l’accessibilité du Web, ne sont finalement vues par le WAI lui-même que comme une option parmi d’autres. Alors qu’on pensait avoir une direction claire sur ce qu’il est bon ou pas bon de faire, ce document nous indique que finalement, oui, mais non.
Hasard du calendrier, mon très estimé collègue Jean-Pierre Villain a rencontré le même jour Shadi Abou-Zahra, l’un des auteurs du draft, pour lui présenter certains travaux réalisés en commun avec Braillenet autour des WCAG 2.0, et plus précisément sur une méthode d’harmonisation des référentiels dérivés de WCAG 2.0, à savoir WCAG-CAC (voir la présentation du projet WCAG-CAC par Denis Boulay de Braillenet, à CSUN 2012 – en anglais, sur Slideshare). Shadi lui a parlé de ce document, et a confirmé que les techniques des WCAG 2.0 ne sont qu’une proposition, car, selon ses termes, il ne faut pas contraindre les développeurs.
Je comprends l’idée de laisser une certaine liberté d’action, et susciter l’invention et les solutions nouvelles. Mais je ne suis pas du tout certain que cela correspond aux attentes des développeurs. Et je suis sûr que c’est très risqué pour l’accessibilité.
Quand, en formation ou dans des spécifications, on présente des critères de succès aux développeurs, la réaction fréquente est: ok, mais comment fait-on? Fort heureusement, on a les Techniques WCAG 2.0 qui permettent de fournir des réponses opérationnelles, et surtout, validées par l’autorité de référence en la matière, le WAI. C’est même pour ça qu’on y est autant attaché, au WAI: parce que ce qu’on y trouve a valeur de vérité. Bon, c’est vrai qu’y trouver une réponse claire à une question précise relève du défi neuronal, mais, ouf, merci Accessiweb et RGAA, on a des ressources en français qui ont fait ce travail infiniment précieux de dépouiller ces techniques, et de les organiser sous une forme qui nous permet soit d’appliquer et vérifier concrètement les recommandations, soit de les expliquer à d’autres.
Phénomène significatif: lorsque plusieurs techniques existent pour un critère de succès (par exemple, on a au moins quatre façons valides de fournir la description détaillée d’une image, et encore, sans parler du HTML5), une réaction fréquente est de l’ordre du: euh, laquelle est la bonne? Réponse: toutes sont bonnes. Réplique: ah, mais laquelle est la plus bonne? Là, on a beau expliquer que ça dépend du contexte, de l’état du site, des contraintes techniques et éditoriales, et qu’on donne le choix pour faciliter la vie… rien à faire, le doute s’instille et s’installe. Car un développeur, sauf s’il est de nature aventureuse, préfère éviter d’avoir à choisir. Dans l’idéal, il y a un bout de code, un plug-in, un logiciel, qui se copie-colle ou se plugge, qui fait le job, et qui permet de passer à autre chose (en fait, dans l’idéal idéal, il ya une moulinette supra-magique qui rend le site accessible, mais malgré ce qu’on tente de vous vendre parfois, c’est encore plus improbable qu’une licorne cruciverbiste qui vous demande l’heure un soir de pluie).
Le second problème, et c’est préoccupant, c’est que cette position est la porte ouverte aux solutions inventées par le développeur. Et là, mes amis, ça va être la fête du slip (si vous me permettez l’expression… Vous me permettez? Merci.). Avec les référentiels, l’évaluateur (ou le concepteur ou le codeur) sait ce qui marche, et peut en déduire par soustraction ce qui ne marche pas. Mais si on dit que finalement les référentiels ne contiennent pas tout ce qu’il est possible de faire, ça veut dire que pour chaque bidouille pondue par l’esprit fécond du codeur, la charge de prouver l’inadéquation de la solution reviendra à l’évaluateur. Ce qui complique singulièrement la tâche, et rend l’audit monstrueusement difficile! C’est vrai que les Techniques WCAG 2.0 sont en partie composées de « Failures » (échecs) qui disqualifient clairement certaines pratiques, mais on est loin d’avoir fait le tour des possibilités. J’en pratique régulièrement, des audits, et croyez-moi, l’imagination de mes chers confrères codeurs et rédacteurs n’a pas de limite connue. Et certains debriefings d’audits ne dépareraient pas aux Jeux Olympiques de la Mauvaise Foi, alors même que ce qui est bon est écrit noir sur blanc dans nos référentiels… Maintenant, s’il est établi qu’on peut faire ce qu’on veut, et vas-y, prouve-moi que j’ai tort… on va s’amuser!
Mais ce n’est rien, on s’habituera et on trouvera les réponses. Le vrai problème, c’est que l’accessibilité du Web, qui a déjà bien du mal à percer, ne va pas être aidée ni améliorée par ce flou artistique revendiqué. À l’heure où l’on réclame à cor et à cris une base de connaissances fiables et non ambiguës, je trouve cette position plus gênante qu’aidante. Et pour moi, cela décrédibilise en partie l’idée que le WAI est une référence suffisante pour appliquer et faire appliquer l’accessibilité. Cela donne même plus de poids au besoin de construire une base de connaissances, reconnue et validée, qui simplifiera grandement la tâche de tous ceux qui œuvrent au quotidien pour faire du Web un lieu accessible à tous.
Il est clair que le WAI devra expliciter ce qu’il entend par « d’autres techniques ». Fait-il référence aux techniques mentionnées par les méthodes d’application des WCAG 2.0 ou accompagnant ces dernières (par exemple, les tests du référentiel Accessiweb ou le guide Accessiweb, abstraction faite de son manque de mise à jour) ? Ou bien fait-il référence à des techniques susceptibles de concurrencer les techniques WCAG 2.0 et dont on n’aura pas la garantie absolue qu’elles seront validées par des experts en accessibilité ?
Si la réponse à la première question est affirmative, il n’y aura, a priori, pas de souci à se faire, je pense. Sinon, tes craintes ont, effectivement, raison d’être.
En fait, le W3C ne se mêle pas des méthodes d’application qui émergent de leurs travaux. Et tant mieux, finalement, ça laisse une liberté d’amélioration qui est indispensable. La difficulté pour l’utilisateur est alors de vérifier le bien-fondé des propositions alternatives.
Pour Accessiweb, le processus de création et de vérification communautaire, qui est transparent, nous garantit une adhérence quasi-parfaite aux standards (à l’exception du fameux critère des images map coté serveur, pour lesquelles Accessiweb autorise un formulaire comme alternative, ce qui n’est pas dans les Techniques. Mais il n’y a aucun doute que cette solution fonctionne. Il suffirait d’ailleurs de la proposer au W3C…).
Pour le RGAA, on était a priori dans le même schéma d’élaboration, mais il y a eu des divergences, et l’histoire particulière de ce document fait qu’elles resteront là pour longtemps. Par exemple, le RGAA autorise de titrer un tableau de données avec un titre de section, ce qui n’est pas une Technique référencée par les WCAG. Connaissant les auteurs, j’aurais tendance à leur faire confiance, mais sans cette « caution WCAG », j’avoue que le doute m’incite à ne jamais préconiser cette solution.
Evidemment, connaître ce type de subtilité implique que l’on soit à fond dans le sujet, et qu’on soit au fait de choses qui ne sont écrites nulle part, hormis dans un fil de discussion d’une liste ou un forum privés. Pour l’écrasante majorité des producteurs de contenus web, cette apparente contradiction ne peut que créer la confusion.
Donc pour moi cette flexibilité laisse plus la porte ouverte aux problèmes qu’aux solutions…
C’est en effet une lecture possible. Pour ma part, je ne suis pas aussi inquiet pour la raison que les Techniques qui accompagnent les WCAG 2.0 sont définies elles-mêmes comme évolutives et donc susceptibles d’être modifiées ou amendées.
Le fait que WAI ne définissent pas ce qu’il entend par « d’autres techniques » ne me paraît pas très nouveau. A ma connaissance cet organisme n’interdit en effet à personne quelque part sur la planète de créer ses propres techniques. Encore lui faudra-t-il beaucoup d’énergie et de force de persuasion pour les imposer comme ayant valeur de référence. Je pense qu’à partir du moment où on se réclame accessible selon les WCAG ou selon un référentiel national, on ne peut pas invoquer des techniques ou des tests qui sortent d’ailleurs. Ce serait comme de dire : « jouons au foot et prenons les règles du horse polo ». Ca peut être marrant, mais dans ce cas ça ne s’appelle plus ni le foot ni le horse polo, mais quelque chose comme le « pied cheval ». Et donc il s’agit d’un tout autre référentiel.
Quant à la remarque de Victor, elle est juste. Mais la probabilité que WAI nomme explicitement un référentiel plutôt qu’un autre est à peu près la même que celle de voir deux lignes droites se croiser. Il lui faudrait faire face à des susceptibilités nationales sans fin.
Ce que tu dis est vrai, et sans doute que la phrase doit se comprendre comme « toute autre technique qui aurait sa place dans les Techniques officielles ». Sauf que ce n’est pas exprimé aussi clairement. Le simple fait de laisser cette notion « d’autre technique » indéfinie rend la chose glissante il me semble. Il est clair que pour faire officialiser une Technique nouvelle, il faut lutter, ça passe par tout un processus de validation, il faut plusieurs cas d’implémentation réelle, on doit avoir vérifié toutes les interérences de critères et autres. Mais si on ne précise pas cela, c’est autrement plus simple de faire passer des choses qui n’ont que l’apparence de la validité.
L’impression qu’il m’en reste est que la charge de la preuve est transférée à l’évaluateur, et donc que le rapport de force est inversé.
Bon, plus qu’à contribuer à l’appel à commentaires…
je voulais bien sûr dire « que de voir deux lignes parallèles se croiser ».
Attention, troll. En ce qui me concerne, j’ai toujours pensé et affirmé publiquement que les WCAG étaient des Guidelines, que je traduis comme des recommandations. J’ai toujours trouvé absurde qu’elles soient utilisées comme des spécifications formelles dont le respect est exigé par la loi alors qu’elles contiennent un nombre incroyable de points dont il est impossible de prononcer la conformité.
La phrase qui est écrite est tout simplement logique. Il va bientôt falloir faire le deuil de la conformité WCAG et de l’audit de conformité WCAG. Et il ne s’agira nullement de faire le deuil de l’accessibilité Web, bien au contraire. Move on.
Bonjour Elie,
Attention toutefois à bien lire le document en question au risque de diffuser une idée fausse.
Il n’y à absolument rien dans ce document qui montrerait le commencement du début du quart de poil de l’idée d’un abandon de
la conformité WCAG.
Bien au contraire, l’étape 1.C réaffirme sans ambiguité l’objectif de l’évaluation : vérifier la conformité A, AA, AAA et conseille d’ailleurs
de procéder à une évaluation AAA même si l’objectif est moins ambitieux.
Je pense que tu a lu trop vite car j’imagine que tu ne peut pas ignorer que la conformité WCAG n’est pas mesurée au niveau des techniques mais des critères de succès.
Par ailleurs, il faut également bien comprendre cette phrase, dans l’esprit de WAI il est tout à fait possible d’utiliser des techniques
non répertoriées à partir du moment où elles permettent de passer le critère de succès considéré donc d’assurer la conformité.
Le travail à réaliser pour valider le support des objectifs d’accessibilité pour une nouvelle technique n’est évidemment pas à la portée de de n’importe qui, il faut s’assure de son intérêt, de son support et de sa robustesse pour les utilisateurs, les technologies d’assistances, les navigateurs, les APIs et les usages…
C’est un travail long et particulièrement couteux. Il est très intéressant d’ailleurs de constater que lors des dernières mises à jour de WCAG aucune « nouvelle technique » pour le corps commun (G, H, C) n’a été proposée. Ou de constater l’énormité du travail actuellemnt en cours pour implémenter ARIA dans WCAG.
Prenons, par exemple, la couverture WCAG de RGAA ou AW, la possibilité d’utiliser une technique nouvelle sur le corps commun (donc en excluant javascript flash et consorts) est tellement infinitésimale qu’elle ne vaut même pas d’être discutée.
Et il faut être très prudent lorsqu’on décide d’utiliser une technique non repertoriée, l’utilisaton d’un titre H à la place d’un élément caption autorisée par RGAA présente le défaut d’avoir au moins un scénario d’usage en échec par exemple.
A l’inverse, l’utilisation d’un formulaire de navigation pour une image map coté serveur, autorisée par AW mais non repertoriée dans les techniques WCAG à été acceptée parce que nous n’avons aucun échec à son utilisation.
Il ne faudrait surtout pas que cette phrase qu’il faut remettre dans le contexte général d’intervention de WCAG et de son ambition de pouvoir suivre l’évolution des technologies soit l’objet de fausses interprétations née d’une lecture un peut trop rapide.
Au délà de cette petite correction, j’avoue être également un peu surpris que tu prennes le risque, sur un problème aussi délicat que la conformité WCAG, d’être mal compris.
Qu’un anonyme balance sans précaution qu’il faut abandonner la conformité WCAG ce n’est pas grave, il faut juste lui conseiller de réfléchir un peut, de lire les centaines de travaux de recherche publiés sur le sujet, en espérant qu’il finisse par se rendre compte à la fois de l’importance du sujet et de sa complexité.
En revanche que quelqu’un qui à la responsabilité du poids de sa parole balance au détour d’un commentaire que le problème est réglé et qu’il faut se préparer à abandonner l’audit de conformité, si tu me pardonnes par avance d’être un peut piquant, c’est faire bien peut de cas de tous ceux qui prendront cette saillie comme parole d’évangile et remplaceront des processus intelligents par de l’accessibilité au doigt mouillé.
C’est également faire bien peut de cas de tous ceux qui au lieu de proposer de casser le thermomètre travaille à le rendre plus intelligent.
Je sais bien que ce n’est absolument pas ton intention (c’est même l’inverse de ton intention) mais c’est comme ça que ton commentaire pourrait être compris et je pense que quelqu’un de ta stature ne peut plus se le permettre.
Quand au « nombre incroyable de points dont il est impossible de prononcer la conformité », je ne sais pas à quels types de problèmes vous êtes confrontés mais chez nous ça se passe admirablement bien, nos clients sont parfaitement satisfaits, nos résultats sont excellents et de ce coté, je tiens à te rassurer, tout va bien..
En même temps, Jean-Pierre, Élie a clairement annoncé la couleur de son commentaire, en utilisant le mot troll, et ce d’autant plus qu’il a commenté un vendredi (ou vendredÿ avec un Y tréma pour les aficionados d’Alsacréations). 😉 [clin d’œil]
juste pour info, ça fait bien longtps que le cas du hx à la place du caption à disparu du RGAA. Cela datait de la V1 si j’ai bonne mémoire
Salut Aurélien,
ce n’est pas dans le test de présence (11.7) mais dans le test de pertinence (11.9), étape 2: « Si est présent un élément caption non vide ou un contenu faisant office de titre situé immédiatement avant le tableau de donnée dans l’ordre du code source, poursuivre le test, sinon le test est non applicable. ». Bon, là on est sur un cas de « bug » du RGAA, sans doute, il n’en reste pas moins que sur cette base, je suis fondé à croire que le titre Hx peut convenir.
Non c’est effectivement correct, si tu a un tableau de donnée -> tu met un caption 11.7, si tu en as mis un ou que tu as utilisé un hx servant de titre -> on vérifie qu’il est pertinent (ce qui n’empêche pas qu’il faudrait un caption masqué par exemple, de cette manière dans tous les cas on a un titre pertinent)
Tu m’accorderas que c’est loin d’être clair! Et que, tel quel, on est en droit de penser que le Hx peut suffire à titrer le tableau, puisqu’il valide le test (sinon pourquoi le conserver dans le test?). Dans le cas où j’ai un caption non vide, mais non pertinent, tout en ayant un Hx pertinent, je valide, or, je ne devrais pas. Donc ce test pose quand même un problème de robustesse.
On dérive du sujet du billet en apparence, mais pas tant que ça: les tests sont là pour éviter la réinterprétation les critères de succès. Processus aussi chronophage que risqué! Et qui de fait n’a aucune chance d’aboutir à un résultat opérationnel concret, dans la vraie vie des projets. Corollaire: les tests doivent être irréprochables quant à leur capacité à satisfaire le critère et à ne pas laisser passer de cas d’échec. Et ce n’est pas simple à concevoir, la preuve. A mon sens le document WCAG-EM devrait alerter plus clairement sur ce point, et faire preuve de moins de désinvolture à ce propos.
je t’accorde que la formulation pourrait être optimisée. Par contre sur le fond AW, comme RGAA vont plus loin que les WCAG car elles n’obligent à ce qu’il y ait un titre uniquement si visuellement il y en a un et donc le caption n’est en rien obligatoire.
De mon coté que le titre soit en hx ou en caption ou les deux dans tout les cas il faut qu’il soit pertinent.
D’accord avec toi sur le fait qu’AW et RGAA vont plus loin que WCAG en forçant l’utilisation d’un titrage sur tout tableau de données. D’accord évidemment aussi sur la nécessité de pertinence. Mais dans la technique H39 des WCAG2, celle qui définit la façon de titrer un tableau de données, il est explicitement mentionné que le caption est *le* marquage approprié pour cette fonctionnalité… Ce qui en exclut d’autres. Non?
Au-delà de cette pécadille sur l’excès de prudence de nos référentiels chéris, reste quand même le problème que le test 11.9 du RGAA valide le cas où le caption est présent, non pertinent, du moment qu’un texte pertinent précède le tableau. L’utilisateur qui consulte le titre du tableau via le caption, c’est-à-dire de la « bonne » façon, et donc ne cherche pas à explorer le texte qui précède le tableau (pourquoi le ferait-il?), est pénalisé. Perso, ça me gêne… [<-- ça, c'est un euphémisme, que ça s'appelle]
Je vais essayer de faire au plus court :
– Je pense, je dis (et je suis prêt à l’assumer) qu’il faut se préparer à abandonner l’audit de conformité WCAG au profit d’autres audits de conformité en matière d’accessibilité. Il nous faut d’autres référentiels, d’autres méthodes, j’y travaille, comme toi, comme d’autres.
– Pour moi, partir de WCAG pour faire de l’audit de conformité n’est pas à mon sens la façon la plus efficiente d’améliorer l’accessibilité et encore moins d’améliorer les sites. Nous n’en avons pas beaucoup d’autres pour l’instant, mais ça ne change rien à mon avis sur la question.
Dernière chose : ce que j’écris peut effectivement être mal interprété. Pas de problème. Tant pis. J’ai travaillé, je travaille et je travaillerai sur l’amélioration de l’accessibilité des sites Internet. Pour ceci, je discute les outils et les méthodes et je ne suis pas près de m’arrêter 😉
Partir directement des WCAG pour des audits, je conçois parfaitement que c’est difficilement envisageable, de par leur haut degré d’abstraction vis-à-vis des technologies du Web, présentes et futures. Mais, il ne faut pas oublier que les WCAG sont le standard en matière d’accessibilité du contenu du Web, ce que nous, qui prônons le respect des standards du Web, ne devons jamais perdre de vue.
Tu parles, Élie, de la nécessité d’autres référentiels et méthodes. Si le cœur t’en dit, pourquoi pas ? Mais, ils ne doivent pas s’écarter du fait que les WCAG sont le standard. D’ailleurs, j’ai des doutes sur une telle nécessité, puisque des référentiels et méthodes existent déjà, qui sont des méthodes d’application des WCAG 2.0 (RGAA et Accessiweb, pour ne citer que ces deux-là) qui permettent de savoir plus concrètement ce qu’il faut faire pour être conforme aux WCAG.
Bref, quand, il y a bientôt deux ans, je me suis servi du référentiel Accessiweb 2.0 (à l’époque) pour un audit d’accessibilité d’une refonte de sites Web pour laquelle le client final souhaitait s’assurer d’une conformité au niveau AA des WCAG 2.0, j’estime ne pas avoir été en tort…
Mais enfin, ne jetez pas le bébé avec l’eau du bain, les amis. WCAG reste la base absolue, la référence. RGAA, Accessiweb sont des méthodes à conserver et à utiliser dans de très nombreux cas.
Mais arrêtons de considérer que viser puis prononcer la conformité à ces référentiels est l’alpha et l’omega de l’accessibilité. On doit maintenant faire mieux, et vite.
Autre chose :
Si je ne me trompe pas, cela fait 13 ans qu’on utilise les WCAG ou les méthodes d’évaluation dérivées pour analyser l’accessibilité des sites, pour essayer de les rendre conforme, pour prononcer leur conformité.
Je comprends que tes clients soient contents, mais le problème essentiel en matière d’accessibilité, ce ne sont ni tes clients ni les miens, mais les utilisateurs de leurs sites. Et de ce côté là, le bilan est nul ou presque. En France et ailleurs. Partout.
A force de planter des vis avec un marteau, on va bien finir par se dire que ça marcherait peut-être mieux avec un tournevis, non?
(et je m’inscris de ce pas au concours de la métaphore à la con)
« Je comprends que tes clients soient contents, mais le problème essentiel en matière d’accessibilité, ce ne sont ni tes clients ni les miens, mais les utilisateurs de leurs sites. Et de ce côté là, le bilan est nul ou presque. En France et ailleurs. Partout. »
Honnêtement je ne vois pas le rapport avec le sujet de la conformité, quant aux utilisateurs de mes clients laisse moi la liberté de juger si le bilan est nul ou pas, c’est mon métier.
« Mais arrêtons de considérer que viser puis prononcer la conformité à ces référentiels est l’alpha et l’omega de l’accessibilité. »
Sauf à être désagréable j’aimerais bien quand-même savoir qui à pu te raconter de telles fadaises, sérieusement tu à rencontrés des professionnels sérieux qui ont cette base de raisonnement ?. Et quand bien même, j’aimerais bien comprendre pourquoi à partir d’une telle approximation on aboutis au raisonnement qu’il faut abandonner la conformité.
Je me place plutôt dans le camps de ceux qui disent et qui travaillent durement à l’amélioration des processus liés à la gestion de la conformité WCAG.
Cela dit, à partir du moment où tu poses en préalable l’abandon de la conformité à WCAG, je ne vois plus, du coup, sur quoi discuter ni sur quoi travailler.
Par ailleurs, il faudrait pouvoir au moins démontrer que la conformité WCAG ne sert à rien (puisqu’il faut l’abandonner).
Moi j’aurais plutôt tendance à te proposer de discuter de l’amélioration des méthodes basées sur la gestion de la conformité WCAG.
C’est mon coté bourrin obstiné sans doute.
Après j’aimerais bien comprendre comment tu passes de « [RGAA et AccessiWeb] sont des méthodes à conserver et à utiliser dans de très nombreux cas. » méthodes fondées sur la conformité à WCAG à « Il faut abandonner la conformité à WCAG ».
JPV
Le bourrin, c’est évidemment moi, il faut bien le reconnaître, j’avais prévenu et j’ai trollé comme un cochon. Il est logique que tu sois monté sur tes 18 grands chevaux qui sont toujours prêts à démarrer 🙂
Il me semble que mes remarques seront largement insuffisantes pour influencer massivement le marché mondial de l’accessibilité, mais sait-on jamais, je ne perds pas espoir.
Arf, moi qui avait eu l’idée avec d’autres (malheureusement non suivie faute de temps) d’un site pour vulgariser le RGAA en montrant de bons exemples (plutôt qu’en disant uniquement « ne faites pas ci, ne faites pas ça »), je vois que l’idée est toujours d’actualité et le besoin est toujours présent.
C’est d’ailleurs un point qui me gêne en accessibilité/qualité : on parle beaucoup de ce qu’il ne faut pas faire, ou de gestion des risques… et si on parlait simplement de faire du travail de qualité ? C’est la même chose, à ceci près qu’un côté se fonde sur la peur et sur l’erreur, l’autre sur le plaisir du travail bien fait.
Typiquement, quand je m’amuse à appliquer/apprendre Opquast sur mon site personnel ou ailleurs, c’est pour avoir la satisfaction de faire un site et un travail de qualité, et pas pour gérer des peurs ou des risques.
C’est ce que j’essaie de faire passer quand j’explique à un stagiaire ou à un collègue : quand on fait un travail « de qualité », on fait au final « de la qualité » (et sans s’en rendre compte).
Point de vue de l’intégrateur/dev légèrement exagéré : en soi, les 9/10 des intés ne demandent pas mieux que de faire bien en accessibilité, mais en voyant des experts être flous ou s’enguirlander sur 5 méthodes là où il en a besoin d’une correcte… le premier réflexe est de se dire « ok, si les experts sont pas foutus de se mettre d’accord et de répondre à mon problème simplement, c’est gentil, mais j’ai 50 demandes urgentes à traiter ».
Point de vue de l’inté un peu plus ouvert d’esprit : ok, je comprends que c’est pas aussi arrêté que ça, mais j’ai 50 demandes à traiter, je fais quoi ? Soit on me donne les outils pour choisir la bonne, soit j’en choisis une arbitrairement.
Au final, plus ou moins la même chose. ^^
Bref, je lance un appel aux experts : trouvez un moyen de simplifier, l’accessibilité et la qualité, ça doit être agréable, cool, fun, hype, tendance, groovy, ce que vous voulez c’est vendredi.
ça vient, ça vient 😉
Héhé, ça je le sais bien que tu y travailles (avec d’autres). 🙂
Et peu importe le temps, c’est l’objectif qui est important.
C’est à mon sens la seule façon de « vendre » la qualité et l’accessibilité : dire « ok, vous ferez du travail de qualité ainsi ».
Cela ne me dérange pas de me taper des heures de lecture, de changer ma façon de bosser, de suivre des formations… du moment qu’au final, je trouve cette satisfaction. Et je pense pas être le seul à être ainsi, mes stagiaires/débutants/collègues sont contents quand ils se disent « pu**** j’ai fait un chouette truc là ! ».
Il suffit juste de savoir la susciter.
Je dois dire que je reste tout de même perplexe quand je lance opquast, c’est pas si « vulgarisé » que ca, et pourtant l’envie de m’y mettre moi aussi elle est là, mais quand on comprend pas, on comprend pas. Et là c’est blocage.
Dommage. Nico, j’y repensais ces temps-ci à ton idée de site de vulgarisation…
« l’accessibilité et la qualité, ça doit être agréable, cool, fun, hype, tendance, groovy, ce que vous voulez c’est vendredi. ».
Et même tous les jours, il faut le faire!
Ce que tu dis ne m’étonne pas, et me conforte dans le fait qu’il faut accompagner, et non contrarier, cette bonne volonté, quand on parle de la production de sites, qui sont surtout des urinoirs où les équipes vident leur vessie (« pisser du code », je l’ai pas inventée cette expression, mais j’aurais bien aimé).
Et puis il y a ce cas très particulier où l’on va parler création, innovation. Pour moi l’accessibilité est l’un des champs d’activité du Web qui permet le plus d’exprimer la créativité du développeur. Et non l’inverse comme on le lit trop souvent… Car en effet, résoudre des problèmes a priori extrêmes (lire un site sans voir ni entendre… gnnééé??) est ce qui pousse l’esprit dans ses retranchements. Je fais souvent un parallèle avec l’aviation: quoi de plus improbable pour l’être humain, ce mammifère dont le squelette a la densité du titane, que de voler dans les airs? Pourtant on le fait avec une désinvolture confondante, chaque jour, et par millions. L’attrait pour le vol aérien a été si fort que l’humanité en entier (ou presque) s’est mobilisée pour le rendre possible. Si on mettait un pouillème de cet enthousiasme au service de l’accessibilité, ce serait formidable… et à vrai dire, c’est un peu le cas. Tout ce qu’on peut faire aujourd’hui est assez étonnant (je reste encore scotché par la démo faite par Robin Christopherson, non-voyant, au dernier Forum Braillenet, de l’utilisation de son smartphone). Mais on est encore dans la situation des premiers aviateurs qui n’avaient pas de jolies pistes bitumées un peu partout, et des tours de contrôle, et des contrôleurs aériens qui parlent tous le même language, et des GPS et des ILS et tout le bazar…
En tous cas ton message est passé, espérons qu’il sera entendu!
Je rajoute ma modeste touche, un retour d’expérience. Dans ma pratique au quotidien, j’ai à rendre des applications métier accessibles. C’est un contexte d’utilisation fort différent des sites web (on y va souvent, pour bosser, on connait l’appli sur le bout des doigts…). Pour ce type d’applications, je dis haut et fort : « WCAG 2.0 et toutes les méthodes qui en découlent sont la base sans pour autant être la seule vérité ». Je m’explique, il est arrivé, en toute connaissance de cause de ne pas suivre les WCAG dans des cas bien particulier car cela ne servait pas mes utilisateurs.
Tout ça pour dire, que, oui, il faut des bonnes pratiques et des exemples pour que les dev sachent, sans se poser de question, ce qu’ils ont à faire. Mais la responsabilité de l’expert est de statuer et de prendre des décisions pour le bien de tous les utilisateurs et de pouvoir les justifier, c’est là qu’est sa valeur ajoutée et cela représente dans le fond que les cas les plus ardus, difficiles au niveau accessibilité !
L’innovation, la recherche de solutions originales doit être laissé aux seul experts !
On est parfaitement d’accord.
Si on veut faire un buffet en bois, on peut faire appel à un ébéniste de métier. Il va imaginer le buffet, choisir sa pièce de bois avec application, la découper et la sécher avec science, utiliser son expérience et son savoir-faire pour choisir les bonnes techniques, les bons outils, les bons gestes… Et on aura un buffet aux petits oignons. Mais il coûtera bonbon, et il sera… unique. Mon ébéniste est alors une ressource critique : sans lui je n’ai pas de buffet, en tous cas pas ce buffet-là. Avec lui j’ai ce buffet, mais je suis le seul à l’avoir.
Maintenant, si je veux un deuxième buffet, un dixième, un millionième… je ne vais pas pouvoir demander à mon ébéniste de les faire. Je vais être obligé d’utiliser des machines, des gens qui savent utiliser ces machines, mettre en place tout un tas de processus et de flux pour que tout cela tourne avec le moins possible d’interventions de mon ébéniste. Je vais donc lui demander d’utiliser son art pour m’aider sur les aspects « métier » de cette production industrielle, et pour le reste je vais m’en remettre à mon dispositif de production. Et plein de gens pourront avoir un buffet en bois, pas unique, pas chantourné à la main au goujon de 12 ; mais abordable, et qui est ce qu’on est en droit d’attendre de lui.
Avec l’accessibilité, on est encore dans une phase artisanale, avec quelques tentatives locales d’industrialisation, mais pas encore assez. Et comme tu le dis très justement, on a besoin des experts pour les choses ardues. Pour ce qui est du « tout-venant », de ce qui est déjà établi et validé, ne réinventons pas l’eau chaude : utilisons ce qui existe. On est l’un des rares domaines où les choses sont aussi bien standardisées et mutualisées (gratuitement en plus), utilisons cette chance pour passer à l’étape suivante.
le fait que les techniques ne soient pas normative n’a rien de nouveau. Elles ne peuvent pas l’être du fait du concept même d »accessibility supported » qui laisse à chaque organisation de définir en fonction de son environnement ce qui est utilisable ou non. Effectivement le manque de documentation en la matière est problématique et Shadi a notamment parlé d’un projet qui vise en partie à combler ce manque en mode crowdsourcing.
C’est exact, les Techniques sont vouées à évoluer et ne sont pas normatives. Ce qui me dérange dans cette phrase du draft c’est qu’hors contexte, de par sa formulation trop concise, elle offre le flanc à tout et n’importe quoi (mais ça peut se corriger, je vais soumettre un commentaire). On peut inventer des Techniques tout-à-fait recevables, mais comme le dit JPV dans son premier commentaire, ce n’est pas à la portée de n’importe qui. Si je suis dans la position de l’évaluateur, face à un développeur qui invente une « solution », sauf si elle est loufoque, j’ai un travail très délicat à effectuer, qui va prendre du temps et va in fine pénaliser le projet (si on se rend compte après une longue enquête que finalement, non, fallait pas). Dans le cas, possible mais peu probable, où ça met à jour une Technique inédite, tant mieux. Mais sinon, la réaction du responsable du projet sera, fort logiquement: « tu pouvais pas le dire avant?? ».
Vouloir s’appuyer sur les Techniques validées, et uniquement elles, c’est avant tout chercher à minimiser l’effort du projet en faveur de l’accessibilité, et limiter le risque de dégradation de cette accessibilité par des choix mal maitrisés.
Personnellement je ne trouve pas que le document et la citation en question soit problématique, on parle de la mise hors de contexte d’un bout de phrase dans un document qui va etre lu par 1% du web et dont la majorité des gens dans ces 1% sont des gens qui utilisent déjà les techniques comme outils d’évaluation.
Je ne dis pas qu’il ne faut pas utiliser les techniques. Je trouve juste ce morceau de phrase est totalement justifié dans le contexte du W3C qui pour l’heure ne défini pas ce qui est « accessibility supported » et ce qui ne l’est pas (y compris certaines techniques qui peuvent dans certains contexte ne pas être des solutions adaptées)