Vous avez commencé. Un audit ? Et après ? - Chris Gibbons

L’audit se termine. Les constats sont consignés. Des tickets sont créés, certains sont corrigés, et l’organisation continue avec une liste d’issues d’accessibilité légèrement raccourcie. Six mois plus tard, la plupart de ces constats seront de retour. Différents composants parfois, mais les mêmes schémas. Le prochain audit produira une liste qui chevauche la précédente d’une manière qui n’étonne plus personne.

C’est la partie du travail d’accessibilité dont on parle peu. Pas parce qu’elle n’existe pas, mais parce qu’elle n’est pas dramatique. Le mode d’échec n’est pas le designer qui supprime un contour de focus ou l’ingénieur qui ne comprend pas le HTML sémantique. Ce sont des échecs visibles. Le plus discret survient après l’audit, quand les personnes concernées par l’accessibilité essaient de faire tenir les correctifs.

Le schéma après l’audit

Je l’ai vu se reproduire dans trois organisations maintenant, et c’est la même forme à chaque fois.

L’audit arrive. Les constats sont triés. Les gros sont assignés à des équipes qui ont une quinzaine de jours pour les corriger avant que le rapport ne soit envoyé à qui l’a commandé. Les petits sont ajoutés à un backlog où ils restent indéfiniment, ressortis de temps en temps quand quelqu’un a de la marge et s’en souvient. Les moyens sont corrigés dans les composants audités et pas dans ceux qui ne l’étaient pas, parce que personne n’a pour tâche d’étendre la correction latéralement.

Six mois passent. De nouvelles fonctionnalités sont livrées. Des anciens composants sont étendus. Les composants corrigés sont modifiés par des ingénieurs qui n’étaient pas présents lors de la correction, et les correctifs s’érodent parce que l’ingénieur ne sait pas pourquoi ils existaient. De nouveaux composants sont construits qui reproduisent les mêmes schémas signalés par l’audit, parce que les constats n’ont jamais été intégrés à la documentation, au linter, à la checklist de revue de code, ni aux connaissances de travail des ingénieurs.

Un deuxième audit est commandé. Les constats chevauchent ceux du premier audit d’une manière qui, si on les examinait assez longtemps, dirait quelque chose de précis sur ce qui a mal tourné. La plupart ne les examine pas assez. Les corrections sont re-soulevées. Le cycle continue.

Ce n’est la faute de personne, exactement. C’est ce qui arrive quand on traite l’accessibilité comme un projet qui a une fin.

Un problème de maintenance déguisé

Les disciplines qui ont résolu cela il y a des années sont la sécurité et la performance. Les deux ont commencé comme des préoccupations exceptionnelles : on faisait appel à un spécialiste, on auditait périodiquement, on corrigeait par projet, et on considérait le sujet réglé. Elles ont fini par être repositionnées comme un travail d’ingénierie continu, parce que le domaine a collectivement réalisé que tout ce qu’on traite comme un audit ponctuel va régresser.

La sécurité a des scanners SAST dans l’intégration continue. Des vérifications de vulnérabilités des dépendances. Du threat modelling intégré à la revue de conception. Un champion sécurité dans chaque équipe. Une équipe plateforme qui prend en charge les standards et les outils. La performance a des budgets Lighthouse, de la télémétrie RUM, des alertes de régression, des revues de performance des nouvelles fonctionnalités avant leur mise en production. Les deux ont des définitions de rôle, des certifications, des trajectoires de carrière reconnues.

L’accessibilité est, dans la plupart des organisations, encore là où la sécurité était en 2008 et la performance en 2012. Audité périodiquement. Corrigé par lots. Appartenant à personne de spécifique. Considérée résolue quand le rapport revient propre, même si le rapport est un instantané d’un système qui change chaque jour.

Le cadre de maintenance importe parce qu’il change la notion de ce qui est bon. Si l’accessibilité est un projet, le succès est « pas de constats dans cet audit ». Si c’est une discipline de maintenance, le succès est « nous avons attrapé la régression dans la revue de PR, avant mise en production ». Ce sont des problèmes différents nécessitant des infrastructures différentes. Le premier a besoin d’un budget d’audit. Le second a besoin de personnes, de processus et d’outils intégrés au cycle de développement.

La plupart des organisations achètent encore des audits et se demandent pourquoi les constats reviennent.

Le rôle que personne ne possède vraiment

Voilà la chose structurelle que rien d’autre ne règle.

L’accessibilité, dans la plupart des organisations, est la responsabilité de tous. Ce qui signifie que ce n’est le travail de personne. Le designer est censé y penser. L’ingénieur est censé l’implémenter. Le QA est censé le tester. Le product manager est censé le prioriser. Le champion accessibilité dans l’équipe est censé défendre la cause, dans le temps qu’il lui reste après son vrai travail. Il n’y a pas d’individu dont l’évaluation dépend du maintien de l’accessibilité.

