Rendre un site conforme au RGAA (niveau AA)

Ce guide rassemble les gestes concrets pour amener une interface web au niveau de conformité RGAA 4.1 AA (aligné sur WCAG 2.1 AA). Il est orienté tâche : « que faire, dans quel ordre, comment le vérifier ». Il ne traite pas du pourquoi de chaque règle — ce raisonnement vit dans l'explanation dédiée — ni du détail des normes citées.

• Pour comprendre le raisonnement (les quatre principes, ce qui distingue WCAG du RGAA, pourquoi ARIA en dernier recours) : voir l'explanation « L'accessibilité comme discipline ».
• Pour le catalogue exact des normes et leurs références officielles (WCAG 2.1, RGAA 4.1, ARIA 1.2, HTML5) : voir la reference « Catalogue des standards et normes appliqués ».

Prérequis : vous savez déjà écrire du HTML/CSS et intervenir sur les gabarits et les contenus du site. Le guide procède surface par surface ; traitez chaque section comme une passe indépendante, puis lancez la vérification finale.

Avant de commencer : cadrer le périmètre

Fixez trois choses avant toute modification.

1. Le périmètre : listez les types de pages (accueil, listes, formulaires, articles, tunnel, back-office). La conformité se déclare par échantillon représentatif, pas page par page.
2. Le niveau visé : AA. Le niveau A est un socle insuffisant pour une déclaration sérieuse ; AAA n'est pas exigé sur l'ensemble d'un site.
3. La méthode de preuve : le RGAA fournit, pour chaque critère, un test opposable. Prévoyez de conserver la trace de vos vérifications — c'est ce qui transforme une intention en conformité démontrable.

Partie 1 — Interface (structure, navigation, composants)

1.1 Poser la structure sémantique

C'est la fondation : elle se rattrape mal une fois le site construit. Traitez-la en premier.

• Déclarez un seul <h1> par page et une hiérarchie de titres sans saut (h1 → h2 → h3). Les titres décrivent la structure, pas la taille visuelle.
• Utilisez les régions natives : <header>, <nav>, <main>, <aside>, <footer>. Un seul <main> par page.
• Nommez les régions répétées (<nav aria-label="Navigation principale">, <nav aria-label="Fil d'Ariane">) pour les distinguer entre elles.
• Ajoutez un lien d'évitement (skip link) en tout début de page vers le contenu principal :

<a href="#contenu" class="skip-link">Aller au contenu principal</a>
<!-- ... en-tête, navigation ... -->
<main id="contenu" tabindex="-1"><!-- ... --></main>

1.2 Garantir la navigation au clavier

Testez tout le parcours à la souris débranchée, uniquement au clavier.

• Tout élément interactif atteignable à la souris doit l'être au clavier.
• L'ordre de tabulation doit suivre l'ordre logique de lecture.
• Aucun piège clavier : on doit pouvoir entrer et sortir de chaque composant.
• Préférez les éléments natifs (<button>, <a>, <input>) : ils sont focusables et actionnables au clavier gratuitement. Évitez de rendre un <div> cliquable — vous devriez alors recréer à la main le focus, les rôles et les raccourcis.

Conventions clavier attendues :

1.3 Rendre le focus visible

Ne supprimez jamais l'indicateur de focus sans le remplacer. Utilisez :focus-visible pour ne l'afficher qu'à la navigation clavier :

:focus-visible {
  outline: 2px solid; /* couleur à ratio suffisant avec le fond */
  outline-offset: 2px;
}
/* À NE PAS FAIRE : button:focus { outline: none; } sans alternative */

1.4 Assurer les contrastes et ne pas dépendre de la couleur

• Texte normal : ratio ≥ 4,5:1 avec le fond.
• Texte large (≥ 18 px gras, ou ≥ 24 px) : ratio ≥ 3:1.
• Composants et éléments graphiques porteurs de sens : ratio ≥ 3:1.
• Ne transmettez jamais une information par la seule couleur : doublez avec un texte, une icône ou un motif (par exemple un astérisque et une mention « obligatoire », pas seulement un champ coloré en rouge).
• Vérifiez les contrastes dans chaque thème (clair et sombre) et dans tous les états (:hover, :focus, :disabled).

