L’accessibilité RGAA peut sembler intimidante : 106 critères, 13 thématiques, jargon technique. Pourtant, 80 % des problèmes les plus fréquents se règlent avec une démarche en cinq étapes simples, sans recourir immédiatement à un audit externe. Cet article est le pendant pratique de notre page pilier sur le cadre légal RGAA.
Note honnête sur notre niveau actuel. Soyons transparents : nous n’avons pas fait réaliser d’audit RGAA officiel par un organisme tiers, et nous ne sommes pas certifiés. Aucun label d’accessibilité externe ne couvre aujourd’hui la plateforme Mairie.app.
Ce que nous nous engageons à faire, dans la limite de nos moyens actuels : respecter au mieux le référentiel RGAA 4.1 niveau AA dans la conception, le développement et la maintenance — sémantique HTML, contrastes vérifiés, navigation clavier, structures ARIA, alternatives textuelles, tests automatisés intégrés au cycle de livraison.
Si vous rencontrez une problématique d’accessibilité sur la plateforme ou sur un site de commune que nous hébergeons, votre retour nous est précieux. Nous mettrons tout en œuvre pour corriger le problème dans les meilleurs délais — signalez-nous une problématique d’accessibilité.
Auto-évaluer le site actuel : checklist 20 points
Avant de payer un audit, commencez par une auto-évaluation rapide. Cette checklist couvre les 20 points qui représentent l’essentiel des non-conformités constatées sur les sites de communes. Comptez environ 1 heure pour parcourir un site moyen.
- Chaque image porteuse d’information a une alternative textuelle utile (pas "image1.jpg")
- Les images purement décoratives sont correctement masquées aux lecteurs d’écran (alt="")
- La hiérarchie des titres est cohérente : un seul h1 par page, h2 puis h3 dans l’ordre
- Le contraste texte/fond est ≥ 4,5:1 pour le texte normal, ≥ 3:1 pour le texte large
- Aucune information n’est véhiculée uniquement par la couleur (rouge = erreur sans texte)
- Tous les liens ont un intitulé explicite hors contexte (pas "cliquez ici", "lire la suite")
- Les liens externes et les liens vers des PDF sont signalés clairement
- Le focus clavier est visible sur tous les éléments interactifs (boutons, liens, champs)
- Toute la navigation est utilisable au clavier sans souris (Tab, Entrée, Échap, flèches)
- Les formulaires ont un label explicitement associé à chaque champ (pas juste un placeholder)
- Les messages d’erreur de formulaire identifient clairement le champ en cause
- Le site reste utilisable avec un zoom à 200 % sans perte d’information ni scroll horizontal
- Le site fonctionne sur mobile (responsive design, cibles tactiles ≥ 44px)
- Les vidéos publiées ont des sous-titres (synchronisés, pas auto-générés brut)
- Les fichiers audio ont une transcription textuelle
- La langue de la page est déclarée dans le code (lang="fr")
- Le titre de chaque page est unique et descriptif (balise title)
- Les tableaux de données ont des en-têtes correctement balisés (th, scope)
- Aucun contenu ne clignote plus de 3 fois par seconde (risque épilepsie)
- La déclaration d’accessibilité est publiée et accessible depuis le pied de page
Score d’interprétation : moins de 10 points sur 20, votre site est en situation critique — engagez immédiatement un plan de mise à niveau. Entre 10 et 15 points : situation typique, des corrections rapides peuvent transformer la conformité. Plus de 15 points : votre socle est solide, un audit externe permettra d’atteindre la conformité totale.
Outils gratuits pour détecter les problèmes
Plusieurs outils gratuits permettent d’automatiser une partie de l’audit RGAA. Ils ne remplacent pas une vérification manuelle (environ 30 % des critères ne sont détectables qu’à l’œil), mais ils éliminent rapidement les erreurs les plus fréquentes.
axe DevTools (extension navigateur)
Le standard de fait du marché. Extension Chrome et Firefox gratuite. Détecte automatiquement les erreurs d’accessibilité sur la page consultée : contrastes, ARIA incorrects, hiérarchie de titres, alternatives manquantes. Rapport clair avec lien vers la documentation WCAG/RGAA correspondante.
deque.com/axe/devtools — usage : ouvrez la page à tester, lancez l’extension, parcourez les erreurs détectées. Faites-le sur 10 à 20 pages représentatives (accueil, actualité, page démarche, formulaire de contact, mentions légales).
WAVE (interface web)
Outil de WebAIM, accessible sans installation. Saisissez une URL, l’outil affiche une version annotée de la page avec icônes d’erreur et de bonnes pratiques. Très visuel, idéal pour sensibiliser des décideurs non-techniques.
wave.webaim.org — particulièrement utile pour visualiser la structure des titres et identifier les images sans alternative.
Lighthouse (Chrome DevTools intégré)
Intégré gratuitement dans Chrome (onglet "Lighthouse" des DevTools). Audit performance + accessibilité + SEO en une seule passe. Le score "Accessibility" synthétise l’état de la page, avec liste des problèmes détectés. Pratique pour suivre l’évolution dans le temps (capture d’écran du score à chaque modification majeure).
Color Contrast Checker (WebAIM)
Vérification ciblée des contrastes texte/fond. Saisissez les deux couleurs en hexadécimal, l’outil indique le ratio et si le contraste est conforme aux niveaux AA et AAA. Indispensable pour valider la charte graphique avant production.
webaim.org/resources/contrastchecker — à utiliser systématiquement avant de valider une couleur primaire de marque.
Tests manuels indispensables
Au-delà des outils, trois tests manuels complètent l’audit automatique :
- Navigation clavier complète : débranchez votre souris, parcourez tout le site avec Tab, Entrée, Échap, flèches. Notez tous les éléments inaccessibles ou dont le focus n’est pas visible.
- Lecteur d’écran : utilisez NVDA (gratuit, Windows) ou VoiceOver (intégré macOS) pour entendre comment le site est restitué. Le contenu reste-t-il compréhensible ?
- Zoom 200 % : dans le navigateur, Ctrl + plusieurs fois jusqu’à 200 %. Le contenu reste-t-il lisible sans scroll horizontal ?
Les 5 corrections rapides à fort impact
D’expérience, cinq corrections corrigent à elles seules 60 à 80 % des erreurs détectées sur les sites de mairie. Aucune ne demande de compétence technique avancée, la plupart se font dans l’éditeur de contenu.
1. Alternatives textuelles sur toutes les images
Pour chaque image porteuse d’information (affiche d’événement, photo d’un élu, infographie), saisir une alternative textuelle utile : décrire ce que l’image apporte, pas son apparence. Pour les images purement décoratives (séparateurs, motifs), saisir un alt vide pour que le lecteur d’écran les ignore.
À éviter : "image1.jpg", "photo", "logo", "DSC_0042", ou décrire mécaniquement ("femme souriante devant un bâtiment"). À privilégier : "Inauguration de la nouvelle école, septembre 2025" si l’image illustre cet événement.
2. Hiérarchie des titres dans l’ordre
Un seul h1 par page (le titre principal), suivi de h2 pour les sections, h3 pour les sous-sections, sans sauter de niveaux. Ne pas utiliser un titre pour styliser un texte en gras — utiliser strong à la place. Erreur fréquente : avoir un h4 sans h3 au-dessus.
3. Contrastes de couleurs
Vérifier au Color Contrast Checker que toutes les couleurs de la charte respectent le ratio 4,5:1 minimum. Les violations les plus fréquentes : texte gris clair sur fond blanc, lien bleu pâle sur fond bleu nuit, texte blanc sur image de fond. Corriger dans le thème graphique du site (variables CSS centralisées idéalement).
4. Focus visible sur tous les éléments interactifs
Au clavier, l’élément en cours de focus doit être visuellement distingué (bordure, surbrillance, soulignement). De nombreux thèmes désactivent le focus par défaut pour des raisons esthétiques (outline: none) — c’est une violation RGAA majeure. Activer un style de focus clair sur boutons, liens, champs de formulaire.
5. Libellés explicites sur les formulaires
Chaque champ doit avoir un libellé label associé via l’attribut for. Un simple placeholder ne suffit pas : il disparaît à la saisie et n’est pas toujours lu par les lecteurs d’écran. Les messages d’erreur doivent identifier le champ concerné ("Le champ Email est invalide") et être annoncés aux technologies d’assistance.
Quand faire appel à un audit professionnel
L’audit RGAA professionnel par un cabinet spécialisé (Access42, Ideance, Tanaguru, Atalan, Klap, Tilo) est utile dans plusieurs cas :
- Commune de plus de 10 000 habitants : le risque de contrôle ARCOM et de plainte augmente avec la visibilité.
- Après une refonte majeure : valider la conformité avant de publier la déclaration d’accessibilité.
- Après une plainte ou un signalement formel : documenter objectivement la conformité ou son défaut, et planifier les corrections.
- Tous les 3 ans en routine : bonne pratique pour les communes visant la conformité stricte au décret.
Coût indicatif : entre 3 000 et 8 000 € selon la taille du site (nombre de pages, gabarits, fonctionnalités complexes comme une billetterie ou un portail famille). L’audit produit un rapport détaillé critère par critère, un taux de conformité chiffré, et un plan de correction priorisé.
Vérifiez que le cabinet utilise bien le référentiel RGAA 4.1 officiel publié sur accessibilite.numerique.gouv.fr et non un référentiel propriétaire. Demandez un échantillon de rapport avant commande.
Rédiger sa déclaration d’accessibilité
La déclaration d’accessibilité est un document obligatoire, à publier sur le site (généralement à l’URL /accessibilite), accessible depuis le pied de page de toutes les pages publiques. Son absence est en elle-même un motif de mise en demeure par l’ARCOM.
Structure imposée par la DINUM
La DINUM publie un modèle officiel à respecter. Il comporte au minimum :
- L’identité de la collectivité et l’engagement à rendre le site accessible
- L’état de conformité (totale, partielle, non conforme) et le taux mesuré
- Le référentiel utilisé (RGAA 4.1) et la méthodologie d’audit
- La liste des non-conformités connues
- Les dérogations pour charge disproportionnée si applicables
- Le dispositif de contact pour signaler une problématique (formulaire, mail, téléphone)
- Les voies de recours (Défenseur des droits)
- La date de la déclaration et la date du dernier audit
Les 3 niveaux de conformité
- Conformité totale (≥ 100 % des critères) : rare, signale un site audité et corrigé en profondeur.
- Conformité partielle (≥ 50 % des critères) : situation la plus fréquente en pratique. Permet d’afficher honnêtement l’état réel.
- Non conforme (< 50 % des critères) : doit être assorti d’un plan de mise en conformité documenté dans le schéma pluriannuel.
Conseil : ne pas annoncer une conformité totale sans audit externe documenté. L’ARCOM contrôle, et une déclaration optimiste démentie par les faits aggrave la sanction.
Outils et ressources DINUM
Le site officiel accessibilite.numerique.gouv.fr fournit gratuitement : le référentiel RGAA 4.1 complet, le modèle officiel de déclaration d’accessibilité, le modèle de schéma pluriannuel, des fiches pratiques par critère.
Modèle Mairie.app : nous proposons un modèle de déclaration d’accessibilité pré-rempli pour communes (DOCX éditable), au format DINUM, à adapter à votre situation. Demandez-le par le formulaire de contact (gratuit, sans engagement).
Aller plus loin
Cet article couvre la démarche pratique. Pour le cadre légal complet (décret 2019-768, sanctions ARCOM, schéma pluriannuel, plan d’action annuel), consultez notre page pilier RGAA. Pour les autres obligations légales d’un site de mairie, voir les 14 éléments obligatoires.
Et si vous voulez auditer plus largement votre site (pas uniquement l’accessibilité), notre checklist 30 points couvre UX, RGAA, RGPD, performance, SEO local et sécurité.
Sources : accessibilite.numerique.gouv.fr (DINUM — référentiel RGAA 4.1 et modèles officiels), Légifrance — décret n° 2019-768, defenseurdesdroits.fr (voies de recours), service-public.fr — accessibilité numérique.