Quand quelque chose est la responsabilité de tous, le mode d’échec est prévisible. Cela devient la responsabilité de ceux qui s’en soucient le plus, ce qui signifie que le travail repose sur les mêmes deux ou trois personnes dans toute l’organisation, qui s’épuisent ou partent. Leurs remplaçants ne prennent pas le relais parce qu’il n’existe pas de définition de rôle qui l’exige. Le savoir institutionnel quitte l’entreprise avec la personne qui l’a construit.

La solution est peu glorieuse : nommer le rôle, lui donner une véritable autorité, le financer. Pas « champion accessibilité ». C’est le modèle volontaire qui crée l’épuisement. Un spécialiste, à plein temps ou proche, dont le mandat couvre les standards, les outils, la revue, la formation, la réponse aux audits, la prévention des régressions. La personne dont le travail dépend de la tenue de l’accessibilité.

Quelques organisations l’ont compris. La plupart non. Celles qui l’ont fait tendent à être les mêmes qui réussissent l’accessibilité structurellement. Elles ont fait du sujet le travail de quelqu’un, lui ont donné du soutien et l’ont tenu responsable du résultat. Les autres fonctionnent sur l’enthousiasme bénévole jusqu’à ce que les bénévoles s’épuisent.

À quoi cela ressemble réellement de l’intérieur

C’est le commentaire sur une PR d’un collègue signalant que le nouveau modal ne gère pas le focus, écrit avec tact parce qu’on ne veut pas être la personne qui donne l’impression de râler pour l’accessibilité. C’est la revue de design où vous demandez, encore une fois, si le nouveau token de couleur respecte le contraste, sachant que le designer a déjà été interrogé. C’est la page de documentation que vous avez écrite que personne ne lit, mais que vous maintenez parce que le jour où quelqu’un en aura besoin, il en aura cruellement besoin.

C’est le document de réponse à l’audit qui prend deux semaines à être bien rédigé parce que vous ne faites pas que lister les corrections, vous essayez de capturer pourquoi les schémas sont apparus afin que la prochaine vague de nouveaux composants ne les reproduise pas. C’est la discussion avec le manager engineering sur pourquoi la règle de lintage qui détecte l’absence d’attribut alt doit faire échouer la build plutôt qu’afficher un avertissement, et le suivi six semaines plus tard quand elle est revertée parce qu’elle a ralenti un sprint. C’est l’argument lent et répété que la déclaration d’accessibilité sur le site n’est pas un actif marketing mais un engagement légal, et que la pratique doit correspondre au texte.

C’est remarquer que la première PR du nouvel ingénieur junior comporte trois problèmes d’accessibilité, et choisir entre les signaler maintenant ou d’abord construire la relation pour les signaler la prochaine fois. Décider, finalement, que vous les signalerez toujours, mais de manière pédagogique plutôt que correctrice. Reconnaître que ce calcul est votre travail, pas le leur.

C’est la petite victoire quand quelqu’un, un jour, pose la question avant que vous n’ayez à le faire. Le nouveau designer qui annote l’ordre de focus dans le spec sans y être invité. L’ingénieur qui s’oppose en revue à un commit d’un collègue parce que le balisage ne se reflète pas dans l’accessibility tree. Ces moments signifient que le fossé des fondations se referme quelque part. Ils sont aussi assez rares pour qu’on s’en souvienne.

Quand ça marche, on dirait que rien ne se passe. Quand ça ne marche pas, le rapport d’audit vous le dit.

Ce que tout cela signifie

L’accessibilité tient dans les organisations qui la traitent comme une discipline de maintenance avec un propriétaire nommé, pas comme un projet avec une date de fin. Le travail technique est vraiment la moitié la plus facile. La moitié la plus difficile est structurelle : faire que ce soit le travail de quelqu’un, l’intégrer au cycle de développement, traiter la régression comme un problème que l’on empêche activement plutôt que l’on découvre six mois plus tard.

La plupart des organisations n’en sont pas encore là. Celles qui y sont parvenues l’ont fait parce que quelqu’un a bataillé assez longtemps en interne pour que la structure change autour d’eux. Ce combat fait partie du travail, même quand on ne le ressent pas. L’audit ne soutient pas l’accessibilité. Le rôle, oui. Le rôle n’existe pas par défaut. Quelqu’un doit le réclamer, puis continuer à le revendiquer.

Si vous êtes la personne dans une organisation qui essaie de faire tenir cela, le schéma est reconnaissable et ce n’est pas votre faute. Le système est conçu pour absorber lentement le travail d’accessibilité dans le bruit de fond jusqu’au prochain audit. Résister à cette absorption est l’essentiel du travail de maintien de l’accessibilité.

Le premier audit est un début. Le rôle est le reste du travail.