Introduction​

Bienvenue dans ce nouvel article qui va aujourd'hui porter sur ma première contribution open source. Celui-ci m'a servi de support pour une journée de conférences organisée au sein de mon entreprise. Je vous propose aujourd'hui de découvrir ce projet de l’intérieur, de revivre cette expérience à mes côtés et surtout de voir les leçons que j’en ai tirées.

L'open source en quelques mots​

Pour contextualiser ce que l'on entend par open source, je souhaitais en donner une brève définition, en m'appuyant sur mes lectures et des sources indiquées en fin de paragraphe.

On parle de logiciels open source lorsqu’il s’agit de logiciels dont le code source est mis à disposition du public. Autrement dit, tout individu, qu'il soit familier avec le code ou non, peut accéder au contenu, le modifier, et le redistribuer, le tout dans le respect des conditions définies par la licence open source adoptée.

Cette transparence permet une amélioration continue des logiciels, rendue possible par les contributions d’une communauté mondiale de contributeurs et contributrices. L’open source dépasse le cadre des logiciels : il incarne un mouvement philosophique fondé sur la collaboration, la transparence et le partage de connaissances. Cette approche permet de résoudre des problèmes techniques de manière collective, favorisant l'innovation et la création de solutions accessibles à tous et toutes. Un article plus détaillé sur ce sujet est disponible sur le site de Red Hat, offrant une perspective plus exhaustive sur les valeurs et les pratiques qui constituent le mouvement open source.

Source : https://www.redhat.com/fr/topics/open-source/what-is-open-source.

Comment contribuer ?​

La question que l'on se pose, et que je me suis posée moi-même est : comment contribuer ? J'avais une vision plutôt biaisée du monde de l'open source et je n'y voyais que des contributions techniques touchant au code sur des projets complexes, qui me semblaient tout simplement inaccessibles. En me renseignant, j'ai rapidement réalisé que l'on pouvait contribuer à l'open source de multiples façons. Voici quelques exemples. Un guide complet est disponible à la fin de ce paragraphe.

• contribuer au code : corriger un bug, maintenir un projet en faisant des mises à jour, proposer et développer de nouvelles fonctionnalités
• faire de la rédaction : créer ou compléter une documentation, écrire une newsletter
• effectuer des traductions ou des relectures
• créer des supports visuels : logo, illustrations, pictogrammes, etc.
• améliorer l'arborescence d'un site : restructurer un menu, améliorer le référencement
• organiser : parcourir les issues sur GitHub et clôturer les cas résolus ou relancer les contributeurs et contributrices
• aider : répondre à des demandes sur des plateformes telles que StackOverflow ou Reddit

Source : https://opensource.guide/

Mon projet de contribution : une traduction​

Storybook​

Passons maintenant au projet en question. Parmi toutes les façons de contribuer listées ci-dessus, je n'ai pas choisi de contribuer en codant. Depuis quelque temps, je travaillais sur un outil au sein de mon entreprise : Storybook. Il s'agit d'un outil de développement utilisé pour créer et documenter des composants d'interface utilisateur de manière isolée. Storybook est souvent utilisé dans des solutions JavaScript ou TypeScript et utilisant React, Vue ou encore Angular. Le Storybook est consultable sous la forme d'une interface et permet de créer, tester et documenter les composants de manière indépendante, faciliant ainsi leur développement en dehors du contexte de l'application principale.

Source : https://storybook.js.org/docs

En mettant en place Storybook au sein de notre projet, j'ai consulté la documentation et découvert un écosystème riche en tutoriels et en ressources adaptées aux développeurs et aux développeuses. Depuis quelques temps, j'avais envie de contribuer à un projet open source sans vraiment savoir par où commencer. En découvrant la possibilité de contribuer à l'enrichissement de la documentation de Storybook (le projet est intitulé Learn Storybook), j'y ai vu l'opportunité de travailler sur un outil que je connaissais et utilisais, tout en me replongeant dans le domaine de la traduction, en partageant mes connaissances. Avant d'être développeuse, j'ai en effet suivi des études de traduction et travaillé sur des projets de localisation en freelance, en traduisant une partie du contenu d'une application de l'anglais vers le français.

Exemple de traduction effectuée pour l'application Plume: https://support.plume.com/s/article/How-can-I-add-SuperPods-to-an-existing-Plume-account?language=fr

A la recherche de traductions​

Pour comprendre les directives et bonnes pratiques de contribution à la documentation de Storybook, je me suis rendue sur le dépôt GitHub du projet.

Une issue intitulée Translation Wanted répertoriait les versions déjà traduites, les versions à mettre à jour selon les version anglaises de référence et les différentes conversations entre contributeurs et contributrices. Elle contenait également un guide pour démarrer le projet.

J’ai demandé si la traduction des documentations encore manquantes intéressait d’autres contributeurs et contributrices, puis j’ai commencé à traduire le projet.

Source : https://github.com/chromaui/learnstorybook.com/pulls

Les tutoriels Learn Storybook​

Dans la documentation Learn Storybook, une traduction française existait déjà pour le premier tutoriel destiné aux développeurs et développeuses : Intro To Storybook

En parcourant le dépôt GitHub et le site de Storybook, j'ai remarqué que plusieurs contenus n'étaient pas encore traduits. J'ai alors choisi de traduire la documentation destinée à la création d'un design system pour les développeurs, intitulée Design Systems for Developers.

Ce tutoriel explique, via des ressources et plusieurs étapes, comment construire un design system avec Storybook en utilisant React .

Pour clarifier le sujet sur lequel j’ai travaillé, je souhaiterais vous expliquer ce que l’on entend par design system. Un design system est un ensemble de règles, composants et ressources qui représentent une base pour concevoir des interfaces utilisateurs cohérentes, de façon efficace et structurée.

Un design system comprend des composants, des règles de style ou de mise en page permettant maintenir une cohérence visuelle et fonctionnelle au sein d'une ou plusieurs applications. Il évite en outre aux développeurs et développeuses de copier-coller des composants ou encore d'ajouter manuellement des styles, couleurs ou polices déjà existants.

En résumé, les principales ressources d'un design system sont les éléments suivants (liste non-exhaustive) :

