En gestion de projet, on ne laisse pas l’accessibilité dans un coin

Laetitia Sahuet 17 décembre 2021 ~ 23 minutes

Connaissez-vous la différence entre une bûche de Noël et… une très bonne bûche de Noël ?

En réalité il n’y a pas vraiment de secret, les facteurs clés de succès d’un bon gâteau vont tourner autour de ces trois axes :

La qualité des ingrédients sélectionnés pour la recette et pour ça, il va falloir dûment choisir ses produits tout en respectant le budget qui a été fixé en amont.
Le respect des étapes de la recette. Croyez-moi, confondre le sucre avec le sel ne fait pas bon ménage… ni même de monter le thermostat du four à 220° pour que ça cuise plus vite alors que la recette indique 160°.
L’amour mis tout au long du processus de fabrication.

En pâtisserie l’improvisation n’a pas sa place. En gestion de projet c’est pareil.

Après ce gourmand parallèle, laissez-moi vous raconter mon histoire.

Le commencement

J’ai commencé ma carrière dans le Web en tant que cheffe de projet. En agence tout d’abord, avant d’intégrer une grande entreprise dans laquelle j’intervenais en tant que consultante en gestion de projet.

À l’époque, je n’avais pas entendu parler d’accessibilité. Ne riez pas, ceci n’est malheureusement pas une blague. Que ce soit en école supérieure ou lors de mes premières expériences professionnelles, je gérais des projets de refonte ou de création de site web sans jamais que le sujet de l’accessibilité ne soit évoqué.

Alors la première fois que j’ai entendu parler d’accessibilité, j’ai commencé par avoir peur. Vous connaissez ce petit coup de chaud déglacé à l’anxiété ? C’était moi (sans exagération aucune bien sûr).

Plusieurs questions se sont posées :

« Ok, mais niveau budget comment allons-nous faire ? »
« Et les équipes sont-elles formées ? »
« Il faut que nous soyons accompagnés ! Mais par quel prestataire ? »
« Et comment savoir que notre travail répond vraiment aux exigences d’accessibilité web ? »
« Et le planning ? Encore plus efficace que le savon qu’on ajouterait sur la piste pour faire un ventriglisse, il va glisser et on ne sera jamais prêt pour la sortie du site en janvier ! »

Élaborer un plan d’action

Ni une ni deux, il fallait mettre en place un plan d’action et c’est ce que nous avons fait avec ma direction de l’époque, aidées du service juridique.

C’est un premier point clé pour la prise en compte de l’accessibilité dans un projet web : la direction et son implication dans le projet. On ne va pas se mentir, vous allez difficilement pouvoir embarquer avec vous toute la chaîne de production d’un site web, si la direction ne vous suit pas.

Car oui, l’accessibilité doit être prise en compte à toutes les étapes d’un projet, de la rédaction du cahier des charges à la maintenance du site web.

Alors vous allez me dire « Ça en fait du monde ! ». Élémentaire, mon cher Watson.

La formation

Pour pouvoir embarquer tout le monde, il faut commencer par sensibiliser et former les équipes. Car comme un sachet de thé, les saveurs vont se diffuser dans une eau à bonne température.

Nous avons alors fait appel à des prestataires externes, à des experts accessibilité qui ont commencé par sensibiliser l’ensemble des équipes puis qui ont délivré des formations adaptées aux différents métiers. Former un designer au développement front-end accessible ne ferait pas sens, tout comme former un contributeur au design d’interface accessible serait intéressant mais il risque de rester sur le bord de la route et clairement ce n’est pas ce que nous voulons.

Au total nous avons mis en place sept types de formations. La première étant la formation de sensibilisation. Celle-ci s’adressait à tous les publics, de la direction aux chefs de projet, en passant par les designers, les développeurs, les testeurs, les contributeurs, etc. L’objectif était que toutes les personnes du service IT soient sensibilisées, mais également les personnes du service marketing et communication. Cela n’est pas un hasard, il serait difficile de justifier la ligne budgétaire liée à l’accessibilité auprès des principales personnes demandant de développer une page web pour une opération de communication, si elles n’ont pas connaissance du sujet. Dans cette formation plusieurs points étaient abordés, que ce soit les enjeux humains, la législation ou les risques juridiques et financiers.

