Retour d’expérience Moooi.com : entre complexité et accessibilité
Je mène le développement du site moooi.com depuis plus d’un an et demi dans l’agence Build in Amsterdam, basé aux Pays-Bas. Je voulais partager mon retour d’expérience, car c’est mon premier projet avec une obligation d’accessibilité, mais cela n’a fait que stimuler nos ambitions.
Moooi, prononcé « moille », est une société néerlandaise de design de meubles et d’intérieurs extraordinaire. Elle possède plusieurs magasins à travers le monde, dont une boutique à New York. Selon la loi étasunienne, le site de la marque doit donc être accessible. Nous observons la même récente considération pour l’accessibilité chez nos autres clients, Suitsupply, Adidas ou Reebok. Arnaud Delafosse l’explique beaucoup mieux que je ne pourrais le faire dans un article de l’année dernière. Moooi est le projet le plus complexe que j’ai mené avec de nombreux types de produits, un site multilingue, des fonctionnalités pour les professionnels, etc., mais l’accessibilité fut la contrainte la plus originale pour moi, et aussi celle sur laquelle je n’ai jamais rechigné.
Le but était donc de refondre la boutique en ligne de Moooi avec une nouvelle identité visuelle et de la rendre accessible en suivant les directives WCAG 2.1 AA.
C’est un site ecommerce dont les produits et la vente sont gérés par Woocommerce et l’éditorial par WordPress. C’est un CMS que nous connaissons bien et qui peut être fortement personnalisé. La partie frontend du site est développée avec React et Redux. Avec une génération côté serveur en Node.js avec Express.
Pour respecter les normes d’accessibilité, nous utilisons beaucoup d’outils présentés par David Dias dans son article Outils et astuces pour rendre accessible et performante son application React. Notamment le linter eslint-plugin-jsx-a11y mais surtout le module react-axe qui audite le site en direct et affiche les erreurs dans la console avec une très bonne documentation. Mais ceci a un coût et les performances du site s’en voient réduites. Difficile alors de travailler sur les animations, nous avons donc ajouté la possibilité de le désactiver dans un panneau de configuration qui se rapproche d’un dat.GUI. Il est malheureusement très facile d’oublier de le réactiver.
Mais l’aide la plus importante n’était pas à trouver chez npm.
Humains après tout
Dès juillet 2019, nous avons eu des réunions avec un consultant de The Accessibility Foundation (en anglais), basé à Utretch, Pays-Bas. D’abord pour du conseil sur les designs, puis très vite aussi des questions techniques.
Nous avons ensuite organisé des examens des premières pages développées, parfois encore avec du contenu temporaire, par ce même consultant pour préparer l’audit prévu en décembre.
En janvier 2020, le résultat du premier audit de The Accessibility Foundation fut encourageant, mais malgré nos efforts, des erreurs nous empêchaient d’obtenir un sans-faute. Après avoir demandé plus de détails sur certains points, notre contact a reconnu ne pas être d’accord avec l’auditeur sur un point. C’est un bon exemple pour rappeler que ce n’est pas un examen de maths, le facteur humain est très important dans l’interprétation des règles et les cas d’utilisations sont considérables.
Nos erreurs étaient majoritairement des oublis ou des maladresses :
- pas de titre au logo SVG (
titlemanquant) ; - un texte alternatif manquant pour une vidéo ;
- une utilisation non sémantique de la balise
emau lieu de CSS ; - des mauvaises valeurs pour l’attribut
autocompletede champ de formulaire ; - des mauvaises interprétations de la hiérarchie du contenu. C’est parfois compliqué de trouver la suite logique des titres avec une mise en page un peu particulière. La règle la plus simple à retenir est que la hiérarchie est stricte : un h3 n’est pas possible sans h2 avant lui.
Le second audit en février révélait qu’il restait quelques erreurs, mais nous avions une semaine pour les corriger puis passer un audit complémentaire.
La troisième fut la bonne, j’étais si soulagé et fier de passer enfin ce test que j’ai imprimé la page affichant 50/50 pour décorer mon bureau.
Il ne faut pas oublier que ces audits ne sont pas des certificats absolus. Le site change tous les jours par la publication de contenu et nos modifications du code, mais cela reste une preuve significative d’un audit d’experts externes.
Mon Nom est Personnalisation
La personnalisation des contenus éditoriaux a été un gros challenge, que ce soit sur la page d’accueil ou dans les articles.
La gestion de la lisibilité et du contraste du texte sur des photos ou vidéos est toujours compliquée. De nombreux paramètres dans le CMS permettent de créer des contenus uniques en modifiant la mise en page, les typographies et les médias.
Impossible d’automatiser la gestion du contraste du texte sur une image, ou encore moins une vidéo, donc nous proposons à l’éditeur de sélectionner un thème clair ou sombre pour chaque bloc. Il peut aussi assombrir le média pour faire ressortir du texte blanc. Nous avons développé un aperçu dans WordPress pour faciliter la création de ces blocs.
Chaque page produit est agencée différemment en fonction du contenu.
Je ne vous recommanderai pas d’avoir un header au fond transparent flottant au-dessus du contenu du site si vous voulez éviter les ennuis de lisibilité. Sur Moooi, nous utilisons ce paramètre de thème des blocs pour adapter la couleur du header quand il est visible au-dessus de ces mêmes blocs.
Tabulations d’un Indien en Index
Avant ce projet, je ne considérais l’accessibilité au clavier que pour les formulaires, surtout pour satisfaire les utilisatrices et utilisateurs intensifs, comme moi. Mais la gestion du focus et du tabindex doit être contrôlée sur tout le site pour rendre une navigation au clavier fonctionnelle. C’est très facile à tester avec la touche tab. de votre clavier, même si les résultats peuvent varier en fonction du navigateur et du système d’exploitation.
Les éléments prenant le focus pouvant être invisibles, pour faciliter le débogage, nous loggons dans la console le document.activeElement lors d’un click ou quand les touches échap. ou tab. sont pressées.
L’état de focus doit être visible pour que l’utilisateur n’utilisant qu’un clavier sache comment naviguer mais pour éviter de gêner les utilisateurs de souris ou autre pointeur
:focus-visible commence à peine à être supporté, mais un polyfill existe. Nous utilisons un style global surchargé par des cas particuliers pour avoir une meilleure visibilité ou coller avec la direction artistique.
:global(.js-focus-visible) &:focus:global(.focus-visible) {
outline: 1px dashed $light_grey;
}
Un élément qui a nécessité une attention particulière pour gérer correctement la navigation au clavier fut le menu principal.
Dessine Moooi un Bouton
Le bouton du menu principal représente bien la volonté de cacher la complexité derrière des éléments simples.
C’est un rappel des boutiques physiques puisque chaque produit est muni d’un bouton NFC, invention de Moooi, prouvant leur authenticité.
Il est placé en bas de l’écran, contrairement au « menu burger » classique, pour une utilisation plus simple sur mobile et il est assez gros pour être vu et manipulé. Pour plus d’accessibilité, mais surtout pour le rendre plus amusant et physique, il peut être glissé-déposé dans d’autres coins de l’écran, pour contenter autant les gauchers·ères que les droitiers·ères. Développé avec React UseGesture, ce fut ma première expérience avec les Hooks de React. Le projet mélange d’ailleurs class components et Hooks. Cela fonctionne très bien mais demande un peu de gymnastique mentale.
Il est aussi multifonctions et sert de lecteur audio si un article, un produit ou un designer comporte une piste audio.
Une intéressante directive de WCAG est l’obligation de pouvoir accéder à un contenu de plus d’une manière. C’est généralement un lien dans le menu et une recherche ou un plan du site. Le menu propose donc un champ de recherche qui affiche les résultats d’un service tiers : https://www.tweakwise.com. Très rapide et optimisable.
Pour offrir le plus d’entrées possible, nous avons ajouté une recherche vocale grâce à la reconnaissance de parole de Google. Ce n’est disponible que sur Chrome mais ne nécessite pas beaucoup de développement. Si ce n’est pas disponible, l’option ne s’affiche tout simplement pas. Ce n’est que du bonus.
De la même manière, pour proposer les produits en Réalité Augmentée, nous nous appuyons sur les solutions offertes par les systèmes d’exploitation : AR Quick look d’iOS et Scene Viewer d’Android. Le développement est minimal et l’accessibilité est assurée, Quick Look supporte évidemment Voice Over, par exemple. Nous essayons le plus possible de combler l’écart entre le shopping physique et numérique.
Ce qui nous a amenés à développer un outil de comparaison de chaque produit avec d’autres objets pour bien se rendre compte de la taille, souvent surprenante, des lampes ou autres canapés. L’implémentation est simple, des pourcentages en CSS pour gérer la taille des deux objets. Avec des variations de présentation pour les produits suspendus ou posés au sol.
Par contre cet outil de comparaison est présenté dans un carrousel, lui-même dans une modale, cela peut paraitre un cauchemar d’UX et d’accessibilité, mais ce fut réfléchi et permet de ne montrer une information que si l’utilisateur en a besoin. L’important a été de s’assurer que la navigation au clavier était respectée. Flickity est mon carrousel fétiche pour cela. Pour les modales, nous utilisons React Portals mais pour gérer le focus au clavier, nous avons testé plusieurs modules avant de nous arrêter sur React FocusLock.
J’adore ces solutions qui ne demandent pas de grandes mises en oeuvre techniques, mais rendent le site plus accueillant et humain. Comme le titre de la page collection qui inclut les filtres actifs dans une phrase.
6918 commits et moooi et moooi et moooi
Le développement a commencé en mai 2019, la version 1.0 de la refonte a été mise en ligne en novembre 2019 et nous avons déployé 160 nouvelles versions depuis. L’équipe de développement était le plus souvent composée de trois personnes, mais jusqu’à huit développeurs ont participé au projet, produisant plus de 450 Merge requests et 6918 commits. L’application React rassemble maintenant 227 composants. 482 champs additionnels dans WordPress (avec l’indispensable plugin ACF).
En plus des fonctionnalités classiques du site marchand, vous pouvez créer des moodboards avec toutes les photos des produits, vous pouvez aussi télécharger des fichiers 3D de nombreux produits.
Nous avons aussi conçu A Life Extraordinary, un mini site pour suppléer au Salone del Mobile de Milan, repoussé à l’année prochaine. Il a été développé en six semaines par deux développeurs, commençant en même temps que le confinement ; pour plus de détails, je vous dirige vers cette étude de cas en anglais.
Juste une note sur les designers qui ont, je pense, un rôle encore plus crucial que nous, développeurs, pour assurer l’accessibilité d’un site. Une collaboration rapprochée est aussi une clé de réussite. Les maquettes du site, des emails et réseaux sociaux, le design system, un digital brand guidelines ont été réalisés sur Figma avec le plug-in Able. Vous pouvez voir la présentation (en anglais) de ma collègue Margot Gabel sur ce projet, de son point de vue de designer, même si elle aborde aussi les questions de développement.
Il faut reconnaitre que bien faire les choses prend plus de temps et demande l’apprentissage de connaissances. C’est pour cela que faire appel à des spécialistes, au moins occasionnellement, est essentiel.
L’accessibilité ne doit pas être considérée comme une fonctionnalité, mais comme une nécessité.
L’accessibilité ne peut pas être un frein à la créativité.
En n’abordant pas les directives WCAG comme de nouvelles contraintes mais comme une chance d’en apprendre plus sur nos utilisateurs, nous avons pu rester fidèles à notre principe de toujours repousser les limites de l’industrie et de délivrer une expérience extraordinaire.