• composants UI réutilisables
• styles et éléments visuels : palette de couleur, typographie, espacement, iconographie
• comportements : animations, éléments interactifs selon des états (survol d'un bouton par exemple)
• règles d'accessibilité
• documentation : bonnes pratiques pour les développeurs, exemples de composants
• maintenabilité : outils de tests, synchronisation avec les mises à jours selon l'évolution d'un entreprise, gestion des versions

Voici quelques exemples de design system intéressants :

• le design system de l’État, avec des codes et des règles bien définis : https://www.systeme-de-design.gouv.fr/fondamentaux/couleurs-palette
• le design system de GitHub : https://primer.style/
• le Lightning Design System de Salesforce : https://www.lightningdesignsystem.com/guidelines/color/overview/
• le design system de Shopify : https://polaris.shopify.com/

Sources : https://www.uxpin.com/studio/blog/storybook-examples/

Zoom sur le processus de traduction​

Découvrir et se familiariser avec le sujet​

Je vous propose à présent de vous expliquer brièvement un processus de traduction. Tout d'abord, il faut lire la version originale du projet à traduire. J'ai choisi de suivre le tutoriel afin de me familiariser avec le projet, la sémantique et tout simplement aussi connaître le sujet.

A noter que tester un projet ou lire un contenu original permet aussi de repérer des incohérences ou des mises à jours manquantes, qui peuvent être également signalées à la communauté et aider les utilisateurs et utilisatrices.

J'ai ensuite jeté un œil à la version française du premier tutoriel afin de lister certains concepts et leurs traductions ou au contraire, repérer les cas où l'on ne les traduit pas. Par exemple, Storybook ou design system se traduisent très rarement en français, suivant le contexte. On a en règle générale tendance à réutiliser la version anglaise. Il en est de même pour les termes Pull Request ou commit, si l'on considère que la cible de la documentation sont des personnes qui font du développement web.

Une fois cette ébauche de glossaire amorcée, j'ai lu les recommandations de traduction indiquées dans l'issue GitHub :

• pas de traduction des commentaires dans le code
• pas de traduction des noms des fichiers
• indications pour lancer le projet en local et vérifier si la mise en page n'a pas cassé.

La Traduction Assistée par Ordinateur (TAO)​

Afin de traduire de façon simplifiée et automatique, j'ai utilisé ce que l'on appelle un outil de Traduction Assistée par Ordinateur, aussi appelé outil de TAO. Mon logiciel préféré est SDL Trados, mais il est payant et généralement utilisé à des fins professionnelles.

J'ai choisi un autre logiciel que j'utilisais quand j'étais étudiante : OmegaT. Il s'agit d'un logiciel open source qui fait très bien le travail.

En lançant le logiciel sur notre ordinateur, il faut avant tout créer un projet :

• on choisi les langues cibles et source
• on y ajoute les dossiers ou fichiers à traduire
• on peut ajouter des glossaires ou des mémoires de traduction (bases de données de segments déjà traduits qui permettent de trouver des correspondances et accélérer le processus de traduction)

Le logiciel va ensuite segmenter les paragraphes ou phrases à traduire. On peut choisir par exemple dans les paramètres de segmenter par phrase, à chaque point, à chaque paragraphe ou personnaliser la segmentation à notre convenance.

Au fur et à mesure de la traduction, le glossaire se remplit et le logiciel détecte les occurrences et les traduit automatiquement. J'ai aussi pu lui indiquer les mots que l'on ne traduisait pas dans le glossaire et ainsi ajouter des règles personnalisées pour ce projet.

Une fois les fichiers traduits, je suis passée par de longues phases de relecture, de recherches sur des termes techniques afin de rendre la traduction la plus fluide possible. Puis, j'ai forké le dépôt GitHub : c'est-à-dire que l'on crée une copie du dépôt existant dans notre propre compte GitHub. J'ai ensuite créé une branche et ajouté les fichiers traduits. Enfin, j'ai lancé le projet en local afin de m'assurer que la mise en page n'était pas cassée.

D'une certaine manière, on pourrait se dire qu'un processus de traduction n'est pas si différent de celui du développement d'une fonctionnalité :

• on dispose de spécificités (contextuelles, fonctionnelles)
• d'une nomenclature ou de terminologies
• de bonnes pratiques
• d'une mise en page
• d'une étape de tests et de relecture du contenu
• d'une mise en production ou d'une livraison du projet

La phase de relecture​

Une fois ma première version de la traduction effectuée, j'ai pu ouvrir ma toute première PR ! Très vite, un contributeur français est venu ajouter des commentaires, et a soulevé certains sujets intéressants comme la définition d'un terme puis la possibilité de n'utiliser que abréviation, ou encore la cohérence de certaines définitions.

A l'heure où j'écris cet article, ma PR n'est pas encore mergée, elle est phase de relecture.

Je suis cependant très contente de vous partager cette première étape de ma contribution, et ce, même si elle n'est pas encore ligne. A mes yeux, c'est déjà un plaisir d'avoir pu proposer quelque chose à un projet tel que les tutoriels de Storybook.

Si vous êtes curieux et curieuses, vous pouvez jeter à un œil à ma PR ici : https://github.com/chromaui/learnstorybook.com/pulls

Bilan et prise de recul​

De manière générale, en commençant cet article, je trouvais ce sujet banal. Je me suis dit qu'aux yeux de beaucoup de personnes qui contribuent, ouvrir une PR et raconter ce processus pouvait être vu comme une simple routine. Bien qu'en tant que développeuse, cela fasse aussi partie de ma routine professionnelle, cette première PR open source était pour moi chargée de sens.

Dans cette partie, j'aimerais mettre en avant mes réflexions et ma prise de recul quant à cette contribution.

Je ne suis pas obligée de contribuer​

Bien que ce projet ne m'engageait à rien, j'ai eu un peu d'angoisse sur la qualité du travail que j’allais fournir : Est-ce que mes traductions sont bonnes ? Est-ce que le projet est vraiment utile ? Et si personne ne relit ma PR, que devrais-je en conclure ? Beaucoup de pression pour au final un projet qui repose sur du volontariat, et où personne ne viendra me reprocher d'avoir essayé et proposé quelque chose !

Cependant, les retours rapides m'ont fait réalisé que le projet allait continuer à tourner et plein d'autres idées me sont venues, comme mettre à jour la version française de la première traduction ou encore de proposer un guide de traduction en français avec des glossaires.

La documentation, souvent oubliée mais appréciée​

Les projets de documentation sont importants. Dans le monde du développement web, ils sont souvent oubliés ou abandonnés en cours de route, et donc rapidement obsolètes.

Pourtant, ils contribuent à une prise en main rapide d'un projet, à une compréhension facilitée d'une technologie ou d'un contexte.

Enfin, je trouve personnellement que la documentation contribue à l'accessibilité d'un projet pour tous et toutes :

• une documentation traduite permet de garantir un accès international et culturel
• une documentation claire et hiérarchisée permet de garantir un accès rapide à l'information recherchée
• une documentation simple permet de donner accès à la connaissance à des développeurs et développeuses débutants
• une documentation avec des supports variés (vidéos, infographies, démos, support Discord) permet de garantir un accès total pour tous types d'utilisateurs, en s'adaptant à leur manière d'apprendre Enfin, rendre la documentation accessible à des contributeurs et contributrices en ligne permet de garantir sa bonne mise à jour et de l'adapter aux besoins des utilisateurs et utilisatrices.

Prendre du plaisir avant tout​

J'ai enfin appris à ne pas trop prendre à cœur le projet. C'est un projet collaboratif, je ne le fais pas dans le cadre de mon travail, je ne suis pas obligée de le faire pour prouver quoique ce soit. En vérité, j'y prends beaucoup de plaisir et j'apprends tout en contribuant, que ce soit dans les domaines du développement web ou de la traduction.

Ce genre d'initiative apporte tout de même une certaine fierté de contribuer à un projet, d'apporter sa pierre à l'édifice et de découvrir ou consolider ses connaissances dans le fonctionnement d'une technologie ou d'un logiciel. On gagne en confiance !

Enfin, en tant que femme, cela me permet d’ajouter une brique dans le monde de l’open source, où les femmes sont encore trop peu représentées.

Les femmes et l'open source​

Quelques chiffres et ressources​

Avant de conclure cet article, je souhaitais en quelques mots rappeler que les femmes sont encore trop peu présentes dans le monde de l'open source. Selon une étude de la Linux Foundation, on compterait 7 à 10% des femmes parmi les personnes qui contribuent à l'open source. Ce chiffre était de 2% en 2006, donc l'évolution est plutôt positive, on avance !

Source : https://openforumeurope.org/where-are-women-of-open-source/

Ces chiffres s'expliquent en outre par le nombre plutôt faible de femmes ingénieures ou évoluant dans les métiers du développement web. J'ai cependant lu d'autres faits et témoignages de femmes qui ont été confrontées à des remarques dévalorisantes liées à leur genre, ou encore qui ont vu leurs contributions complètement ignorées, surtout dans les initiatives qui touchaient à du code. Ce cas de figure se retrouvait moins dans les projets de rédaction ou de design.

Afin d'éviter d'être confrontées à ce genre de situations, certaines ont choisi de renommer leurs pseudos avec des noms neutres. A noter que ce genre de comportement touchait également la couleur de peau, les origines ou encore l'orientation sexuelles des contributeur.ices.

Source : https://fr.wikipedia.org/wiki/Diversit%C3%A9_dans_le_mouvement_open_source

Des modèles féminins dans la tech​

Tout au long de la préparation de ce projet, de cet article et de la conférence qui en découle, je me suis intéressée à ce sujet, et j'ai commencé à chercher des informations sur les femmes dans l'open source en parallèle de mes recherches sur Storybook.

A ma grande surprise, je suis tombée sur le tweet d'une femme qui traduisait la version espagnole de cette documentation et qui l'avait mise en ligne l'année dernière. Elle était très fière. Il y a quelques semaines, elle a ouvert une autre PR pour mettre à jour sa traduction et proposer une traduction du tutoriel qui touche aux design system. Cette anecdote peut paraître simpliste, mais cela m'a fait plaisir et m'a motivée pour avancer sur ma traduction. En toute honnêteté, je me suis davantage identifiée à elle qu'à un homme et je pense que cela a contribué à me redonner de la confiance et de la motivation.

Il y a quelques semaines, j'ai assisté à un événement de conférences en ligne appelée Open Tech Con. Une femme proposait une conférence et a évoqué un fait intéressant : lorsque l'on mentionne les femmes dans la tech, on aime parler de Ada Lovelace par exemple, mais qui appartient à une certaine époque. Pouvons-nous toutes dire que nous nous identifions à elle ? Pendant sa conférence, Marcy Ericka Charollois appuyait le fait qu'il est aussi important de mettre en avant le travail des femmes d'aujourd'hui et d'ainsi avoir des modèles actuels et inspirants. Personnellement, Marcy Ericka Charollois et Lucy Macartney qui travaille sur le même projet que moi font partie de ces modèles.

Ressources sur Lucy Macartney contributrice du projet de la documentation de Learn Storybook : https://codingwithlucy.hashnode.dev/

Ressources sur les conférences de Marcy Ericka Charollois : https://www.paris-web.fr/orateurs/marcy-ericka-charollois

Lien vers le site de la conférence Open Tech Con : https://opentechcon.fr/programme/

Conclusion​

Si je devais retenir une leçon de cette première contribution open source : peu importe la taille de la contribution, l'important est de se lancer, si on en a envie ! Contribuer à l'open source m'a rappelé qu'il n'est pas nécessaire de viser la perfection dès le début, car c'est une initiative collective. Ce sont les tentatives, les échecs et les retours constructifs qui nous aident à progresser.

Au-delà des compétences techniques, c'est un formidable terrain pour développer : sa communication, sa résilience ou encore sa patience.

Que ce soit une PR acceptée, un commentaire constructif reçu, ou même une conférence donnée, ces étapes représentent des jalons qui renforcent la confiance en soi.

En écrivant cet article et en donnant une conférence, je célèbre avec vous une autre petite victoire personnelle !

Cette checklist a été élaborée lors d'un projet de refonte. Elle n'est pas exhaustive mais permet de passer en revue les critères de base en matière d'accessibilité web. Elle a été créée en se basant sur la checklist de ContentSquare que vous pouvez télécharger ici : https://contentsquare.com/fr-fr/insights/guide-accessibilite-numerique/ (formulaire à remplir)

Aspects utiles pour les élément du design system / des maquettes​

Handicap visuel​

Contraste​

• Ratio de contraste police général : 4.5:1
• Ratio de contraste pour textes gras de plus de 18.5px ou texte de plus de 24px : 3:1
  • Ressources sur les contrastes : https://stephaniewalter.design/fr/blog/accessibilite-et-couleurs-outils-et-ressources-pour-concevoir-des-produits-accessible/

Navigation clarifiée​

• Distinguer les en-têtes (h1,h2,h3, etc.)
• Espacements : aérer les paragraphes, ajouter des sous-titres si c'est nécessaire
• Proposer un menu clair : navigation simple, fil rouge, plan du site

Texte et typographie​

• Utiliser une police d'au moins 14px ou permettre un bon affichage avec la fonction zoom du navigateur
• Ne jamais justifier le texte
• Éviter les textes entièrement en majuscules

Formulaires​

• Privilégier un contraste fort entre l'input et le label
• Placer l'étiquette et le conseil à l'extérieur du champ

Exemple :

Liens​

• Ajouter une couleur différente, un soulignement ou une police plus grande pour indiquer un lien

Contenu​

• Développer les abréviations telles que "janvier" au lieu de "janv."
• Éviter les tirets tels que "8-10" pour indiquer "de 8 à 10"
• Développer les acronymes au moins une ou deux fois

Handicap auditif​

• Notifications visuelles

On n'aura sûrement pas de son pour des notifications, mais on peut veiller à ce qu'une notification puisse être bien explicite.

Exemple :

​

Handicap cognitif​

Police​

• Privilégier les polices bâtons ou sans sérif (à voir comment ça s'articule avec la police d'elmy mais d'expérience elle était conforme)

Importance d'un texte​

• Éviter les majuscules ou l'italique pour souligner l'importance d'un texte
• Privilégier les polices en gras ou les encadrés

Images​

• Parfois une image vaut plus qu'un mot, s'il est bien accessible : voir si on peut ajouter une image pour élément qui ne serait pas assez clair (plutôt côté funnel je pense)

Design​

• Être cohérent et constant au niveau des polices, couleur et hiérarchie (je trouve que c'est déjà le cas)

Aspects utiles pour le développement​

Documents de référence​

• https://fr.reactjs.org/docs/accessibility.html
• https://design.numerique.gouv.fr/articles/2021-10-06-assistant-rgaa/

Handicap visuel​

Texte alternatif pour les images​

• Ajouter systématiquement un texte alternatif pour les images

Handicap physique​

Navigation​

• Veiller à pouvoir naviguer entre les input et les menus sans la souris

Comment tester ?​

Introduction​

Bienvenue à cette introduction sur l'accessibilité web ! L'idée de cet article est d'avoir un aperçu des notions de handicap et d'accessibilité web et de comprendre les réglementations et les normes en matière d'accessibilité web.

À travers cet article, j'espère pouvoir vous guider vers de bonnes pratiques en matière de contenu, de design et de développement web, en ayant conscience des différents handicaps et des outils utilisés par les personnes en situation de handicap. Enfin, je vous expliquerai les différentes manières de tester l'accessibilité d'un site web, tout en pointant les limites de certains outils.

Bonne lecture ! 🐌

Définir le handicap​

• incapacité temporaire
• incapacité situationnelle
• incapacité permanente

Afin d'illustrer mes propos, voici différentes situations que peuvent vivre certaines personnes, et qui font qu'à un moment de leur vie, qu'il soit durable ou non, elles seront confrontées à une situation de handicap.

• Jean est en fauteuil roulant depuis sa naissance : handicap moteur permanent.
• Jeanine a une otite séreuse, elle n'entend pas bien depuis 15 jours : handicap auditif temporaire.
• Yves est serveur au Mi Casa, et aujourd'hui, il y a de la musique et beaucoup de gens, il n'entend pas bien : handicap auditif situationnel.
• Marie est sourde depuis sa naissance : handicap auditif permanent.
• Justine s'est cassé le bras, elle ne peut pas utiliser son nouveau clavier : handicap moteur temporaire.
• Florian est alsacien et il a un accent très prononcé, à Marseille personne ne le comprend : handicap situationnel.

Dans le cadre de l'accessibilité web, l’exclusion physique, cognitive et sociale ne découle pas de l’état de santé de la personne, mais plutôt de son incapacité à interagir avec une interface.

Définir l’accessibilité web​

• L’accessibilité web se définit par des sites web et des technologies développés pour que les personnes en situation de handicap puissent les utiliser.
• Elle n’est pourtant pas exclusivement réservée aux personnes handicapées : elle facilite notamment l’utilisation d’un site web et d’une application pour tous les utilisateurs.
• Lorsqu’un site web est accessible, l’utilisateur peut percevoir, comprendre, naviguer, mais aussi interagir et créer du contenu.
• L’accessibilité numérique ne consiste pas à créer de nouvelles technologies, mais s’attache plutôt au respect de normes techniques afin de rendre les technologies et supports numériques adaptés aux situations de handicap.

Source : https://www.w3.org/WAI/fundamentals/accessibility-intro/fr

Réglementer l’accessibilité web : W3C, WCAG et WAI​

Le World Wide Web Consortium (W3C) développe des standards internationaux pour le web : vous connaissez sûrement PNG, SVG, URI. Ces standards font partie des Recommandations du W3C et ils sont revus pour la prise en compte de l'accessibilité.

Vous pouvez en apprendre plus ici : https://www.w3.org/WAI/standards-guidelines/fr et ici : https://fr.wikipedia.org/wiki/Standards_du_Web

Le WCAG : Web Content Accessibility Guidelines​

C'est la norme internationale du W3C pour l’accessibilité des contenus web, reconnue par la Commission européenne. Elle est caractérisée par 4 grands principes pour définir l’accessibilité d’un site :

• perceptible : alternative textuelle aux images, aux boutons, taille des caractères correcte ou modifiable, la couleur ne doit pas être le seul moyen de donner une information

• utilisable : navigation au clavier facilitée, plusieurs manières de naviguer, éléments lisibles et utilisables, évitement des éléments susceptibles de provoquer des crises telles que les lumières clignotantes, organisation du contenu avec des titres pour chaque partie

• compréhensible : informations simples à trouver, correction ou anticipation des erreurs, langue facilement détectable par le lecteur d'écran, navigation facilement identifiable et cohérente

• robuste : application utilisable sur de nombreux supports et anticipation des améliorations

Source : https://www.w3.org/Translations/WCAG20-fr/

On parle également de différents niveaux d'accessibilité :

• niveau A : le site et ses contenus remplissent tous les critères essentiels d’accessibilité
• niveau AA : l’accessibilité est optimisée et approfondie
• niveau AAA : l’accessibilité est excellente à tout point de vue, le site respecte tous les critères

Le référentiel français : RGAA​

En France, le référentiel d'accessibilité est le Référentiel Général d’Amélioration de l’Accessibilité (RGAA), il se base sur le WCAG. Il comporte 106 critères consultables ici : https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/ .

La loi française n°2005-102 du 11 février 2005 veut rendre accessibles tous les services de communication publique en ligne de l’État, des collectivités territoriales et des établissements publics qui en dépendent. Elle prône l’utilisation des WCAG pour mesurer la conformité d’un site web.

Les obligations légales en matière d'accessibilité​

Qui est concerné ?​

Les obligations légales d'accessibilité concernent les organismes et entreprises suivants :

• les services de l'Etat
• les collectivités territoriales
• les établissements publics
• les entreprises en France dont le chiffre d'affaires est supérieur à 250 millions d'euros
• les organisations d'intérêt général

Les outils concernés par les normes en matière d'accessibilité sont :

• les sites web, intranets, extranets, logiciels
• les mobiliers extérieurs numériques
• les applications

Quelles obligations ?​

L'organisme ou la société concerné.e doit être en mesure de fournir un service en conformité aux critères applicables du RGAA de niveau A et AA.

Sur le service en ligne, doivent également figurer :

• Une page d’aide à l’utilisation des composants complexes
• Une liste de contenus dérogés et des moyens de justification
• Une solution d’assistance pour permettre aux utilisateurs de pallier les difficultés rencontrées

Les indices d'évaluation sont les suivants :

• Conforme (C) (j'ai aussi vu Totalement Conforme sur certains sites)
• Non conforme (NC)
• Non applicable (NA)
• Non testé (NT)

Trois documents sont nécessaires pour attester l’accessibilité d’un site internet :

• Une déclaration d’accessibilité justifiant la mise en conformité au RGAA avec le niveau de conformité et des éléments expliquant la raison des non-conformités
• Un schéma pluriannuel de mise en accessibilité sur 3 ans
• Des plans d’actions annuels élaborés à partir du schéma pluriannuel

Quelle loi ?​

La loi à respecter est la suivante : https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000006682279/2022-11-17/

Les obligations des entreprises ou organismes concernés sont un respect des critères du RGAA ainsi qu'une déclaration d'accessibilité à publier sur la solution en question. Si les critères ne sont pas tous remplis, la déclaration permet d'attester du premier travail d'accessibilité effectué, des pages ou modules concernés, etc.

Voici quelques exemples de sites remplissant les critères RGAA et/ou qui ont ajouté une déclaration d'accessibilité :

• La Métropole de Rennes https://metropole.rennes.fr/43-communes a opté pour un outil de surcouche (nous en reparlerons plus tard).
• Vous pouvez aussi consulter d'une déclaration d'accessibilité sur le site de la Commission européenne (niveau AA) : https://commission.europa.eu/accessibility-statement_fr.
• Sur ce site, vous pouvez voir la mention d'une non conformité : https://conformite.education.fr/?appli=galaxie
• Autre exemple de déclaration d'accessibilité sur un site totalement conforme (niveau AAA): https://www.service-public.fr/P10000

Quelles sanctions ?​

Les risques encourus sont une amende de 20 000 euros par service en ligne. Pour en apprendre plus sur les sanctions, vous pouvez consulter ce lien.

Comprendre ses utilisateurs​

Tester les technologies d'assistance​

Les personnes en situation de handicap sont souvent amenées à utiliser divers outils sur leur ordinateur ou leur téléphone. Il est intéressant de les tester, pour se rendre compte de comment ces outils se comportent sur les sites. Ils permettent à la fois de mieux comprendre les utilisateurs et de détecter les écueils sur nos applications.

• les lecteurs d’écran

Le logiciel restitue l’information affichée à l’écran en mode texte. Il existe différents types de lecteurs d'écran :

• un composant intégré au système d'exploitation, comme VoiceOver sur Mac ou le Narrateur sur Windows
• un plug-in, comme ChromeVox, qui permet de lire certaines informations dans le navigateur
• un logiciel (JAWS, NVDA, Orca, etc.) à télécharger et installer sur le système d'exploitation, qui permet d'accéder à l'ensemble du système et de ses applications.

Voici comment fonctionne un lecteur d'écran : https://www.youtube.com/watch?v=DePdWynmd_Y

Pour aller plus loin et comprendre leur utilisation : https://www.ionos.fr/digitalguide/sites-internet/developpement-web/lecteurs-decran-logiciels-pour-malvoyants-et-non-voyants/

• les plages brailles

Elles sont utilisées comme des tablettes numériques classiques et permettent de consulter une page web en braille.

• Exemple d'utilisation d'une plage braille : https://www.ceciaa.com/technologie-braille-relief/terminal-braille/plage-braille.html
• Vidéo sur l'utilisation d'une plage braille : https://www.youtube.com/watch?v=fi6mYmfaRLk

• le clavier

De nombreuses personnes utilisent uniquement le clavier pour naviguer sur un site web.

• les souris et claviers alternatifs

Il existe une multitude de souris et de claviers adaptés à différents handicaps : touches plus grosses, souris ergonomiques, clavier mono-manuel, etc. Vous trouverez plusieurs exemples sur ce site : https://www.zenlap.fr/handicap

• les applications DYS :

Les personnes atteintes de troubles DYS (dyslexie, dysorthographie et dysgraphie) bénéficient elles aussi d’outils d’aide à la lecture ou l'écriture. Elles peuvent également être amenées à utiliser les lecteurs d'écran.

Voici également un article qui décrit une liste de lecteurs d'écrans et d'outils utilisés pour limiter les flashs et les publicités dans certains cas de troubles cognitifs : https://wiki.lalutineduweb.fr/handicap/mes-aides-techniques/

Les bonnes pratiques en matière d'accessibilité

Les couleurs et les contrastes​

Source : https://stephaniewalter.design/fr/blog/accessibilite-et-couleurs-outils-et-ressources-pour-concevoir-des-produits-accessible/

Je vais ici mettre l'accent sur les couleurs et les contrastes. Afin de permettre une meilleure lisibilité et un certain confort pour les personnes malvoyantes (mais pas que), il faut veiller en premier lieu à garantir un bon contraste entre le fond et le texte. Mais comment on s'assure de ce ratio ?

En matière de respect des normes, voilà à quoi cela ressemble :

• niveau A : la couleur n'est pas utilisée comme la seule manière de véhiculer une information, ou une erreur.

Exemples :

• Chez elmy, lorsque nous avons développé les graphiques du suivi de consommation sur l'espace client, nous avions initialement une couleur verte pour indiquer une donnée manquante ou partielle, et une autre couleur verte pour indiquer une donnée. Il a été convenu de plutôt utiliser des hachures pour différencier ces données, et d'indiquer une petite légende en bas du graphique. Cette technique permet d'améliorer la lecture pour les personnes qui ont des difficultés à percevoir les couleurs.

• niveau AA : les rapports de contrastes sont écrits sous la forme suivante : [L1;L2]. L1 indique la luminance de la couleur la plus claire et L2 celle de la couleur la plus sombre. Les textes standards doivent avoir un ratio de contrastes d'au moins 4,5:1. Les grands textes doivent avoir un ratio de contraste d'au moins 3:1.

• Niveau AAA (contraste optimal): les textes standards doivent avoir un ratio de contrastes d’au moins 7:1. Quant aux grands textes, leur ratio de contraste doit être d’au moins 4,5:1.

Pour tester le ratio, beaucoup d'outils et d'extensions sont à notre disposition :

• WEBAIM ContrastChecker : https://webaim.org/resources/contrastchecker/
• Siegemedia : https://www.siegemedia.com/contrast-ratio#%23fff-on-%23000000
• Tableau récapitulatif des ratios et exemples de contrastes : https://developer.mozilla.org/fr/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast

Les images​

Les personnes malvoyantes ou aveugles ont une impossibilité ou une difficulté à percevoir les images. En étant aidées d'un lecteur d'écran, il est possible pour elles de comprendre l'illustration si on prend en compte quelques bonnes pratiques.

Je parlerai ici de pratiques liées au développement web. Lorsqu'une image est ajoutée dans notre code, on a la possibilité d'ajouter un attribut alt. Voilà à quoi le code HTML d'une image peut ressembler :

Mauvaise pratique

<img src="foret-neige-finale.jpg" />

Bonne pratique

<img src="foret-neige.jpg" alt="Photo d'une forêt de pins enneigée et illuminée par le soleil." />

L'attribut alt est-il vraiment obligatoire ?​

Apparemment non, mais il faut au moins mettre l'attribut alt, même s'il est vide, pour permettre aux lecteurs d'écran d'indiquer qu'il y a une image. C'est souvent le cas d'images purement décoratives, comme la bannière sur la page de votre blog. En cas de doute, il est possible de consulter cet arbre de décision : https://www.w3.org/WAI/tutorials/images/decision-tree/

L'accessibilité des images ne concerne pas que les sites web ! De plus en plus de réseaux sociaux permettent également de renseigner des attributs alt, comme Twitter (X). Pourtant, rien ne nous empêche d'indiquer nous-même en description ce que comporte l'image : par exemple dans la description d'un post Instagram ou Facebook.

L'essentiel est d'éviter au maximum les textes directement inclus dans les images, car les lecteurs d'écran ne peuvent pas les lire.

On pense également aux petits pictogrammes dans les interfaces de paiement, qui doivent comporter leur attribut alt !

Le contenu textuel​

• Le choix de la police : bien choisir sa police garantira un contenu clair et lisible par le maximum d'utilisateurs. Les polices classiques sont à privilégier, et il faut en général éviter les contenus tout en majuscules.
• La taille de texte doit être au minimum de 16px.

En matière de développement, il est conseillé d'utiliser des tailles relatives grâce à em ou rem accompagnées qu'un ratio : Privilégiez ainsi ce type de paramètres pour vos tailles de polices :

html { 
font-size: 62.5%; /* ratio qui permet une correspondance entre rem et px */
}
body { 
font-size: 1.6rem; /* = 16px */
} 
h1   { 
font-size: 2.4rem; /* = 24px */
} 

Elles s'adapteront ainsi mieux au support d'affichage.

• Hiérarchiser correctement le contenu pour les lecteurs d’écran. On utilise différents niveaux de titres pour avoir un contenu clair : on utilise donc correctement les balises h1, h2 etc. pour nos titres ! Aérer le contenu avec des espaces, des paragraphes courts, des listes, rend la lecture plus aisée.
• Avoir un contenu clair et simple : pas besoin d'y aller par quatre chemins. Plus l'information est simple, plus l'expérience utilisateur sera satisfaisante : alors on privilégie un vocabulaire accessible, on défini les acronymes et on utilise le moins d'abréviations possibles.
• Accompagner l’utilisateur : fournir des textes alternatifs pour les images ou encore des transcriptions pour les vidéos contribue à une meilleure expérience utilisateur. Les liens, les boutons de navigation ou de téléchargement doivent être explicites : l'utilisateur doit savoir ce qui se cache derrière.

Des documentations plus techniques sur l'accessibilité des formulaires sont disponibles par ici :

• https://www.w3.org/WAI/tutorials/forms/
• documentation ARIA : https://developer.mozilla.org/fr/docs/Web/Accessibility/ARIA

Vidéo et audio​

Les médias audio et vidéos sont aussi concernés par les normes en matière d'accessibilité.

• Les vidéos doivent être sous-titrées : en plus de bénéficier aux personnes avec un handicap auditif, elles sont très pratiques lorsqu'on est confrontés à un handicap plutôt situationnel. Par exemple : je suis dans le train et je veux regarder une vidéo sans activer le son. Il faut bien veiller à ce que les sous-titres respectent les normes d'accessibilité des contenus textuels : ratio de contrastes, taille suffisante et animations limitées.

• Les contenus audios tels que les podcasts doivent comporter une transcription sur la même page ou sur une page dédiée, peu importe, tant qu'elle est facilement accessible. La transcription textuelle est de nouveau utile pour d'autres personnes que celles en situation de handicap auditif : on pense par exemple à l'utilisateur qui ne dispose pas d'une bonne connexion internet.

• Ici, un exemple de transcription d'un contenu vidéo : https://www.ted.com/talks/ji_hae_park_the_violin_and_my_dark_night_of_the_soul/transcript
• Sur la page dédiée à l'accessibilité de ce site, on peut retrouver une transcription des podcasts : https://nouvellesecoutes.fr/accessibilite/

En matière de développement, et si votre vidéo ou votre audio est inclus dans une page web, il faut s'assurer que son utilisateur pourra la démarrer peu importe son mode de navigation, la vidéo doit donc pouvoir être consultable en utilisant uniquement les touches du clavier.

Pour en apprendre plus, c'est par ici :

https://developer.mozilla.org/fr/docs/Learn/Accessibility/-Multimedia#cr%C3%A9ation_de_contr%C3%B4les_audio_et_vid%C3%A9o_personnalis%C3%A9s

• Proposer des services personnalisés : on peut aller plus loin en matière d'expérience client, et proposer des services adaptés aux handicaps.

Je vous partage ici deux cas intéressants de services personnalisés :

Des tutoriels bricolages et un appel avec le service client en Langue des Signes : https://www.mr-bricolage.fr/accessibilite-c.html

Des services personnalisés et un outil de surcouche : https://www.bouyguestelecom.fr/accessibilite-services

Les animations​

Les animations sur un site web ou composant, ça fait toujours son petit effet. Elles peuvent cependant être un véritable calvaire pour certains handicaps : problèmes vestibulaires, épilepsie, ou encore troubles cognitifs. Elles peuvent déclencher des crises ou distraire l'utilisateur.

Il faut ainsi éviter au maximum les flashs répétés ou encore les passages brutaux du sombre au clair. S'il y a des animations, comme un slider qui défile, elles doivent pouvoir être interrompues. Aussi, l'ouverture d'une popup ou le téléchargement d'un document devrait être notifié à l'utilisateur.

Exemples de boutons stop pour un slider

• https://www.atalan.fr/agissons/fr/index.html
• https://www.sncf.com/fr

Un contenu simple et aéré​

• Les troubles DYS (incluant notamment la dyslexie) se traduisent en général par des difficultés à la lecture, à l’écriture et à la reconnaissance des mots et des lettres. Les personnes concernées peuvent parfois avoir recours aux lecteurs d’écrans.
• Les personnes avec des handicaps moteurs ou neurologiques peuvent également avoir des difficultés à se repérer et à naviguer sur un site web. Certaines personnes n'utilisent pas d'outils d'assistance, il est donc primordial de garantir un site clair, aéré et bien structuré dans la mesure du possible.
• Les personnes atteintes de troubles cognitifs ont le même droit à l’information que les autres. Un bon exemple de sites web accessibles : Pôle Emploi : https://www.pole-emploi.org/accueil/actualites/pole-emploi-publie-son-rapport-d.html?type=article ou encore Wikipédia : https://fr.wikipedia.org/wiki/Wikip%C3%A9dia_en_anglais_simple proposent des contenus ou des documents en version simplifiée. Les institutions publiques utilisent de plus en plus souvent un langage simple pour les textes d’information.
• Autre exemple de contenu dit FALC (Facile à Lire et à Comprendre) : https://www.culture.gouv.fr/Thematiques/Developpement-culturel/Culture-et-handicap/Facile-a-lire-et-a-comprendre-FALC-une-methode-utile

Tester l'accessibilité​

Outils de tests automatiques et extensions​

Le site est déjà en ligne

Dans le cas où notre projet serait déjà en ligne, et que l'on n'a pas pu le rendre accessible, on peut vite se retrouver débordé.e et ne pas savoir par où commencer. Pas de panique, plusieurs solutions s'offrent à nous !

On peut déjà commencer par tester différents outils et avoir un aperçu de l'accessibilité de notre site.

Voici quelques exemples d'outils :

• Tester les contrastes : https://webaim.org/resources/contrastchecker/
• Comprendre comment verront nos utilisateurs avec des troubles tels que le daltonisme : http://colororacle.org/
• Analyser de façon plus complète l'accessibilité du site : https://wave.webaim.org/ WAVE (extension)
• Inspecteur sur Firefox : https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/index.html
• Lighthouse : https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=fr
• L'Assistant RGAA : https://design.numerique.gouv.fr/articles/2021-10-06-assistant-rgaa/. Je trouve cette extension vraiment pratique pour contrôler la conformité RGAA en étant directement sur la page à tester. C'est plus une checklist qu'un outil de contrôle automatique.

Il faut cependant avoir en tête que ces outils automatiques ne repèrent que 20 à 30 % des critères d'accessibilité.

Ils ne remplacent surtout pas un utilisateur et se limitent très souvent au handicap visuel. Ils ne sont pour autant pas à négliger, car ils constituent une bonne base.

Le site n'est pas encore créé

Dans le cas où l'on souhaiterait mettre en place l'accessibilité au début d'un projet, l'avantage, c'est qu'on peut inclure l'accessibilité web dès sa phase de conception. Elle implique donc la participation des UX/UI designer, des rédacteur.ices, des product owner et enfin des développeur.euses.

Dans les deux cas : mettre en place des phases de test

On peut penser à inclure des tests utilisateurs spécialement dédiés à l'accessibilité. La sensibilisation de toutes et tous est primordiale et peut se traduire par l'intervention d'experts en accessibilité (souvent dans les cas où la loi exige l'accessibilité d'un site), d'ateliers et de découverte / veille en la matière. Idéalement, inclure des testeurs en situation de handicap garantit des retours plus fiables.

Les outils présentés ci-dessus sont intéressants à utiliser même quand on n’a pas de handicap, ils permettent de mieux comprendre la réalité d’une situation et les défauts d’une application. Ils ne remplacent en rien l’expérience vécue par la personne et ne représentent pas tous les handicaps. Il peut y avoir des risques de biais cognitifs si on prend systématiquement pour acquis des tests effectués par des personnes valides.

Pour en savoir plus sur les biais cognitifs de manière plus générale : https://www.ux-republic.com/les-10-biais-cognitifs-les-plus-repandus/

Tests sans personnes en situation de handicap permanent

Ils peuvent tout de même donner des pistes sans qu’on ne s’en rende vraiment compte, car un testeur peut avoir été en situation de handicap temporaire (soleil dans les yeux, tests dans le métro).

Tests avec des personnes en situation de handicap permanent

Ils sont beaucoup plus fiables, mais nécessitent d’être effectués par des personnes en situation de handicap, qui utilisent des outils spécifiques comme les lecteurs d’écrans. L'équipe qui travaille sur le projet n'a pas forcément les personnes recherchées. On peut envisager des séances de tests en invitant des personnes concernées par certains handicaps (nécessite une certaine organisation si ces personnes sont externes à l'entreprise).

Tests et encadrement par un expert en accessibilité web

On peut faire appel à des experts en accessibilité web vont être embarqués pendant la phase de conception d'un projet et ainsi aider à garantir des supports et des tests solides, afin de mettre le produit en conformité.

Les retours utilisateurs

On peut suivre les retours des utilisateurs sur un projet existant et commencer à améliorer l'outil au fur et à mesure. Pour obtenir davantage de retours, on peut lancer des sessions de tests avec des utilisateurs connus ou encore effectuer sondages/tests en interne parmi les employé.es.

Sensibiliser avant tout

Dans tous les cas, avoir déjà une idée en tête que l'accessibilité est importante est un bon début de sensibilisation. Je ne suis pas partisane du fait qu'il faille s'en vouloir de ne pas avoir de site accessible, car diverses raisons peuvent en découler, et surtout rien n'est perdu !

Sur un projet existant, on peut faire confiance à de petites checklists, comme celle que je vais vous partager. Elle est très simple et peut paraître évidente, mais à titre personnel, mieux vaut se baser en premier lieu sur des critères simples et accessibles.

Checklist utilisée lors de la phase de conception du funnel de souscription d'elmy : https://justinetarlet.netlify.app/blog/checklist-accessibilite-web

Les outils de surcouche, c'est quoi ?​

Vous avez sûrement déjà remarqué des petits modules dédiés à l'accessibilité en vous baladant sur le web. Ils prennent la forme de liens dans le menu, de popup, de modules d'aide : leur forme est variée. Ils permettent d'appliquer une couche accessible sur un site web existant. Ils sont en grande partie conçus pour :

• modifier le contraste
• agrandir la police
• stopper les animations ou camoufler les images
• espacer les mots et augmenter les interlignes

Voici deux exemples d'outils et quelques sites utilisant ces modules de surcouche :

• AccessiWay https://www.accessiway.fr/ sur ces sites web : https://www.breizh-sante-handicap.fr/ ou encore celui de Rennes cité plus haut : https://metropole.rennes.fr/
• Facility : https://www.facil-iti.fr/ sur le site de Veepee : https://www.veepee.fr/gr/home/default
• Autre exemple sur le site de la SNCF : https://www.sncf.com/fr

Pourquoi ont-ils autant de succès ?​

Dans les cas où par exemple, un site existant est dans l'obligation légale de rendre son site accessible, il peut parfois s'avérer coûteux en temps et en argent de mettre en place une refonte ou un projet d'accessibilité. On peut utiliser des solutions de surcouche qui vont venir modifier la couche de style ou de JavaScript du site et répondre à certains critères d'accessibilité, et ce, beaucoup plus rapidement qu'en se lançant dans un projet de mise en conformité.

Quelles sont leurs limites ?​

Si l'accessibilité d'un site web pouvait être réglée en 5 minutes, je n'aurais pas écrit cet article avec toutes ces bonnes pratiques : je vous aurai directement parlé des outils de surcouche.

• Les outils de surcouche ne traitent principalement que la partie graphique, soit 10 % des besoins en accessibilité. Il n'y a par exemple rien de proposé pour les personnes malentendantes comme des sous-titrages.

• Il a malheureusement été pointé du doigt que ces outils pouvaient créer d'autres soucis d'accessibilité. Par exemple, un système de zoom en surcouche va agrandir ou diminuer la police, mais la mise en page du site sera détériorée, et la navigation sera tout bonnement impossible.

• Manque d'ergonomie :

Les modules d'accessibilité implémentés sur les sites utilisant ces solutions sont variés. Et le problème, c'est que leur utilisation elle-même peut se révéler complexe :

• le module en question peut être difficile à trouver : parfois, c'est un simple lien dans le menu ou le footer, parfois c'est une icône ou une bulle en bas de page.

• dans certains cas, les modules sont très (trop) complexes avec de nombreux paramètres. Au final, je trouve que le module de d'accessibilité, bien qu'il permettre une grande liberté en matière de personnalisation, est peu accessible. On passe au final plus de temps à le paramétrer qu'à naviguer sur le site.

• Données utilisateurs et cookies : on peut aussi se poser la question des données privées qui sont récupérées : il n'y a souvent pas de demandes d'accès aux informations concernant les données de l'utilisateur, puisque des cookies sont utilisés par ces solutions de surcouches.

• Performance et risques liés à la sécurité : les scripts utilisés étant extérieurs, il est souvent difficile de contrôle leur fiabilité et les potentielles failles qu'ils peuvent comporter.

Prudence donc si l'on souhaite se lancer avec les outils de surcouche : bien se renseigner également sur les entreprises qui le vendent et leur compatibilité avec le code du site web existant !

Bien qu’ils contribuent à améliorer l’accessibilité web, les outils ne peuvent en aucun cas remplacer l’application des standards et référentiels existants pour se mettre en conformité.

Je pense tout de même que l'accessibilité, même en cours de route peut être simple à mettre en place, si on a les bons réflexes et une bonne sensibilisation.

L'accessibilité web, un atout ?​

Outre le fait d'inclure les personnes en situation de handicap, un site accessible le sera pour le plus grand nombre. Il le sera lors de nos incapacités situationnelles : je suis dans le métro, je veux regarder une vidéo, elle n'a pas de sous-titres.

Les critères de clarté, de structure, d'anticipation des actions de l'utilisateur vont converger vers les critères de l'expérience utilisateur (UX). L'UX signifie User Experience et résume la qualité de l'expérience qu'un utilisateur vivra sur un site ou une application.

Source : https://www.usabilis.com/definition-ux-experience-utilisateur-user-experience/

Celle-ci peut être fortement améliorée si l'accessibilité l'est aussi. Un site avec une bonne UX coche déjà les quelques cases de l'accessibilité.

J'espère que cet article vous aura plus, et vous aura permis d'être sensibilisé.e au sujet de l'accessibilité web. En deux mots : restez simples et accessibles !

Sources​

• https://jaetheme.com/blog/accessibilite-level-a/
• https://blog.ipedis.com/normes-wcag-2.1
• https://checklists.opquast.com/fr/assurance-qualite-web
• https://webaim.org/resources/contrastchecker/
• http://colororacle.org/
• https://www.checkmycolours.com/
• https://wave.webaim.org/
• https://romeo.elsevier.com/accessibility_checklist/
• https://www.w3.org/WAI/WCAG21/quickref/
• https://www.w3.org/Translations/WCAG20-fr/
• https://raw.githubusercontent.com/DISIC/guide-troubles_DYS/master/Guide-des-troubles-DYS.pdf
• https://www.usabilis.com/definition-ux-experience-utilisateur-user-experience/
• https://www.ionos.fr/digitalguide/sites-internet/developpement-web/sites-web-accessibles/