Fenêtres modales (popins)

Sommaire

Principe

Les popins 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.

Socle HTML


<div tabindex="-1">
  [Contenu de la popin]
</div>

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

tabindex="-1" doit être appliqué sur le conteneur de la popin.

Interactions au clavier

Tab

Lorsque la popin est affichée, déplace successivement le focus clavier vers chacun des éléments interactifs contenus dans la popin. Si le focus clavier est positionné au niveau du dernier élément interactif contenu dans la popin au moment où la touche est pressée, le focus clavier est déplacé au niveau du premier élément interactif contenu dans la popin.

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 popin 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 popin.

Échap

Lorsque la popin est affichée, ferme la popin et déplace le focus clavier sur l’élément interactif qui a déclenché l’ouverture de la popin.

Comportements attendus

Lorsque la popin est affichée à l’écran

Lorsque la popin est fermée

Remarques

Dans la situation où les conteneurs HTML de la popin et celui du reste de la page sont frères dans le code source, c’est-à-dire au même niveau hiérarchique dans l’arbre DOM, appliquer un attribut aria-hidden="true" sur le conteneur du reste de la page lorsque la popin est affichée :


<body>
  <div aria-hidden="true">
    [Contenu du reste de la page]
  </div>
  <div tabindex="-1">
    [Contenu de la popin]
  </div>
</body>

Supprimer ensuite l’attribut aria-hidden="true" appliqué sur le conteneur du reste de la page lorsque la popin est fermée :


<body>
  <div>
    [Contenu du reste de la page]
  </div>
</body>

Composants

Les composants ci-après 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, variables en fonction de la version utilisée.

  1. jQuery simple and accessible modal window, using ARIA.
  2. Lightboxing.

6 commentaires

  • Par Julie, le 8 avril 2016 à 13h00.

    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.

      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.

    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.

      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.

    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.

      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

Ajouter un commentaire

Les champs avec astérisque (*) sont obligatoires.

Haut de page