Améliorer l’accessibilité d’un site existant : retour d’expérience chez JoliCode

Malgré des avancées réglementaires importantes, l’accessibilité numérique reste largement sous-estimée dans de nombreux projets web. Depuis le 28 juin 2025, l’European Accessibility Act (EAA) étend les obligations d’accessibilité à de nombreux services numériques privés. Pourtant, la réalité est encore loin des objectifs fixés : selon l’Observatoire du respect des obligations d’accessibilité numérique, seuls 44 sites sur 7 560 contrôlés déclarent être totalement conformes au référentiel général d’amélioration de l’accessibilité (RGAA), soit 0,58 % de l’échantillon analysé.

Atteindre un bon niveau d’accessibilité demande généralement un travail de fond sur la conception, le contenu et les développements du site. Cependant, certaines améliorations simples, peu coûteuses et rapides à mettre en œuvre permettent déjà d’offrir une expérience plus inclusive à l’ensemble de vos visiteurs.

Dans cet article, je partage les premières actions que j’ai mises en place sur le site de JoliCode. Ces améliorations ont permis de corriger plusieurs problèmes courants et constituent une première étape vers une expérience plus accessible pour toutes et tous.

Section intitulée l-etat-des-lieuxL’état des lieux

La première étape consiste à réaliser ce qu’on appelle un audit d’accessibilité. Il permet de tester l’ensemble des 106 critères constitutifs du RGAA. Pour cela, l’outil ARA développé par la direction interministérielle du numérique (DINUM) propose une interface en ligne et la génération de rapport et de déclaration de conformité.

Pour ma part, armée de la liste des critères, j’ai passé en revue un échantillon de pages représentatif : la page d’accueil, la page contact, la page blog et une page article. L’objectif était également de mieux connaître les critères du RGAA et les différentes méthodes permettant de les évaluer. La navigation au clavier, l’utilisation d’un lecteur d’écran et quelques extensions de navigateur m’ont permis d’identifier rapidement plusieurs problèmes d’accessibilité. Même si l’accessibilité est prise en compte dès le début de nos projets, les mises à jour et maintenances successives, ainsi que les diverses contributions, ont introduit au fil du temps des erreurs fréquentes et faciles à corriger.

Pour structurer les corrections issues de cet audit, j’ai commencé par regrouper les problèmes identifiés dans un tableau de suivi. L’objectif était de relier chaque point à son critère RGAA et de pouvoir suivre facilement les corrections à mettre en place sur le site. Le format du tableau était le suivant :

Type	Correction à faire	Critère correspondant	Statut	Images
« Navigation » ou « Contrastes »	Description de la correction à appliquer	Lien vers le critère RGAA correspondant	✅, 🔜 ou ❌ avec un lien vers la pull request si elle existe	Capture d’écran du problème constaté

Section intitulée ameliorer-la-lisibilite-des-contenusAméliorer la lisibilité des contenus

Parmi les erreurs les plus fréquentes, on retrouve souvent des problèmes de contrastes insuffisants. C’est l’un des éléments qui doit être anticipé dès la phase de conception d’un site. Il existe pourtant des outils simples en ligne (et même des plugins Figma) permettant de vérifier le contraste entre une couleur d’arrière-plan et d’avant-plan. Sur le site de JoliCode la couleur rose ainsi qu’un niveau de gris, avaient un contraste insuffisant (sur fond blanc et noir pour le rose, sur fond blanc pour le gris). J’ai utilisé l’outil de Tanaguru permettant de trouver des couleurs similaires respectant les critères de contraste. L’usage du rose a été limité au fond blanc, les liens sur section sombres s’affichant désormais en jaune. Cette modification n’a pas eu d’impact sur l’identité visuelle du site tout en améliorant la lisibilité des contenus.

Section intitulée faciliter-la-navigationFaciliter la navigation

Section intitulée corriger-la-navigation-principaleCorriger la navigation principale

Le menu de navigation principal comportait plusieurs problèmes :

• Il n’utilisait pas les bons attributs ARIA
• Il n’était pas totalement utilisable au clavier
• Le menu actif était indiqué uniquement par un changement de couleur

Pour corriger la structure du menu, je me suis basée sur le pattern “Disclosure Navigation Menu” du guide de la Web Accessibility Initiative (WAI). Pour ne pas toucher au design mais permettre l’utilisation des sous-menus au clavier, un bouton s’affiche désormais lors de la tabulation et permet d’y accéder. La barre jaune initialement affichée uniquement au survol permet désormais d’indiquer le menu actif, permettant une meilleure visibilité aux personnes qui distinguent difficilement certaines couleurs.

Section intitulée ajouter-un-lien-d-evitementAjouter un lien d’évitement

