Fenêtres modales

Sommaire

Principe.
Socle HTML.
Rôles, états et propriétés ARIA.
Interactions au clavier.
Comportements attendus.
Composants.

Principe

Les fenêtres modales sont des fenêtres qui apparaissent directement à l’intérieur de la fenêtre courante du navigateur, au-dessus de la page web qui les appelle.

Il s’agit de fenêtres modales, c’est-à-dire de fenêtres qui prennent le contrôle de la page courante tant qu’elles sont affichées à l’écran.

Cette fiche s’appuie sur le motif de conception « Dialog (modal) » détaillé dans les ARIA Authoring Practices Guide (APG) du W3C.

Socle HTML

Le socle HTML d’une fenêtre modale est différent selon que cette dernière possède un titre affiché à l’écran ou non.

Fenêtre modale avec un titre affiché à l’écran

<div role="dialog" aria-modal="true" aria-labelledby="modal-heading">
  <button>Fermer</button>
  <h1 id="modal-heading">[Titre de la modale]</h1>
  [Contenu de la modale]
</div>

Fenêtre modale sans titre affiché à l’écran

<div role="dialog" aria-modal="true" aria-label="[Titre de la modale]">
   <button>Fermer</button>
   [Contenu de la modale]
 </div>

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

role="dialog" doit être appliqué sur le conteneur de la fenêtre modale.
aria-modal="true" doit être appliqué sur le conteneur de la fenêtre modale.
Si le titre de la fenêtre modale est affiché à l’écran, il doit être rattaché à la fenêtre modale via l’attribut aria-labelledby :
- Le titre de la fenêtre modale doit posséder un attribut id renseigné avec une valeur unique.
- Le conteneur de la fenêtre modale doit posséder un attribut aria-labelledby renseigné avec la valeur de l’attribut id du titre de la fenêtre modale.
Si le titre de la fenêtre modale n’est pas affiché à l’écran, aria-label doit être appliqué et renseigné sur le conteneur de la fenêtre modale.

Interactions au clavier

`Tab`

Lorsque la fenêtre modale est affichée, déplace successivement le focus clavier vers chacun des éléments interactifs contenus dans la fenêtre modale. Si le focus clavier est positionné au niveau du dernier élément interactif contenu dans la boîte de dialogue modale au moment où la touche est pressée, le focus clavier est déplacé au niveau du premier élément interactif contenu dans la fenêtre modale.

`Maj` + `Tab`

Même comportement qu’avec la touche Tab, mais cette fois dans l’ordre inverse de lecture. Si le focus clavier est positionné au niveau du premier élément interactif contenu dans la fenêtre modale au moment où la combinaison de touches est pressée, le focus clavier est déplacé au niveau du dernier élément interactif contenu dans la fenêtre modale.

`Échap`

Lorsque la boîte de dialogue modale est affichée, ferme la fenêtre modale, et déplace le focus clavier sur l’élément interactif qui a déclenché l’ouverture de la fenêtre modale.

Comportements attendus

Lorsque la fenêtre modale est affichée à l’écran

Le focus clavier est positionné dynamiquement sur le premier élément interactif contenu dans la fenêtre modale.
Le focus clavier doit être bloqué à l’intérieur de la fenêtre modale et il ne doit pas être possible de tabuler sur le reste de la page, en-dessous de la fenêtre modale.
Il est possible de fermer la fenêtre modale avec la touche Échap.

Lorsque la fenêtre modale est fermée

Le focus clavier doit être replacé au niveau de l’élément qui a déclenché l’ouverture de la fenêtre modale.
Dans l’idéal, la fenêtre modale est supprimée du DOM. Toutefois, si la fenêtre modale reste présente dans le code source, display: none ou visibility: hidden doivent être appliqués sur son conteneur.

Composants

Ces composants « Fenêtres modales » sont proposés ici car leur niveau d’accessibilité est jugé bon ou très bon.

Toutefois, avant de les utiliser dans votre projet, il est important de vérifier le respect des spécifications présentées ci-avant. Certains pouvant nécessiter quelques ajustements.

6 commentaires

Par Julie, le 8 avril 2016 à 13h00.

Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

Bonjour,

Ne faut-il pas ajouter le role="dialog" également pour ces popins même si elles ne constituent pas un dialogue en tant que tel ?
Cela permettrait d’entrer dans le mode « application » pour le lecteur d’écran et donc de faciliter la navigation.

De plus, les exemples de composants proposés ajoutent bien ce rôle.

