Analyse d'accessibilité GNUT06
Analyse RGAA bénévole du site d'un groupement numérique azuréen
Comment aider une association et ses bénévoles à améliorer l'accessibilité de leur site sans expertise interne ?
Résumé
Dans le cadre d'un bénévolat auprès du GNUT06, j'ai analysé l'accessibilité du site de l'association : définition du périmètre, analyse RGAA sur un échantillon de 7 pages, puis rédaction d'un rapport présentant chaque non-conformité avec ses conséquences pour les utilisateurs et des pistes de correction.
Le rapport sert aujourd'hui de feuille de route aux bénévoles qui font évoluer le site.
- RGAA
- Audit d'accessibilité
- Rapport
- Conseil
- Accompagnement associatif
Contexte
- Client
- GNUT06 (Groupement Numérique d'Utilité Territoriale des Alpes-Maritimes)
- Période
- Juillet 2026
- Durée
- 1 semaine d'analyse et de rédaction, accompagnement en cours
- Type de mission
- Bénévolat
- Périmètre
- Site web de l'association(Lien ouvrant dans un nouvel onglet), échantillon de 7 pages
Le GNUT06 est un groupement engagé pour l'inclusion des personnes en situation de handicap par l'innovation numérique. Une association dont c'est la raison d'être a tout intérêt à ce que son propre site soit exemplaire : c'est le premier point de contact avec les publics qu'elle défend.
Ce que j'ai fait
Choisir les pages à analyser
L'objectif n'était pas un audit RGAA complet, hors de portée pour une association bénévole, mais d'identifier les principaux points à améliorer. Encore fallait-il analyser les bonnes pages.
J'ai navigué sur l'ensemble du site pour repérer les pages les plus représentatives : celles reposant sur un gabarit réutilisé ailleurs, et celles portant une fonctionnalité qui leur est propre.
Résultats
Un échantillon de 7 pages :
- Accueil
- Point d'entrée du site, nombreuses images et informations
- Mentions légales
- Page obligatoire, systématiquement incluse dans un audit
- Contact
- Formulaire, liens variés et iframe de carte
- Connexion
- Parcours classique d'un membre : formulaire et alternative de connexion
- À propos
- Page d'information simple, gabarit réutilisé
- Événements
- Scripts de réservation complexes
- Don
- Iframe complexe contenant un formulaire
Réaliser l'analyse
J'ai évalué chaque page au regard des critères RGAA, en gardant une trace exploitable par des non-spécialistes. Pour chaque problème détecté, j'ai documenté le constat, son impact sur les utilisateurs et une piste de correction.
Outils utilisés
- Checkfox (checkfox.eu(Lien ouvrant dans un nouvel onglet)), outil d'audit en bêta que j'ai testé à cette occasion. Interface plus lisible que les grilles Excel habituelles, rappel des tests à effectuer pour chaque critère et lien direct vers le glossaire des termes techniques.
- Bookmarklets Access42 pour tester les critères un à un : détection des images et de leurs alternatives, cohérence entre nom visible et nom accessible des liens, vérification des paramètres de formulaires.
- Extensions Firefox et outils de diagnostic complémentaires.
Résultats
Rédiger le rapport
Les destinataires sont des bénévoles, pas des experts accessibilité. Le rapport devait être compréhensible sans connaissance préalable du RGAA et directement actionnable. J'ai structuré le rapport avec 3 intentions :
- Rappeler ce qu'un défaut d'accessibilité provoque concrètement chez un utilisateur
- Présenter chaque erreur détectée avec son impact et sa piste de correction
- Laisser un livrable réutilisable comme base des travaux suivants
Résultats
Un rapport livré aux responsables du site, qui sert de feuille de route aux prochaines évolutions.
Deux erreurs révélatrices
Voici des erreurs d'accessibilité que j'ai pu constater sur le site, pas forcément les plus bloquantes ou les plus critiques, mais qui me permettent d'expliquer quelques bonnes pratiques à avoir en termes d'accessibilité.
Des liens déguisés en boutons
Sur la page d'accueil, la quasi-totalité des liens portait un attribut role="button".
Pourquoi c'est un problème
Un lecteur d'écran annonce le rôle sémantique d'un élément en même temps que son texte : « lien visité », « titre de niveau 1 ». C'est ce qui permet à l'utilisateur d'anticiper ce qui va se passer. L'attribut role d'ARIA sert à donner du sens à des balises qui n'en ont pas, comme div ou span. Appliqué à une balise qui possède déjà une sémantique, il l'écrase.
Ici, l'utilisateur entend « bouton », donc s'attend à une action sur la page. Il obtient une navigation. Décalage entre l'annonce et le comportement réel.
La correction
Retirer l'attribut role="button" des liens concernés.
Des liens d'évitement inopérants
Un lien d'évitement permet à un utilisateur naviguant au clavier d'atteindre directement le contenu principal, sans traverser l'en-tête et la navigation. Il reste masqué et n'apparaît qu'au moment où il reçoit le focus.
Pourquoi c'est un problème
Sur la majorité des pages analysées, ces liens étaient placés dans le code après le bloc de navigation. Pour les atteindre au clavier, il fallait donc traverser toute la barre de navigation, exactement ce qu'ils sont censés éviter. Ils n'apparaissaient pas non plus à l'écran au focus. Fonctionnalité présente, mais sans effet.
La correction
Remonter ces liens en tête du DOM pour qu'ils reçoivent le focus en premier, et corriger les classes CSS pour qu'ils deviennent visibles dès qu'ils sont atteints.
Et ensuite ?
Le rapport a été livré et présenté aux bénévoles en charge du site en juillet 2026. L'accompagnement à la mise en œuvre est en cours, au rythme d'une équipe bénévole et ralenti par la période estivale.
Cette mission confirme une chose utile au-delà du cas GNUT06 : une structure sans budget ni expertise interne peut faire progresser son site de façon significative, à condition qu'on lui livre autre chose qu'une liste de critères, à savoir des explications sur ce que chaque défaut change pour ses utilisateurs.
Envie d'en savoir plus ?
L'accessibilité n'est pas réservée aux grandes organisations soumises à obligation légale. Si vous vous demandez où en est votre site et par quoi commencer, parlons-en.