1.5 Dimensionner les cibles et respecter les préférences système

• Zones cliquables/tactiles : ≥ 44 × 44 px, avec un espacement suffisant.
• Respectez prefers-reduced-motion : coupez ou atténuez les animations pour les personnes sensibles au mouvement.

@media (prefers-reduced-motion: reduce) {
  * { animation: none; transition: none; }
}

• Aucun clignotement > 3 fois par seconde (risque de convulsions).
• Le contenu doit rester lisible et complet au zoom texte jusqu'à 200 % : dimensionnez en rem/em, évitez les hauteurs fixes et overflow: hidden qui tronquent.

1.6 Rendre les formulaires accessibles

• Chaque champ a un <label> visible et associé (for ↔ id).
• Signalez les champs obligatoires visuellement et textuellement, pas seulement par une couleur.
• Fournissez les instructions avant le champ (format attendu), reliées par aria-describedby.
• Liez les messages d'erreur au champ concerné et annoncez-les :

<label for="email">Adresse e-mail <span aria-hidden="true">*</span>
  <span class="sr-only">obligatoire</span>
</label>
<input type="email" id="email" name="email"
       aria-describedby="email-aide email-erreur" aria-invalid="false" required>
<small id="email-aide">Nous ne partagerons jamais votre adresse.</small>
<p id="email-erreur" role="alert"><!-- message injecté dynamiquement --></p>

1.7 Traiter les composants riches (ARIA en dernier recours)

Pour tout composant sans équivalent HTML natif (modale, onglets, menu, arborescence), suivez le pattern correspondant de l'ARIA Authoring Practices Guide du W3C plutôt que d'inventer. N'ajoutez de l'ARIA que lorsqu'aucun élément natif ne convient : un ARIA mal posé casse plus qu'il ne répare.

Exemple — une modale conforme suppose au minimum :

• role="dialog" et aria-modal="true" ;
• un titre relié par aria-labelledby ;
• le focus piégé dans la modale tant qu'elle est ouverte ;
• la fermeture par Échap ;
• le retour du focus sur l'élément déclencheur à la fermeture.

Pour les messages dynamiques (succès/erreur hors formulaire), utilisez une région live : role="status" avec aria-live="polite", ou role="alert" (assertif) selon la criticité.

1.8 Neutraliser le décoratif

Masquez aux technologies d'assistance tout ce qui ne porte pas de sens :

• icônes purement décoratives : aria-hidden="true" (et le libellé sur le texte visible ou via aria-label sur le bouton icône seul) ;
• images décoratives : alt="" (attribut présent, valeur vide).

Partie 2 — Contenus éditoriaux

L'interface peut être parfaite : des contenus mal structurés cassent la conformité. Cette passe concerne les rédacteurs autant que les développeurs.

2.1 Structurer le texte

• Réutilisez la hiérarchie de titres (un seul h1, pas de saut de niveau) — les titres servent à naviguer, pas à grossir le texte.
• Employez de vraies listes (<ul>, <ol>) pour les énumérations et les étapes, jamais des tirets manuels dans un paragraphe.
• Gardez des paragraphes courts (une idée principale chacun).
• Utilisez l'emphase sémantique : <strong> pour l'importance, <em> pour l'accentuation — pas du gras purement visuel.

2.2 Écrire des liens explicites

Le texte d'un lien doit être compréhensible hors contexte. Bannissez « cliquez ici », « en savoir plus », « lire la suite » isolés.

• Signalez l'ouverture dans une nouvelle fenêtre dans le texte du lien.
• Pour un lien vers un fichier, indiquez format et poids (ex. « (PDF, 2,5 Mo) »).

2.3 Décrire images et médias

• Image informative : alt décrivant le contenu et la fonction, sans commencer par « Image de… ».
• Image complexe (graphique, schéma) : alt court + description longue adjacente (par ex. via <figure>/<figcaption> reliée par aria-describedby).
• Vidéo : sous-titres synchronisés, transcription textuelle complète, et audiodescription pour l'information visuelle non dite dans la bande son.
• Audio : transcription textuelle complète (avec les changements de locuteur et les sons significatifs).

