Boîte de dialogue modale

Une boîte de dialogue modale est une fenêtre superposée qui bloque toute autre interaction dans la page Web sous-jacente, jusqu’à ce que l’internaute ferme cette boîte.

En arrière-plan du dialogue, les contenus avec lesquels on ne peut plus interagir adoptent généralement une apparence visuelle obscurcie. Toutefois, il importe que le comportement modal du dialogue soit aussi transposé avec les outils d’adaptation (lecteurs d’écran, logiciels de commandes vocales, etc.) et avec la navigation au clavier.

Voici les principaux comportements attendus avec les outils d’adaptation (lecteurs d’écran, commandes vocales, etc.) ainsi que la navigation au clavier :

• À l’ouverture de la boîte de dialogue, le focus y est déplacé.
  • Remarque : En général, le focus initial est placé sur le premier élément de contenu du dialogue qui peut recevoir le focus. Cependant, le choix de l’élément le plus approprié pour recevoir le focus dépend de la nature et de la longueur des contenus du dialogue. Pour plus de détails, voir la section Gestion du focus à l’ouverture du dialogue.
• La boîte de dialogue est annoncée comme telle aux outils d’adaptation. Un libellé y est associé, pour en identifier la fonction.
• Le comportement modal du dialogue s’applique pour l’ensemble des utilisateurs. Plus précisément :
  • Tout le contenu de la page en dehors de la boîte de dialogue courante est masqué aux outils d’adaptation;
  • La navigation au clavier est contrainte à l’intérieur du dialogue (ex. : pas possible de naviguer avec Tabulation en dehors du dialogue).
• La boîte de dialogue peut se refermer avec la touche Échap, en plus du bouton prévu à cet effet.
• À la fermeture de la boîte de dialogue, le focus est ramené sur l’élément qui en a déclenché l’ouverture (ex. bouton).
  • Remarque : Si l’élément déclencheur a disparu entretemps, le focus doit être ramené sur un autre élément focusable qui fait sens dans la logique de navigation, idéalement le plus près possible de l’ancien élément déclencheur.
• Lorsque la boîte de dialogue est fermée, celle-ci n’est pas exposée aux outils d’adaptation et ne fait pas partie du parcours de navigation au clavier.

Autres points à surveiller

• Si plusieurs boîtes de dialogue sont imbriquées, l’activation de la touche Échap entraîne une fermeture des dialogues en cascades (une à la fois), en ramenant le focus sur le bouton déclencheur précédent. Il faut éviter de fermer l’ensemble des dialogues d’un seul coup.

Rôles, états et propriétés ARIA

• L’élément qui sert de conteneur de dialogue a un attribut role avec la valeur dialog.
• Tous les éléments requis pour faire fonctionner le dialogue sont les descendants de l’élément à qui on a appliqué role="dialog".
• Ces éléments doivent être eux-mêmes enchâssés dans un conteneur avec role="document". Dans le cas contraire, les contenus du dialogue qui ne reçoivent pas le focus ne seront pas lus par certaines combinaisons d’outils d’adaptation et de navigateurs.
• L’élément de conteneur de dialogue a aria-modal défini sur true.
  (Lire la remarque concernant les approches aria-modal et aria-hidden à la fin de cette section.)
• Le dialogue a un nom accessible défini de l’une ou l’autre des manières suivantes :
  • Si le titre de la boîte de dialogue est visible : l’attribut aria-labelledby est donné au dialogue, avec une valeur correspondant à l’identifiant unique (ID) du titre.
  • S’il n’y a aucun titre ou libellé visible pour la boîte de dialogue : le nom accessible est communiqué par l’attribut aria-label.
• (Optionnel) L’attribut aria-describedby peut être appliqué à l’élément ayant le rôle de dialogue, pour indiquer le ou les éléments de contenus de la boîte de dialogue qui décrivent son objectif principal ou son message. Cela permet aux lecteurs d’écran d’annoncer la description avec le nom accessible de la boîte de dialogue et l’élément qui reçoit le focus initial lorsque le dialogue s’ouvre.
  • Remarque : Le Guide des pratiques de conception ARIA recommande de ne pas utiliser aria-describedby si l’élément qui a le rôle de dialogue comprend des structures sémantiques (listes, tableaux, plusieurs paragraphes) qui seraient difficiles à comprendre en étant annoncés comme une seule chaîne continue.

