Modales

Une fenêtre modale est une fenêtre qui s'affiche au premier plan suite à un événement et qui requiert une action de la part de l'utilisateur. La fenêtre est affichée au premier plan et tant qu'elle reste ouverte, la page parent est "gelée".

Une modale peut avoir diverses fonctions. Elle peut proposer à l'utilisateur de sélectionner une option, de confirmer une action, de modifier des paramètres ou des données ou de rédiger un commentaire ou un message.

A quoi ressemble une fenêtre modale ?

Cette vidéo présente une fenêtre modale classique.

Description vidéo

Sur la page twitter.com (après connexion), le fait de cliquer sur le bouton "Tweet" ouvre une fenêtre modale où l'on tape son tweet.

  • L'utilisateur tabule jusqu'au bouton "Tweet" en haut de l'écran à droite et appuie sur la touche ENTER.
  • Une modale s'ouvre et le champ texte reçoit le focus.
  • L'utilisateur tape "Hallo!" dans le champ texte.
  • Il parcourt plusieurs contrôles en tabulant avant d'arriver sur le bouton "Tweet".
  • Il active le bouton "Tweet" en appuyant sur ENTER.
  • Le tweet "Hallo!" est publié et la modale se ferme.

Quels sont les différents modèles de fenêtres modales ?

Une fenêtre modale est un composant fréquemment trouvé dans les logiciels. Les premières modales à paraître dans un environnement Web ressemblaient à des avertissements système générés par le navigateur, que l'auteur créait en JavaScript avec "alert" ou "confirm".

Ces messages ne pouvaient pas être stylés et étaient très limités en termes de contenus. En conséquence, les auteurs de site ont commencé à créer des modales personnalisables à partir de divs.

Si l'on considère qu'une modale est une fenêtre de premier plan qui masque la page active, on constate que ces configurations sont de moins en moins fréquentes car les sites sont de plus en plus optimisés pour mobile. Ce qui apparaît comme une modale sur mobile est en réalité un écran intermédiaire.

