L'accessibilité numérique : comment l'atteindre ?

0:15 Bienvenue pour ce meet-up. Je m'appelle Emmanuel, je suis développeur tout d'abord, avec une forte appétence sur le domaine d'aujourd'hui. Donc un grand merci pour l'invitation. Aujourd'hui, on va parler d'accessibilité avec trois intervenantes, Marion, Mélanie et Romy. Je les laisserai se présenter. Juste après. Avant de rentrer directement dans le sujet, on a décidé de faire un petit jeu, un petit question-réponse rapide. N'hésitez pas à mettre dans le chat les réponses, donc c'est des vrais ou faux, pour avoir un petit peu d'animation et voir les réponses sélectionnées. La première question, l'accessibilité numérique, c'est pour les personnes handicapées. Est-ce que c'est vrai ou est-ce que c'est faux? N'hésitez pas à mettre votre réponse dans le Rémi dit c'est faux, Alain dit c'est faux. Pour l'instant, on n'a que des faux. Et en effet, pas seulement.

1:18 L'accessibilité numérique, c'est pour toutes les personnes en situation de handicap. Parce qu'en effet, il y a par exemple Sarah qui se déplace en fauteuil roulant, n'a aucun... un problème pour naviguer sur un service numérique, contrairement à Chloé, Radka ou Olivier, qui visuellement, on ne pourrait pas penser qu'ils ont un handicap, mais ont des difficultés en tout cas pour naviguer sur certains services numériques, parce que par exemple, Chloé a eu une tendinite parce qu'il y a eu un accident, Radka ne parle pas français, donc il comprend mieux un service numérique avec du texte court, ou Olivier qui est daltonien, donc il ne détecte pas trop les couleurs. Deuxième question, ne vous inquiétez pas, j'en ai que trois. Deuxième question, deuxième affirmation plutôt, 8,5 des personnes ont besoin d'accessibilité numérique. Est-ce que c'est vrai ou faux? Faux. Rémi, toujours le premier. Faux, faux, faux.

2:18 Tout le monde dit faux. En effet, 20 à 40% des utilisateurs et utilisatrices ont un accès difficile, partiel ou impossible aux informations et services en ligne. Un handicap peut être permanent, situationnel ou temporaire. À un moment de notre vie, on sera... Quasiment tous, dans une situation de handicap à un moment donné. C'est pour ça que ce chiffre est beaucoup plus important que le 8,5 mentionné dans l'affirmation. Dernière question pour cette introduction. Vrai ou faux, vous avez compris le principe, il faut anticiper l'ajout de fonctionnalités d'accessibilité à un produit. Par exemple ici, on a décidé d'ajouter un menu accessibilité pour changer le contraste. Est-ce que c'est vrai ou faux? Ah, là, il y a plus de vrai et de faux. Là, il y a un doute. Et la réponse est faux. L'ajout de fonctionnalités peut éventuellement améliorer l'accessibilité d'un site web, mais ce n'est pas ce qu'on rencontre dans la vie de tous les jours.

3:22 Le plus souvent, l'ajout de fonctionnalités dégrade le niveau d'accessibilité d'un service numérique. L'accessibilité se pense dès les premières années de vie, les premières étapes de vie d'un service numérique, dès la conception, dès la réflexion du projet. Donc, ce n'est pas en ajoutant des fonctionnalités supplémentaires qu'un service va magiquement devenir... accessible. Donc on va parler de tout ça pendant cette 55 minutes restantes avec trois intervenantes. On va commencer avec Marion. Marion, si tu veux bien venir sur scène. Bonjour, bonjour Emmanuel. Tu vas bien? Bonjour à tous. Très bien, merci. Je te laisse partager ton écran. Bien sûr. En attendant, n'hésitez pas à poser des questions. Il y a à votre droite un onglet Q&A. Et on prendra les questions soit après les trois interventions, soit à la toute fin, en fonction des questions. Donc, n'hésitez pas, je ferai.

4:23 Je ferai le tri au fur et à mesure. Super. Et si vous voulez juste discuter, il y a l'onglet de chat pour cela. Très bien, oui, je suis prête. Merci, Emmanuel, pour cette intro. Bonjour à tous, je suis Marion Ranvier, directrice de l'accessibilité numérique chez Content Square et directrice de la fondation Content Square. Donc, effectivement, aujourd'hui, je suis là pour vous parler de l'accessibilité numérique et vous donner aussi un petit peu plus de... Comment on traite ce sujet en interne. Juste en introduction, une courte définition. L'accessibilité numérique, c'est l'habilité d'un site web, d'une app mobile ou d'un document numérique à être facilement navigable et compréhensible par tous. Et aujourd'hui, sur ma première slide, finalement, je voulais un petit peu vous parler des bénéfices de l'accessibilité et vous dire pourquoi c'est important de voir l'accessibilité comme un enjeu majeur et de le prioriser finalement dans vos roadmaps.

5:27 Aujourd'hui, plus d'un milliard de personnes dans le monde sont en situation de handicap et ça affecte certains de ces handicaps à lire l'information et le contenu en ligne. Et à contrario, plus de 70% du web n'est pas accessible. Donc, mon premier point serait aussi une notion business qu'il faut toujours mettre en perspective, qui vous permettrait finalement d'améliorer vos revenus, puisque 1 milliard de la population équivaut à 15% de la population, donc vous pourriez aller toucher une nouvelle audience et atteindre un nouveau public qui navigue peu ou pas sur vos interfaces digitales actuellement. Donc ça, ça serait un premier point bénéfique pour se soucier de l'accessibilité. Le deuxième, finalement, c'est qu'il y aurait une amélioration de l'utilisabilité et ça créerait une meilleure expérience pour tous les utilisateurs. En effet, quand on veille à la conformité d'un site web, on s'assure qu'il est accessible à tous les utilisateurs. Ensuite, un point légal, en effet, ça vous permettrait peut-être de réduire les risques.

6:30 de poursuites judiciaires dans le sens où l'accessibilité numérique est régie par des lois et des référentiels. Il y a le WECAG aux États-Unis, il y a le RG2A en France, qui est le référentiel général de l'amélioration de l'accessibilité numérique. Et simplement à titre d'info, c'est une obligation légale en France pour le secteur public qui génère plus de 250 millions de chiffres d'affaires et le secteur privé, pardon, le secteur... Privé qui génère plus de 250 millions de chiffres d'affaires et le secteur public ou délégataire d'une mission publique. Ensuite, il y a une notion de meilleure image de marque. En effet, les consommateurs sont plus enclins à soutenir une marque qui est digitalement et physiquement accessible. Et si je puis me permettre, je rajouterais aussi, les utilisateurs sont plus fidèles. Quand un site n'est pas accessible, on quitte le site, on n'y revient pas. Alors que du coup, vous pouvez vraiment fidéliser vos utilisateurs si votre site est accessible. Et le dernier point sur une notion de référencement de site Internet, référencement naturel.

7:31 En effet, si vous codez votre site accessible, cela pourra permettre un meilleur référencement naturel. Et Google regarde aussi beaucoup de plus près, en tout cas, l'accessibilité pour référencer les sites. J'aimerais ensuite vous parler finalement de nos enjeux aujourd'hui chez Content Square. Donc, Content Square est en hypercroissance, c'est une licorne et on a pour objectif finalement de redéfinir les règles du jeu en montrant qu'une licorne, où une société en hypercroissance peut aussi avoir de l'impact. Et à ce sujet, sur le sujet de l'accessibilité numérique, on a une stratégie à deux volets. La première, c'est l'accompagnement de nos clients pour les sensibiliser à l'accessibilité numérique et leur permettre de créer de meilleures expériences digitales pour tous leurs utilisateurs. Donc, on a des offres de services qui leur permettent finalement d'auditer pour détecter les erreurs d'accessibilité et recevoir des recommandations pour tendre vers un site web conforme et accessible.

