Comment une mission, a priori impossible, a complètement changé mon approche de l’accessibilité.
Voici l’accompagnement que j’ai du improviser, il y a quelques années, lorsqu’il a fallu aider un organe de presse sportive à réaliser son site dédié aux jeux paralympiques qui se devait, nécessairement, vu le sujet, d’être parfaitement accessible, pour ne pas passer à côté de son public. Soit appliquer la grosse centaine de règles du référentiel d’accessibilité, ce qui demande des compétences pointues.
Évidemment, leur équipe web, comme beaucoup, n’y connaissait rien. Et s’y prenait en plus… un mois seulement avant l’événement ! Et n’avait que peu de temps à consacrer à l’accessibilité, sur ces quatre petites semaines déjà bien denses, où tout restait à faire, depuis le design ex nihilo jusqu’à la mise en ligne.
Renoncer à l’objectif
Passé le premier réflexe « mission impossible » qui m’avait fait tomber les bras, il avait bien fallu chercher, non pas tant comment atteindre l’objectif, intenable, mais comment leur éviter d’aller dans le mur.
À commencer par lâcher du lest en abandonnant l’ambition de pleine conformité au référentiel d’accessibilité, ici irréaliste : trop difficile à atteindre en temps normal, elle était proprement décourageante. Or démotiver et/ou braquer les équipes en maintenant la barre trop haut aurait fait pire que mieux. Plutôt que d’imposer un quelconque niveau à atteindre, mieux vaut partir du niveau de l’équipe.
Alors, comment aider cette équipe en urgence ? Certainement pas par l’habituel audit correctif : ils n’auraient jamais le temps de corriger ! Il fallait intervenir avant. Mais pas le temps de former ni même de coder à quatre mains. Restait plus qu’à essayer de nourrir l’équipe de ressources opérationnelles, facilement et rapidement appropriables : exemples, tutos…
Aider à progresser
Ça tombait bien, les notices AcceDe Web venaient de paraître, qui proposent cela. J’ai donc utilisé les entrées de ces notices pour construire une grille d’accompagnement :
- En première colonne, la liste des tuto, avec lien vers ceux-ci, permet à chaque intervenant(e) de comprendre rapidement ce qui est attendu, le laissant libre d’estimer la difficulté pour lui-même, et de choisir, en libre-service, ce qui est faisable ou pas dans ce délai, et par quoi commencer. Ces notices ont en effet le mérite d’être autoportantes : aisément compréhensibles, elles ne nécessitent pas d’être explicitées avant usage. C’est donc l’équipe elle-même qui, rendue autonome, décide.
- Seule indication, superfétatoire, j’ai classé ces tutos en trois priorités pour les utilisateurs, en les formulant simplement : « ce qui doit être fait » pour éviter les points bloquants, « ce qui devrait être fait » pour lever les autres difficultés et « ce qui pourrait être fait » pour améliorer le confort.
- Enfin, j’ai reformulé l’objectif ainsi : « entre le début et la fin, je veux constater une progression ». Forte ou faible, peu importe. Les deux colonnes suivantes servent donc à consigner les « prises de température » : la première au début des développements, « dès qu’une page est produite, même inachevée », et la seconde une semaine avant ouverture officielle du site.
- Pour aller plus vite, j’ai simplifié la notation, binaire : c’est « OK » ou « NON ». Et il suffit d’un seul défaut pour « NON », l’idée étant d’indiquer à l’équipe où elle doit agir, pas d’être exhaustif, et compter sur l’intelligence : lorsqu’un type d’erreur est compris par le dev, il va logiquement la corriger dans toutes ses occurrences, ce d’autant plus s’il a bien factorisé son code. Il est donc inutile de lister exhaustivement toutes les occurrences (comme dans les audits de conformité, autrement plus laborieux et consécutivement épais).
Vous savez quoi ? Ça a marché. Étonnamment bien. Mieux que tout autre projet que j’avais connu, qui s’appuyait sur le RGAA ou plus anciennement AccessiWeb. Ce qui m’a naturellement conduit à délaisser ces référentiels, pour cette méthode qui, reconduite en d’autres contextes, a confirmé son efficacité.
Si le site mis en ligne n’était certes pas top, j’étais satisfaite d’avoir constaté une progression et l’équipe était contente d’avoir réussi à faire quelque chose de pas totalement mauvais. En plus d’avoir appris en faisant, sur le tas. Bref, nous avions fait de notre mieux.
Amélioration surprise
Ça aurait pu en rester là, mais belle surprise : ce sont les internautes qui ont pris le relai, dont une association d’aveugles et malvoyants. Constatant l’effort, réussissant à utiliser le site mis en ligne, ils et elles ont spontanément signalé les défauts qui les bloquaient encore ou qui les gênaient dans leur consultation. Si bien qu’il ne restait plus que ces quelques améliorations à faire, au cas par cas.
Nous n’avons jamais su si le site avait finalement atteint le niveau de conformité requis. Et ça n’avait plus la moindre importance. Puisque nous savions que les internautes concernés, utilisaient le site, avec leurs handicaps, avec satisfaction.
Apprentissage
Cette improbable réussite a définitivement remis en cause mon approche de l’accompagnement en accessibilité. Plutôt que de viser un niveau de conformité somme toute administratif, mieux vaut faire confiance aux humains à l’œuvre :
- partir de la réalité du projet (et non pas du niveau à atteindre),
- responsabiliser et autonomiser l’équipe (en l’outillant),
- la laisser décider (en connaissance de cause donc),
- et prendre en compte les retours des utilisateurices (évidemment).
À la réflexion, cela raisonne comme le premier principe du manifeste agile : « les individus et leurs interactions, de préférence aux processus et aux outils ». Et ce qui change tout, ce sont les notices AcceDe Web, opérationnelles et autosuffisantes, dont je ne saurai assez remercier l’existence.
Vos commentaires
1. Le 24 juillet 2020 à 07:38, par Sébastien Delorme
En réponse à : Rendre accessible en un mois seulement ?
Oh, j’étais passé totalement à côté de ce billet.
Ayant participé à la création et la rédaction d’AcceDe Web lorsque j’étais chez Atalan, je suis particulièrement touché par ce témoignage. C’est exactement pour ce type d’usage que nous avions créé ces notices et décidé de les publier sous une licence ouverte.
Merci pour ce précieux témoignage qui servira je l’espère à sensibiliser à une approche plus pragmatique et efficace de l’accessibilité.
2. Le 24 juillet 2020 à 08:40, par Julie Moynat
En réponse à : Rendre accessible en un mois seulement ?
Effectivement, dans un délai très court et, en plus, avec une équipe non formée à l’accessibilité, c’était mission impossible de se conformer au niveau AA du RGAA ou des WCAG même avec la meilleure volonté du monde.
C’est une très bonne approche, pour ce cas de figure, de faire de la priorisation et de se concentrer sur les points bloquants, majeurs puis mineurs et d’être dans l’idée de faire le maximum pour la sortie du site. Il aurait, bien sûr, été plus judicieux pour le projet de s’y prendre bien plus tôt, surtout quand la cible est les personnes handicapées – mais bon, c’est une autre histoire !
Quoiqu’il en soit, les notices AcceDe Web, sont effectivement un très bon outil d’apprentissage et c’est un choix très judicieux.
En revanche, la conclusion de ce retour d’expérience me gêne très fortement et me choque.
Certes, il n’était pas possible, dans le délai imparti, de réaliser un site pleinement conforme au niveau AA. Cependant, il ne me semble absolument pas normal d’attendre que les utilisateurs et utilisatrices remontent les problèmes d’accessibilité plutôt que de prendre les devants en faisant réaliser un audit indépendant pour relever les problèmes, tout en affichant le résultat sur le site en faisant en sorte que les anomalies soient corrigées ensuite.
Pourquoi toujours faire reposer cette charge sur les personnes handicapées ? Au quotidien, le monde entier leur fait comprendre qu’elles ne sont pas prioritaires, et elles galèrent à utiliser les sites web que les entreprises ont mal conçus (et je ne parle même pas de « la vie réelle » !). Sur ce projet, vous saviez le besoin d’accessibilité important et vous avez attendu que les gens vous remontent les bugs. On devrait être rémunéré pour ce travail. Mener des tests utilisateurices aurait déjà été une approche plus honnête.
Et ensuite, il n’y a plus eu de retour donc vous avez estimé que le site était suffisamment accessible ?
Comment être sûre que les gens n’avaient pas seulement la flemme de remonter les problèmes ? Ou ne réussissaient tout simplement pas à le faire ? Ou ne pouvaient pas connaître le problème ? Admettons qu’il y ait une image porteuse d’information avec alternative vide : une personne aveugle ne saurait même pas que cette image existe donc comment imaginer que le problème puisse être remonté par une personne concernée ?
Les règles WCAG ont été conçues pour que les besoins des utilisateurices en situation de handicap soient couverts. Elles ne sont pas sorties d’un chapeau au hasard et elles sont loin d’être déconnectées de la réalité. Elles sont certes perfectibles et c’est pour ça qu’elles continuent d’évoluer, comme toute chose.
D’ailleurs, un audit d’accessibilité permet aussi de remonter des incompréhensions des équipes de développement quand elles se sont auto-formées. Même si les notices AcceDe Web sont très claires, il peut arriver qu’elles soient comprises de travers ou pas lues jusqu’au bout.
Je ne comprends pas qu’on puisse se satisfaire de ce résultat, surtout pour ce genre de site orienté handicap. Il peut y avoir une première approche « pragmatique » : on fait ce qu’on peut dans le temps imparti mais la deuxième approche ne doit sûrement pas être « on attend de voir si les gens se plaignent ». On prend les devants, on fait faire un audit, on priorise à nouveau et on corrige en se faisant accompagner.
Bref, l’idée de départ était bonne mais la fin me déçoit énormément.
3. Le 24 juillet 2020 à 11:30, par Romy Têtue
En réponse à : Rendre accessible en un mois seulement ?
@Julie : euh… non, il n’est pas question de faire reposer la responsabilité de l’accessibilité sur les utilisateurs/trices ! Ce n’est pas ce que dit ce REX, au contraire, puisque leur contribution fut une surprise : elle n’était pas attendue/anticipée/prévue.
Face à si court délai, il est vain de considérer qu’il aurait fallu s’y prendre plus tôt (c’est trop tard), autrement, en prévoyant des tests d’utilisabilité, un audit ou même des correctifs (y’a plus le temps), ni de s’en référer aux WCAG (c’est disproportionné)… L’urgence l’emporte sur l’idéal. Pas d’autre choix que renoncer. Impossible de garantir l’accès à tous et toutes : il y aura des laissé-pour-compte. Dès lors, on ne peut se satisfaire que d’éviter le pire, de constater un progrès. C’est tout.
4. Le 25 juillet 2020 à 06:55, par Julie Moynat
En réponse à : Rendre accessible en un mois seulement ?
En commentaire, tu me réponds :
Mais dans l’article tu dis, et c’est l’un des points les plus problématiques :
Ces deux points sont contradictoires et, par ailleurs, je me demande comment il est possible d’arriver à la conclusion que les personnes concernées utilisent le site avec satisfaction puisque c’est impossible à mesurer vraiment.
Oui, ces retours utilisateurices étaient une surprise et c’est bien ce que je pointe du doigt. Ça ne devrait pas arriver. Les personnes handicapées visitant le site ne devraient pas avoir à dire aux organismes qui devraient avoir un site conforme aux règles d’accessibilité niveau AA qu’il ne l’est pas et pose des problèmes (voir pourquoi dans mon premier commentaire). C’est à l’organisme de s’enquérir de l’état de son site dès la mise en production avant qu’on lui en fasse part.
C’est ce qui s’est passé sur ce projet et c’est trop tard, certes, mais cet article généralise sans remettre ça en cause. Cette phrase a d’ailleurs été citée sur Twitter comme si elle était une vérité mais il ne peut y avoir de preuve.
Et puis, il y a ce paragraphe :
Tu parles de ta méthode sur un projet comme si elle était meilleure que suivre le RGAA ou les WCAG pour obtenir un site accessible à tous et toutes. Comme si le RGAA ou les WCAG étaient à côté de leurs pompes.
De plus, tu nous parles d’une expérience sur un projet mais tu dis que tu appliques ça à tous les projets et tu encourages les autres à faire de même.
Sauf que si tu fonctionnes uniquement avec les notices AccessiWeb comme dit dans l’article et sans jamais faire d’audit ; je ne vois pas comment tu mesures l’efficacité de cette méthode. Les audits restent essentiels pour savoir où on en est et vérifier qu’on n’a pas fait de bêtise ou compris de travers. Et, pour les audits, il y a différentes méthodes selon les besoins comme je l’ai expliqué lors de ma conférence à Paris Web. On s’adapte. Et je ne parle même pas de niveau de conformité mais de savoir quels sont les critères qui ne sont pas conformes afin de pouvoir corriger.
C’est pour ça que je dis que la fin de cet article me choque et est problématique.
Alors peut-être qu’il manque juste une partie où tu expliquerais que tu laisses des agences externes faire les audits car tu ne fais plus ça dans ton rôle ; je ne sais pas. Mais je ne comprends pas pourquoi laisser entendre que les audits ne servent à rien.
WCAG essaie de couvrir un maximum de handicaps. C’est pas au petit bonheur la chance.
Je suis désolée, mais sur un sujet aussi important, complexe et méconnu, on ne peut pas faire confiance les yeux fermés aux équipes. Il faut vérifier que c’est bien fait. Je le vois au quotidien dans mon travail.
5. Le 28 juillet 2020 à 09:32, par Romy Têtue
En réponse à : Rendre accessible en un mois seulement ?
Je témoigne ici d’un projet où il n’y a pas le temps suffisant pour bien faire, encore moins pour un audit et j’ai l’impression que tu réponds que c’est scandaleux de n’en avoir pas fait… c’est un dialogue de sourdes ! Du coup, ça me pose question : aurait-il mieux valu ne rien faire du tout ? Vaut-il mieux se taire plutôt que témoigner d’une expérience partielle (sans audit mais étonnement pas complètement foireuse, contre toute attente) ?
Quand on part de si loin et avec si peu de temps, WCAG/RGAA sont totalement inadaptés. Oui, c’est à côté de la plaque dans un tel contexte. Le sujet de ce REX est donc comment faire sans ? Que faire quand l’approche idéale n’est pas déployable ? C’est un vrai problème, puisque ce contexte insuffisant est le plus courant. Puisque ce retour d’expérience n’est pas satisfaisant, qu’aurait-il valu mieux faire ?
6. Le 28 juillet 2020 à 21:43, par Nico
En réponse à : Rendre accessible en un mois seulement ?
C’est là le nœud du problème. Même avec des envies et besoins d’accessibilité, y a absolument PAS les moyens, ni temporels ni financiers. J’ai vécu ça sur bon nombre de projets aussi, la somme de taf à abattre pour mettre en place WCAG/RGAA est vouée à l’échec, non pas que ces méthodes soient nulles, mais juste impossibles dans ces cas (t’as 3 semaines pour shipper, il te faut des mois pour amener les outils et les gens à maturité, produire, etc. on fait quoi ?).
A un moment, tu finis par passer en tactique guérilla, quand tu sais que tu n’as aucune prise, pas le temps de faire de la chirurgie, c’est à la guerre comme à la guerre : à l’impossible personne n’est tenu, alors on fonce, on priorise, on déformalise, on fait au mieux.
Perso, face à ces projets, j’avais choisi l’angle des composants accessibles et des templates aussi accessibles que possible : c’étaient des points toujours défaillants, donc au moins je savais qu’ils ne seraient pas parfaits, mais toujours mieux que rien. Autant taper là où j’avais le maximum d’impact. Et transmettre de la connaissance autant que possible.
7. Le 29 juillet 2020 à 06:16, par Luc
En réponse à : Rendre accessible en un mois seulement ?
Haaaaan… J’ai vu passer cet article ces derniers jours en pensant qu’il était tout frais, mais en fait pas du tout. Mais mieux vaut tard que jamais !
Merci pour ce retour d’expérience hyper intéressant. C’est très inspirant pour les gens qui évoluent la plupart du temps dans un contexte hostile à l’accessibilité, parce que pas le temps et pas de formation initiale des personnes intervenantes.
Jusqu’à présent, je fonctionne plutôt comme Nico. Je pousse l’utilisation de composants dont le niveau d’accessibilité est prouvé pour assurer une base. Et je profite de la moindre occasion pour éduquer les gens et leur expliquer pourquoi faire comme ci et pas comme ça. Mais c’est un long chemin semé d’embuches et les « sorties de route » dès que je tourne le dos sont encore fréquentes.
Bref, je trouve cette expérience vraiment intéressante et ça me donne envie de faire des tests dans ce sens, pour voir comment ça prend. Merci ! :-3
Répondre à cet article
Suivre les commentaires :
| 