2.4 Déclarer la langue

• Déclarez la langue principale de la page : <html lang="fr">.
• Marquez les passages dans une autre langue avec l'attribut lang sur l'élément concerné (ex. <span lang="en">…</span>).
• Définissez les acronymes à leur première occurrence (<abbr title="…">).

2.5 Baliser les tableaux de données

• Un <caption> qui décrit le tableau.
• Des en-têtes explicites : <th scope="col"> et/ou <th scope="row">.
• Pour les tableaux complexes (en-têtes sur plusieurs niveaux), reliez cellules et en-têtes via headers/id.
• N'employez jamais de tableau pour la mise en page. Pour des données simples clé/valeur, une liste de définitions (<dl>) est souvent préférable.

Partie 3 — Vérifier la conformité

Aucune de ces trois strates ne suffit seule : combinez-les.

3.1 Passe automatisée (couverture partielle)

Les outils automatiques détectent une part réelle mais limitée des problèmes (contrastes, attributs manquants, structure). Passez sur chaque type de page un outil d'analyse d'accessibilité (extension de navigateur ou audit intégré aux outils de développement). Corrigez, puis relancez.

3.2 Passe manuelle (indispensable)

Ce que l'automatique ne voit pas :

• Navigation au clavier seul sur chaque parcours clé (focus visible, ordre logique, pas de piège, modales fermables à Échap).
• Zoom texte à 200 % : rien n'est tronqué ni superposé.
• Lecteur d'écran : parcourez au moins un parcours critique et vérifiez que titres, libellés, erreurs et régions sont annoncés correctement.
• Sens des libellés : chaque lien/bouton reste compréhensible hors contexte.

3.3 Vérification par les usagers

L'idéal reste le test avec de vraies personnes en situation de handicap, sur leurs propres technologies d'assistance. C'est le seul niveau qui valide le ressenti réel d'usage.

3.4 Consigner la conformité

Conservez la trace des critères vérifiés et de leur méthode de test. Le RGAA prévoit une déclaration d'accessibilité publiant l'état de conformité (total, partiel, non conforme), l'échantillon testé et les non-conformités connues. C'est la sortie attendue d'une démarche RGAA aboutie.

Aide-mémoire (checklist AA)

Interface :

• Un seul <h1>, hiérarchie de titres sans saut
• Régions natives (header/nav/main/footer) + lien d'évitement
• Parcours complet au clavier, ordre logique, aucun piège
• Focus visible partout (jamais outline: none sans alternative)
• Contrastes ≥ 4,5:1 (texte) / 3:1 (texte large, composants), tous thèmes
• Aucune information par la seule couleur
• Cibles ≥ 44 × 44 px ; prefers-reduced-motion respecté ; zoom 200 % OK
• Champs avec label associé, erreurs reliées et annoncées
• Composants riches conformes aux patterns ARIA du W3C (ARIA en dernier recours)
• Décoratif masqué (aria-hidden / alt="")

Contenus :

• Titres, listes et emphase sémantiques
• Liens explicites hors contexte ; format/poids des fichiers indiqués
• alt pertinents ; descriptions longues pour images complexes
• Vidéos sous-titrées + transcription ; audio transcrit
• lang de page et des passages étrangers ; acronymes définis
• Tableaux avec caption et th scope ; pas de tableau de mise en page

Vérification :

• Passe automatisée sur chaque type de page
• Passe manuelle (clavier, zoom, lecteur d'écran)
• Test usagers si possible
• Déclaration d'accessibilité rédigée

Voir aussi

• Explanation — L'accessibilité comme discipline (le pourquoi des quatre principes, WCAG vs RGAA, ARIA en dernier recours).
• Reference — Catalogue des standards et normes appliqués (WCAG 2.1, RGAA 4.1, ARIA 1.2, HTML5, avec les liens officiels).
• ARIA Authoring Practices Guide (W3C) pour les patterns de composants riches.