8:36 Et notre deuxième volet, sur une partie finalement à but non lucratif, on a décidé d'aller plus loin en créant une fondation qui a pour mission de sensibiliser toutes les parties prenantes, parce que vous allez le voir dans toute notre présentation, finalement l'accessibilité c'est vraiment l'affaire de tous. Et donc notre fondation a pour objectif de sensibiliser et d'offrir gratuitement des technologies d'assistance pour un public en situation de handicap. Je continue. Donc, effectivement, on prend la parole sur ce sujet de l'accessibilité en externe, mais du coup, quelle est notre démarche en interne? Et c'est le use case que je voulais partager aujourd'hui avec vous, en vous disant qu'effectivement, l'accessibilité numérique, ça peut paraître un sujet complexe, mais en tout cas, la première chose à faire, ou une des premières choses à faire, c'est de connaître son niveau d'accessibilité. Et comment on connaît son niveau d'accessibilité? On le connaît en auditant son site.

9:37 Donc, nos premières démarches ont été d'auditer aussi bien nos sites web que notre plateforme web. Et ce que je voulais vous dire ici, c'est qu'en toute humilité, finalement, on a audité notre site et on s'est rendu compte, sans grande surprise, qu'on n'était pas très bon. Typiquement, sur notre site web, notre taux de conformité est de 45%. Vous voyez, il y a encore beaucoup de travail pour s'améliorer. En revanche, on a décidé de publier notre déclaration d'accessibilité très prochainement sur notre site pour faire savoir à nos internautes qu'on a audité notre plateforme, notre taux n'est pas très bon, mais qu'on va tendre et qu'on a des objectifs très soutenus et un engagement fort pour corriger ces erreurs d'accessibilité, notamment corriger 80% des erreurs détectées par notre audit d'ici le premier trimestre et que nous allons lancer un nouveau site web au deuxième trimestre et qu'on a pensé l'accessibilité en amont, aussi bien dans la création de notre site que dans le nouveau branding qu'on est en train de mettre en place.

10:43 Et donc, pour notre plateforme web, c'est la même chose, notre plateforme SaaS sur cette mise en conformité. Et c'est le use case que je vais vous présenter aujourd'hui pour vous montrer comment on va mettre en place cette stratégie de mise en conformité de notre plateforme Content Square. Donc, la première chose, finalement, c'est le training, c'est former les équipes. Et je vous l'ai dit en préambule, l'accessibilité, c'est l'affaire de tous. Et je pense que voilà, cette slide le résume bien. L'idée, c'est d'aller former aussi bien le top management sur de la sensibilisation pour qu'ils soient les sponsors du projet et qu'ils puissent aussi allouer des ressources et du budget. Bien sûr, les project managers, puisqu'il faut s'assurer que l'accessibilité soit prise en compte tout au long du cycle de vie du projet. et du produit. L'UX, pour qu'il y ait une vraie base accessible et solide. Bien sûr, les designers, parce que l'accessibilité, ce n'est pas simplement une question technique. Les développeurs et la QI pour avoir une base technique accessible, robuste et pérenne.

11:50 Ce à quoi on a ajouté aussi les contributeurs et les éditeurs, parce que finalement, quand vous allez ajouter du contenu, il faut que ce contenu soit pensé accessible. Ensuite, mesurer le niveau d'accessibilité. On peut retrouver finalement pas mal d'outils qui peuvent tester automatiquement l'accessibilité numérique. C'est bien, mais attention, ce n'est pas assez. En effet, quand l'outil vous dit que votre score d'accessibilité est faible, c'est que le site n'est pas accessible. En revanche, si l'outil vous dit que votre score est assez élevé, ça ne signifie pas non plus que votre site est accessible. En effet, les outils automatiques ne suffisent pas. Pour auditer, il faut que ça soit audité par un expert accessibilité. Et c'est pourquoi chez ContentSquare, nous avons fait le choix d'avoir nos propres experts accessibilité permanents. Et notamment, nous avons Natacha dans l'équipe qui est notre expert accessibilité. Je continue en vous parlant de la stratégie.

12:55 Il faut construire une stratégie finalement de mise en place de l'accessibilité en interne. Donc, former les champions de l'accessibilité, on l'a vu, former des champions dans chaque équipe et dans chaque département, produits, QA, design, dev. Ensuite, il est important d'évaluer la stack technique des outils utilisés par les équipes. Et le troisième point, nous, en tout cas, on a fait le choix de commencer par l'accessibilité de notre design system, du système de conception. Donc, peut-être une courte définition sur le design system. La définition du design system s'apparente à celle d'une interface ou d'un guide de conception. Il fournit des lignes directrices, le langage et la bibliothèque, regroupées en une sorte de charte graphique. Et en interne, on aime bien prendre l'exemple des Legos. Finalement, on va aller rendre accessibles toutes les briques pour que quand on construise notre château ou notre fusée, elle ait un socle des fondations déjà accessibles.

14:02 Et ensuite, pour les composants qui ne font pas partie du design system, on va aller utiliser les éléments de conception comme base pour construire chaque module afin de rendre tous les autres composants accessibles. Je vais vous donner ici aussi des exemples. Et une notion, à mon sens, très importante, c'est qu'en fait, l'accessibilité, il faut vraiment la voir à toutes les étapes du projet. On part bien sûr des spécifications. On va penser pourquoi, qu'est-ce qu'on veut créer comme composant, comment on va choisir ces composants et comment on va penser l'accessibilité dans le choix de ces composants. Ensuite, bien sûr, on a l'ergonomie. Pensez à l'accessibilité, par exemple, pour prendre en compte tous les types de navigation. L'UX et le design, bien sûr, sur notamment, par exemple, le contraste, des boutons assez gros. Ensuite, vient les développements. Le testing, hyper important. important sur des tests automatiques et manuels.

15:04 La contribution, alors là, c'est peut-être plus, par exemple, sur des sites web, quand il y a des nouveaux contributeurs, par exemple, sur un blog où on vient ajouter du contenu. Et pour finir, la maintenance, quand on apporte des corrections ou des mises à jour ou des évolutions, bien penser accessibilité. Et vous le voyez, en fait, finalement, il faut penser à l'accessibilité tout au long du projet. Et quand on a fini la maintenance, on repart sur les specs parce que l'accessibilité doit suivre le cycle de vie du produit ou du projet sur tout le long terme. Hop, donc un use case par rapport à Content Square. Donc finalement, nous, qu'est-ce qu'on a fait en premier lieu? Donc, créer un design system accessible. Eh bien, la première chose à faire, c'est effectuer un audit des composants du design system, du système de conception pour fournir des recommandations. On est obligé de passer par là pour connaître finalement notre niveau d'accessibilité et savoir ce qu'on va devoir améliorer.