Les formations suivantes étaient adaptées aux différents métiers. Nous avions :

une formation dédiée aux chefs de produit et chefs de projet ;
une formation pour les designers ;
une formation dédiée aux développeurs ;
une formation pour les testeurs / QA ;
une formation pour les rédacteurs et les contributeurs ;
une formation élaborée spécifiquement pour le service juridique.

Il nous aura fallu près de deux mois avant que tout ce beau monde soit formé. Ce n’était pas une mince affaire, mais n’ayez crainte, si vous êtes bien accompagné il n’y aura pas d’embûche.

Alors vous allez me dire, à juste titre « Cette démarche est très bien, mais comment s’assurer qu’une fois les formations passées l’accessibilité est réellement prise en compte ? », et puis « En cas de turnover c’est un retour à la case départ, et nous n’allons pas avoir le budget pour former tous les nouveaux collaborateurs dès leur arrivées ! » Je comprends ces interrogations, je me les suis moi même posées. Voici trois éléments de réponse :

désigner des référents accessibilité au sein des équipes ;
être accompagné ;
être outillé.

Voyons cela de plus près.

L’accessibilité, sujet du quotidien

Les référents

Après chaque formation, nous (les experts accessibilité et moi) demandions si des personnes seraient intéressées pour devenir référents accessibilité, ou garant de l’accessibilité sur son sujet. Ce que nous voulions c’est avoir un référent par équipe qui pourrait, entre autres :

nous remonter tout point bloquant ;
indiquer les besoins d’amélioration d’un service ou d’une fonctionnalité ;
s’assurer que l’accessibilité est prise en compte dans les nouveaux projets ;
être le point de contact privilégié des sujets d’accessibilité de son équipe ;
nous communiquer la liste des nouveaux arrivants dans les équipes et, avant même qu’ils ne soient formés, les renseigner sur le projet accessibilité de façon synthétique.

Ici j’en profite pour rappeler que je fais référence à la mise en place d’une stratégie de déploiement de l’accessibilité numérique dans un grand groupe. Il aurait été compliqué de couvrir tous les sujets web qui transitaient sans référents accessibilité. Et puis nous n’aurions certainement pas été informés de tous les projets. De plus, cela permettait d’avoir connaissance des nouveaux collaborateurs et pouvoir, lorsque cela était nécessaire, programmer de nouvelles sessions de formation.

Je ne peux donc que vous recommander, lectrices et lecteurs, d’identifier des personnes éligibles au poste de référent accessibilité au sein de votre entreprise, ou bien d’aller défendre cette idée auprès de votre direction. J’y reviendrai plus tard mais vous avez sûrement entendu parler de « coûts de non qualité », et identifier des référents est un moyen précieux de s’éviter ce type de coûts en fin de projet.

Bref, in référent accessibilité we trust.

Accompagnement et outiller

Vous l’avez sûrement remarqué, je parle à la première personne du pluriel. J’utilise le « nous » sans même vous les avoir présentés, c’est assez impoli n’est-ce pas ? Alors laissez-moi vous présenter les experts accessibilité avec qui j’ai travaillé tout au long de cette mission.

La direction et le service juridique, sensibles au sujet de l’accessibilité numérique, ont alloué un budget au recrutement de deux consultants externes experts en accessibilité pour nous accompagner. Ce sont ces deux experts qui ont délivré les formations dont je vous ai parlé précédemment, et c’est également eux qui ont accompagné les équipes au quotidien pour répondre à toutes les interrogations liées à l’accessibilité.

Comme le capitaine lors d’une expédition maritime, ils nous ont permis de prendre la bonne direction au moment où nous étions tous un peu perdus concernant la stratégie à déployer.

Ils ont alors pris part à différents chantiers dont les principaux étaient :

la mise en place d’un design system accessible ;
la création d’une bibliothèque de composants accessibles ;
la rédaction de checklists accessibilité à destination des chefs de projet, chefs de produit et également testeurs / QA ;
la rédaction de spécifications techniques détaillées, mais également de documents intitulés « À faire vs À ne pas faire », ludiques et pratiques ;
L’installation sur les postes informatiques des designers et développeurs d’outils (je fais référence à des outils de test des ratios de contraste, des outils de tests automatisés) ;
la mise en place d’une liste de questions à poser lors des entretiens d’embauche pour s’assurer un niveau minimum de connaissance du sujet des futurs collaborateurs ;