Autres considérations techniques

• Divers aspects fonctionnels sont gérés par JavaScript, notamment :
  • Le placement du focus en ouverture du dialogue;
  • La fermeture avec la touche Échap et le retour du focus sur l’élément déclencheur;
  • La gestion du cycle de focus avec Tabulation ou Maj+Tabulation, dont l’emploi est contraint à l’intérieur du dialogue;
  • L’ajout d’une contrainte additionnelle empêchant le focus de se déplacer sur des contenus à l’extérieur du dialogue. Cela prévient des mises en focus non désirées survenant par d’autres moyens que la navigation avec Tabulation. Cette contrainte unifiée permet de gérer une variété de scénarios d’interactions hors du dialogue : commandes vocales, déplacements d’un lecteur d’écran par d’autres touches clavier ou par gestuelles tactiles, etc. L’attribut aria-modal (ou aria-hidden), de par sa fonction déclarative, n’est pas toujours suffisant pour assurer une pleine robustesse du comportement modal attendu.
• Lorsque le dialogue est fermé, on peut le masquer aux outils d’adaptation avec la mise en forme CSS display:none, ou en retirant le dialogue du DOM.

Approches aria-modal et aria-hidden

Le comportement modal du dialogue peut être déclaré aux outils d’adaptation avec l’une ou l’autre des techniques suivantes :

1. Assigner aria-modal="true" au conteneur ayant le rôle de dialogue (approche plus récente); ou
2. Utiliser aria-hidden="true" pour masquer aux outils d’adaptation les contenus situés à l’extérieur du dialogue modal, lorsque le dialogue est ouvert (approche rétrocompatible avec des environnements plus anciens). À la fermeture du dialogue, les contenus qui étaient en arrière-plan de celui-ci sont de nouveau exposés aux outils d’adaptation (aria-hidden="false").

Dans son Guide des pratiques de conception ARIA, le W3C fournit quelques précisions sur ces deux approches, tout en reconnaissant leur cohabitation dans un contexte de support évolutif du nouvel attribut aria-modal (traduction libre) :

• La propriété aria-modal a été introduite dans ARIA 1.1. Du fait de sa nouveauté, elle peut être prise en charge de manière variable par les combinaisons de lecteurs d’écran et de navigateurs.
• L’application de aria-modal à l’élément de dialogue remplace la technique d’emploi de aria-hidden sur l’arrière-plan, pour informer les outils d’adaptation que le contenu en dehors d’un dialogue est inerte.
  • Note de la rédaction : Le terme « inerte » signifie que les contenus situés à l’extérieur du dialogue ouvert ne sont pas focusables et que les internautes ne peuvent interagir avec ceux-ci.)
• Dans les anciennes implémentations de dialogue où aria-hidden est utilisé pour rendre le contenu en dehors du dialogue inerte, il est important que :
  • aria-hidden soit défini sur true pour chaque élément contenant une partie de la couche inerte;
  • l’élément de dialogue ne soit pas un descendant d’un élément ayant aria-hidden défini sur true.
  • Note de la rédaction : En d’autres termes, dans ces implémentations, tous les contenus situés en dehors d’un dialogue modal ouvert doivent être masqués avec aria-hidden="true". Cependant, puisque l’application d’aria-hidden="true" à un élément s’applique aussi à tous ses enfants (descendants), il est impératif que le conteneur du dialogue soit placé à l’extérieur du conteneur qui regroupe les contenus masqués en arrière-plan du dialogue.

Pour le moment, les exemples fournis dans cette fiche conservent l’approche plus ancienne (attribut aria-hidden). Cela comporte l’avantage d’être bien reconnu par les lecteurs d’écran et navigateurs plus anciens, tout en fonctionnant dans des environnements récents, dont certains présentent encore un support partiel de l’attribut aria-modal. 

Éventuellement, de plus en plus de personnes qui utilisent des lecteurs d’écran auront accès à un environnement technologique offrant un support adéquat de l’attribut aria-modal. Nous proposerons bientôt un exemple additionnel de boîte de dialogue utilisant cet attribut.

L’élément le plus approprié pour recevoir le focus à l’ouverture dépend de la nature et de la longueur des contenus du dialogue.

Cela dit, le placement du focus illustré dans les exemples demeure adapté à une majorité de situations (en-tête<h1> rendu focusable au moyen de tabindex="-1").