16:09 Le deuxième point, hors design system, c'est effectuer un audit des composants qui n'appartiennent pas au design system pour fournir des recommandations. Donc, on va auditer et adapter les composants qui ne sont pas présents dans le design system. Et comme on aura formé dans le meilleur des mondes toutes nos équipes avant, on devrait pouvoir avoir des équipes UX ou R&D qui sont capables finalement d'auditer ces composants hors design system. Ensuite, on va pouvoir apporter des modifications. Donc, les modifications vont être regroupées en lots et on va pouvoir faire une release, donc là, la release Canary, qui va être faite pour chaque lot. Et ensuite, on a une revue des releases par les équipes et des adaptations de chaque module. Donc, on voit bien finalement que c'est l'affaire de tous et que toutes les équipes sont impliquées.

17:15 Je voulais peut-être faire un petit point pour finir sur, il est important de maintenir le niveau d'accessibilité. C'est très bien d'avoir un site accessible ou de tendre vers un site accessible, mais finalement, quand vous allez communiquer auprès de vos utilisateurs en situation de handicap ou non, que votre site est accessible, vous ne pouvez plus vous permettre de ne plus penser à l'accessibilité first dans tout ce que vous faites. Donc, c'est pour ça qu'il est très important de maintenir ce niveau d'accessibilité. Et pour le maintenir, vous pouvez mettre en place des outils ou des alertes qui vous permettent en fait d'avoir des détections des erreurs. Donc, il y a Light House, il y a Axcore et bientôt, il y a les outils aussi de Content Square qui pourront permettre finalement de créer des alertes pour vous dire, ah bien là, on a un souci d'accessibilité. Et là aussi où je voulais mettre l'accent aujourd'hui, c'est sur cette notion de penser inclusive design first. Tous les composants que vous créez doivent être conçus accessibles dès le départ.

18:19 Et je voulais vous citer finalement… Un exemple qu'on a eu, nous, chez Contentsquare, on a développé un composant qui est le click and swap. Et on a eu, par exemple, Jeff, qui est product designer accessibilité chez LinkedIn, qui nous a fait un message en disant, c'est top parce que du point de vue ergonomique, ça pourrait en faire un composant accessible. Mais en fait, malheureusement, il n'a pas été pensé tout de suite accessible. Donc là, très vite, on a audité ce composant. On a vu que techniquement, il n'était pas accessible. Donc, on l'a mis très vite dans notre roadmap pour le mettre en conformité. Mais ce que je veux vous dire par là, c'est que finalement, la communauté des experts accessibilité est très friande de nouveaux composants accessibles. Et en fait, il faut penser l'accessibilité comme un innovation driver. Et donc, en fait, ça nous a fait nous rendre compte qu'on devait penser accessibilité first, inclusive design first dans tout ce qu'on développait.

19:23 Je vous remercie, c'est la fin de ma présentation. Je me rends disponible à la fin pour une session de Q&A si vous avez des questions. Je vous remercie. J'espère que j'ai été claire. Merci à tous. Très claire. J'espère que cette première intervention vous a plu. Deux choses que je garderai en tête, c'est que l'activité, ce n'est pas qu'une question technique, que ça se prépare en amont et jusqu'à la fin du... ce que Marion a appelé maintenance. Il y avait une question que je me permets de prendre maintenant d'Alexandre Allary concernant l'outillage. Je la mentionne maintenant. parce que Marion a répondu déjà dessus, mais je le redis à l'oral. Les outils qu'elle mentionnait, c'est Lighthouse et Axcore. À ma connaissance, on ne peut pas auditer toutes les pages d'un site automatiquement. Il faut l'indiquer manuellement lorsqu'on lance Lighthouse ou Axcore. Je vais inviter la deuxième intervenante, Mélanie.

20:24 Bonjour. Bonjour Mélanie. Est-ce que tu vas bien? Tu es prête? Ça va, ça va. Pas de stress? Tout va bien. Mélanie qui travaille chez Pix. Donc effectivement, je suis Mélanie Boudard. De base, je suis développeur plutôt au front. Je suis après passée chargée d'accessibilité et depuis peu, je suis VPE chez PIX. Et donc, je suis là un peu pour vous expliquer le cheminement qu'on a eu avec l'accessibilité côté PIX. Donc, PIX, pour ceux qui ne connaissent pas, c'est une startup, maintenant un groupe d'intérêt public d'État, qui va évaluer les compétences numériques des citoyens. Donc, on a un panel d'utilisateurs très large. Et il y a à peu près deux ans, on a commencé à regarder un peu l'accessibilité à Pix et on a fait un premier constat. Le premier constat que vous partagez peut-être, c'est que notre site est déjà en ligne depuis à peu près deux ans et demi. Il avait un assez gros legacy. En interne, on n'avait pas d'experts en accessibilité, pas de personnes vraiment formées, pas de chargés d'accessibilité.

21:26 À côté de ça, on avait fait des petites tentatives par-ci, par-là. On connaît. On connaissait le mot, on connaissait la problématique, on avait envie d'y aller, on avait tenté des choses sans vraiment avancer sur le sujet. Et ça restait pourtant un sujet assez mal compris, possiblement en interne, en se disant que certains publics, comme on a vu, ne pourraient pas nous intéresser, que c'est compliqué, que ce n'est pas obligatoirement très utile. C'était aussi un sujet qui pouvait faire peur, notamment par ce manque de connaissances et surtout par le chantier qui semblait complètement titanesque, notamment lié au fait que le site est déjà en ligne depuis deux ans avec le Legacy. Mais, et j'espère que vous partagez ce constat aussi de votre côté, on en parle et on a envie quand même d'y aller, malgré toutes ces difficultés et ces peurs. Donc on s'est dit, on y va. Et il y a à peu près effectivement deux ans, la première chose qu'on a fait, c'est d'essayer de relancer l'accessibilité en interne. Le premier point, ça a été de porter le changement. Maintenant, on y va. Pour ça, on a fait émerger le rôle de chargé d'accessibilité.

22:28 Donc ça, ça a été une personne qui était motivée, pas obligatoirement une experte en accessibilité, je voudrais insister dessus, vraiment juste une personne motivée qui est prête à s'intéresser et à prendre du temps. Cette personne a pu avoir une formation de deux jours quand même pour mettre le pied à l'étrier et découvrir un peu plus. Et une fois que cette personne chargée d'accessibilité était là, avait le rôle et la casquette, on a pu commencer un peu plus à en parler en interne. C'est quoi l'accessibilité? C'est quoi nos obligations légales? Comme a présenté Marion avant, pourquoi? le faire pour des raisons légales, de public, tout ça. On est ensuite passé sur des formations très courtes, parce que c'est vrai qu'au départ, quand on ne comprend pas, c'est très dur parfois d'avoir le temps ou le budget pour pouvoir mettre l'accessibilité en place. Donc seulement des demi-journées avec, cette fois-ci, des experts extérieurs pour initier tous les corps de métier à l'accessibilité. Donc les devs, bien sûr, les UX aussi, mais aussi la communication ou d'autres types de métiers qui seront, à un moment donné, en lien avec l'accessibilité.

23:29 Et ensuite, on est arrivé sur une phase un peu plus longue de monter en compétence en douceur. C'est-à-dire qu'on n'a pas formé tout d'un coup tous nos développeurs à l'accessibilité. On a tout d'abord ouvert un Slack pour partager dessus des liens qu'on trouvait, des vidéos intéressantes, tout ça. On s'est aussi challengé en interne pour comprendre comment ça marchait. Donc effectivement, il y a plein d'extensions. Il y a une extension qui s'appelle Wave, qui est très simple d'utilisation. Vous l'ouvrez, elle vous dit vos heures d'accessibilité sur la page. Donc ça peut être un challenge côté développement de se dire, bon, on va essayer d'avoir zéro erreur Wave sur la page. C'est déjà un grand pas et ça permet déjà d'apprendre pas mal de choses. Et après, essayer de tester le site en zoomant avec d'autres outils d'accessibilité où les gens n'ont pas l'habitude possiblement de mettre un zoom sur la page et de voir à quel point possiblement l'écriture ne fonctionne plus. Donc ça, on a pu relancer l'accessibilité. On a vu une dynamique, mais ce n'était clairement pas suffisant. C'était des petits pas. Cette période a dû durer à peu près un an.

