Étude de cas : mise en conformité au RGAA du site Plan International France.
Premier volet de notre mini-série consacrée à la mise en place de l’accessibilité numérique vue par Magnétic. Chacun d’eux tentera de faire la lumière sur une thématique, à travers un projet.
Aujourd’hui, coup de projecteur sur la mise en conformité au RGAA du site Plan-international.fr, développé sous WordPress.
La nature même du site, des pages aux structures complexes, très riches en contenu, donnait déjà le ton : la mise en place de l’accessibilité serait longue et compliquée.
Suite à l’audit initial et parmi l’ensemble des corrections à apporter, deux chantiers se sont distingués :
- Composer avec une charte graphique fournie qui n’était pas accessible elle-même.
- Rendre accessible les scripts et les composants d’interface complexes : sliders, carrousels, contenus à onglets, formulaires, etc.
Pour la charte graphique, le gap de contrastes à atteindre étant trop grand et nous avons dû nous résoudre à mettre en place une version contrastée, via un bouton en haut de page.
Ce dispositif n’est pas du tout une solution que nous préconisons parce qu’elle se rapproche, toutes proportions gardées, de ces outils de surcouches d’accessibilité qui promettent de rendre les sites accessibles en 1 clic. Lire, à ce sujet, l’excellent article de la Lutine du Web.
Dans notre cas, le changement de couleurs via un bouton s’est imposé comme la seule alternative viable. Mais nous avons fait cela de manière très précise pour éviter de dénaturer la charte graphique. Il a fallu pour cela revoir tous les éléments dont le ratio de couleurs entre le fond et le texte était insuffisant. Considérant le nombre de blocs et de possibilités entre eux dans le site, ce travail fut long et chirurgical.
Pour le deuxième chantier, les interfaces riches, le problème était différent car il existe quantité de librairies et de composants dédiés sous WordPress. Inutile donc de coder un carrousel puisqu’il en existe pléthore qui fonctionne très bien. Mais qui sont accessibles, vraiment accessibles, c’est déjà plus rare.
Dans ce cas, deux solutions sont possibles :
- Soit on change complètement de plugin,
- Soit on créé son propre composant.
Cette dernière solution est plus lourde en terme de ressources mais évidemment, bien plus fiable.
Dans ce projet, nous avons dû faire les deux.
Nous avons dû changer de plugin pour la gestion des carrousels – il y en a 3, fonctionnellement différents sur le site – en remplaçant la librairy Slick, pourtant très populaire, par Splide, un composant plus récent et dont la prise en charge des éléments d’accessibilité a considérablement simplifié le travail.
La création ex-nihilo d’un composant s’est avérée indispensable en remplacement de Contact Form 7 qui est sans doute LE plugin le plus répandu pour la gestion des formulaires sur WordPress. Mais hélas, il n’est pas totalement accessible, notamment dans la gestion des erreurs.
Impossible de modifier un tel composant et plutôt que d’en rechercher un autre (nous n’avions aucune garantie d’en trouver un qui nous convienne à 100%), nous avons décidé de développer tous nos formulaires nous-même et ainsi, nous avons pu avoir le contrôle total sur l’un des composants d’interface les plus complexes qui soient sur un site (du point de vue de l’expérience utilisateur et donc de l’accessibilité) : le formulaire.
Ce n’est d’ailleurs pas pour rien qu’un chapitre entier du référentiel RGAA lui est consacré.
Ces 2 exemples montrent qu’il n’existe pas de recette toute faite pour rendre un site accessible et qu’il faut s’adapter selon un contexte donné : l’état du site avant démarrage des travaux, la technologie utilisée, les besoins métier du client, etc.
Mais l’objectif, lui, sera toujours le même : garantir une consultation égale à tous les utilisateurs, sans distinction.