Vous l’aurez compris, bien qu’une grande partie du travail consistait à accompagner les équipes sur le terrain, il y avait aussi tous les à‑cotés qui font qu’un tel projet peut se déployer, à l’instant T mais de manière pérenne également.

Faisons le point

Les principaux ingrédients pour la mise en place de l’accessibilité numérique au sein d’une organisation sont donc :

200 grammes d’engagement de la direction ;
150 grammes de sessions de sensibilisation et de formations adaptées ;
3 cuillères à soupe de référents accessibilité ;
150 grammes d’accompagnement quotidien sur le terrain ;
100 grammes de mise en place d’outils (design system accessible, bibliothèque de composants, spécifications techniques, etc.) ;
une noix de beurre pour le moule.

Préchauffez le four à 180°, mélangez tous les ingrédients et enfournez jusqu’à atteindre un taux de conformité WCAG (Web Content Accessibility Guidelines) 2.1 niveau AA de 100 % (bon, il va falloir bosser un peu quand même on ne va pas se mentir). Après cuisson, maintenir au four pour que le tout ne refroidisse pas.

Si vous réunissez tous ces ingrédients, le projet sera sur la bonne voie. Maintenant, voyons comment cela s’articule au quotidien dans un projet de création, de refonte, ou d’évolution d’un site web.

Prendre en compte l’accessibilité dans un projet web

Les prestataires externes

Commençons par le commencement. Il n’y a pas de site web sans cahier des charges. C’est le premier point sur lequel je souhaite mettre l’accent.

Il est primordial d’intégrer l’accessibilité comme étant une exigence à respecter dans votre cahier des charges. Ce doit être un pré-requis si vous travaillez avec des prestataires externes, qu’il s’agisse de livraison de maquettes graphiques, de composants tiers spécifiques, de vidéos pour lesquelles il faudra fournir les sous-titres, l’audiodescription, les alternatives textuelles, etc. Veillez à indiquer le référentiel (exemple WCAG 2.1 niveau AA) et le niveau de conformité attendu. Rappelez aussi qu’en cas d’audit et de non respect de cette exigence le prestataire doit s’engager à prendre en charge les correctifs durant toute la période de garantie après livraison du site web.

De plus, accompagné des experts accessibilité et du service juridique, nous avons travaillé sur la rédaction d’une clause qui était ajoutée à tous les documents contractuels avec les prestataires externes. Croyez-moi, en cas de mauvaise surprise, elle est très confortable et moelleuse pour se reposer dessus.

Cette clause était valable aussi bien pour les prestataires en charge de la refonte globale d’un site, d’une page ou même d’une fonctionnalité. Si cette clause vous intéresse, retrouvez-la à la fin de cet article.

Comme indiqué précédemment, lors de la création de votre site web, il va falloir s’assurer que toute la chaîne de production prend en considération le sujet. Il va alors être primordial de poser des jalons à toutes les étapes pour s’assurer qu’il n’y a pas de loupé. Et c’est ici que je reviens faire un focus sur les coûts de non-qualité. Ce sont ces coûts qui résultent d’un dysfonctionnement sur la chaîne de production et dont on ne se rend compte que 10 jours avant, voir après, la mise en production du site web. Vous voyez de quoi je parle ? Pour vous donner un exemple, il sera forcément plus coûteux de revoir la charge graphique d’un site web à 10 jours de sa mise en production plutôt qu’au moment où celle-ci est créée et validée. Cela implique de ré-engager des coûts supplémentaires, que ce soit auprès des designers, des chefs de produit ou de projet, des développeurs et des testeurs. Voyez ces jalons comme un garde-fou permettant d’éviter de tomber dans le précipice.

Pour poser ces jalons, il va donc falloir intégrer l’accessibilité dans vos plannings.

La planification

Comment parler de gestion de projet web sans parler de planning ? Et comment s’assurer de la prise en compte de l’accessibilité sans poser des jalons ?

Puisque toute la chaîne de production est concernée, il faudra alors planifier des phases de recette à toutes les étapes clés du projet (phase de conception, développement, contribution, recette).