24:31 On avançait, mais on n'avait aucune confiance dans ce qu'on faisait. Et petit à petit, l'engagement a disparu parce qu'on n'allait nulle part. C'est là où on a voulu se redonner un objectif clair et passer par l'audit. Donc l'audit d'accessibilité que vous pouvez faire pour connaître votre note d'audit. Nous, ça nous a permis d'avoir un objectif vraiment clair, une date et un accompagnement. Donc, pour préparer l'audit, qu'est-ce qu'on a fait? D'abord, c'est dédiaboliser l'audit. Parce que dès qu'on parle d'audit, avec possiblement un pourcentage à la fin qui est sûrement mauvais comme la plupart des sites, Ça fait peur, on a l'impression que c'est une mauvaise note, qu'on se fait punir. Il faut vraiment expliquer en interne comment ça va se passer, que ça va être un score très bas. Et c'est un problème, mais pas tant que ça, parce que derrière, on va pouvoir l'utiliser comme outil d'amélioration. Ensuite, il faut le préparer, bien sûr, trouver quelle entreprise va faire l'audit. Nous, on est parti avec Tanaguru pour information. Et on a mis une date, dans trois mois, on lance l'audit de notre site.

25:34 On a pu expliquer en interne ce qui allait se passer à toute l'entreprise. Et comme on l'a dit, c'est vraiment toutes les personnes, pas seulement l'équipe de développement, mais vraiment tous les acteurs qui, à un moment donné, possiblement écrivent des textes ou font des PDF pour le site, être au courant de ce qui va se passer. Et on s'est challengé, toujours comme je disais avant, trois mois avant l'audit, on sait quelles pages vont être auditées. On essaie d'avoir zéro error wave en se disant, voilà, qu'est-ce qui se passe si on a zéro error wave et qu'on va à l'audit. L'audit passé, comme beaucoup, le site n'est pas accessible. On a eu un score bas d'environ 35%, ce qui est un petit effet démoralisant. Mais pareil, il faut communiquer sur le pourquoi ce score est aussi bas. Et surtout, maintenant, on avait une liste des critères qui n'étaient pas validés pour chaque page. Donc, quand vous faites l'audit, le résultat se voit un grand fichier Excel très long avec tous les critères RGA. Ce qui est validé ou non par page. Donc pour nous, c'est quand même une mine d'informations. C'est tout d'un coup, on a pour chaque page, qu'est-ce qu'il faut améliorer un par un.

26:38 Et cette liste d'actions permet après vraiment d'avancer. Donc, qu'est-ce qu'on en fait, cette audite? Comme je disais, on a d'abord dédramatisé, expliqué le score et motivé avec la liste d'action. Et ensuite, on a essayé d'analyser vraiment l'audit, de trouver les actions qui étaient faciles à faire, un changement de couleur par-ci, un halt d'image qui n'était pas fait par là, Donc, c'est assez facile. Et on a essayé de se pousser à améliorer notre pourcentage. 35% c'est bas. On avait visé 50% pour être partiellement conforme comme premier step de notre côté. Ensuite, on crée des tickets pour chaque critère, chaque page. On a pris un critère, une page, ça fait un ticket. Et voilà, après on rentre dans les sprints habituels avec des tickets et des pages. Et on ajoute ensuite dans la roadmap notre objectif d'atteindre les 50%. Et on a ajouté, nous, de notre côté, à peu près deux tickets par sprint. Et ça, je pense que c'est important pour nous, l'audit en tout cas, c'est vraiment ce qu'on a utilisé comme un outil et sur lequel on boucle.

27:47 C'est qu'on fait l'audit pour connaître nos scores et nos faiblesses. On prend le temps d'analyser derrière la grille d'audit exactement ce qu'on va pouvoir améliorer. Et rentrer après dans une boucle de sprint habituelle. Puis mettre à jour l'audit et le score, et on recommence en fait. Comme disait Marion, c'est un cycle sans fin. Nous, on fait beaucoup de mise en prod. À n'importe quelle mise en prod, on peut faire baisser notre taux d'accessibilité. Ça fait possible. Et donc, refaire régulièrement ces audits et ce suivi pour savoir est-ce qu'on s'est amélioré, est-ce qu'on a perdu de la qualité sur certaines pages en termes d'accessibilité, c'est important comme ça de continuer le cycle. Et ça donne à chaque fois un objectif toujours plus fort en termes de pourcentage, toujours aller plus loin. Espérer atteindre le 100% pour information, on n'y est pas, ça prend du temps tout ça. Entre l'audit, donc les trois mois avant l'audit, et passer de 35 à 50%, on a eu en tout et pour tout à peu près 6-7 mois.

28:51 Donc c'est assez long, mais ça a permis beaucoup de choses durant ces mois. Parce qu'on a eu l'audit, on a pu faire les tickets et l'améliorer. Mais ce n'est pas fini. Qu'est-ce qui se passe après? Voir qu'est-ce qui se passe pendant. Le premier point, c'est de partager sur ce qui s'est passé et sur l'audit. Quand les développeurs prennent un nouveau ticket ou un UX, ou même les PO quand ils doivent tester le ticket derrière sur l'accessibilité, ce n'est pas seulement il fallait changer la couleur de telle à telle couleur, Ça leur donne des nouvelles informations et ça permet de partager au fil de l'eau avec les tickets sur, là, en fait, on a fait une erreur, ça, je ne savais pas, je l'apprends avec les tickets. Donc, c'est aussi un outil d'apprentissage à chaque nouveau ticket. S'il y a un critère d'accessibilité que possiblement les équipes ne connaissaient pas, ils vont pouvoir découvrir. Si c'est possible, former les personnes. Alors, ce n'est pas toujours possible, je sais que ce soit en termes de budget ou de temps, mais ça reste quelque chose d'appréciable de former les gens via des vraies formations et d'engager toute l'entreprise dans

30:00 Cette continuité se partage. Nous, on parle sur Slack. On s'est essayé aussi à des newsletters un peu en interne pour partager des petites présentations sur ce que ça signifie, notamment pour certains handicaps qui pouvaient être mal compris. Donc vraiment, partager un maximum. Plus on partage, plus les gens sont au courant, plus ils vont y penser, que ce soit dans leur développement technique, dans la création de PDF, quand ils font un tweet pour l'entreprise ou ainsi de suite. On continue aussi avec des objectifs plus grands. Comme je disais, on a la liste des erreurs. On peut refaire un audit régulièrement. On peut essayer d'atteindre les 50%, donc ne pas valider tous les critères. Puis en plus, après, essayer de valider les 100% une fois que ça atteint. C'est possible aussi de s'outiller, on en a parlé rapidement, effectivement, Axe Permage, je conseille aussi l'extension Wave. C'est aussi possible de mettre des linters en termes d'accessibilité pour surveiller notamment. Par exemple, on a un linter qui vérifie qu'il y a un alt sur chaque image côté HTML.

