Modal vs Dialog : quand utiliser chaque composant pour l'accessibilité

Les termes "modal" et "dialog" sont souvent utilisés de manière interchangeable, mais ils désignent des comportements différents avec des implications importantes pour l'accessibilité. Comprendre quand utiliser chaque composant vous aidera à créer des interfaces plus accessibles et plus ergonomiques.

Définitions : modal vs dialogue

Le dialogue (dialog)

Un dialogue est une fenêtre superposée au contenu principal qui requiert l'attention de l'utilisateur. Il peut être :

• Modal : L'utilisateur ne peut pas interagir avec le reste de la page
• Non-modal : L'utilisateur peut continuer à interagir avec la page

La modale

Une modale est un type spécifique de dialogue qui bloque l'interaction avec tout le contenu sous-jacent. Le contenu en arrière-plan est considéré comme "inerte" : les utilisateurs ne peuvent ni cliquer, ni naviguer au clavier, ni interagir d'aucune manière avec les éléments hors de la modale.

[!NOTE] Techniquement, toute modale est un dialogue, mais tous les dialogues ne sont pas des modales. Dans le langage courant, "modale" et "dialogue" sont souvent confondus.

Quand utiliser une modale

Les modales sont appropriées quand :

• Une action urgente est requise : Confirmation de suppression, alerte critique
• Une décision bloque le flux : Accepter les conditions, choisir une option obligatoire
• L'attention complète est nécessaire : Formulaire complexe, processus en plusieurs étapes
• Le contexte doit être préservé : L'utilisateur doit revenir exactement où il était

Exemples légitimes

• Confirmation avant suppression irréversible
• Formulaire d'inscription/connexion
• Visionneuse d'image plein écran
• Panier de validation de commande

À éviter

• Messages d'information simples (utilisez une notification)
• Contenu qu'on peut consulter en parallèle
• Publicités ou promotions intrusives
• Formulaires de newsletter au chargement de page

[!TIP] Avant d'implémenter une modale, posez-vous la question : "Cette information est-elle si importante qu'elle justifie d'interrompre l'utilisateur ?" Si la réponse est non, envisagez une alternative.

Quand utiliser un dialogue non-modal

Les dialogues non-modaux conviennent quand :

• L'utilisateur peut avoir besoin de consulter la page : Aide contextuelle, panneau d'outils
• Le dialogue est un complément : Chat en direct, notes, bookmarks
• L'interaction est optionnelle : Paramètres rapides, filtres

Exemples légitimes

• Panneau de chat/assistance
• Palette d'outils (éditeur graphique)
• Recherche rapide (Cmd+K)
• Notifications interactives

L'élément HTML <dialog> natif

L'élément <dialog> introduit en HTML5 révolutionne l'implémentation des dialogues accessibles.

Syntaxe de base

<dialog id="mon-dialogue">
  <h2>Titre du dialogue</h2>
  <p>Contenu du dialogue.</p>
  <button onclick="this.closest('dialog').close()">Fermer</button>
</dialog>

<button onclick="document.getElementById('mon-dialogue').showModal()">
  Ouvrir en modal
</button>

<button onclick="document.getElementById('mon-dialogue').show()">
  Ouvrir en non-modal
</button>

showModal() vs show()

Avantages du dialog natif

L'élément <dialog> gère automatiquement de nombreux aspects d'accessibilité :

• Piège de focus : Le focus reste dans la modale (avec showModal())
• Fermeture Échap : Fonctionnelle nativement
• Inertie du contenu : L'arrière-plan est rendu inerte
• Sémantique : Les technologies d'assistance reconnaissent le rôle
• Backdrop : Pseudo-élément ::backdrop pour l'overlay

dialog::backdrop {
  background: rgba(0, 0, 0, 0.5);
}

Accessibilité des dialogues : les règles essentielles

1. Gestion du focus à l'ouverture

Quand un dialogue s'ouvre, le focus doit être placé sur un élément à l'intérieur :

const dialog = document.getElementById('mon-dialogue');