Si vous fonctionnez par lots, ou qu’il vous est possible d’établir un planning dont le niveau de granularité est élevé, intégrer des phases de revue de l’accessibilité dès que cela vous semble pertinent.

Par exemple, intégrez une phase de validation d’un premier lot de maquettes fonctionnelles avant la livraison finale. Également, prévoyez une phase de validation de la charte graphique. Prévoyez du temps de relecture et de contribution des spécifications fonctionnelles et techniques par l’expert accessibilité, etc.

Les instances de gouvernance telle que le comité opérationnel du projet (COOP) vous permettront de garder un œil sur la bonne avancée des travaux et vous assurer que ces phases de validation ont bien eu lieu. Selon l’envergure du projet, il était possible de prévoir un COOP par semaine.

Aussi, si vous travaillez en agile, intégrer l’accessibilité dans la liste des critères de votre definition of done. Ainsi, si l’accessibilité n’est pas vérifiée c’est un No Go à la mise en production (et on évite de fait les coûts de non qualité). Mieux vaut se rendre compte à temps que nous avons oublié d’ajouter notre crème liquide à notre ganache montée sans quoi le résultat attendu ne sera pas à la hauteur des espérances.

La conception

Vous avez sûrement déjà vu de célèbres cheffes pâtissières et chefs pâtissiers au moment d’imaginer un gâteau, faire un croquis qui en détaille la composition. Ils renseignent la forme, le type de biscuit, l’insert. Les maquettes fonctionnelles de notre site web sont un peu nos croquis à nous, elles représentent le squelette du site web.

Prévoir une phase de revue de ces maquettes, ou prototypes, est indispensable. Cela permettra d’écarter tout manquement qui pourrait venir ensuite impacter le reste de la chaîne de production.

Pour citer des exemples, il peut s’agir de veiller à ce qu’il y ait bien deux moyens de navigation possible, s’assurer que les carrousels ont des boutons pour naviguer en vue mobile, que les champs des formulaires ont des étiquettes, etc. Cette étape permettra aussi d’anticiper d’éventuelles difficultés au moment de la phase de développement.

Les maquettes graphiques devront également faire l’objet d’une vérification de l’accessibilité. Que ce soit les ratios de contraste des couleurs, s’assurer que l’information n’est pas transmise uniquement par la couleur, etc. C’est une étape indispensable avant de passer à la phase de développement. N’hésitez pas, en tant que chef de projet ou chef de produit à rappeler aux designers de prendre en compte l’accessibilité.

Aussi, des ateliers avec les experts accessibilité et les designers étaient régulièrement prévus. Nous faisions ça autour d’un petit-déjeuner et c’était l’occasion de, non seulement passer un moment convivial et ludique, mais aussi de décortiquer des maquettes graphiques produites et voir ensemble quels étaient les points à améliorer. Il s’agissait d’un bon format puisque ces ateliers contribuaient à la montée en compétence des designers.

Investir une heure de son temps et de ses équipes dans ce type d’atelier peut être un frein d’un point de vue budgétaire, mais sur le long terme c’est un vrai gain. Nous pouvions constater que les points d’amélioration évoqués lors de ces ateliers étaient rarement reproduits sur les futures maquettes.

Le développement

Avant toute chose, il sera indispensable de prévoir une phase de rédaction des spécifications techniques. Que ce soit dans un document détaillé, ou, si vous travaillez en agile, dans des tickets liés à vos US (users stories). Rédiger des recommandations techniques pour l’implémentation des composants est un indispensable à la réussite du projet. Accompagner les équipes techniques aussi. Des points d’échange étaient organisés à la demande des développeurs pour lever toute ambiguïté et zones d’ombre.

Tout au long de cette phase de développement, les experts accessibilité accompagnaient les équipes avant la validation finale.

Autre point, nous demandions que les développeurs s’assurent que les erreurs remontées par des outils de tests automatiques soient corrigées (les erreurs remontées par axe par exemple).

Lors des formations dédiées aux développeurs, un certain nombre d’outils étaient donnés et nous faisions attention à ce qu’ils soient bien utilisés. Je ne vous cache pas que le pli peut parfois être dur à prendre, mais une fois que c’est bon, cela fait gagner du temps à tout le monde, experts accessibilité et développeurs compris.