31:01 Le design system, comme côté Contentsquare, est aussi un outil très fort parce que si vos petits blocs sont déjà accessibles, ça sera plus simple de construire une page web complètement accessible. Et enfin, il faut continuer à valider l'accessibilité au même type que le reste. Si votre site doit être responsive, c'est souvent que c'est vérifié côté PO. L'accessibilité, c'est pareil. Alors, ça demande effectivement de se former et d'apprendre à faire, mais c'est un ensemble, en fait, qui... Qui permet d'avancer dans ces directions. Donc globalement, qu'est-ce qui a fonctionné pour Pix et peut-être pour vous? C'est trouver au moins une personne motivée. Si vraiment vous n'avez pas de notion d'accessibilité dans votre entreprise, si ça n'avance pas ou qu'on en parle comme ça, une personne motivée, même qui n'est pas experte, qui n'est pas formée, pour prendre un peu le lead sur le sujet et regrouper les gens, faire des discussions, partager. C'est vraiment le point qui nous a débloqués, en fait, dans cette boucle à ne pas avancer.

32:03 L'audit, c'est vraiment un outil de cadrage. C'est ce qui nous a aussi aidé à passer à un nouveau step en termes d'accessibilité. Ce n'est pas une punition, c'est vraiment un outil. Et enfin, je conseillerais de partager un maximum pour apprendre et donner du sens. Les Slack, les mails, les discussions, on pourra peut-être partager après des comptes ou quoi que ce soit qui sont un peu suivis par tout le monde. C'est souvent assez mal connu, les développeurs, les UX ne se sont pas formés souvent dans les formations actuelles à l'accessibilité. Donc, c'est normal actuellement que les gens ne savent pas faire accessible. Et pourtant, il faut continuer à apprendre ensemble. Si vous pouvez avoir des experts en accessibilité, c'est super. Ce n'est pas le cas de toutes les entreprises, donc n'hésitez pas à former en interne. Voilà pour moi. Merci, Mélanie. J'ai mis sur le chat un lien vers un Slack accessibilité anglo-saxon. Le sujet vous intéresse. Il n'y en a sûrement pas le seul, mais c'est celui que moi j'utilise personnellement.

33:06 Merci pour cette intervention, Mélanie. Je voulais juste ajouter quelque chose. Il ne faut pas voir un audit comme une punition. Quand je fais des audits, souvent les gens ont peur. On n'est pas là pour taper sur les doigts des développeurs et développeuses, on est juste là pour améliorer le produit. Donc n'ayez pas peur, on est bienveillant, normalement. Et voilà, on est là pour améliorer le produit. Et ensuite, Mélanie a parlé d'une matrice pour l'audit. En fait, il faut savoir, c'est qu'on va tester un panel de pages du site en vérifiant 106 critères qui sont définis dans le référentiel RG2A, c'est le référentiel français. Et donc, grâce à ça, vous pouvez aller sur le site de RG2A, c'est un peu un livre de recettes, où pour chaque critère, on a les choses à vérifier, que ce soit dans le code HTML, CSS ou JavaScript. Merci Mélanie. Tout à l'heure, on se rejoint en fin de session pour les questions. Et pour finir, je vais inviter Romy d'Octo.

34:14 Romy, ça va? Très bien. On va partir d'un retour d'expérience de l'accompagnement qu'on a effectué. Je vais peut-être commencer par me présenter, excusez-moi, je pars bien en tête. Je suis Romy du MVDR, je suis consultante. en design d'expérience utilisateur et experte en accessibilité numérique. Et à ce titre-là, j'accompagne différents projets en ergonomie, en accessibilité. On a donc accompagné Île-de-France Mobilité. Dans leur démarche d'accessibilité. Je vais partir de ce Rex-là pour en tirer et voir un petit peu les leçons qu'on en a tirées et la proposition. position d'accompagnement qu'on peut faire à la suite. Pour situer un petit peu Île-de-France Mobilité, c'est le portail de tous les transports en commun d'Île-de-France.

35:15 C'est 11 millions de franciliens qui se déplacent sur le réseau et parmi ceux-ci, 35 cas de visiteurs par jour sur le portail. Ce qu'on avait vu précédemment, c'est qu'on sait que parmi les utilisateurs d'un produit numérique, il y en a à peu près 20 à 40%, cette fourchette-là, qui ont des difficultés d'accès, c'est difficile, partiel ou impossible. Et donc, parmi ces utilisateurs-là, on sait qu'il y a des difficultés d'accès qu'on va essayer de résoudre, c'est ce qu'on appelle l'accessibilité numérique. Et ça se traite en France, en tout cas, avec le RG2A, qui a déjà été mentionné, et c'est sans six critères. Je rappelle les obligations légales. Île-de-France Mobilité, c'est du secteur public et c'est soumis à deux obligations légales. La première, c'est une conformité à la norme d'accessibilité à 100%. C'est la loi de 2005. Et la deuxième, c'est la publication du niveau d'accessibilité sur notamment l'écran d'accueil du produit numérique. Et ça, c'est depuis 2019.

36:16 Voilà le paysage au début de cet accompagnement. Et au début, comme souvent, on part de loin. Et il y a donc une première étape, c'est un besoin de sensibiliser. de former et d'aligner tout le monde sur ce que c'est l'accessibilité et sur comment on va faire cela. Donc les premières actions, sensibilisation. Chose importante, s'aligner, aligner l'équipe sur un premier objectif atteignable. On ne va pas tout de suite viser le top niveau, on va se donner un premier objectif. ensemble, dans un premier temps, on souhaite atteindre un premier palier. On va engager aussi des formations pour que les designers et développeurs, en particulier ici, acquièrent les savoir-faire nécessaires. Et il y a la mise en place de tests automatisés qui ont déjà été mentionnés. C'est un petit point sur cette salle-là et pourtant c'est quelque chose d'assez important à mettre en place. Il faut savoir que dans tous les critères d'accessibilité, donc la centaine de critères d'accessibilité du référentiel, une partie sont automatisables, à peu près un quart.

37:25 Donc, ça nous permet de couvrir 25% de ce qui est attendu en accessibilité. Mettre en place ces tests automatisés, les avoir tous au vert, on sait qu'on est déjà à 25% de conformité. Ensuite, dans un second temps, on va injecter de l'accessibilité au cœur des itérations. On travaille en agile ici. Ce qu'il faut retenir, c'est qu'on va saupoudrer l'accessibilité sur les pratiques et les façons de faire déjà existantes. Il ne s'agit pas de choses en plus, de fonctionnalités en plus, de rituels en plus. On va saupoudrer l'accessibilité dans nos pratiques. On a une pratique de recette design, on y ajoute quelques tests d'accessibilité, plus particulièrement 10 tests en 10 minutes qui s'appellent les Easy Check. C'est un protocole de test du W3C, il s'agit de manipulation assez simple. On va utiliser aussi ce qui s'appelle les notices Accès Web, c'est un ensemble de tutos qui permettent de documenter, de s'auto-former sur ce qui est attendu.

38:32 Côté design, côté développeur, côté production de contenu. Et puis, dans nos ateliers de co-conception, on inclut la notion de« tres amigos», pour dire« tripartite». Il y a, en effet, besoin… d'un dialogue, de négociations, d'un travail de collaborer entre designers et développeurs pour réussir l'accessibilité. Face à un problème d'accessibilité qu'on souhaite résoudre, la réponse peut être design, peut être dev, ou peut être à cheval entre les deux. Donc, il y a besoin qu'il y ait une collaboration étroite et une bonne... entre ces deux, entre designer et développeur, avec le PO pour tout ce qui est côté fonctionnel. Donc ça, c'est au cœur des itérations. Je vais vous donner quelques exemples de concrètement faire ça, qu'est-ce que ça donne. Par exemple, sur ce qui est travail côté graphique, sur ce qui est travail des couleurs, généralement, on présente dans nos chartes graphiques, on présente les couleurs de cette façon-là, avec des petits rectangles de couleurs.

