Vous vous souvenez de cet article (en anglais) ? J’y abordais le sujet de l’accessibilité et de l’utilisation d’une application web par une personne en situation de handicap.
Et bien ça n’aura pas loupé, à peine l’article publié notre Delphine préférée (office manager de son état) a communiqué en internet sur l’avancement des différents projets d’inclusivité chez Indy.
Occasion rêvée d’adresser la problématique concrètement dans la vraie vie (l’IRL quoi). Et vous savez quoi ? C’est plus dur que ça en a l’air ! Donc autant partager les découvertes, non ?
C’est donc parti pour un journal de bord du projet d’amélioration des problématiques d’accessibilité de l’application Indy et de ses copines utilisées en interne.
🐣 JOUR 1 : naissance de #dev_guilde-accessibility
En dessous du message ci-dessus (vous suivez ?), j’en ai gentiment appelé à l’équipe produit Indy pour savoir si des projets étaient déjà en cours sur le sujet.
→ non, pas formellement du moins, même si nous y sommes tou·te·s sensibles et attentifs.
Qu’à cela ne tienne, maintenant c’est le cas. Et “ownership” oblige, je vais le mener.
Plus on est de neurodivergents plus on rit ? Eloïse et Benjamin se proposent instantanément pour me filer un coup de main. Et comme il n’y a pas que le javascript dans la vie (et dans le produit), c’est Léa qui va venir représenter le customer care, et donc nos clients.
Tout ça, ça crée une guilde des plus sympathiques !
🏁 JOUR 2 : c’est partiiiii
Mercredi 13 juillet, première réunion. Où l’on se réunit pour savoir où l’on veut aller.
Objectif du jour : entériner la création de la guilde accessibilité produit, son périmètre, sa raison d’être, ses missions et des objectifs actionnables.
En effet, l’accessibilité n’est pas une tâche atomique, et il faut savoir définir des objectifs considérés suffisants car on aurait trop vite fait de poursuivre son amélioration à l’infini.
Et comment savoir si on est allé trop loin ? Il faut savoir si et quand on a fini, et donc pouvoir mesurer un niveau de “qualité” des applications à atteindre et maintenir.
Et comment savoir si on est allé assez loin ? Il faut déjà savoir d’où l’on vient, et donc pouvoir mesurer le niveau actuel de l’accessibilité des applications. Donc faire un audit de l’existant.
🛠️ JOUR 3 : les premiers coups dans la fourmilière
On n’est pas venus pour souffrir, OK ? Alors on ne va pas réinventer le fil à couper l’eau tiède, il y en a déjà de très bien dans le commerce.
Par contre on va très sérieusement appliquer les recommandations de l’état de l’Art sur le sujet.
Mais un pas après l’autre, alors la première chose qu’on a faite, c’est ajouter cette ligne :
// .eslintrc.js extends: ['plugin:vuejs-accessibility/recommended'],
Parce que oui, on fait du VueJS, on utilise ESLint, et on travaille sur l’accessibilité.
Donc on a ajouté le plugin ESLint VueJS-Accessibility. Logique imparable !
Et le recommended alors ?
Il correspond à :
rules: {
"vuejs-accessibility/alt-text": "error",
"vuejs-accessibility/anchor-has-content": "error",
"vuejs-accessibility/aria-props": "error",
"vuejs-accessibility/aria-role": "error",
"vuejs-accessibility/aria-unsupported-elements": "error",
"vuejs-accessibility/click-events-have-key-events": "error",
"vuejs-accessibility/form-control-has-label": "error",
"vuejs-accessibility/heading-has-content": "error",
"vuejs-accessibility/iframe-has-title": "error",
"vuejs-accessibility/interactive-supports-focus": "error",
"vuejs-accessibility/label-has-for": "error",
"vuejs-accessibility/media-has-caption": "error",
"vuejs-accessibility/mouse-events-have-key-events": "error",
"vuejs-accessibility/no-access-key": "error",
"vuejs-accessibility/no-autofocus": "error",
"vuejs-accessibility/no-distracting-elements": "error",
"vuejs-accessibility/no-onchange": "error",
"vuejs-accessibility/no-redundant-roles": "error",
"vuejs-accessibility/role-has-required-aria-props": "error",
"vuejs-accessibility/tabindex-no-positive": "error"
}
Après on a npm run lint et notre terminal s’est mis à clignoter de toutes les couleurs (enfin, tant que c’est du rouge).
Après on a retroussé nos claviers, et on a réparé toutes les erreurs remontées par le plugin :
Avec sur le podium des choses pas top :
vuejs-accessibility/label-has-forvuejs-accessibility/click-events-have-key-eventsvuejs-accessibility/form-control-has-label
Et pour une utilisatrice malvoyante, ça aurait posé souci dans les formulaires !
Après on a regardé notre code, tout ce qu’on avait amélioré “et voici, cela était très bon”. Enfin, un peu mieux quoi. C’est pas fini !
Et sans grande difficulté qui plus est, comme quoi parfois c’est pas compliqué de bien faire :
🚀 DEMAIN : la suite au prochain épisode
Non, c’est pas fini, loin de là. Ce premier article touche à sa fin car le jour 3 s’est achevé hier.
Mais demain ? Demain on va continuer !
Parce que c’est bien beau de regarder les recommandations, mais ça ne répond pas nécessairement aux besoins de nos utilisateurs. Et nos utilisateurs c’est notre raison de travailler.
Donc à prévoir :
- Des sondages auprès de nos utilisateurs (internes et externes) pour déterminer les priorités
- Des audits plus poussés (tout ne peut pas se voir dans le code, exemple tout bête : le contraste d’un texte ou les couleurs d’un bouton)
- La détermination d’indicateurs fiables pour suivre l’évolution de l’accessibilité
- La rédaction d’une convention technique pour encadrer le développement de nos applications et intégrer l’accessibilité aux bonnes pratiques de code chez Indy
- Un deuxième article de blog !