Il y a également la possibilité de créer une modale native en HTML5 ce qui devrait simplifier leur implémentation et leur restitution. Cependant, à ce jour les navigateurs supportent mal ces éléments natifs ce qui rend leur implémentation risquée (voir un article sur sa prise en compte aujourd'hui (en anglais)). Internet Explorer et Edge de Microsoft et Safari d'Apple ne le supportent pas, et à ce jour Firefox ne supporte cette implémentation que si elle est activée manuellement (une possibilité ignorée par le plupart des utilisateurs). Un dialog polyfill existe qui permet de générer des fenêtres modales personnalisées dans des navigateurs qui ne les supportent pas encore (à noter : nous n'avons pas encore testé cette solution).

Quelles sont les difficultés rencontrées par les utilisateurs face aux fenêtres modales ?

Pour les utilisateurs naviguant au clavier - l'impossibilité d'ouvrir la modale

Un problème majeur pour les utilisateurs naviguant au clavier, et en particulier avec un lecteur d'écran, est l'impossibilité d'accéder aux modales. Quand une fenêtre modale s'affiche, elle se trouve souvent en bas du code source de la page. Cela signifie qu'elle est très éloignée de l'élément qui l'a déclenché. Lorsque l'utilisateur actionne un bouton qui ouvre une modale, le focus est rarement pris dans la fenêtre. Interagir avec le contenu de la modale avec le clavier semble impossible, ou nécessite de parcourir l'ensemble du contenu de la page.

Pour les utilisateurs naviguant au lecteur d'écran - l'impossibilité de détecter la fenêtre modale

Alors que les utilisateurs voyants perçoivent au moins l'ouverture de la fenêtre modale et s'attentent à une interaction, les utilisateurs non-voyants ne sont souvent pas en mesure de détecter sa présence. Le focus continue à parcourir le contenu en arrière plan alors que l'application est figée car elle nécessite une action de la part de l'utilisateur.

Pour les utilisateurs naviguant au lecteur d'écran - des contrôles non identifiés ou inaccessibles au clavier

De nombreux utilisateurs rencontrent des problèmes provoqués par le fait que les principaux contrôles, comme le bouton de fermeture, ne sont pas accessibles au clavier, n'ont pas d'étiquette ou ont une étiquette dans une autre langue.

Des composants provenant de bibliothèques JavaScript inaccessibles

Un certain nombre de problèmes rencontrés par les utilisateurs proviennent du fait que les intégrateurs prennent souvent leurs composants dans des bibliothèques ou frameworks JavaScript. Ces composants tous faits n'ont pas de role=dialog et en conséquence ne sont pas correctement annoncés par les lecteurs d'écran. Peu nombreux sont les composants qui placent le focus dans la fenêtre modale et en règle générale à sa fermeture, le focus ne se retrouve pas de nouveau sur l'élément déclencheur mais en début de page.

Pour certains des frameworks Javascript et CSS les plus connus, des plugins ou composants accessibles ont été développés. Quelques exemples : ngA11y pour Angular, bootstrap-accessibility-plugin pour Bootstrap, et une boîte de dialogue modale 100% accessible pour React.

Quelques exemples de difficultés rencontrées par les utilisateurs

Voici quelques exemples de difficultés rencontrées par les personnes en situation de handicap face aux fenêtres modales.

1 Les utilisateurs malvoyants : Difficulté à percevoir la modale

Pour les personnes qui consultent des pages web avec un agrandisseur, les modales peuvent s'ouvrir partiellement ou entièrement en dehors du champs de vision.

Description vidéo

Un utilisateur mal voyant naviguant avec Windows 10 Magnifier visualise la page à 700% de sa taille originale. Il souhaite poster un tweet sur Twitter (twitter.com, après connexion).

  • Tout d'abord, il ferme une notification lui demandant de confirmer son adresse mail.
  • Il parcourt la page de gauche à droit, localise le bouton "Twittern" et le sélectionne.
  • Sur un écran assombri, une fenêtre modale s'affiche en dehors de la partie visible de la page.
  • L'utilisateur déplace le curseur à la souris, et parcourt la page.
  • L'utilisateur localise la modale avec le champ texte lui permettant de tweeter.

2 Interaction clavier : mauvaise gestion et visibilité du focus et contrôles sans étiquettes

La vidéo montre un utilisateur qui essaie d’interagir avec une fenêtre modale à l'aide du clavier. Le lecteur d'écran a été activé pour annoncer la prise de focus. Pour les personnes voyantes, le focus n'est pas du tout visible.

Description vidéo

Sur la page simplesite.com, une boîte à outils pour concevoir visuellement des sites web simples, un utilisateur interagit au clavier avec une fenêtre modale pour sélectionner les différents éléments de la page web.

  • Naviguant au clavier, l'utilisateur se met sur le bouton "ADD CONTENT", dont la prise de focus n'est pas visible, et l'active (voir note)
  • La fenêtre modale s'ouvre.
  • L'utilisateur tabule mais la prise de focus n'est pas visible sur le bouton de fermeture (x).
  • Il continue à tabuler ; le focus demeure invisible pour l'ensemble des éléments de la modale.
  • La tabulation l'amène en dehors de la boîte de dialogue et sur la barre d'adresse du navigateur Chrome.
  • Le focus se déplace dans la page derrière la boîte de dialogue.

Note: Pour permettre de mieux suivre les actions, le lecteur d'écran est activé. Un utilisateur voyant ne serait pas en mesure de localiser le focus et ne saurait ouvrir la modale à moins d'utiliser une programme qui force une visualisation du focus (Force Focus par exemple).

Comment créer des boîtes de dialogue modales accessibles ?

  • Faire en sorte que la fenêtre modale soit bien visible. Elle présente un contenu qui n'est pas visible sur la page initiale. Pour les utilisateurs naviguant au lecteur d'écran, il est important de bien détecter l'ouverture d'une fenêtre modale. Si elle n'est pas correctement codée, elle peut passer inaperçue. Utiliser role="dialog" (ou role="alertdialog") et aria-modal="true" (mais voir cette note sur aria-modal).
  • Déplacer le focus dans la modale, puis le replacer sur l'élément déclencheur. Pour les personnes naviguant au clavier (y compris les personnes non-voyantes), le focus doit se déplacer sur la fenêtre à son ouverture pour permettre d’interagir avec ses contenus. A sa fermeture, le focus doit de nouveau se trouver sur l'élément qui a déclenché l'ouverture de la fenêtre modale.
  • Maintenir le focus dans la modale. Le focus au clavier doit rester au sein de la fenêtre modale tant qu'elle est ouverte. Il doit pouvoir se déplacer sur l'ensemble des éléments interactifs.
  • Donner à la boîte de dialogue un intitulé pertinent. Il est possible de faire référence à un titre visible via aria-labelledby, ou un intitulé caché via aria-label.
  • Étiqueter l'ensemble des contrôles, y compris le bouton de fermeture. Chaque boîte de dialogue doit disposer d'un moyen correctement identifié permettant de la fermer. Des boutons-icônes [x] doivent avoir des intitulés pertinents qui, à la vocalisation, permettent aux utilisateurs de lecteur d'écran de comprendre leur fonction.
  • Cacher les contenus d'arrière plan. Tant que la modale reste ouverte, marquer les contenus de la page de l'arrière plan avec aria-hidden="true".
  • Gérer les interactions avec la souris en dehors de la boîte de dialogue. Soit les clics en dehors de la fenêtre sont ignorés, soit ils actionnent la fermeture de la modale.
  • Faire en sorte que la touch ECHAP ferme la modale. Les utilisateurs sont habitués à pouvoir fermer les fenêtres modales en appuyant sur la touche ECHAP. Ne compter pas exclusivement sur cette solution ; il faut également proposer une solution visible pour fermer la modale, très importante pour les personnes qui naviguent sans clavier.

Note à propos de aria-modal: Le fait d'utiliser aria-modal="true" rend actuellement tout contenu statique présent dans une modale inaccessible sous MacOS et iOS (voir The current state of modal dialog accessibility (en anglais).

Pour aller plus loin