39:42 Travailler l'accessibilité là-dessus, ça va être de proposer un tableau croisé des couleurs pour distinguer, pour repérer facilement quels sont les contrastes qui vont être satisfaisants. Est-ce que j'utilise ce bleu-là et ce bleu-là ensemble? Est-ce que ça donne un contraste suffisant? Dans notre kit, Il y a un tableau de contraste qui est ajouté. Pour le lire, je donne quand même le principe pour le lire, on a toutes les couleurs en abscisse et en ordonnée, et puis la cellule qui les rassemble. En rouge, ça veut dire qu'il ne faut pas utiliser cette association de couleurs-là, le contraste ne sera pas suffisant. En vert, on peut utiliser ce couple de couleurs, le contraste sera suffisant. Donc ça, c'est côté graphique. Un autre exemple, on va prévoir les alternatives textuelles. Ici, sur une image, pour les personnes qui ne les voient pas, que ce soit une personne qui est aveugle ou que ce soit quelqu'un qui est dans le métro et qui a trop peu de réseau et pour laquelle l'image ne se charge pas, il n'aura pas accès à l'information assez

40:47 importante qui est portée par cette image-là parce que c'est une infographie. Et du coup, ce qu'on a choisi ici de mettre en place, c'est ce qu'on appelle des... Des alternatives textuelles, plus précisément une transcription textuelle, vous voyez, sous l'image, il y a un petit bloc qui déplie et replie la même information, mais cette fois-ci de façon textuelle. Si l'image n'est pas visible, si elle ne charge pas, on peut déplier, accéder à l'information sans forcément avoir besoin de l'image. Là, je viens de vous donner deux exemples qui sont visibles, que je peux transmettre dans des slides ici. Mais attention, l'accessibilité, ce n'est pas quelque chose qui se voit. Il y a très peu d'exemples qu'on va voir. pouvoir vous montrer, oh, regardez, ça, c'est accessible. Non, c'est quelque chose qui se manipule. Et qui se manipule, ça veut dire votre interface, Ok, souvent on fait une vérification visuelle, mais vérifiez-la aussi, est-ce que vous pouvez la naviguer au clavier? Est-ce que vous pouvez l'utiliser et avoir le même accès aux services, aux informations, sans les images?

41:50 Est-ce que ça fonctionne toujours si les caractères sont très agrandis pour les personnes qui ne voient pas bien, etc. Donc, ça va être une succession de manipulations assez simples, en fait, qu'on va effectuer pour pouvoir vérifier que l'interface reste consultable dans tous ces cas d'usage. Donc voilà où on en est après avoir mis en place tout ça. Un premier temps de montée en compétence, un deuxième temps d'insérer au sein des pratiques, au sein des itérations. Ça nous permet de distinguer ces grandes étapes, montée en compétence, accompagnement. On est prêt à se confronter à l'audit RG2A. Alors l'audit RG2A. C'est la seule façon de mesurer le niveau d'accessibilité atteint. Du coup, on programme cette audite-là et le score qu'on a atteint, c'est 41%. Il faut savoir qu'un audit se déroule en trois temps. Il y a une première mesure qui est effectuée avec une liste d'erreurs et de corrections qui vont guider les corrections qui restent à effectuer après tout ce qu'on a mis en place.

43:02 Et un troisième temps de contre-visite, donc après correction, la contre-visite nous amène à un score de 70%, ce qui nous permet d'afficher sur le site la mention obligatoire correspondante, qui est ici accessibilité partiellement conforme. Ce qui est intéressant dans ce retour d'expérience, dans cette timeline que je vous présente, c'est aussi les dates entre le début de cet accompagnement-là, où on part de zéro, comme souvent, Et le score final, il y a à peu près un an ici, qui s'est... Qui sait écouter. En mettant ce qu'on vient de voir en pratique. Ce qu'on en retient de ce retour d'expérience-là et des autres, c'est une démarche qui va se faire en trois temps que je vais présenter. Je vais juste rappeler le contexte. On parle de conformité à une norme d'accessibilité.

44:02 Elle s'exprime en pourcentage, c'est ce qu'il y a sur la droite de cette échelle-là, avec les mentions textuelles correspondantes. En dessous de 50%, ce sera non conforme, au-dessus partiellement conforme, et au-delà de 100%, et oui, on peut aller encore au-delà, c'est totalement conforme. Le niveau qui est légalement requis, c'est 100% de conformité. Je précise que c'est un niveau qui est, bien que ce soit le niveau légalement requis, c'est ambitieux de l'atteindre. Il y a en pratique encore, malheureusement, trop peu de sites qui l'atteignent. Et assez souvent, on part de loin, oui, j'ai mis en dessous de zéro, tout simplement parce que l'accessibilité numérique, ce n'est pas enseigné. Vous pouvez avoir d'excellents développeurs, d'excellents designers, ils n'en ont juste jamais entendu parler dans leur parcours de formation et dans leur pratique antérieure. Donc souvent, on part d'assez loin, on commence à se préoccuper. Et d'accessibilité. Du coup, la première étape, c'est nécessairement temps de monter en compétence pour acquérir cette connaissance-là.

45:10 Ensuite, il y a un temps de conception et de fabrication des interfaces de façon accessible. Puis, il y a un temps de vérifier la conformité avec un audit, ses correctifs et les déclarations obligatoires qui s'en suivent. Voilà pour la démarche de façon globale. Je vais la resituer un petit peu, faire un rappel en fait aussi du contexte actuel de l'accessibilité numérique. Oui, c'est méconnu, on n'en a souvent pas entendu parler en cours dans nos... Dans nos apprentissages. Et pour autant, c'est une technologie qui est, c'est une préoccupation qui est très ancienne. En fait, cette préoccupation d'accessibilité est là dès l'origine, en tout cas des technologies web, dès l'origine du web, très tôt, on s'est soucié que ce soit utilisable par tous et toutes. Ce qui veut dire aussi que c'est une technologie qui est mature, c'est déjà prévu dans la techno qu'on utilise, c'est par défaut accessible.

46:15 Tant mieux, on s'appuie donc sur un socle technique qui est très favorable à l'accessibilité. Ce qu'il faut retenir aussi, c'est qu'il n'y a rien qui est impossible techniquement, on n'a pas de limitation technique. Seule chose, c'est qu'on ne savait pas qu'on pouvait le faire, mais on peut le faire. C'est aussi une chose Chance, l'accessibilité numérique, c'est aussi une chance pour les personnes handicapées. Pour illustrer cette notion-là, c'est beaucoup plus simple pour une personne qui est aveugle ou handicapée de faire ses courses en ligne que de les faire au supermarché. C'est beaucoup plus simple de lire des livres numériques que d'aller dans une bibliothèque où il n'y a que des livres papiers, donc il faudrait une version braille. Et comme c'est un sujet qui est ancien, on s'appuie sur 20 années d'études utilisateurs, sur une technologie qui fonctionne, et ça a eu le temps de se structurer sous la forme d'une norme qu'on a déjà évoquée, WECAG, c'est la norme d'accessibilité. Toute autre documentation s'y réfère.

