Accessibilité : où en sommes-nous chez OpenClassrooms ?
Avant même de travailler chez OpenClassrooms, je savais que j’allais rejoindre une équipe très attentive à l’accessibilité. Effectivement, c’est une valeur qui est au coeur des missions de l’entreprise, une des mes collègues a d’ailleurs publié un article très complet sur le sujet. Les bonnes pratiques de développement étaient aussi mises en avant. De plus, l’entreprise se veut regardante de ses impacts, sur l’éducation évidemment mais aussi sur l’environnement, l’humain.e et le social auprès de ses salarié.e.s.
Lors de mon entretien technique avec un développeur, il y avait effectivement un bouton à analyser au niveau de l’accessibilité. Je ne saurais dire si c’est une pratique courante mais c’était la première fois que mes compétences à ce sujet étaient évaluées en entretien.
OpenClassrooms affiche donc clairement une volonté d’être une entreprise inclusive et accessible à tou.te.s jusqu’à son site. Allons voir ce qu’il en est au quotidien au sein de l’équipe front-end !
Les pratiques existantes et recensées
Pour commencer, faisons un point sur la documentation que j’ai trouvée sur le sujet. Je m’intéresse uniquement aux actions menées côté développement front. Toutes les mesures en amont, liées au design par exemple, ne seront pas analysées ici.
Dans les deux pages de documentation interne que j’ai trouvées, nous abordons des points élémentaires mais indispensables tels que la structure sémantique des pages html. Il nous est conseillé d’utiliser cette extension à chaque création ou modification de page.
Concernant les icônes, nous devons ignorer les décoratives via aria-hidden et donner un texte explicite aux sémantiques.
// Icône décorative :
<Icon
className={classes.rectangle}
aria-hidden="true"
>// Icône sémantique :
<IconButton
className={classes.up}
aria-label="Revenir à l'élément précédent"
disabled={!onOrderUp}
onClick={onOrderUp}
color="inherit"
>
<ArrowUpwardIcon />
</IconButton>
Il en est de même pour les illustrations qui doivent être insérées dans un tag <img>. Nous utilisons soit Material UI, soit un composant maison et les deux se chargent de gérer les labels aria.
<img
className={classes.partnersLogos}
alt={client.name}
src={client.logo}
/>Aussi, tous les éléments interactifs doivent être focalisables via la navigation clavier et rester focalisés quand ils sont ouverts, avoir des états de hover et focus et être fermables via la touche échap.
'&:focus': {
boxShadow: shadows[6],
},
fadeScreen: {
opacity: 0.08,
'&:hover': {
opacity: 0.3,
cursor: 'pointer',
},Nous entendons toujours parler de la navigation à la voix et au clavier, si la navigation au clavier est relativement intuitive, combien de développeur.se.s maîtrisent vraiment celle à la voix ? Nous avons une page richement documentée sur le sujet, dans laquelle se trouve les commandes basiques de navigation hors souris, des infographies sur les différents types de handicap et de nombreux liens relatifs à l’accessibilité.
Interroger mes collègues sur leur routine d’accessibilité
Afin de savoir lesquelles de ces pratiques nous appliquons vraiment, j’ai réalisé un sondage très simple auprès de mes collègues : de quelles pratiques avez-vous connaissance ? Parmi celles-ci lesquelles appliquez-vous ? Faites-vous des actions supplémentaires ? Avez-vous des suggestions d’amélioration ?
Voici les résultats :
Nous constatons que la majorité de l’équipe est au fait des pratiques à appliquer avec une moyenne de 8,5/9 par réponse et que ces règles sont globalement plutôt bien appliquées, avec une moyenne de 6,5/9 par réponse.
Sans surprise la sémantique html et la navigation clavier sont vérifiées par tout le monde.
Toujours sans surprise, la navigation par la voix n’est vérifiée que par deux d’entre nous.
Les icônes décoratives ne sont cachées dans aria que par la moitié de l’équipe.
Les autres actions aria étant assez bien respectées, il semblerait que celle-ci soit oubliée ou que l’on ne sache pas comment la réaliser.
De même pour la persistance du focus et la fermeture via la touche échap des éléments interactifs, seule la moitié d’entre nous le fait, contrairement aux autres points d’attention sur les éléments interactifs. Probablement un oubli ou un manque de connaissance.
Globalement nous avons une assez bonne connaissance des bonnes pratiques concernant l’accessibilité et nous les respectons en majeure partie.
Mettre à jour nos exigences
Mais cela est-il suffisant ? Avons-nous réalisé un site web accessible pour autant ?
Non.
Nous sommes effectivement vigilant.e.s sur plusieurs points fondamentaux, pour autant cela ne suffit pas à rendre nos pages 100% accessibles. Nous devons nous améliorer sur les pratiques que nous n’appliquons pas encore régulièrement et probablement recueillir celles que nous faisons déjà sans les avoir formalisées.
Pour cela, allons faire un tour du côté du sondage avec les réponses de mes collègues.
Un de nos rôles en tant que développeu.r.se front-end est d’être gardien.ne de l’accessibilité avant même de commencer à développer, comme expliqué par un.e de mes collègues : “Ce n’est pas du code mais il faut dire non aux chef.fe.s de projet quand : une image contient du texte ou que le contraste ne passe pas les vérifications des normes AA”. Par exemple, on retrouve cette suggestion “pas de texte trop petit (ou agrandissable), pas de texte dans les images.”, “les éléments cliquables doivent être suffisamment grands (min 44x44)”. Il s’agit bien du travail des designer.euse.s mais nous devons le vérifier lorsqu’il.elle.s nous le présentent pour discuter de la faisabilité technique.
Les animations sont surveillées de près également, comme le rapporte un.e des développeu.r.se.s : “Désactiver les animations si la réduction d’animations est activée, ajouter des rôles aux attributs”, “ Quand je travaille avec des animations, j’active leur réduction dans les réglages pour m’assurer qu’elles soient bien statiques sans que l’expérience utilisateur.ice en pâtisse”, “préférer les images statiques aux animations”.
Une de mes collègues propose cette solution :
Sur Mac, la réduction des animations s’active dans les Préférences Système > Accessibilité > Affichage > Réduire les animations. Mais si on ne le gère pas dans le code avec une solution alternative aux animations, la demande d’annulation dans le navigateur n’est pas prise en compte.
Il suffit d’initialiser une variable, puis de l’utiliser comme condition. Pour sa valeur false on affichera l’animation demandée, pour sa valeur true une version statique de l’image ou de la transition.
const reducedMotion = useMediaQuery(‘(prefers-reduced-motion: reduce)’{
videoId
&& !reducedMotion
&& <div
className={classes.video}
ref={videoRef}
/>
}
Sinon nous l’inscrivons dans le JSS :
doubleChevronIcon: {
@media (prefers-reduced-motion:reduce) {
.animation {
animation: none,
}
}
}Concernant notre outil Lighthouse, je me suis rendu compte qu’il est peu utilisé, certain.e.s proposent, dans certains cas, d’utiliser Axe qui est assez réputé pour l’accessibilité “J’utilise Axe DevTools (parfois c’est pertinent, parfois non)”, “J’utilise différentes extensions pour vérifier l’accessibilité, pas seulement LightHouse. Ca m’aide à identifier les faux positifs”.
Nous devrions également enrichir nos règles de base avec des vérifications comme celles-ci “donner des attributs alt aux images, s’assurer que les zones de saisies soient connectées à leur label, que les messages d’erreur de saisie y soient également connectés avec un aria-describedby”.
La dernière question de mon sondage concernait les améliorations à implémenter.
L’amélioration la plus demandée concerne les audits. Nous en avons déjà fait réaliser quelques-uns mais il semblerait que l’équipe souhaite en faire de manière régulière. En effet, cela nous permet d’avoir du recul et de maintenir un certain niveau d’exigence tout en ajoutant de nouvelles normes.
L’idée d’automatiser certaines tâches est avancée et elle me paraît assez importante quand l’on sait que la plupart des éléments non-accessibles le sont car nous manquons de temps ou d’attention.
Nous pourrions commencer par remettre à jour nos composants du design system en rendant obligatoire la validation de critères d’accessibilité (nous sommes d’ailleurs en train de refaire une passe sur toutes les icônes de la stack et leur aria-label, il serait intéressant de le faire sur cette tâche).
Ce serait également pertinent de regarder si des modules tels qu’Axe ou Lighthouse peuvent être intégrés dans notre processus d’intégration continue via la CI/CD ou nos Gitlab actions.
Il ne faut pas oublier l’humain. Il est essentiel de continuer à en parler pour sensibiliser l’équipe et ancrer ces pratiques dans nos habitudes de développement. Il serait aussi essentiel d’avoir des contacts ou des membres de l’équipe en situation de handicap afin d’avoir un retour direct et continu.
Les prochaines étapes
La recherche des pratiques instaurées et à respecter a été assez fastidieuse et chronophage. Nous devrions déjà commencer par mettre à jour notre page Notion dédiée à l’accessibilité et y regrouper les différentes ressources existantes.
La page se rapprochant le plus d’un centre de ressources n’est pas très agréable visuellement et n’incite pas forcément à l’approfondissement de ce sujet.
Je suggère donc les améliorations suivantes :
- centralisation des connaissances et mise à jour des pratiques requises au sujet de l’accessibilité,
- refonte de la page Notion pour la rendre plus pédagogue et stimulante,
- discussion autour de Lighthouse pour comprendre sa faible utilisation : de là, présentation et promotion de l’outil ou discussion autour d’un potentiel nouvel outil,
- formaliser les vérifications concernant les animations,
- automatiser le plus de tâches et vérifications possibles,
- afin de faciliter la cohésion design/développement nous pourrions essayer cet outil pour Figma : aide les designe.r.use.s à documenter les questions d’accessibilité afin de les partager aves les développeu.r.se.s lors de la remise des maquettes,
- réaliser un audit complet de la plateforme (nous avons un budget alloué), il serait peut-être intéressant de le faire avant d’établir de nouvelles règles,
- la mise en place d’un dark mode est également avancée pour pallier à certaines situations de handicap. Après quelques recherches, il semble que le dark mode soit plus approprié aux personnes avec des troubles de la vision et le light mode plus adapté aux personnes n’en ayant pas. Implémenter un dark mode pourrait donc être une bonne idée si nous laissons le choix aux utilisateur.ice.s.
Dans cet article, j’ai voulu faire un tour d’horizon de l’état actuel de la stack front-end. Bien que notre site soit plus facilement accessible que d’autres, nous avons encore beaucoup de progrès à faire au sein de notre équipe.
Mais au-delà des améliorations côté front-end, il est nécessaire que les équipes produit, design et tech travaillent main dans la main pour produire une plateforme accessible à tou.te.s. Comme le rappelle Stephanie Hagadorn, tout cela doit avoir lieu avant la phase de développement pour éviter que le sujet soit vécu comme une contrainte, tant par les équipes techniques qui peuvent le vivre comme des tâches rébarbatives de correction de code existant, que les équipes produit et design qui peuvent accorder plus d’importance à sortir de nouvelles features que retravailler sur les existantes :
Selon un rapport d’IBM, le prix de la résolution des erreurs après la publication peut être jusqu’à 30 fois plus élevé que si elles étaient découvertes pendant la phase de conception. [Traduction]
