Introduction
Dans cet article de blog rédigé à quatre mains, Alexis Lucio et Sim K Sidhu expliquent comment ils ont lancé un programme d’accessibilité chez Splunk. Splunk transforme les données en actions grâce à sa plateforme « Data-To-Everything », conçue pour explorer, surveiller, analyser et exploiter les données à n’importe quelle échelle. Compte tenu de la mission de Splunk, qui consiste à « rendre les données machine accessibles, utilisables et utiles à tous », on pourrait penser que l'application des bonnes pratiques en matière d'accessibilité (a11y) est un jeu d'enfant ; or, comme le savent tous les professionnels de l'accessibilité, ce n'est pas toujours le cas.
Dans cet article de blog, ils partageront les enseignements tirés de la mise en place d'une équipe chargée de l'accessibilité, notamment en ce qui concerne :
- Que faire lorsque votre équipe n'atteint pas le niveau des collaborateurs seniors,
- Que faire lorsque vous travaillez dans une entreprise axée sur l'ingénierie, par opposition à une entreprise axée sur le design ou sur l'utilisateur, et
- Que faire lorsque l'on travaille dans une entreprise B2B de taille moyenne, par opposition à une entreprise vendant directement aux consommateurs ?
Au tout début : une équipe d'accessibilité composée d'une seule personne
Sim revient sur son expérience en tant que première experte en accessibilité chez Splunk.
Sim : À mes débuts chez Splunk, je ne connaissais pas bien la suite de produits et je n’avais jamais utilisé ces outils. J’ai donc dû non seulement apprendre à m’en servir, mais aussi élaborer un plan d’accessibilité pour celle-ci. À l’aide d’outils que je maîtrisais déjà, tels que JIRA et Confluence, j’ai évalué les cas de test existants, puis j’ai procédé à des tests sur l’ensemble de la suite de produits. Ce processus m’a permis d’établir un rapport d’analyse d’accessibilité complet pour le produit.
Après avoir examiné ce rapport, je me suis rendu compte que ces cas de test semblaient excellents en termes de tests fonctionnels, mais qu’ils ne respectaient pas les principes fondamentaux de l’accessibilité, tels que les bonnes pratiques des WCAG. J’ai donc commencé à intégrer les critères de succès des WCAG 2.1 dans les cas de test, afin de répondre à tous les besoins et objectifs futurs en matière de tests. Grâce à JIRA, j’ai également pu extraire des rapports d’état pour tous les bugs JIRA ouverts existants, ce qui m’a aidé à analyser en quoi la plupart de ces bugs ne respectaient pas les exigences d’accessibilité. J’ai ensuite examiné en détail les niveaux de gravité des bogues existants et j’ai procédé à leur attribution ou à leur modification selon les besoins. Enfin, j’ai décidé d’examiner les modèles volontaires d’accessibilité des produits (VPAT) disponibles pour nos produits afin de mieux comprendre leur niveau de conformité actuel et de proposer des modifications à apporter à ces modèles.
Alors que je travaillais sur tous ces projets, j'ai appris que l'équipe de conception prévoyait de recruter un concepteur spécialisé dans l'accessibilité à temps plein. Je ne peux pas vous dire à quel point j'étais ravi d'apprendre cette nouvelle : même si je faisais partie d'une équipe d'assurance qualité, je n'avais jamais eu l'occasion de travailler de manière régulière avec un concepteur.
Développer l'accessibilité : sensibiliser les collaborateurs et mettre en place un réseau
Alexis, qui occupait auparavant le poste de concepteur UX chez Splunk, se voit offrir une nouvelle opportunité.
Alexis: En septembre 2019, mon responsable du design m’a convoquée dans une salle de réunion où il m’a posé la question suivante : « Comment aimerais-tu aborder la diversité et l’inclusion au-delà de la race, du genre et de l’orientation sexuelle ? » Il m’a expliqué qu’il avait pris connaissance de mon travail au sein des groupes de ressources pour les employés (ERG) et des interventions que j’avais menées sur la diversité, l’équité et l’inclusion, et que, sur cette base, je correspondais parfaitement au profil recherché pour un poste de conceptrice en accessibilité. J’ai répondu « Bien sûr que oui ! » et j’ai commencé à me préparer. En février 2020, notre équipe, qui ne comptait qu’une seule personne, est passée à deux. Pour nous, en tant que collaborateurs individuels, il était essentiel de développer notre action : comment pouvions-nous promouvoir l’accessibilité au sein d’une entreprise de 6 000 personnes, sans parler de faire savoir que deux personnes étaient désormais là pour soutenir les bonnes pratiques et les mesures en matière d’accessibilité ?
Nous avons décidé d’adopter une double approche en matière de sensibilisation : tout en travaillant ensemble sur la stratégie et l’analyse comparative, Sim et moi nous sommes également concentrés sur nos propres sphères d’influence. Du côté de la conception, je savais qu’il était important de me former en tant qu’« expert en accessibilité » et de transmettre ces informations au reste de mon organisation sous une forme accessible. J’ai lancé « A11y Hour », une série mensuelle abordant tous les aspects de l’accessibilité. Au début, les thèmes étaient choisis par Sim et moi-même. Par la suite, nous avons constaté que l’intérêt était suffisant pour prendre en compte les demandes du public. Du côté de l’assurance qualité, Sim s’est appuyé sur les supports pédagogiques que j’avais créés pour souligner l’importance des accords de niveau de service (SLA) et d’un processus de correction pour les ingénieurs. Nous avons également insisté sur le fait que nos clients, plus encore que nous, soulevaient des préoccupations en matière d’accessibilité, car la plupart des entreprises B2B exigent d’analyser le niveau de conformité d’un produit avant son achat.
Avant tout, le fait d'être une équipe de deux personnes a permis d'établir chez Splunk le principe selon lequel l'accessibilité du Web relève d'une responsabilité partagée entre les concepteurs et les ingénieurs, un aspect qui avait été négligé jusqu'à présent.
Mesure et analyse comparative
Sim : Tout en assumant nos responsabilités quotidiennes, nous avons posé les bases du programme d’accessibilité Web de Splunk pour les collaborateurs actuels et futurs. Après une première phase de recherche, de nombreuses questions restaient encore sans réponse, telles que :
- Combien de tickets liés à l'accessibilité avons-nous ? Quel était le rapport entre le nombre de tickets « a11y » clôturés et celui des tickets ouverts ?
- Quel critère de référence à l'échelle du portefeuille aurions-nous pu définir pour a11y ? Splunk compte près de 10 produits phares et a procédé à de nombreuses acquisitions ces dernières années, ce qui rend cette question difficile à trancher.
- Avant notre intervention, des travaux liés à l'accessibilité avaient-ils déjà été réalisés par le passé ? Si oui, qui s'en est chargé et comment en ont-ils défini le périmètre ? Nous connaissions le contexte pour certains de nos produits, mais il en restait encore trop pour lesquels nous n'avions pas de certitude.
- Quels clients, le cas échéant, avons-nous perdus par le passé en raison du non-respect des normes d'accessibilité ?
- Quel pourcentage de notre temps devrions-nous consacrer à une approche proactive par rapport à une approche réactive en matière d'accessibilité ?
Au cours de notre recherche, nous avons échangé avec différentes équipes et divers partenaires interfonctionnels, ce qui nous a permis de tisser un réseau au sein de Splunk et de nouer des alliances en faveur de l'accessibilité au sein de l'organisation.
Constituer un réseau interne d'alliés en faveur de l'accessibilité
Alexis : L’un des aspects uniques de notre parcours a été les groupes de ressources pour les employés (ERG) de Splunk, également appelés « Business Resource Group » (BRG) ou « groupes d’affinité ». Je co-dirigeais depuis un an le groupe de ressources pour les employés « latinx » et je connaissais les co-responsables de « disabled=true », un ERG qui œuvre à la création d’un environnement inclusif et accessible pour les Splunkers actuels et futurs en situation de handicap, souffrant d’une maladie chronique ou de douleurs chroniques. En juin 2020, les ERG ont organisé des séances d’écoute avec la direction de l’entreprise. Ayant établi un partenariat avec « disabled=true » afin de mieux comprendre le point de vue des utilisateurs en situation de handicap, nous avons été invités à leur séance d’écoute, où, parmi la liste des suggestions, nous avons constaté qu’une augmentation des effectifs de notre équipe d’accessibilité (a11y) était proposée. De plus, l’ERG nous a donné l’occasion d’exprimer notre réalité concernant les difficultés que nous rencontrions, non seulement d’un point de vue humain et culturel en matière d’accessibilité, mais aussi au niveau des programmes et des opérations.
L'un des dirigeants participant à la visioconférence était le vice-président senior de l'ingénierie ; à l'issue de celle-ci, il nous a invités à intervenir lors de la réunion de son équipe de direction pour présenter l'importance de l'accessibilité. Il nous a fallu un certain temps pour nous remettre du choc initial, mais nous avons ensuite compris qu'il s'agissait là d'une occasion en or que nous ne pouvions pas laisser passer.
Convaincre les dirigeants de l'importance de l'accessibilité
Sim: Au cours des six semaines suivantes, nous avons élaboré une présentation et commencé à recueillir les retours de notre réseau de référents internes en matière d’accessibilité. Il était important pour nous d’adapter l’argumentaire en faveur de l’accessibilité en fonction de notre public. En tant que designer, il est assez facile pour Alexis de convaincre d’autres designers que l’accessibilité est la bonne chose à faire ; cependant, nous savions que cela ne pouvait pas être le seul angle d’approche à adopter auprès de nos dirigeants. En réfléchissant avec nos champions, nous avons élargi notre philosophie : nous devions aborder l’accessibilité comme une pratique permettant de réduire les risques juridiques, de remporter davantage de contrats (en particulier en tant qu’entreprise B2B soumise à la réglementation fédérale en matière de marchés publics) et, lorsqu’elle est intégrée tout au long du cycle de vie du développement produit, comme une solution nettement moins coûteuse que la correction des bugs après le lancement.
Parallèlement, notre réseau de champions de l'accessibilité nous a poussés à faire mieux en nous fournissant des exemples de bonnes pratiques en matière d'accessibilité. Certes, nous aurions pu citer des entreprises comme Apple, Google, Airbnb et Salesforce ; cependant, certaines d'entre elles n'appartenaient même pas à notre secteur d'activité, et encore moins à celui de nos concurrents. Grâce à ces retours, nous avons trouvé des exemples concrets chez nos concurrents et, à tout le moins, parmi les produits présents sur le même marché.
Le dernier conseil que nous ont donné nos collègues était « montrer, ne pas raconter », c’est-à-dire qu’il était bien plus efficace de présenter concrètement une expérience utilisateur avec une technologie d’assistance que d’en parler simplement. Dans ce cas précis, nous nous sommes souvenus d’un ingénieur commercial avec lequel nous avions récemment collaboré sur un tableau de bord public consacré à la COVID-19 et qui nous avait également fourni une estimation financière de la transaction, ce qui allait trouver un écho auprès de notre public. J’ai proposé d’assombrir l’écran et d’utiliser JAWS sur le tableau de bord. En masquant l’interface, notre public était contraint de vivre exactement la même expérience que celle des utilisateurs de lecteurs d’écran, au lieu de se fier à sa vue. Nous avons produit quelques exemples supplémentaires selon ce principe, en nous concentrant sur les pages les plus visibles et les plus fréquemment utilisées.
Enfin, le jour tant attendu est arrivé en août… et nous avons reçu d’excellents retours ! Les dirigeants nous ont invités à revenir deux semaines plus tard avec notre analyse des lacunes et notre proposition sur la manière dont nous allions mettre en place un programme. Après cela, nous avons vraiment dû réfléchir à la façon dont nous voulions faire de l’accessibilité non pas simplement une liste de contrôle ou un projet, mais un véritable programme.
Mettre en place un programme d'accessibilité avec une équipe de deux personnes
Alexis: Avant notre présentation, nous avions commencé à gagner du terrain en contactant les équipes pour leur proposer de collaborer avec elles ; soudain, les rôles se sont inversés : ce sont les équipes qui ont pris contact avec nous et qui souhaitaient nous rencontrer au plus vite. Nous avons rapidement compris qu’il nous fallait mettre en place un processus pour suivre ces demandes et, pour y répondre, nous avons créé un formulaire de demande destiné à l’équipe A11y, dans lequel les équipes pouvaient décrire en quoi elles avaient besoin de nous, indiquer les échéances à venir et préciser si la demande était liée ou non à un problème client. Ce formulaire permettait également de collecter des données quantitatives afin que nous puissions observer les tendances au fil du temps et identifier les besoins au sein de notre propre organisation.
Le partage des connaissances en matière d’accessibilité est également devenu extrêmement important, car il n’est pas envisageable de passer de deux personnes à plus de 6 000 collaborateurs. Pour y remédier, nous avons créé le canal #a11y-questions sur le Slack de notre entreprise. Au lieu de répondre aux mêmes questions qui nous étaient envoyées directement par message privé, nous pouvions désormais épingler une réponse visible à l’intention de toutes les parties prenantes dans le cadre de notre FAQ.
Tout en gérant notre succès fulgurant, nous avons constaté que les ressources fondamentales que nous avions mises en place nous permettaient de diffuser davantage la culture de l’accessibilité. Par exemple, la présentation que nous avions élaborée à l’intention des dirigeants a été adaptée pour les stages intensifs destinés aux nouveaux ingénieurs. Cette démarche d’intégration garantit que chaque collaborateur commence avec une idée minimale de ce qu’est l’accessibilité et de son importance pour Splunk. Notre plus grande réussite a toutefois été d’obtenir que d’autres collaborateurs de Splunk consacrent du temps à temps partiel à l’organisation d’une réunion hebdomadaire de l’équipe principale chargée de l’accessibilité. Ensemble, nous avons créé la documentation dont nous avions besoin depuis longtemps, notamment une page Confluence dédiée à l’accessibilité. Cette page contient des appels d’offres en cours et publiés en interne, des VPAT, des analyses comparatives entre les différentes suites de produits, ainsi que les objectifs et résultats clés (OKR) trimestriels de l’équipe, qui s’inscrivent dans les OKR de l’organisation dans son ensemble. Enfin, cette page rassemble également des statistiques sur les tickets JIRA, ce qui nous permet de suivre la progression des corrections au fil du temps, d’identifier les composants à traiter en priorité et de repérer d’autres besoins.
Approche « Shift Left » en matière d'accessibilité
Sim: Après avoir travaillé en équipe depuis plus d’un an maintenant, nous commencions enfin à récolter les fruits d’une approche « shift left » en matière d’accessibilité. Auparavant, je testais les produits avant leur mise en production et je signalais les bugs, ce qui ne laissait que peu, voire pas du tout, de temps aux développeurs pour corriger les problèmes signalés. Grâce à la présence d’Alexis en tant qu’expert en conception a11y, de nombreux bugs liés à l’accessibilité sont détectés dès la phase de conception, ce qui facilite mon travail en aval. De plus, le fait de disposer de ressources a11y plus en amont dans le cycle de vie du développement produit nous a permis d’interagir avec les clients, les ingénieurs commerciaux et notre équipe terrain afin d’identifier les problèmes les plus urgents.
Ce virage vers une approche plus proactive nous a surtout permis d’adopter une démarche plus proactive en matière d’accessibilité (a11y) avec les équipes chargées des produits, plutôt qu’une approche purement corrective. Voici comment nous aidons nos équipes chargées des produits à adopter cette approche plus proactive :
- Publier la documentation du système de conception, qui contient les meilleures pratiques en matière d'accessibilité ainsi qu'une documentation axée sur les composants, au cas où un développeur aurait besoin de personnaliser un composant.
- Mettre en place une boîte à outils d'accessibilité destinée aux designers, comprenant des listes de contrôle adaptées aux flux de travail courants ainsi que des ressources non techniques à leur intention (Un grand merci à Angela, notre stagiaire en design, qui a collaboré avec Alexis pour mener ce projet à bien !)
- Intégrer les bonnes pratiques en matière d'accessibilité dans les critères d'acceptation des exigences produit, de manière à ce que le chef de produit n'ait pas à mémoriser toutes les directives.
- Collaborez avec les équipes produit pour organiser une série d'ateliers en présentiel et en ligne (sous-titrés) afin d'en savoir plus sur l'accessibilité et sur son importance pour Splunk.
Résumé
- L'accessibilité est destinée à nos utilisateurs, et il est judicieux d'adapter l'argumentaire en faveur de l'accessibilité à votre public de parties prenantes.
- Le fait de distinguer les défis liés aux personnes et à la culture de ceux liés aux programmes et aux opérations peut aider à identifier plus rapidement les points sensibles, à déterminer ce qui doit être traité de manière proactive plutôt que réactive, et à mettre en œuvre une stratégie même si vous disposez de ressources limitées.
- Le travail d'équipe est essentiel pour mener à bien les efforts de grande envergure que requiert l'accessibilité. Sachez reconnaître quand vous avez atteint vos limites et n'hésitez pas à faire appel à des ressources extérieures à votre équipe.
Nous tenons également à remercier tous nos mentors, nos anciens collègues et nos dirigeants qui ont contribué au succès de Splunk en matière d'accessibilité. Sans vous, nous n'en serions pas là aujourd'hui.
Vous travaillez sur l'accessibilité au sein d'une équipe, ou à un ou deux ? N'hésitez pas à contacter Sim sur LinkedIn ou Alexis sur Twitter; les échanges que nous avons eus depuis notre intervention à l'axe-con ont été formidables, et même si nous savons que cela peut être intimidant de faire partie d'une petite équipe, sachez que vous n'êtes pas seuls et que la communauté de l'accessibilité est là pour vous aider.
