Traditionnellement l’accessibilité est reléguée en bout de chaîne, tant en matière de qui doit s’en charger (l’équipe de développement) que du moment où on doit s’en charger (vers la fin, quand on aura bien avancé sur tout le reste). On part du principe que c’est un sujet technique (ce qui a été longtemps l’implicite du sujet, y compris quand on formait les gens), et qu’on n’a pas besoin de peaufiner tout de suite alors que les spécifications changent encore. On verra plus tard !
Cependant, la compréhension du sujet évolue, en bien. On attend toujours de l’équipe de développement qu’elle s’y attelle, sauf que : l’accessibilité est aussi le sujet des chefs de projet, des concepteurices, des rédacteurices, etc.
- Par exemple : les chefs de projet et les concepteurices doivent expliciter l’exigence dès la rédaction du cahier des charges.
- Si c’est du développement interne, le reste du projet saura à quoi s’attendre.
- Si c’est du développement externe, les prestataires ne pourront pas dire que ce n’était pas prévu.
- Autre exemple : un concepteur d’interface invente un truc qui paraît génial (ou recycle un truc inaccessible vu sur le site d’Apple — histoire vécue trop souvent). Mais ce truc génial coûtera le double du budget initial pour rétropédaler parce qu’on n’a pas pensé que ça devait être accessible. Sans compter la frustration pour les chefs de projet qui ont eu des étoiles dans les yeux puis qui ont l’impression qu’on rétrograde vers un truc accessible-mais-triste [1].
Au pire [2], le projet acte que c’est un besoin marginal et toute la chaîne de décision le dépriorise. J’ai coutume de dire que ce sera dans le septième sprint du cycle qui en compte six. On va dire que je suis pessimiste. Malheureusement non, c’est empirique (et fréquemment partagé dans le milieu de l’accessibilité).
Comme pour les exigences d’éco-conception ou de sécurité, tous les maillons de la chaîne devraient a minima savoir de quoi on parle et y être attentifs quand il s’agit des questions d’accessibilité.
Vous connaissez le RACI ? C’est une matrice de responsabilité (comme le dit joliment Wikipedia) qui se définit par quatre termes :
- R : responsible. Ce sont les personnes qui exécutent le travail.
- A : accountable. Ce sont les personnes qui pilotent l’activité. Idéalement il n’y en a qu’une par activité, sauf armée mexicaine et dilution (appelée aussi « méthode des parapluies en cascade »).
- C : consulted. Ce sont les personnes qui doivent être consultées (hah !).
- I : informed. Ce sont les personnes qu’on tient informées (hah encore !).
Il y a quelques années j’avais initié un travail de matrice basée sur les WCAG 2,1, quand on a commencé à dire systématiquement que toute la chaîne était impactée alors que la responsabilité continuait à retomber sur les épaules de la partie développement. Redisons-le, ce n’est pas son travail de compenser les manques du design, d’altérer les fonctionnalités, de sous-titrer une vidéo ou de décider des contenus alternatifs ! On avait fait un atelier à Paris Web sur le sujet, parce qu’on est plus intelligent à plusieurs.
Voilà tous les acteurices qu’on avait identifiées à l’époque, sans même remonter aux chefs de projet qui évidemment devraient avoir l’œil partout (pardon c’est en anglais) :
- Analysis
- Architecture
- Interaction Design / Usability
- Graphics Design
- Content Strategy
- Search Engine Optimization
- HTML/CSS Prototyping
- Front-End Development
- Back-End Development
- Quality control
Si ça vous intéresse, la matrice WCAG 2.1 est téléchargeable ici même.
Mais il y a bien mieux ! Maintenant il y a ARRM : Accessibility Roles and Responsibilities Mapping ! Autrement dit : une cartographie des rôles et responsabilités dans l’accessibilité [3]. Attention, ce n’est pas fini. Mais c’est un début, en cours de rédaction. J’attends avec impatience de pouvoir partager ARRM.
D’ici-là, ce qu’il faut retenir, qui est une évidence pour les spécialistes mais reste encore à véritablement intégrer dans la culture des projets : l’accessibilité est l’affaire de toustes, tout au long du projet.