Par
·
lecture de 7 minutes
On parle beaucoup d’accessibilité numérique ces temps-ci. Mais trop souvent, ça se résume à une case à cocher à la fin d’un projet, ou à un audit qu’on commande parce qu’on « devrait bien le faire ». Rocío Alvarado et Karine Simard en discutent pour remettre les pendules à l’heure : l’accessibilité n’est pas un extra, ni un luxe. C’est une responsabilité partagée, à intégrer dès le début, dans tout le cycle de vie d’un produit numérique.
Et quand on le fait bien, non seulement les expériences deviennent plus inclusives, mais les projets vont plus vite, coûtent moins cher et créent des équipes plus compétentes à long terme.
Bienvenue dans une façon beaucoup plus intelligente – et franchement plus humaine – de faire du numérique.
Evolve Digital : d’un événement Drupal à une réflexion sur tout le numérique
La conférence Evolve Digital en est déjà à sa 4e édition. Au départ, c’était un événement très niché, centré sur la plateforme Drupal. Mais, comme son nom le dit, la conférence a elle-même évolué : aujourd’hui, on y parle du numérique au sens large, de tout l’écosystème qui entoure les plateformes, les sites, les applications et les produits digitaux.
Organisée par l’entreprise montréalaise Evolving Web, spécialiste notamment de Drupal, la conférence rassemble des gens de terrain qui vivent les défis du numérique au quotidien. C’est dans ce contexte que Rocío Alvarado a pris part à un panel sur l’accessibilité numérique, en compagnie d’autres spécialistes : Olivier Fortin de Radio‑Canada, Carolina Crespot de Bisperot et Jennifer Chadwick de Journey Accessibility.
Ce qui a frappé Rocío pendant cette discussion, ce n’est pas la divergence d’opinions, mais au contraire à quel point tout le monde était aligné : même vision, mêmes constats, mêmes enjeux. Quand différents experts issus de milieux variés arrivent aux mêmes conclusions, c’est souvent un signe que quelque chose de fondamental est en train de se cristalliser.
L’accessibilité : pas un rôle, une responsabilité partagée
Pendant longtemps, on a eu tendance à voir l’accessibilité comme le « job » d’une personne en particulier : la spécialiste en accessibilité, la personne en QA, ou encore l’équipe qui fait l’audit à la fin. Cette vision-là est non seulement réductrice, elle est aussi vouée à l’échec.
Rocío le dit clairement : l’accessibilité, c’est la responsabilité de tout le monde impliqué dans un produit numérique. De l’analyse initiale du projet jusqu’à l’assurance qualité, en passant par la gestion de projet, le design, le contenu, le développement, chaque rôle a un impact direct sur l’expérience des personnes utilisatrices, incluant celles qui ont des limitations fonctionnelles.
Un design peut avoir l’air hyper inclusif sur Figma, mais si, au développement, personne ne fait attention à la structure sémantique, aux balises, au focus clavier ou aux lecteurs d’écran, on perd tout le bénéfice du travail en amont. À l’inverse, un ou une développeuse peut tout donner pour coder proprement, mais si les maquettes sont conçues sans se soucier des contrastes de couleurs ou de la hiérarchie de l’information, il ou elle part avec un handicap dès le départ.
L’accessibilité, c’est un fil qui traverse tout le projet. Si on coupe ce fil à un endroit, c’est l’expérience complète qui se fragilise.
Le réflexe (trop) courant : l’audit de fin de projet
Dans la pratique, les organisations font souvent la même chose : elles arrivent en fin de projet, avec un site web presque terminé, et se disent qu’il serait peut-être temps de « faire vérifier ça pour l’accessibilité ». On commande alors un audit, souvent dans un contexte d’urgence : la mise en ligne est prévue, les campagnes sont prêtes, la pression est forte.
Un audit dans ce contexte demeure utile. Comme le rappelle Rocío, ça permet de savoir précisément où en est le produit à un moment donné, d’identifier des non‑conformités, de documenter des enjeux et de proposer des pistes de solution. Mais ça ne devrait jamais être le seul point de contrôle.
Pourquoi ? Parce que lorsqu’on découvre des problèmes majeurs à la toute fin, les corriger devient coûteux, long, parfois même politiquement délicat. Revoir une navigation complète, ajuster une palette de couleurs, repenser un gabarit de page ou revoir une logique de composantes, ce n’est pas une petite patch de dernière minute. Résultat : on fait le minimum pour passer le test, on repousse des corrections plus profondes à plus tard… et ce « plus tard » n’arrive jamais.
On se retrouve avec un produit qui coche certaines cases, mais qui n’incarne pas réellement une approche inclusive ni durable.
Changer de posture : intégrer l’accessibilité dans l’escouade de développement
À l’opposé de ce scénario classique, Rocío raconte une expérience qui illustre ce à quoi peut ressembler une vraie approche intégrée : plutôt que de faire un audit en fin de course, la personne spécialiste en accessibilité a été intégrée directement à l’escouade de développement d’une plateforme numérique, en tant que QA accessibilité.
Concrètement, ça change tout.
Dès le design, Rocío a un œil sur les maquettes, peut détecter les points sensibles – comme les contrastes de couleur, les états au survol et au focus, la lisibilité des textes, la clarté des parcours – et proposer des ajustements avant même que la première ligne de code soit écrite. Les problèmes potentiels sont donc désamorcés très tôt, quand les coûts de changement sont encore faibles.
Pendant le développement, l’équipe sait qu’elle peut poser des questions au fur et à mesure : « Ce carousel, on le gère comment pour le clavier ? », « Ce composant-là, on l’a déjà vu ailleurs, c’était fait comment ? », etc. Rocío ne se contente pas de dire « ça ne marche pas » : elle propose des pistes, montre des exemples en ligne, partage des bonnes pratiques adaptées au contexte réel de l’équipe.
À ce moment-là, l’accessibilité cesse d’être une série de contraintes abstraites et devient un espace d’apprentissage et de collaboration.
De la liste Excel à la collaboration en temps réel
Quand l’accessibilité arrive seulement sous forme d’audit en fin de projet, ce qui revient souvent au client, c’est un fichier Excel volumineux : une liste de problématiques, des références aux critères WCAG, quelques pistes de solution. C’est utile, mais c’est froid, déconnecté du quotidien des développeurs et développeuses.
On leur dit quoi corriger, mais rarement comment l’intégrer dans leurs pratiques de façon durable. La communication passe parfois par plusieurs intermédiaires, ce qui dilue le message et éloigne les spécialistes accessibilité des personnes qui écrivent réellement le code.
À l’inverse, quand une spécialiste est intégrée dans l’équipe, chaque bug, chaque question, chaque ajustement devient un moment d’apprentissage. On ne remet pas juste un verdict ; on explique, on montre des alternatives, on cherche des solutions ensemble. Pour l’équipe de développement, c’est beaucoup plus riche : on ne subit plus l’accessibilité, on la maîtrise de plus en plus.
Ce genre d’accompagnement dans des cas réels crée de nouveaux réflexes. La prochaine fois qu’un développeur devra coder un composant similaire, il se souviendra des discussions, des exemples, des raisons derrière les choix. L’accessibilité devient progressivement un automatisme, pas juste une contrainte de conformité.
Moins de problèmes en préprod, moins de coûts, plus de qualité
Les bénéfices concrets de cette approche intégrée se voient clairement au moment de la validation pré‑production. Dans le projet où Rocío jouait le rôle de QA accessibilité au cœur de l’escouade, la phase finale de validation a révélé… beaucoup moins de problèmes.
Normal : le travail de fond avait déjà été fait en amont. Les processus étaient pensés avec l’accessibilité en tête, les composantes critiques avaient été revues, les parcours utilisateurs testés avec de vrais scénarios. Dans certains cas, il ne restait quasiment plus rien à corriger. La validation devenait alors une confirmation, pas une découverte de chantier.
Pour l’organisation, c’est un gain direct : moins de correctifs de dernière minute, moins de stress avant la mise en ligne, moins de coûts cachés. Pour l’équipe, c’est une immense satisfaction : on sent qu’on a livré quelque chose de solide, qui respecte mieux la diversité des personnes utilisatrices.
Et pour l’accessibilité elle-même, c’est un cercle vertueux : chaque projet consolide les compétences de l’équipe, qui devient de plus en plus autonome pour intégrer ces pratiques de façon naturelle.
L’accessibilité comme culture de projet, pas comme projet à part
Ce qui se dégage de la discussion entre Karine et Rocío, c’est que le vrai changement ne vient pas seulement d’un outil, d’un audit ou d’une personne experte. Il vient du moment où une organisation décide d’intégrer l’accessibilité dans sa culture de projet.
Ça veut dire :
- impliquer les spécialistes en accessibilité dès le début, pas à la fin ;
- donner du temps et de l’espace pour former les équipes ;
- prévoir plusieurs points de contrôle au long du cycle de vie ;
- traiter l’accessibilité comme un critère de qualité au même titre que la performance, la sécurité ou l’ergonomie.
Dans cette logique, le livre blanc sur le cycle de vie de l’accessibilité devient un outil stratégique : il sert de guide pour repenser la façon dont on planifie, conçoit, développe, teste et fait évoluer nos plateformes numériques, en s’assurant que l’accessibilité n’est jamais un ajout de dernière minute.
Au-delà de la conformité : une question d’impact réel
On pourrait se dire que tout ça, c’est surtout une histoire de conformité réglementaire, de WCAG et de normes à respecter. Mais ce que le panel d’Evolve Digital met en lumière, c’est que l’accessibilité a un impact très concret sur la vie des gens.
Quand un formulaire est impossible à remplir au clavier, c’est une personne qui abandonne une démarche importante. Quand un texte manque de contraste, c’est une partie de la population qui fatigue plus vite ou renonce à lire. Quand une interface ne se comporte pas correctement avec un lecteur d’écran, c’est un service public ou une ressource essentielle qui devient, de fait, excluante.
À l’inverse, quand une équipe prend le temps de bien faire les choses, de tester, de ajuster, d’apprendre en continu, elle crée des expériences plus justes, plus accueillantes, plus efficaces pour tout le monde – pas seulement pour les personnes en situation de handicap. On parle ici d’un investissement qui a des retombées humaines, mais aussi organisationnelles et même économiques.
Vers des projets numériques accessibles… dès le premier essai
Au fond, ce que racontent Karine Simard et Rocío Alvarado, c’est la transition entre deux modèles :
- un modèle réactif, où l’accessibilité arrive à la fin, sous forme d’audit, avec une liste de problèmes à régler à la hâte ;
- un modèle proactif, où l’accessibilité est intégrée tout au long du cycle de vie du projet, portée par l’ensemble de l’équipe, soutenue par des spécialistes qui accompagnent au quotidien.
Le deuxième modèle demande un changement de posture, oui. Mais il simplifie la vie de tout le monde. Les gestionnaires ont moins de mauvaises surprises. Les designers travaillent avec des balises claires. Les développeurs et développeuses apprennent en même temps qu’ils livrent. Les spécialistes en accessibilité sortent du rôle de « policiers de la conformité » pour devenir de vrais partenaires.
Et surtout, les personnes qui utilisent les plateformes – avec toutes leurs réalités, leurs capacités, leurs outils – ont enfin accès à des services numériques qui les considèrent pleinement.
C’est ça, au fond, l’objectif : des projets numériques accessibles non pas par obligation, mais parce qu’ils ont été pensés comme tels dès le premier essai.