47:19 Elle se décline en différents référentiels et méthodes selon les pays, selon les législations locales. Et en France, ça se décline sous la forme du RG2A. Qu'on a déjà évoqué. Donc, on a un contexte qui est plutôt favorable. Il n'y a pas de grandes difficultés. C'est très favorable pour réussir l'accessibilité numérique. Je vais faire un focus aussi sur quand on regarde les critères de la norme d'accessibilité du RG2A et qu'on les ventile en face de chaque critère, qu'on note quelles sont les compétences nécessaires pour le respecter. On a à peu près cette répartition-là et on voit que la plus grande responsabilité, c'est sur les compétences en développement front. Je précise, développement front, c'est-à-dire HTML, JS et ARIA, qui sont les trois langages qui vont être les plus utiles pour réussir l'accessibilité numérique.

48:22 Il y a aussi une part qui est non négligeable, puisque c'est un petit peu plus d'un quart, qui repose sur la production des contenus, des textes, des images, des infographies, comme on a vu tout à l'heure, des PDF, des vidéos, pour lesquelles il faudra prévoir des sous-titres. Et puis une dernière part, à peu près 13%, qui relève du design. Ce qu'il faut surtout retenir de ça, c'est que tous les profils qui vont intervenir sur un projet sont concernés et ont des choses à faire chacun pour réussir l'accessibilité numérique. C'est un travail d'équipe et sous la houlette des chefs de projet et P.O. Un petit focus aussi sur le risque à aborder l'accessibilité de façon corrective, qui s'explique par une dette d'accessibilité qui va grossir très vite. Dès les premières lignes de code posées, la dette d'accessibilité grossit de façon très rapide.

49:28 En fait, la métaphore pour comprendre ça, c'est comme en pâtisserie. Ce n'est pas quand le gâteau sort du four et qu'on le pose sur le présentoir qu'on se pose la question de« Ah, au fait, est-ce qu'il est consommable par les personnes qui sont intolérantes au gluten? » C'est trop tard. Pour le rendre consommable par les personnes intolérantes au gluten, il faut jeter le gâteau et le refaire. Alors que si on s'était posé la question avant de faire le gâteau, il était extrêmement facile de tendre la main vers le pain. paquet de farine sans gluten pour faire le même gâteau et ça n'est pas c'est beaucoup moins coûteux en fait de se soucier d'accessibilité si on s'en pense dès le début que si on y pense à la fin où le souvent le risque c'est de trop de correctifs à faire trop coûteux trop de temps et de ne pas effectuer ces correctifs, ou alors de devoir tout jeter pour recommencer, ce qui n'est pas une façon de parler, ce qui est du vécu. Je vais conclure sur nos convictions, c'est ça que nous partageons, Mélanie, Marion et moi, autour de l'accessibilité.

50:40 Très important de concevoir dès le début pour tous les utilisateurs et utilisatrices. On ne corrige pas l'accessibilité, on va fabriquer accessible. Ça marche mieux si on adopte une démarche d'amélioration progressive. En agilité, ça s'y prête très bien. C'est aussi un travail d'équipe qui va impliquer tous les profils. Donc, important que chacun prenne sa part dans ce travail-là. Et c'est aussi une responsabilité partagée dans le sens où ce n'est pas une expertise isolée. Le modèle de« on a un produit à rendre accessible, on va mettre un expert en accessibilité dans l'équipe et ça va le faire», ça ne marche pas en fait. Ça fait 20 ans qu'on fonctionne comme ça et que ça donne peu de résultats. Il y a vraiment à partager cette responsabilité entre tous les intervenants. Merci beaucoup, Romy. Je vais inviter les deux intervenantes de tout à l'heure pour la session Q&A. Pour rebondir sur ce que dit Romy, l'accessibilité, c'est en effet dans la conception d'un service numérique, mais aussi en tant qu'utilisateur.

51:49 En tant qu'utilisateur, dès que vous concevez des documents, il y a des bonnes pratiques à respecter pour la structuration de ce document. Quand vous publiez vos photos de vacances sur votre réseau social, il y a des mécanismes pour mettre des alternatives textuelles sur Twitter, sur LinkedIn, des alternatives textuelles, vous devez les mettre, comme ça les gens qui ont des problèmes pour lire le contenu, ils sont capables de le comprendre en tout cas. Deuxièmement, je vous conseille de faire un test une fois, d'essayer de naviguer sur votre service numérique juste avec le clavier. Et éventuellement, si vous n'avez pas peur d'avoir un mal de crâne, de lancer un certain utilisateur vocal pour essayer de voir si l'expérience utilisateur de certains personas est optimale. Et vous allez voir que la plupart du temps, la première fois que vous allez faire ça, ce n'est souvent pas le cas. Alors, il y a quelques questions. Il n'y a pas encore les réponses, mais quelques questions. Question anonyme.

52:52 Avez-vous déjà mis en place des tests utilisateurs avec des personnes en situation de handicap? Est-ce que l'une d'entre vous souhaite prendre la parole? voir à quelle fréquence c'est fait, comment ça fonctionne, etc. On dit oui toutes les trois? Oui. J'ai eu deux hochements de tête. Mais vas-y Romy, si tu veux prendre. Oui, mais je vais commencer par faire un warning qui va... Oui, oui, c'est une très bonne idée. C'est bien de faire des tests avec des utilisateurs en situation de handicap, avec des besoins particuliers. Ne les faites pas, brûle pour point. C'est-à-dire ne les faites pas sans avoir engagé préalablement une démarche d'accessibilité. Le réflexe qu'ont parfois les UX designers, c'est nous, on travaille avec les utilisateurs, on commence par aller les voir, recueillir leurs besoins. Et pour l'accessibilité, ce n'est pas comme ça qu'il faut procéder. Il faut d'abord faire en sorte que l'écran fonctionne avec un centre-tigeur vocal avant de mettre derrière un aveugle pour vérifier si c'est confortable pour lui.

53:54 Donc d'abord respecter la norme, exactement pour mieux comprendre. De la même façon qu'en design, on va d'abord respecter certains principes d'ergonomie, vérifier que ça s'affiche bien avant de mettre des utilisateurs derrière. Là, c'est pareil. Il faut d'abord mettre en conformité avant de mettre des tests utilisateurs derrière. Je m'arrête sur le warning et je vous laisse parler. Dans le process, c'est éventuellement les tests automatisés pour détecter ce qui est facilement détectable, les tests manuels par un expert audit. Et une fois que toutes ces étapes sont... Au green ou pas loin, à éventuellement faire des... des tests utilisateurs avec des personnes en situation de handicap. Je module juste les tests manuels. Ce sont des tests qui sont assez simples à faire. Tout le monde peut les faire. Naviguer au clavier, on peut tous le tester. Afficher en gros caractère, on peut tous le faire. Et après, effectivement, dans un tiers du temps. Est-ce que Mélanie ou Marion souhaitent ajouter quelque chose à ce que vient d'expliquer Romy? J'aimerais juste rajouter un petit truc. Effectivement, on a pu faire des tests utilisateurs. Ce n'est pas encore... On ne les fait pas régulièrement et tout.

