L’accessibilité est systémique
Traduction de l’article Accessibility is systemic de Jeremy Keith. Cet article a été beaucoup lu et partagé, il est juste. Il plaira aux novices, mais n’apportera rien aux expérimentés.
L’accessibilité est systémique
Je réfléchissais à l’article de Jacob Kaplan-Moss appelé Quality Is Systemic (titre en français: la qualité est systémique).
La qualité logicielle est davantage l’expression d’un système élaboré pour produire de la qualité, plutôt que l’expression d’une performance individuelle. Autrement dit : un groupe de programmeurs médiocres travaillant avec une structure conçue pour produire de la qualité produira un meilleur logiciel qu’un groupe de programmeurs fantastiques travaillant dans un système conçu avec d’autres objectifs.
Je pense que Jacob touche une quelque chose de fondamental. Je pense aussi que cela s’applique autant à la conception qu’au développement. Voire plus.
Dans le design, on met peut-être trop l’accent sur le talent et les compétences individuelles des designers et pas assez sur la création et l’entretien d’un environnement sain où n’importe qui peut contribuer au processus de conception.
Jacob évoque également le sujet de l’embauche :
Au lieu de consacrer beaucoup de temps et d’efforts à l’embauche pour n’ « embaucher que les meilleurs », orientez une partie de cet effort vers la mise en place d’un système qualitatif basé sur un éventail plus large de qualités individuelles.
Comment n’être pas d’accord avec cette affirmation ! C’est une raison pour laquelle la stratégie la mieux adaptée sur le long terme consiste à se concentrer sur la formation de jeunes concepteurs et/ou développeurs plutôt que sur la chasse aux talents (rockstars).
En aparté, si vous pensez que le processus de développement des designers et développeurs juniors est plus délicat maintenant que nous travaillons à distance, je vous recommande fortement de lire le post de Mandy, Official myths (Mythes officiels) :
Soutenir le personnel subalterne est un travail. C’est un travail que vous soyez dans un bureau de temps en temps ou tout le temps, et c’est un travail si Slack est le seul bureau que vous connaissez. Renvoyer le personnel au bureau ne facilite pas le soutien du personnel subalterne ni ne le rend encore plus probable.
Embaucher des designers et des développeurs très expérimentés est tout à fait logique, du moins à court terme. Mais je pense que la meilleure solution à long terme - comme l’a souligné Jacob - est de créer (et d’entretenir) un système où même les praticiens inexpérimentés pourront faire du bon travail en ayant le soutien et l’accès aux connaissances dont ils ont besoin.
J’y pensais la semaine dernière quand Irina a très gentiment accepté de présenter un lunch’n’learn (déjeuner & apprendre) pour Clearleft (agence de réalisation de sites web) sur le design inclusif.
Elle a répondu à une question qui me trottait dans la tête : quelle est la différence entre design inclusif et accessibilité ?
Comme le dit Irina, l’accessibilité est axée sur la mise en œuvre. Pour rendre un site Web accessible, vous avez besoin de personnes possédant les compétences, les connaissances et l’expérience nécessaire.
Mais la conception inclusive concerne le processus et le système qui mène à cette mise en œuvre.
Pour utiliser ce cliché du double losange, peut-être que la conception inclusive consiste à « construire la bonne chose » et l’accessibilité à « construire la chose correctement ».
Ou pour le dire autrement, peut-être que l’accessibilité concerne les résultats, alors que la conception inclusive concerne les intrants. Vous avez besoin des deux, mais peut-être mettons-nous trop l’accent sur les sorties et pas assez sur les entrées.
C’est ce qui m’a fait penser à l’affirmation de Jacob selon laquelle la qualité est systémique.
Imaginez quelqu’un qui est un expert en accessibilité : il connaît tous les détails des WCAG (Web Content Accessibility Guidelines) et ARIA (Accessible Rich Internet Applications). Maintenant, placez cette personne dans une organisation qui ne donne pas la priorité à l’accessibilité. Ils vont avoir du fil à retordre et ils ne pourront probablement pas être très efficaces malgré toutes leurs compétences.
Imaginez maintenant une organisation qui privilégie l’inclusivité. Même si leur personnel n’a pas (encore) les compétences et les connaissances d’un expert en accessibilité, le simple fait d’avoir les processus et les priorités en place dès le départ permettra à chacun de contribuer plus facilement à une expérience plus accessible.
Il est possible de rendre quelque chose accessible en l’absence d’un système qui donne la priorité à la conception inclusive, mais ce sera un travail difficile. Alors que s’assurer que la conception inclusive est une priorité au niveau organisationnel, il est beaucoup plus probable que les résultats soient accessibles.
Conclusion
Dans mon dernier article (Numérique responsable, la charge du développeur Front), je parlais horizontalité et verticalité dans la réalisation de services numériques.
L’horizontalité c’est le passage de l’information d’un métier à l’autre. Ex. Concepteur => graphistes => développeurs.
La verticalité, c’est le passage de l’information d’un supérieur hiérarchique à un autre. Ex. Dirigeant => Responsable Projets => Développeurs.
L’accessibilité en temps de discipline technique s’insère dans la gestion horizontale. L’accessibilité en temps que processus d’organisation s’insère dans la gestion verticale.
Des personnes peuvent tout à fait voir l’accessibilité comme un simple dispositif technique (comme parfois on le perçois dans le bâtiment). Seulement (je ne crois pas me tromper), en France l’accessibilité est considérée depuis de nombreuses années comme un processus d’amélioration d’un organisme. Voire la conception du RGAA (Référentiel Général d’Amélioration de l’Accessibilité).
Jeremy a tout-à-fait raison de manière pragmatique. C’est ainsi qu’on voit l’accessibilité sur le terrain , quand on interagit avec un organisme. Seulement, sa description de l’accessibilité n’est pas correct. Un expert en accessibilité ne peut pas se limiter à la simple connaissance de critères WCAG (Web Content Accessibility Guidelines). Un entreprise qui travaille sur l’inclusivité ne peut pas ignorer l’existence de référentiels.
Il est possible que la liaison entre les compétences en accessibilité technique et inclusivité soit beaucoup moins mature aux États-Unis qu’en France. Ce que je désigne comme une erreur de la part de Jeremy n’est qu’une peut-être qu’une réalité du milieu qu’il fréquente (je crois que je manque de connaissance sur le domaine).
Seulement, il touche le point crucial concernant la qualité des services numériques. La compétence des entreprises de conseils en accessibilité et/ou des référents accessibilité est d’articuler les compétences en accessibilité aussi bien de manière horizontale que verticale. Car si l’un des 2 est bloqué alors les évolutions sont au point mort.
Il y a donc un enjeu majeur à définir le rôle, métier, statut… d’un auditeur expert en accessibilité.
Un auditeur (expert) n’est pas une API qui renvoie un fichier avec les erreurs dans un terminal. Un auditeur (expert) n’est pas une personne qui va donner des formations et faire monter en compétence l’ensemble d’un entreprise.