Dans son Guide des pratiques de création ARIA, le W3c résume quelques cas types de gestion du focus à l’ouverture d’une boîte de dialogue modale. En voici une traduction libre :

• Si le contenu de la boîte de dialogue comprend des structures sémantiques (listes, tableaux, plusieurs paragraphes) qui doivent être perçues pour bien comprendre le contenu, c’est-à-dire si le contenu serait difficile à comprendre s’il était annoncé comme une seule chaîne continue, il est conseillé d’ajouter tabindex="-1" à un élément statique au début du contenu et d’y placer le focus initial. Cela permet aux utilisateurs de technologies d’adaptation de mieux lire le contenu, en naviguant à travers les structures sémantiques. Dans ce cas, il est également recommandé de ne pas appliquer aria-describedby au conteneur de la boîte de dialogue.
• Si le contenu est suffisamment volumineux pour que la mise en focus du premier élément interactif puisse faire disparaître le début du contenu hors de la vue, il est conseillé d’ajouter tabindex="-1" à un élément statique en haut de la boîte de dialogue, comme le titre ou le premier paragraphe, et d’y placer le focus initial.
• Si une boîte de dialogue contient l’étape finale d’un processus difficilement réversible, comme la suppression de données ou la finalisation d’une transaction financière, il est préférable de placer le focus sur l’action la moins destructrice, particulièrement si l’annulation de l’action est difficile ou impossible. Le modèle de boîte de dialogue d’alerte est souvent utilisé dans ces situations.
• Si une boîte de dialogue se limite à des interactions qui soit fournissent des informations supplémentaires, soit poursuivent le traitement, il est conseillé de placer le focus sur l’élément qui sera probablement le plus fréquemment utilisé, comme un bouton OK ou Continuer.

Hiérarchie des niveaux de titres (en-têtes)

Lorsqu’une boîte de dialogue modale contient des titres, il est recommandé de commencer par un niveau d’en-tête 1 (<h1>), indépendamment de la structure de la page sous-jacente. En effet, le dialogue crée ici un nouveau contexte d’interaction, distinct des contenus de la page en arrière-plan.

Les exemples de dialogue se basent sur un modèle de boîte modale de Greg Kraus, auquel nous avons apporté quelques changements. L’exemple de dialogue avec formulaire intègre, en plus, le composant de validation de formulaire adapté de la Boîte à outils de l’expérience Web.

Voici les principaux ajustements effectués sur le modèle de Greg Kraus, tenant compte des aspects abordés dans cette fiche :

• Gestion du focus : Au lieu de déplacer le focus sur le bouton de fermeture, nous dirigeons le focus initial sur le titre visible du dialogue, situé au tout début. Ce titre est encadré par une balise d’en-tête <h1>, auquel on a assigné tabindex="-1". Cela le rend focusable par voie de programmation, sans l’inclure dans l’ordre de tabulation.
• Affichage adaptatif : Les styles CSS ont été revus pour autoriser le défilement des contenus de la boîte de dialogue. Cela évite des pertes de contenus ou des chevauchements lors d’un grossissement du texte ou d’un affichage sur appareils mobiles.
• Fermeture du dialogue avec la touche Échap : Ce comportement était prévu dans le script d’origine, mais était rattaché à l’emploi d’une classe CSS particulière pour le bouton de fermeture. Pour plus de flexibilité, indépendamment de la mise en forme, nous avons effectué un ajustement JavaScript.
• Gestion de dialogues multiples : Dans l’exemple de dialogue avec formulaire, des ajouts JavaScript prennent en charge des boîtes de dialogue multiples et la fermeture par incréments de celles-ci.

Approches aria-modal et aria-hidden

Le modèle de Kraus utilise l’approche aria-hidden pour masquer aux outils d’adaptation les contenus en arrière-plan du dialogue modal. Nous avons conservé cette technique plus ancienne dans les exemples de cette fiche, par souci d’offrir une solution robuste et rétrocompatible (voir la section Explications techniques pour plus de détails).

Éventuellement, de plus en plus de personnes qui utilisent des lecteurs d’écran auront accès à un environnement technologique offrant un support adéquat de l’attribut aria-modal. Nous proposerons bientôt un exemple additionnel de boîte de dialogue utilisant cet attribut.