Auditer et corriger une modale (RGAA & WCAG)

Dans cet article, nous nous adressons aux auditeurs en accessibilité pour aborder les modales, des éléments web omniprésents mais fréquemment sources de barrières d'accessibilité. Alors que les modales servent à diverses fonctions essentielles — de la présentation d'informations à la collecte de consentements — leur mauvaise implémentation peut entraver l'expérience utilisateur, en particulier pour ceux qui dépendent des technologies d'assistance.

À travers des scénarios fictifs illustrant des modales non conformes aux critères d'accessibilité, cet article vise à démontrer comment les auditer efficacement et les transformer en éléments pleinement accessibles. En suivant ces conseils, vous pourrez identifier les erreurs courantes et appliquer des solutions éprouvées pour améliorer l'accessibilité des modales et les rendre conformes aux WCAG et au RGAA.

Élément déclencheur.

Les éléments déclencheurs des modales sont des points de contact importants sur un site. La facilité d'accès à ces éléments est primordiale pour garantir que tous les utilisateurs — qu'ils naviguent par souris, clavier, commande vocale ou autres technologies d'assistance — puissent les utiliser sans obstacle.

Problèmes fréquents

RGAA 7.1 · Majeur — présence d'un rôle inapproprié

Exemples non conformes :

<a href="#" onclick="openModal()">Ouvrir</a>
<div onclick="openModal()">Ouvrir</div>

Il est important pour un utilisateur de technologies d'assistance de connaître le rôle des éléments. C'est un rôle de bouton qui est attendu. Un lien rechargera la page, par exemple.

RGAA 7.3 · Bloquant — ne fonctionne pas au clavier

Exemples non conformes :

<span onclick="openModal()">Ouvrir</span>
<a onclick="openModal()">Ouvrir</a>

Intitulé manquant ou non explicite

RGAA 7.1 · Bloquant — pas d'intitulé (vide, ou image sans alt) :

<div onclick="openModal()"></div>
<div onclick="openModal()"><img src="img/picto.png" alt=""></div>

RGAA 7.1 · Majeur — intitulé non explicite (ex. « + », « ? », icône seule hors contexte).

Solutions

Rôle et clavier

Soit remplacer le lien par un <button type="button">.

Soit attribuer role="button", tabindex="0" et gérer les touches Entrée / Espace en JavaScript.

Intitulé pertinent

Exemples conformes — on peut s'appuyer sur un texte visible, title, ou aria-label :

<button type="button"
        title="Ouvrir les paramètres"
        onclick="openModal()">Ouvrir</button>

<button type="button"
        aria-label="Ouvrir les paramètres"
        onclick="openModal()">
  <svg aria-hidden="true">...</svg>
</button>

Checklist auditeur — Déclencheur

Attribution de rôle — l'élément est-il identifié comme un bouton ?
Accessibilité au clavier — est-il activable avec Entrée et Espace ?
Intitulé — est-il présent, explicite, et compréhensible hors contexte ?

Élément de fermeture.

L'élément de fermeture, souvent marqué d'une icône « × », doit permettre de quitter la modale facilement. Une gestion inadéquate peut piéger les utilisateurs clavier — un cas classique de keyboard trap.

Fig. 02 — Bouton de fermeture : icône × en haut à droite, rôle natif <button>, nom accessible « Fermer la fenêtre ».

Problèmes fréquents

RGAA 7.1 — rôle inapproprié (lien vide, ou <span> cliquable).
RGAA 7.3 — non fonctionnel au clavier.
Intitulé manquant — bouton vide, ou icône seule sans alternative textuelle.

Solutions

Utiliser une balise <button> native.
Ajouter un nom accessible via texte visible, title, aria-label, ou alt sur l'image contenue.

<button type="button"
        aria-label="Fermer la fenêtre"
        onclick="close()">×</button>

Comportement — gestion du focus.

La gestion du focus est critique. Lorsqu'une modale s'ouvre, le focus doit y entrer. Lorsqu'elle est ouverte, il ne doit pas en sortir. À la fermeture, il doit revenir au point de départ — c'est-à-dire sur l'élément déclencheur.

Fig. 03 — Cycle du focus : entrée dans la modale, boucle interne pendant l'ouverture, retour au déclencheur à la fermeture.

Erreurs RGAA 12.8 (majeur)

Le focus reste sur le bouton déclencheur (donc en arrière-plan) à l'ouverture.
Le focus peut sortir de la modale en tabulant — absence de focus trap.
À la fermeture, le focus est perdu et repart au début de la page (body).

Comportement attendu

Ouverture — déplacer le focus en JavaScript sur la modale, ou sur son premier élément interactif.
Navigation — boucler le focus à l'intérieur (intercepter Tab et Shift+Tab).
Fermeture — appeler element.focus() sur le bouton déclencheur pour y revenir.
Touche Échap — Esc doit également fermer la modale.

Structure sémantique.

La structure communique aux lecteurs d'écran qu'il s'agit d'une boîte de dialogue, et non d'un simple contenu inséré dans la page.

Manquements RGAA 7.1

Absence de rôle sémantique (role="dialog").
Absence de nom — le titre de la modale n'est pas relié par aria-labelledby.
Arrière-plan non masqué pour les technologies d'assistance (aria-hidden manquant sur le reste du contenu).

Code type conforme

<div role="dialog"
     aria-modal="true"
     aria-labelledby="modalTitle">
  <div role="document">
    <h1 id="modalTitle">Titre de la modale</h1>
    <!-- contenu -->
    <button>Fermer</button>
  </div>
</div>

Note — l'attribut aria-modal="true" indique aux lecteurs d'écran que le contenu derrière la modale est inerte.

Conclusion.

Cet article sert de ressource pour les auditeurs et les développeurs. En détaillant les erreurs courantes, nous espérons faciliter la prise en compte de ces critères dès la conception — plutôt qu'en audit final.

Pour les auditeurs professionnels cherchant à améliorer la qualité de leurs audits, nous proposons un service de relecture d'audits d'accessibilité.

Un composant à auditer ?

Nous auditons vos patterns complexes — modales, menus, date-pickers, combobox.

Prendre contact →

#modale #focus #aria #dialog #rgaa-7.1 #rgaa-12.8

Auditer et corrigerune modale.