La recette

L’envie de faire le parallèle avec la pâtisserie est trop forte, vous vous en doutez bien. Alors allons‑y. Ici la recette c’est un peu la lame de couteau qu’on plante dans un gâteau en fin de cuisson. Si la lame ressort propre alors ça signifie qu’il est cuit.

Dans le web, notre lame propre c’est lorsqu’il n’y a plus d’anomalie majeure et critique et qu’il nous est possible de donner le Go pour la mise en production.

Les testeurs et QA étaient formés à l’accessibilité, ils savaient prendre en main l’inspecteur de code, et nous avions mis en place une liste de tests à dérouler avant chaque mise en production. Il s’agissait d’une dizaine de tests permettant d’assurer un niveau de qualité minimum. Alors bien sûr, ces tests ne couvraient pas l’ensemble des critères du référentiel, toutefois nous avons pu constater l’efficacité de leur intégration dans nos processus de production.

Tous les tickets liés à l’accessibilité du site étaient flagués « Accessibilité », et, je vais y revenir, mais cela nous permettait d’avoir un contrôle sur le nombre de tickets embarqués par sprint pour les projets dont la méthodologie était en agile.

La contribution

Vous pensiez avoir terminé ? Que nenni ! Passons maintenant à la contribution, et son rôle est plus important que celui d’un glaçage miroir.

Comme pour chacune des étapes précédentes, les contributeurs étaient formés à l’accessibilité. Nous avions, en plus des formations, mis en place des guides d’utilisation des CMS (content management system) ou système de gestion de contenu des sites web.

Ces guides expliquaient comment mettre en forme son contenu de manière accessible, par exemple, comment utiliser une liste à puces ou liste ordonnée sans avoir à ajouter « – » en début de phrase ou encore comment différencier un retour chariot dans un même paragraphe d’un nouveau paragraphe.

Nous expliquions comment rendre un intitulé de lien accessible ou pour les liens vers un fichier (doc, pdf, etc.) nous évoquions le fait d’ajouter le nom, le format et la taille du fichier en question.

Pour les images, nous expliquions comment distinguer une image décorative d’une image porteuse d’information et de fait, comment renseigner ou non son alternative textuelle.

Rédiger des contenus accessibles est un vrai sujet, tant dans le fond que dans la forme, vous devez donc y porter une attention toute particulière.

L’audit

Bon alors maintenant que nous avons tout bien fait, comment savoir si notre site est conforme ou ne l’est pas ?

Pour l’évaluer, il faudra forcément passer par un audit de conformité. Pour cela il va falloir établir l’échantillon des pages représentatives du site. Ce sont ces pages qui seront auditées.

L’échantillon se compose d’une liste de pages obligatoires (page d’accueil, page contact, page des mentions légales, page accessibilité, page du plan du site, page d’aide, page d’authentification) et de page représentatives des principaux contenus de votre site web.

L’audit peut être lancé une fois l’échantillon établi et l’environnement défini (vous pouvez lancer un audit sur votre environnement de de pré-production par exemple).

Il y a deux sortes d’audits :

les audits simples, livrés avec une grille de conformité faisant état des critères du référentiel (conforme, non conforme, non applicable) avec listing des anomalies sans solutions apportées ;
les audits détaillés livrés, en plus de la grille de conformité, avec un rapport d’audit faisant état des anomalies relevées, classées par impact utilisateur (bloquant, majeur, mineur) et pour lesquelles une proposition de solution est donnée.

Nous faisions toujours des audits détaillés. Cela nous permettait de connaître la volumétrie des erreurs à traiter que nous découpions en ticket dans notre outil de ticketing (nous utilisions JIRA).

Le fait que les erreurs disposent d’un niveau d’impact utilisateur nous permettait de prioriser les correctifs. Évidemment, la règle était de traiter les erreurs bloquantes avant les erreurs mineures.

Je ne vais pas rentrer dans plus de détails ici mais l’audit est également indispensable pour établir votre déclaration d’accessibilité qui doit paraître sur votre site web. Pour en savoir plus, rendez-vous sur la page du « Référentiel général d’amélioration de l’accessibilité – RGAA Version 4.1 ».