54:56 Et pour nous, ça a été très important parce qu'on avait mis des choses en place pour l'accessibilité. Donc, ça allait aider les personnes. Et en fait, en testant, ça les a fait galérer plus qu'autre chose sur notre site. On avait rajouté des textes invisibles pour peut-être aider quand ils sont qu'avec l'audio. À se retrouver dans la page. Et en fait, avec notre vision de personnes voyantes, on avait rendu le site moins accessible qu'il ne l'était si on n'avait rien fait. Donc, c'est très important d'avoir les utilisateurs. Très bien, on va continuer parce qu'on arrive au bout du timing. Question à mon avis pour Mélanie, pour Pix, pourquoi avoir choisi d'atteindre un score 50% plutôt que 75% ou même 100%? 100% ça aurait fait trop peur à toute l'équipe. Ça aurait été beaucoup trop de boulot et je ne sais même pas si on l'aurait atteint. Donc ça aurait été un objectif non atteignable et donc déprimant pour tout le monde. Quand on arrive à 35%, on a pu le faire en quelques mois. On avait à peu près une vingtaine de tickets, 25 tickets. C'est un objectif entendable en fait.

55:56 Maintenant, on va aller vers l'objectif du 75%. Mais c'est bien de ne pas toujours atteindre 100% direct. Essayer déjà d'atteindre 50%, ce sera déjà très bien. Et après, peut-être 70, 80, voire 70. Mais sinon, ça fait trop peur et ça peut trop démoraliser en fait. Il faut avoir des petites victoires au fur et à mesure. Sinon, les gens n'arriveront pas jusqu'au bout. Et comme l'a dit l'une d'entre vous, je ne sais plus qui, avoir 100% à un instant T, c'est faisable, mais le garder dans le temps, c'est plus compliqué. Donc c'est pour ça qu'aller étape par étape, c'est mieux. Avez-vous des références de sites super méga accessibles? celui de Octo, de Pix et de Crotonspire. Mais même pas Pix, en fait. Nous, on n'est pas encore non plus. Spontanément, moi, je citerais quand même Microsoft, qui sont quand même les pionniers depuis des années en termes d'accessibilité numérique. Ah, Romy, tu n'es pas d'accord avec moi. Non, mais... Moi, je citerais service public, mais je ne sais pas si Romy citerait la même. Si, tout à fait. Un des sites les plus exemplaires et de façon durable dans le temps, c'est servicepublic.fr.

57:04 Exactement, je le vois cité en conversation. Vraiment une très belle équipe qui marche avec ce qu'on vient de dire. Toutes les personnes de l'équipe sont impliquées. Le score, c'est 100%. Des fois, il baisse un petit peu, il remonte, mais c'est vraiment très haut niveau et très beau travail. Ils sont en cours de refonte, ils viennent de refondre une partie du portail entre prendre.servicpublic.fr. Dès la mise en ligne, c'est conforme, il y a niveau, il y a toutes les déclarations obligatoires, c'est vraiment très beau travail. Ça marche. Et quelle lecture vous conseilleriez pour monter en compétence sur le sujet? Par où on doit commencer? Après avoir suivi ce webinar. Ça, c'est une question. Vas-y, Romy. Merci. C'est toi qui as levé la main. Oui, oui. Il y a peu de lectures.

58:04 Alors, lecture, livre, il y en a très peu. Par contre, je sais qu'il y a eu un livre sur l'accessibilité numérique qui est paru chez Erol il y a quelques années. Comme il n'y en a qu'un seul, ce ne sera pas difficile à trouver. Il est de Harmonia Signé. Je pourrais noter la référence après. Quelle lecture ensuite? Il y a une masse de ressources sur Internet. Il y a plein de sites, blogs. C'est même l'inverse, c'est difficile de s'y repérer. Je vous le redis, ça existe depuis plusieurs dizaines d'années. Il y a plein de docs. Moi, je vous ai partagé sur le chat un guide qu'on a publié. Vous pouvez le télécharger gratuitement aussi. C'est se mettre à la place des personnes en situation de handicap. Et on l'a publié sur un site où on a essayé de simuler des troubles pour que vous puissiez aussi vous mettre effectivement à la place des personnes en situation de handicap. Car quand on n'a pas de handicap, on ne se rend pas compte des difficultés au quotidien. J'ai ajouté un lien dans le chat. C'est un document en anglais pour les composants assez riches d'une interface graphique. C'est assez détaillé.

59:06 Ils expliquent vraiment comment on doit tester les composants riches, qu'est-ce qu'il faut ajouter, qu'est-ce qu'il faut supprimer, à quel moment, à quelle étape, etc. Pour que le composant soit super accessible. Dès que je fais des composants riches, je regarde cette documentation-là, est-ce qu'il y a une entrée pour le composant que je suis en train de développer ? Et je ne fais que suivre les choses. Et oui, il y a des très bonnes infos aussi dans le chat avec OpQuest, Assurance Qualité Web. Voilà, donc tout à fait. Si vous voulez être certifié OpQuest, etc., il y a des choses. Par contre, comme on disait, il y a vraiment beaucoup, beaucoup, beaucoup de ressources. Donc, vous pouvez vous perdre assez rapidement dedans. En fait, n'hésitez pas à vous reposer sur… Enfin, moi, les extensions et tout, ça m'a pris beaucoup de choses. Après, on se renseigne et on picore un peu par-ci, par-là. Sur Twitter, il y a aussi plein de personnes qui en parlent, que vous pouvez suivre pour apprendre un petit peu sur Twitter. Il y a beaucoup de ressources. Je vais rajouter un lien que j'aime beaucoup. beaucoup plutôt côté développeur. Et c'est très large. On va essayer de prendre encore une ou deux questions.

1:00:08 Question de Rémi. Quelles actions peut-on faire en tant que membre sur un projet pour faire un audit maison sans avoir besoin d'une intervention extérieure? Qu'est-ce que je peux faire, moi, avec mes simples pouvoirs de développeur ou de développeuse pour initier, pour voir l'état des dégâts éventuels de mon site? Je dirais, Romy, tu en parlais dans ta présentation, des deep checks d'accessibilité à faire facilement à la main. La première phase d'audit, je sais de retrouver effectivement le lien, on va le repartager. Première chose, c'est test autour. C'est ce que tu disais, Mélanie, avec Wave. Marion, tu en as certainement parlé. Il y a des... Wave, c'est un plugin qui s'installe dans le navigateur. On appuie sur le bouton, ça liste toutes les erreurs automatiquement détectables. Deuxième chose, il y a 10 gestes assez simples à faire. Pareil, je peux trouver la documentation pour les expliquer. Et dans tout développeur, ils ont au moins un navigateur Chrome quelque part.

1:01:16 Il y a l'Itahouse qui est installé par défaut. Donc, il faut juste le lancer. Vous n'avez rien à installer supplémentaire. Au moins, vous avez un premier score qui sera calculé. Malheureusement, il y a une dernière question. Il y a cinq. On va aller en... À conclure, on m'a dit. En tout cas, on essaiera peut-être de répondre à vos questions. On va faire un screenshot des questions restantes et on les répondra peut-être en insynchrone sur les réseaux sociaux. Merci à toutes et à tous d'être venus ce midi. Merci aux intervenantes. Merci Romy, merci Marion, merci Mélanie. Merci. N'hésitez pas à les contacter sur LinkedIn. Je pense que les profils LinkedIn ont été mis dans le chat. Si vous avez des questions, je parle à leur nom, mais je pense qu'elles seront OK pour y répondre sans aucun souci. Je vous souhaite une bonne après-midi. Et j'ai oublié, vous pouvez rester dans la salle de Rémo si vous voulez continuer les discussions. On va rester un petit peu pour discuter avec vous. Merci beaucoup. Merci.