Répondre
- Par Sébastien Delorme, le 18 avril 2016 à 14h19.
  
  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
  
  Bonjour Julie,
  
  En fait, la réponse est dans la question ;).
  
  Ces popins ne constituent pas un fenêtre de dialogue en tant que telles.
  
  En ajoutant role="dialog" on permet au lecteur d’écran de passer en mode application. Sur des boîtes de dialogue modales comme sur des boîtes d’alerte modales cela sera demandé. Le lecteur d’écran va agir comme dans une application à l’ouverture de la modale :
  - Annoncer l’ouverture de la modale,
  - Lire automatiquement son titre (grâce à aria-labelledby ou aria-label),
  - Lire automatiquement son contenu (grâce à aria-describedby),
  - Permettre l’utilisation des boutons de validation et/ou d’annulation.
  Ni plus, ni moins.
  Le comportement n’est plus celui d’une page web, mais celui d’une fenêtre modale système.
  
  Toutefois, dans une popin comme décrite sur cette page, nous pouvons potentiellement afficher plusieurs éléments de natures différentes :
  - Des champs de formulaire,
  - Des vidéos,
  - Des liens,
  - Des contenus avec des images, des titres, du texte,
  - Etc.
  Ainsi, l’utilisateur pourra/devra lister des titres, naviguer de lien en lien, naviguer de bouton en bouton, lire du texte, en sélectionner, etc.
  S’il est en mode application, il n’aura plus du tout ces possibilités, c’est pour cette raison que nous n’utiliserons pas dans ce cas role="dialog", pour permettre de conserver les options de navigation habituelles à une page web.
  
  Je pense qu’il peut être intéressant que nous ajoutions une petite capture d’écran en introduction de chaque composant pour bien percevoir les différences. Nous le ferons prochainement.
  
  Encore merci pour tes commentaires constructifs.
  
  Bien à toi,
  Sébastien.
  
  Répondre
Par Julie, le 18 avril 2016 à 15h01.

Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

Bonjour Sébastien,

Merci pour ta réponse. On en apprend tous les jours.

Je viens de tester la modale de Bootstrap car il utilise un role="dialog" pour le conteneur de la popin mais la div du niveau d’en dessous a ensuite un role="document" pour permettre la navigation classique entre les éléments.
C’est ce que fait aussi Nicolas Hoffmann dans le script partagé dans la rubrique « Composants ».

Que penses-tu de cette technique ?

Répondre
- Par Sébastien Delorme, le 21 avril 2016 à 11h29.
  
  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
  
  Bonjour Julie,
  
  Effectivement cette technique permet de résoudre le problème que j’ai identifié plus haut.
  
  Elle a un inconvénient : celui de ne pas être tout à fait conforme à l’objectif initial.
  En effet, une fenêtre de dialogue modale telle que définie par role="dialog" correspond à A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. C’est donc un détournement, car une popin avec une vidéo, un formulaire ou un autre contenu divers ne correspond pas vraiment à ça.
  
  Toutefois, cet inconvénient est également un avantage. Puisqu’il n’existe pas vraiment de rôle pour les modales génériques, l’utilisation de role="dialog" permet d’annoncer à l’utilisateur qu’une fenêtre s’est ouverte. Il sait donc qu’il est toujours sur la même page, qu’il n’a pas changé, mais qu’il est désormais sur une fenêtre par-dessus.
  
  C’est donc un détournement intéressant.
  Je vois généralement deux possibilités d’intégration pour les popins :
  - 1. Détourner un modèle de conception clairement défini et proche, comme par exemple celui des boîtes de dialogue modales (popins de dialogue) et s’assurer qu’il reste pertinent et fonctionnel dans ce contexte (en ajoutant par exemple role="document" sur la zone de contenu).
  - 2. Imaginer un autre modèle pertinent pour l’utilisateur et compatible avec les aides techniques, comme c’est le cas de cette fiche (car il n’existe aucun modèle de conception ARIA pour les popins).
  Bien à toi,
  Sébastien.
  
  Répondre
Par Nico, le 21 avril 2017 à 8h34.

Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

Hello,

oseré-je suggérer le dernier composant accessible estampillé Van11y => https://van11y.net/fr/modale-accessible/ ;) (IE9+ et sans jQuery)

Au plaisir,
Nico

Répondre
- Par Johan Ramon, le 24 avril 2017 à 13h46.
  
  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
  
  Salut Nico,
  
  Merci beaucoup pour ton script et ta proposition !
  
  Nous allons prochainement remettre à plat les trois fiches « Fenêtres modales », « Boîtes de dialogue modales » et « Boîtes d’alerte modales » de cette notice pour qu’elles collent aux nouveaux Design Patterns ARIA correspondant (et aussi pour qu’elles soient compatibles avec le lecteur d’écran VoiceOver).
  
  Du coup, nous étudierons l’ajout de ton script dans la fiche qui va bien à ce moment là. ;)
  
  Johan
  
  Répondre