À ce stade, vous connaissez le niveau de conformité de votre site web, vous savez combien d’erreurs vous avez à corriger pour vous améliorer et vous savez combien d’erreurs sont bloquantes, majeures et mineures. Y’a plus qu’à ! Une fois tous les tickets corrigés, un contre-audit sera utile pour connaître le nouveau taux de conformité de votre site web.

Les KPIs

Les KPIs, ou indicateurs clés de performance, sont les véritables stars de toutes les organisations, il est difficile de passer à côté et l’accessibilité n’y fait pas exception.

Alors voyons quelles étaient les indicateurs que nous suivions avec attention :

Le taux de conformité : lorsque nous l’avions, le taux de conformité était notre principal indicateur. Mais n’oublions pas que c’est une photo à l’instant T de la conformité du site. Plus il vit, plus il va être amené à varier. Une nouvelle page, une nouvelle fonctionnalité vont fortement l’impacter. Pour connaître le nouveau taux, il faudra lancer un nouvel audit.
Le nombre de tickets traités par sprint : cet indicateur permet aussi d’évaluer la prise en compte de l’accessibilité dans le projet. Si tous les tickets flagués « accessibilité » restent sur le banc de touche, il y a fort à parier qu’une piqûre de rappel sur l’importance de l’accessibilité est nécessaire. Chaque fin de semaine, je faisais un état, par projet, du nombre de tickets traités vs le nombre de tickets accessibilité global que je communiquais à la direction.
Les tests utilisateurs : mettre en place des tests utilisateurs pour évaluer l’accessibilité de votre site web est indispensable. Cela permet de mesurer et d’identifier les problèmes que peuvent rencontrer les utilisateurs. Nous passions par une entreprise spécialisée dans les tests utilisateurs. Avec elle nous définissions les scénarios de tests (parcours, durée, actions) à exécuter. Tous les problèmes remontés dans ces tests étaient alors transformés en tickets qui allaient être traités en priorité.

En résumé, il vous faudra suivre le taux de conformité, connaître le nombre de ticket accessibilité que vous avez dans vos backlogs et suivre leur traitement, vérifier l’accessibilité de vos sites et applications via la mise en place de tests utilisateur.

Maintenir l’accessibilité

L’accessibilité, vous l’avez compris, est un sujet de tous les jours, un sujet à ne pas laisser dans un coin.

Maintenir l’accessibilité de vos sites web et applications implique de la prendre en compte après la mise en production. Lors du développement d’une nouvelle fonctionnalité par exemple, ou lors de la mise en place d’un nouveau service. Toutes les évolutions devront être validées en incluant parmi les critères d’exigences l’accessibilité. Elle est donc à inclure dans vos processus de tous les jours.

Et rappelez-vous, l’accessibilité, comme en pâtisserie, plus on pratique et plus on s’améliore.

Annexe

Comme promis, ci-dessous la clause accessibilité dont je vous parlais dans la partie « Les prestataires externes » :

Accessibilité web

L’initiative internationale pour l’accessibilité du Web (WAI) définit l’accessibilité numérique comme suit :

« L’accessibilité du Web signifie que les personnes en situation de handicap peuvent utiliser le Web. Plus précisément qu’elles peuvent percevoir, comprendre, naviguer et interagir avec le Web, et qu’elles peuvent contribuer sur le Web. L’accessibilité du Web bénéficie aussi à d’autres, notamment les personnes âgées dont les capacités changent avec l’âge.

L’accessibilité du Web comprend tous les handicaps qui affectent l’accès au Web, ce qui inclut les handicaps visuels, auditifs, physiques, de paroles, cognitives et neurologiques. » Introduction à l’accessibilité du Web (anglais)

« Nom de l’entreprise » est particulièrement soucieux de l’accessibilité numérique de ses sites internet.

Nous considérons que toutes les personnes, quelles que soient leurs aptitudes physiques ou mentales, leur matériel ou leurs usages sur le Web sont en droit de bénéficier du meilleur service que nous puissions leur offrir.

Pour mener à bien cet engagement, nos partenaires et prestataires doivent respecter les recommandations internationales pour l’accessibilité des contenus Web (WCAG 2.1 – En) au niveau AA. Les livrables (maquettes graphiques et prototypes ainsi que le code) devront impérativement respecter ces recommandations et ce niveau d’exigence.