Bonnes pratiques RGAA
106 critères pour faciliter la mise en accessibilité des sites et services numériques.
RGAA au format pdf
Le handicap est défini comme : « toute limitation d’activité ou restriction de participation à la
vie en société subie dans son environnement par une personne en raison d’une altération
substantielle, durable ou définitive d’une ou plusieurs fonctions physiques, sensorielles,
mentales, cognitives ou psychiques, d’un polyhandicap ou d’un trouble de santé invalidant »
(article L. 114 du code de l’action sociale et des familles).
L’accessibilité numérique consiste à rendre les services de communication au public en ligne
accessibles aux personnes handicapées, c’est-à-dire :
• perceptibles : par exemple, faciliter la perception visuelle et auditive du contenu par
l’utilisateur ; proposer des équivalents textuels à tout contenu non textuel ; créer un contenu
qui puisse être présenté de différentes manières sans perte d’information ni de structure (par
exemple avec une mise en page simplifiée) ;
• utilisables : par exemple, fournir à l’utilisateur des éléments d’orientation pour
naviguer, trouver le contenu ; rendre toutes les fonctionnalités accessibles au clavier ; laisser
à l’utilisateur suffisamment de temps pour lire et utiliser le contenu ; ne pas concevoir de
contenu susceptible de provoquer des crises d’épilepsie ;
• compréhensibles : par exemple, faire en sorte que les pages fonctionnent de
manière prévisible ; aider l’utilisateur à corriger les erreurs de saisie.
• et robustes : par exemple, optimiser la compatibilité avec les utilisations actuelles et
futures, y compris avec les technologies d’assistance.
Sont concernés les sites internet, intranet, extranet ; les progiciels, dès lors qu’ils
constituent des applications utilisées au travers d’un navigateur web ou d’une
application mobile
Structurer correctement le code HTML
✔ Utiliser les bonnes balises HTML pour structurer le contenu :
● <header> pour l’en-tête de la page.
● <nav> pour les menus de navigation.
● <main> pour le contenu principal.
● <section> pour regrouper des parties du contenu.
● <article> pour des contenus indépendants.
● <aside> pour les contenus complémentaires.
● <footer> pour le pied de page.
✔ Respecter la hiérarchie des titres (<h1> à <h6>) :
● Un seul <h1> par page (titre principal).
● Ne pas sauter de niveau (<h2> suivi directement d’un <h4> est à éviter).
✔ Chaque page doit avoir un titre clair et pertinent (<title> dans <head>).
Faciliter la navigation et l’interaction
✔ Rendre tous les éléments interactifs accessibles au clavier :
● Les liens et boutons doivent être atteignables avec la touche Tab.
● Éviter les <div> et <span> cliquables sans role="button" ou role="link".
● Utiliser tabindex="0" pour rendre un élément focusable si nécessaire.
✔ Ajouter des liens d’évitement en haut de la page :
<a href="#main-content" class="skip-link">Aller au contenu
principal</a>
● Cela permet aux utilisateurs de sauter directement au contenu sans devoir tabuler à
travers tout le menu.
✔ Assurer un focus visible sur les éléments interactifs :
● Ne jamais désactiver l’effet de focus (outline: none est à proscrire).
● Ajouter un style personnalisé si nécessaire :
button:focus, a:focus {
outline: 2px solid #005fcc; /* Ajout d’un contour visible */
}
✔ Gérer les menus et les popups avec ARIA :
● Ajouter aria-expanded="true|false" pour indiquer si un menu est ouvert ou
fermé.
● Associer les menus déroulants avec aria-controls.
Assurer un bon contraste et une bonne lisibilité
Un mauvais contraste rend la lecture difficile pour les malvoyants et les daltoniens.
✔ Respecter un ratio de contraste suffisant :
● 4.5:1 pour le texte normal.
● 3:1 pour les textes de plus de 24px ou en gras à partir de 18px.
✔ Vérifier les contrastes avec des outils :
● WebAIM Contrast Checker.
● Color Contrast Analyzer.
✔ Ne pas utiliser uniquement la couleur pour transmettre une information :
● Ex : Ne pas dire "Les champs en rouge sont obligatoires".
● Ajouter un texte explicatif et/ou une icône.
✔ Permettre un zoom jusqu’à 200 % sans casser la mise en page, avoir des pertes
d’informations ou de fonctionnalités.
Gérer les alternatives textuelles et les médias
✔ Ajouter un attribut alt pertinent aux images :
● ✅ <img src="[Link]" alt="Un chien noir jouant dans un
parc">
● ❌ <img src="[Link]" alt=""> (uniquement si l’image est décorative).
✔ Utiliser les balises <figure> et <figcaption> pour des légendes d’image.
✔ Sous-titrer les vidéos et proposer une transcription textuelle.
✔ Éviter les GIFs ou les animations qui clignotent trop vite (risque d’épilepsie).
✔ Assurer que les lecteurs d'écran puissent accéder aux éléments multimédias (via
aria-label, aria-labelledby, etc.).
Améliorer la compréhension des contenus
Les personnes ayant des troubles cognitifs ou des difficultés de lecture doivent pouvoir
comprendre facilement le contenu.
✔ Utiliser un langage clair et simple avec une syntaxe compréhensible.
✔ Éviter le jargon technique et expliquer les acronymes.
✔ Rédiger des libellés explicites pour les boutons et liens :
✅ "Télécharger le rapport en PDF"
❌ "Cliquez ici"
●
●
✔ Ajouter des instructions et des messages d’erreur explicites pour les formulaires.
✔ Proposer une version facile à lire et à comprendre (FALC) si possible.
Assurer l’accessibilité des formulaires
✔ Associer chaque champ à un <label> clair et descriptif :
<label for="email">Adresse e-mail :</label>
<input type="email" id="email" name="email">
✔ Indiquer les champs obligatoires textuellement (éviter seulement l’astérisque).
✔ Fournir des messages d’erreur clairs, précis et visibles.
Détection et gestion des erreurs dans les
formulaires
Les erreurs de saisie dans les formulaires doivent être détectées et signalées de manière
claire et accessible.
✔ Mettre en évidence les erreurs de manière claire (visuellement et via ARIA).
✔ Utiliser aria-invalid="true" et aria-describedby pour lier l’erreur au champ de
saisie.
✔ Ajouter un message d’erreur spécifique pour chaque champ en cas de problème (pas
juste "Erreur", mais des détails comme "Le format de l’email est incorrect").
✔ Afficher les erreurs avant l’envoi du formulaire pour permettre à l'utilisateur de les
corriger.
✔ Associer les erreurs aux champs concernés avec aria-describedby :
<label for="email">Email :</label>
<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Veuillez entrer un email
valide.</span>
✔ Utiliser des couleurs ET du texte (éviter le simple texte en rouge).
✔ Éviter de supprimer immédiatement un champ incorrect, cela perturbe la navigation.
✔ Si un champ est requis, l'indiquer clairement avec un texte (au-delà de l’astérisque).
Accessibilité des formulaires de recherche
Les barres de recherche doivent être facilement utilisables pour tout le monde, y compris
ceux qui ne peuvent pas utiliser la souris.
✔ Ajouter un label explicite à la barre de recherche.
✔ Utiliser aria-label pour décrire précisément la fonction du champ de recherche.
✔ Ajouter un placeholder clair indiquant le type de recherche (par exemple "Recherche par
mot-clé").
✔ Assurer que le champ de recherche fonctionne correctement à l’aide du clavier.
✔ S’assurer que les résultats de recherche soient bien présentés et accessibles (les
résultats doivent être lisibles et compréhensibles).
Accessibilité des outils de recherche
✔ Fournir un label explicite au champ de recherche.
✔ Ajouter aria-label="Rechercher sur le site" si nécessaire.
✔ Permettre l’utilisation du clavier (Enter pour valider la recherche).
Exemple :
<form role="search">
<label for="search">Rechercher :</label>
<input type="text" id="search" name="q">
<button type="submit">OK</button>
</form>
Gestion de l'auto-complétion et des suggestions
Les fonctionnalités d’auto-complétion et de suggestion doivent être accessibles et
permettre à l’utilisateur de naviguer facilement entre les suggestions.
✔ Utiliser des attributs ARIA appropriés pour les suggestions automatiques, par exemple
aria-autocomplete="list" pour les champs de recherche.
✔ Assurer que l’utilisateur peut naviguer au clavier entre les suggestions.
✔ Fournir une confirmation claire que les suggestions sont des résultats d’une recherche
ou d'une auto-complétion.
Utiliser les attributs ARIA avec précaution
✔ Ne pas utiliser ARIA (Accessible Rich Internet Applications) si le HTML natif suffit
(ex. : un <button> est mieux qu’un <div role="button">).
✔ Utiliser aria-live="polite|assertive" pour les messages dynamiques.
✔ Ne pas ajouter d’attributs ARIA inutiles, car cela peut perturber les lecteurs d’écran.
Gestion des tableaux de données
✔ Utiliser <th> pour les en-têtes de colonnes ou de lignes.
✔ Associer les en-têtes aux cellules avec scope="col" ou scope="row".
✔ Pour les tableaux complexes, utiliser headers et id pour lier les cellules aux en-têtes
correspondants.
Exemple :
<table>
<caption>Liste des étudiants et de leurs notes</caption>
<thead>
<tr>
<th scope="col">Nom</th>
<th scope="col">Matière</th>
<th scope="col">Note</th>
</tr>
</thead>
<tbody>
<tr>
<td>Marie Dupont</td>
<td>Mathématiques</td>
<td>18</td>
</tr>
</tbody>
</table>
Accessibilité des documents téléchargeables
Si le site propose des fichiers PDF, Word, Excel, etc., ils doivent aussi être accessibles.
✔ Proposer une alternative HTML au fichier si possible.
✔ Structurer correctement les documents avec des titres et une table des matières.
✔ Ajouter du texte alternatif aux images des documents.
✔ Vérifier que le texte est sélectionnable (éviter les scans d’images).
✔ Utiliser des métadonnées pour décrire le document.
Accessibilité des documents PDF
Les documents PDF peuvent être difficiles à lire pour certaines personnes, il est donc
essentiel de les rendre accessibles.
✔ Si possible, fournir une version HTML du document en complément.
✔ Utiliser des outils d’accessibilité PDF (comme Adobe Acrobat ou PDF/UA) pour
vérifier la structure, le balisage et l’accessibilité du fichier.
✔ Si le PDF contient des images ou graphiques, ajouter du texte alternatif pour chaque
élément important.
✔ Organiser le PDF avec des titres hiérarchiques, des table des matières et des
légendes d'images.
✔ S’assurer que les documents sont lisibles avec un lecteur d'écran.
Accessibilité des cadres et contenus intégrés
(iframe, vidéos, cartes, etc.)
✔ Ajouter un titre clair à chaque <iframe> pour indiquer son contenu.
✔ Proposer une alternative textuelle si le contenu de l’iframe est indispensable.
✔ Assurer que les contenus intégrés (YouTube, Google Maps, etc.) soient navigables au
clavier.
Exemple :
<iframe src="[Link] title="Carte interactive de
nos bureaux"></iframe>
Accessibilité des animations et contenus
dynamiques
Les contenus en mouvement peuvent poser problème aux personnes atteintes de troubles
cognitifs, de déficiences visuelles ou d’épilepsie.
✔ Limiter les animations (éviter les clignotements trop rapides).
✔ Ajouter la possibilité de mettre en pause ou arrêter les animations.
✔ Ne pas afficher de contenu en mouvement pendant plus de 5 secondes sans contrôle
utilisateur.
✔ Respecter les préférences de l’utilisateur (prefers-reduced-motion en CSS).
Exemple CSS pour réduire les animations si demandé :
@media (prefers-reduced-motion: reduce) {
* {
animation: none !important;
transition: none !important;
}
}
Respect des préférences utilisateur
Les utilisateurs peuvent avoir des réglages spécifiques (police, zoom, contrastes,
animations désactivées, etc.).
✔ Prendre en compte prefers-reduced-motion pour désactiver les animations si
demandé.
✔ Laisser l’utilisateur personnaliser l’interface (taille du texte, contraste).
✔ Éviter les textes sous forme d’images (préférer du texte HTML + CSS).
Accessibilité des captchas
Les captchas peuvent être une barrière pour les personnes ayant une déficience visuelle ou
cognitive.
✔ Éviter les captchas visuels uniquement (préférer des alternatives textuelles ou audio).
✔ Proposer une alternative accessible, comme un test basé sur une question simple.
✔ Ne pas bloquer les utilisateurs si le captcha échoue plusieurs fois.
Exemple :
✅ "Quelle est la somme de 2 + 3 ?" au lieu d’un texte illisible à recopier.
✅ Utiliser reCAPTCHA v3 qui fonctionne sans interaction utilisateur.
●
●
Accessibilité des notifications et messages
dynamiques
Les notifications (erreurs, succès, alertes) doivent être perçues par tous les utilisateurs, y
compris ceux utilisant un lecteur d’écran.
✔ Utiliser aria-live pour les messages dynamiques afin qu’ils soient annoncés
automatiquement.
✔ Ajouter un message texte visible en complément des alertes sonores ou visuelles.
✔ Éviter les pop-ups bloquants difficiles à fermer.
Exemple :
<div role="alert" aria-live="assertive">
Erreur : Votre mot de passe est incorrect.
</div>
Accessibilité des menus et barres de navigation
✔ Utiliser <nav> pour définir la zone de navigation.
✔ Ajouter un titre explicite au menu (aria-label="Menu principal").
✔ Assurer que les sous-menus s’ouvrent et se ferment avec le clavier (touche Tab et
Enter).
Exemple de menu accessible :
<nav aria-label="Menu principal">
<ul>
<li><a href="#">Accueil</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Contact</a></li>
</ul>
</nav>
Accessibilité des graphiques et infographies
Les graphiques et infographies doivent être compréhensibles pour les personnes
aveugles ou malvoyantes.
✔ Ajouter un résumé textuel expliquant le graphique.
✔ Utiliser SVG accessibles avec des descriptions (title, desc).
✔ Assurer une bonne lisibilité des couleurs et motifs pour les daltoniens.
Exemple :
<svg width="100" height="100" role="img"
aria-labelledby="chart-title chart-desc">
<title id="chart-title">Répartition des ventes</title>
<desc id="chart-desc">Le graphique montre 50% de ventes en ligne
et 50% en magasin.</desc>
</svg>
Accessibilité et temps limite
Si une action a un temps limité (ex : expiration d’une session), l’utilisateur doit être averti et
avoir la possibilité de prolonger son temps.
✔ Informer l’utilisateur avant l’expiration d’une session.
✔ Lui permettre de prolonger le temps disponible.
✔ Ne pas forcer une déconnexion soudaine sans avertissement.
Gestion des contenus en plusieurs langues
Si une page contient du texte en plusieurs langues, il faut l’indiquer pour que les lecteurs
d’écran adaptent la prononciation.
✔ Définir la langue principale du document dans la balise <html> :
<html lang="fr">
✔ Indiquer les changements de langue dans le contenu avec lang (y compris les textes
traduits) :
<p>Ce site est un exemple. <span lang="en">This is an
example.</span></p>
Sans cet attribut, un lecteur d’écran pourrait lire l’anglais avec une voix française, rendant le
texte incompréhensible.
✔ Assurer que les utilisateurs savent comment changer de langue sur le site et que cela ne
perturbe pas l’accessibilité.
Accessibilité des éléments en JavaScript
Les contenus générés dynamiquement par JavaScript doivent être accessibles.
✔ S’assurer que tous les éléments interactifs soient focusables (tabindex=0 si
nécessaire).
✔ Éviter de modifier le DOM sans informer les lecteurs d’écran (ajouter
aria-live="polite" pour les mises à jour de contenu).
✔ Tester les événements keydown en plus de click pour permettre une interaction
clavier :
[Link]('keydown', (event) => {
if ([Link] === 'Enter' || [Link] === ' ') {
[Link]();
[Link]();
}
});
Accessibilité des applications mobiles
Les applications mobiles doivent aussi respecter des critères d’accessibilité.
✔ Utiliser les bonnes balises ARIA et les composants natifs accessibles.
✔ Tester l’application avec VoiceOver (iOS) et TalkBack (Android).
✔ Ajouter des labels accessibles (contentDescription sur Android,
accessibilityLabel sur iOS).
Accessibilité des liens
Les liens sont essentiels pour la navigation sur le web, mais ils doivent être clairement
identifiables et fonctionnels pour tous les utilisateurs sans perturber la navigation.
✔ Utiliser des liens explicites (pas seulement "Cliquez ici", "En savoir plus", etc.).
✔ Donner aux utilisateurs une idée claire de ce qu'ils vont trouver en cliquant sur un lien.
✔ Utiliser les attributs title de manière appropriée (s'ils sont nécessaires) :
<a href="[Link]" title="Contactez-nous pour toute
question">Nous contacter</a>
✔ Ne jamais utiliser des liens uniquement pour des actions (ex : <a> qui ne mène nulle part
sans href). Utiliser des boutons pour des actions (<button>).
✔ Vérifier que les liens sont distincts du texte ordinaire (par exemple, en les soulignant ou
en utilisant une couleur différente).
✔ Ne jamais avoir des liens qui changent de rôle (un lien qui devient un bouton une fois
cliqué, par exemple).
✔ Indiquer que le lien est externe afin que les utilisateurs puissent s’y préparer. Par
exemple, en ajoutant un texte explicite à côté du lien comme "Ouvrir dans un nouvel onglet"
ou en utilisant l’attribut rel="noopener noreferrer" pour des raisons de sécurité.
✔ Utiliser aria-label ou title pour décrire plus clairement ce qui se passera après
avoir cliqué sur le lien.
✔ Si un lien ouvre une nouvelle fenêtre ou un nouvel onglet, le signaler clairement à
l’utilisateur.
Accessibilité des widgets interactifs
Les widgets interactifs comme les carrousels, les sélecteurs de date ou les filtres doivent
être accessibles.
✔ Rendre les widgets accessibles au clavier :
● Les utilisateurs doivent pouvoir naviguer entre les éléments et interagir avec eux
uniquement via le clavier.
● Par exemple, un carrousel doit permettre de passer d’une diapositive à l’autre avec
Tab, Shift+Tab, Flèches, etc.
✔ Utiliser les attributs ARIA pour améliorer l’accessibilité des composants
dynamiques.
● Exemple pour un carrousel :
<div role="region" aria-live="polite">
<button role="button" aria-label="Slide
précédent">Précédent</button>
<div role="group" aria-roledescription="carrousel"
aria-label="Slides">[contenu du carrousel]</div>
<button role="button" aria-label="Slide suivant">Suivant</button>
</div>
Prise en charge des erreurs côté serveur
Les erreurs côté serveur, comme une connexion réseau perdue ou une réponse
incorrecte, doivent être gérées de manière accessible.
✔ Fournir un message d'erreur clair et compréhensible lorsque quelque chose ne
fonctionne pas (ex : "Erreur 404 : Page introuvable").
✔ Fournir des suggestions sur la manière de résoudre l'erreur ou revenir à l'écran
précédent.
✔ Assurer que les erreurs sont annoncées aux utilisateurs de manière audible (avec un
lecteur d’écran, par exemple).
Compatibilité avec les lecteurs d’écran et
navigateurs
✔ Tester avec plusieurs lecteurs d’écran :
🖥 NVDA (Windows, gratuit)
🍏 VoiceOver (Mac/iPhone, intégré)
●
💰 JAWS (Windows, payant)
●
●
✔ Tester sans souris (navigation au clavier).
✔ Tester avec plusieurs navigateurs (Chrome, Firefox, Edge, Safari).
✔ Vérifier les contrastes et couleurs sur différents écrans.
Suivi et mise en conformité RGAA
Un site accessible évolue constamment et doit être mis à jour régulièrement.
✔ Effectuer un audit régulier avec un outil comme WAVE ou axe DevTools.
✔ Vérifier les nouvelles exigences RGAA et adapter le site en conséquence.
✔ Former les équipes au design inclusif et aux standards d’accessibilité.
Tester l’accessibilité régulièrement
✔ Tester avec des outils automatiques :
● WAVE.
● axe DevTools.
● Le validateur RGAA officiel.
✔ Tester avec un lecteur d’écran :
● NVDA (Windows).
● VoiceOver (Mac/iOS).
● JAWS (payant).
✔ Tester uniquement au clavier (désactiver la souris temporairement).