S’il est important que le menu de navigation soit accessible, il faut également permettre à l’utilisateur d’accéder facilement au contenu du site, sans forcément avoir à parcourir tout le menu. Ainsi, j’ai ajouté un lien d’accès rapide accessible via la touche tabulation dès l’arrivée sur le site. Il permet aux utilisateurs naviguant au clavier ou avec un lecteur d’écran d’accéder directement au contenu du site.

Section intitulée structurer-l-informationStructurer l’information

L’utilisation de titres au sein d’une page web est essentielle pour structurer l’information. Elle rend la lecture plus agréable, permet de mettre des mots clés en avant d’un point de vue SEO et certains utilisateurs et utilisatrices s’en servent pour naviguer. Sur ce dernier point il est donc important d’avoir une hiérarchie de titres cohérente : éviter les sauts de titre (passer d’un h2 à un h4 par exemple) et surtout un ordre incohérent (passer d’un h1 à un h3 puis un h2). Pour cela je vous conseille l’extension headings map qui permet de visualiser simplement une erreur dans la hiérarchie de vos titres.

Sur le site de JoliCode, un titre avait été balisé de manière à prendre un certain style mais l’ordre n’était plus cohérent. Le balisage a été changé et le style géré via une classe CSS.

Section intitulée donner-du-sens-aux-imagesDonner du sens aux images

Vient le sujet majeur de l’accessibilité des images et son fameux attribut alt. On en a tellement entendu parler que certains contributeurs se mettent désormais à le remplir, même quand ce n’est pas nécessaire.

Voici ce qu’il faut retenir :

• une image qui n’apporte pas d’information supplémentaire doit avoir un attribut alt vide. Cela signifie que même si l’image est porteuse d’information, si cette information est présente dans le texte à côté de l’image, il est inutile de l’indiquer dans l’attribut alt. Le lecteur d’écran risquerait de lire deux fois la même information, générant du bruit inutile. Le mieux est l’ennemi du bien.
• En revanche, si l’image est essentielle à la compréhension, il faut remplir l’attribut alt pour la décrire.

Demandez-vous simplement : si on retire l’image, est-ce que l’information reste compréhensible dans son entièreté ? Ou au contraire est-ce que l’on perd de l’information ? Si retirer l’image ne change rien alors elle n’est pas porteuse de sens et l’attribut alt doit être présent, mais vide.

En partant de ce constat, plusieurs attributs alt ont été corrigés, même si, nombre d’entre eux étant contribués dans les pages article, il en reste sûrement à améliorer.

Les SVG méritent également une attention particulière. Pour les SVG en ligne, il faut là aussi, dissocier ceux qui sont porteurs d’information et ceux qui ne le sont pas. Dans le premier cas, il est nécessaire de fournir une alternative textuelle directement dans le SVG, par exemple à l’aide d’un élément <title>.

<svg role="img">
  <title>texte de description</title>
  ...
</svg>

Dans le deuxième cas, l’attribut aria-hidden="true" doit être ajouté à la balise.

<svg aria-hidden="true">
…
</svg>

Section intitulée rendre-les-formulaires-plus-explicitesRendre les formulaires plus explicites

Lier un champ de formulaire à un libellé est globalement maîtrisé. Mais sur le site de JoliCode, il y a un cas que nous n’avions pas forcément anticipé. Sur la page blog, le formulaire de recherche possède un champ avec un libellé non visible.

Si un label est bien présent dans le code et accessible aux technologies d’assistance grâce à une classe sr-only, il ne satisfait pas le critère 11.1.3 du RGAA :

Même si le champ possède un placeholder, celui-ci disparaissant au focus, le référentiel demande qu’un autre texte visible indique la fonction du champ de formulaire. Afin d’éviter un changement graphique, j’ai ajouté un attribut title pour répondre au critère.

Section intitulée enseignements-et-perspectivesEnseignements et perspectives

Ces différentes corrections représentent finalement peu d’efforts et de lignes de code pour un gain non négligeable pour de nombreuses personnes. Elles correspondent à des erreurs parmi les plus fréquemment rencontrées :

• le respect des contrastes de couleurs,
• la bonne gestion des alternatives textuelles des images et des SVG,
• une navigation entièrement utilisable au clavier,
• l’ajout d’un lien d’évitement,
• et une meilleure explicitation des formulaires.

Pour autant, ce travail ne suffit pas à rendre un site conforme au RGAA. L’accessibilité reste un sujet transversal qui concerne aussi bien la conception, le design, le développement que la production de contenu. Ces premières améliorations constituent donc moins une finalité qu’un point de départ vers une démarche d’amélioration continue.