dialog.addEventListener('open', () => {
  // Focus sur le premier élément focusable ou le titre
  const premierFocusable = dialog.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  premierFocusable?.focus();
});

Avec <dialog> natif et showModal(), le navigateur gère automatiquement le focus sur le premier élément focusable.

2. Piège de focus pour les modales

Pour une modale, le focus ne doit jamais sortir du dialogue :

function trapFocus(dialog) {
  const focusables = dialog.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const premier = focusables[0];
  const dernier = focusables[focusables.length - 1];

  dialog.addEventListener('keydown', (e) => {
    if (e.key !== 'Tab') return;

    if (e.shiftKey && document.activeElement === premier) {
      e.preventDefault();
      dernier.focus();
    } else if (!e.shiftKey && document.activeElement === dernier) {
      e.preventDefault();
      premier.focus();
    }
  });
}

[!NOTE] L'élément <dialog> avec showModal() gère nativement le piège de focus. Ce code n'est nécessaire que pour les implémentations custom.

3. Fermeture avec Échap

Permettez toujours la fermeture avec la touche Échap :

dialog.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    dialog.close();
  }
});

Le <dialog> natif gère cela automatiquement.

4. Retour du focus à la fermeture

Restaurez le focus sur l'élément déclencheur :

let déclencheur;

function ouvrirModale(button) {
  déclencheur = button;
  dialog.showModal();
}

dialog.addEventListener('close', () => {
  déclencheur?.focus();
});

5. Attributs ARIA nécessaires

Pour les implementations custom (sans <dialog>) :

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="titre-dialogue"
  aria-describedby="description-dialogue"
>
  <h2 id="titre-dialogue">Confirmation</h2>
  <p id="description-dialogue">Voulez-vous vraiment supprimer cet élément ?</p>
  <!-- ... -->
</div>

• role="dialog" : Identifie le composant comme un dialogue
• aria-modal="true" : Indique que c'est une modale (contenu extérieur inerte)
• aria-labelledby : Référence le titre du dialogue
• aria-describedby : Référence la description (optionnel)

Erreurs courantes à éviter

Surutilisation des modales

Les modales interrompent le flux utilisateur. Utilisez-les uniquement quand c'est justifié.

Modales non fermables

Fournissez toujours :

• Un bouton de fermeture visible
• La fermeture via Échap
• Optionnellement, la fermeture en cliquant sur l'overlay

Contenu excessif

Une modale avec trop de contenu nécessite un scroll interne. Envisagez une page dédiée pour les contenus longs.

Focus mal géré

Le focus qui "saute" hors de la modale ou qui ne revient pas au déclencheur désoriente les utilisateurs clavier.

aria-modal sans comportement modal

Si vous utilisez aria-modal="true", le contenu extérieur DOIT être réellement inerte. Sinon, vous créez une confusion pour les technologies d'assistance.

Test d'accessibilité des dialogues

Votre checklist :

1. Focus initial : Le focus se déplace dans le dialogue à l'ouverture ?
2. Piège de focus : Tab reste dans la modale (si modale) ?
3. Fermeture Échap : Le dialogue se ferme avec Échap ?
4. Retour focus : Le focus revient au déclencheur à la fermeture ?
5. Lecteur d'écran : Le dialogue est annoncé correctement ?
6. Clavier complet : Tous les contrôles sont utilisables au clavier ?

Testez l'accessibilité complète de votre site avec notre outil d'audit RGAA.

Conclusion

Le choix entre modal et dialogue non-modal impacte directement l'expérience utilisateur et l'accessibilité. Les modales, de par leur nature intrusive, doivent être réservées aux situations où bloquer l'interaction est vraiment nécessaire.

L'élément HTML <dialog> simplifie grandement l'implémentation accessible en gérant nativement le piège de focus, la fermeture Échap et l'inertie du contenu environnant. Privilégiez cette solution native plutôt que les implémentations JavaScript personnalisées.

Consultez notre guide sur les modales accessibles avec ARIA pour une implémentation technique détaillée.