Boîtes de dialogues (non modales)

Une boîte de dialogue (non modale) apparaît au-dessus de la page courante, parfois suite à une action de la part de l'utilisateur. La page est partiellement masquée par la pop-in mais l'utilisateur peut encore accéder à son contenu.

La boîte de dialogue peut avoir plusieurs fonctions : il  s'agit parfois de demander à l'utilisateur d'accepter l'utilisation de cookies, ou de répondre à un sondage. Il peut également afficher des informations complémentaires.

A quoi ressemble une boîte de dialogue non modale ?

Cette vidéo montre une boîte de dialogue qui s'ouvre sans action de la part de l'utilisateur.

Comment identifier une boîte de dialogue non modale ?

Il existe plusieurs définitions et les frontière ne sont pas toujours très claires.

Pour certains les boîtes de dialogues non-modales se démarquent par le fait que le focus circule au sein de la boîte (qui contient le "tab ring"), ce qui implique qu'elle soit correctement paramétrée pour avoir ce comportement après ouverture.

Pour d'autres, une boîte de dialogue non modale se caractérise par le fait qu'elle apparaît au-dessus de la page courante mais l'utilisateur peut encore accéder à son contenu. Le fait de tabuler ou cliquer en dehors de la boîte permet de la fermer.

Autre considération : est-ce que la boîte contient un formulaire (donc clairement une boîte de dialogue) ou plutôt des informations (type notification cookies) ? Pour les informations, le rôle region est plus adapté que le rôle dialog, mais la distinction n'est pas toujours très claire.

Si l'utilisateur doit continuer à avoir accès à la boîte de dialogue non modale, il faut prévoir un mécanisme permettant de déplacer le focus à d'autres éléments de la page sans pour autant fermer ou rendre inaccessible la boîte de dialogue. ARIA Authoring Practices 1.0 (aujourd'hui déprécié) préconisait l'utilisation de la touche F6 (voir un exemple de gestion d'erreur de Deque), et d'autres l'utilisation des touches CTRL + TAB.

Des notifications cookies

Des contenus générés après chargement de la page (comme des notifications cookies) ou après un certain délai (comme un sondage) sont très courants et peuvent être très gênants pour les utilisateurs naviguant au clavier. Certains sondages prennent le focus à l'ouverture, d'autres pas. En règle générale les notifications de cookies ne prennent pas le focus et évitent un changement de contexte pour l'utilisateur.

Des fenêtres d'alerte

Il existe une variante de message généré par la page qui disparaît au bout de quelques secondes : des fenêtres d'alerte. Ces messages, type "Votre formulaire a été sauvegardé" ou "Votre formulaire a été transmis" ne peuvent pas être qualifiés de boîtes de dialogue non modales, mais seront néanmoins traités dans cette section.

Des infobulles ("toogle tips")

Les infobulles ou messages d'alerte apparaissent au-dessus de la page courante après activation de boutons, mais ils ne contiennent pas d'éléments interactifs qui nécessitent une prise de focus. Cela implique qu'ils peuvent être restitués après leur apparition via aria-live. Voir Heydon Pickering's Tooltips & Toggletips (en anglais).

Des Pop-in avec des éléments interactifs générées par l'utilisateur

Il existe d'autres contenus qui apparaissent à l'activation de liens, par exemple des définitions de glossaire dotée d'un bouton "fermer" et un lien "lire plus", mais qui ferment automatiquement lorsque l'utilisateur tabule ou clic en dehors de la pop-in. Ces composants sont plus complexes que des infobulles, et ne se comportent pas comme des boites de dialogues non modales avec un "tab ring", mais seront néanmoins traités ici.

Des composants permettant d'afficher/masquer du contenu

Des contenus s'affichent et se masquent à l'activation d'un élément, souvent un bouton de commande. Ces éléments ne contiennent pas de "tab ring" ; les contenus apparaissent à la suite et non pas au-dessus de la page courante. En règle générale le focus reste sur le bouton de commande, ce qui convient à condition que les contenus affichés sont présentés à la suite du bouton (voir la page à propos des "disclosure widgets").

Des "stage widgets"

D'autres composants activés par l'utilisateur (appelés souvent des "stage widgets") peuvent masquer une bonne partie de la page, mais ne piègent pas le focus et ne ferment pas automatiquement en tabulant en dehors de la boîte de dialogue. Ils se situent quelque part entre les "disclosure widgets" et des boîtes de dialogue non modales.

Quelles sont les difficultés rencontrées par les utilisateurs face aux boîtes de dialogue non modales ?

Les boîtes de dialogues non modales sont source de difficultés pour certains utilisateurs en situation de handicap, comme les exemples qui suivent le témoignent.

Pour les utilisateurs naviguant au clavier, localiser et faire partir la boîte de dialogue non modale peut s’avérer complexe, surtout lorsque l'ordre de tabulation ne suit pas l'ordre visuel des éléments sur la page.

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

Il existe peu de règles strictes permettant de créer des boîtes de dialogues non modales accessibles ; tout dépend du contexte et des contenus. Il faudrait toujours se demander si une boîte de dialogue modale ou un "disclosure widget" serait mieux adapté.

Selon le mode d'activation de la boîte de dialogue (par l'utilisateur ou par le page Web), les préconisations varient.

Recommandations générales

• Donner les boîtes de dialogue non modales des intitulés pertinentes. L'intitulé visible doit être identifiée via aria-labelledby, ou une intitulé cachée doit être reliée via aria-label.
• Donner à l'ensemble des contrôles des étiquettes pertinentes, y compris le bouton de fermeture. Chaque boîte de dialogue doit avoir un contrôle bien étiqueté permettant de le fermer. Des boutons à base d'icônes [x] doivent avoir des intitulés accessibles aux lecteurs d'écrans.
• Utiliser les rôles ARIA appropriés. Utiliser role="dialog" et aria-modal="false" sur la boîte de dialogue.

Des boîtes de dialogue non modales activés par le site Web

Ces recommandations sont relatives aux boîtes qui s'ouvrent automatiquement au chargement de la page (exemple : notifications cookies) ou au bout d'un certain délai (exemple : invitations à participer à un sondage, ou de dialoguer avec un chatbot, ou des offres promotionnelles).

• Penser à la gestion du focus. Selon les contenus ou le contexte d'usage, il faut décider si le focus doit être pris par la boîte à son ouverture. En règle générale, les boîtes de dialogue non modales qui ne se positionnent pas par dessus les contenus de la page ne doivent pas prendre le focus.
• Faire en sorte que les boîtes qui se positionnent au-dessus des contenus de la page sont faciles à faire partir. Si une boîte de dialogue non modale obscure les contenus de la page, il faut qu'elle puisse être fermée via le clavier. Dans ce cas, la boîte de dialogue doit prendre le focus pour faciliter cette action. (Cas particulier : les notifications présentées dans une bannière en bas de la page — dans ce cas, les utilisateurs peuvent scroller pour accéder aux contenus).
• Respecter l'ordre de lecture des contenus. Si une boîte de dialogue non modale ne prend pas le focus et n'obscure pas les contenus de la page (comme des notifications de cookies qui repoussent les contenus de la page ou des notifications en bas de la page), faire en sorte que sa position dans le code respecte sa position visuelle dans la page pour que les utilisateurs puissent y accéder pour la fermer.
• Penser annoncer les boîtes de dialogue générés par le site. Les boîtes de dialogue qui s'ouvrent automatiquement peuvent être annoncées via aria-live="polite" pour que les utilisateurs de lecteur d'écran en prennent connaissance sans pour autant perdre la position du focus.

Des boîtes de dialogue non modales générés par l'utilisateur

• Placer la boîte de dialogue non modale juste après l'élément qui déclenche son ouverture. Cela permet aux utilisateurs non-voyants d'accéder aux contenus de la boîte via les flèches et d'accéder aux contrôles en tabulant.
• Autre solution, placer le focus dans la boîte de dialogue. Si les contenus de la boîte de dialogue ne peuvent pas être positionnés juste après l'élément déclencheur, placer le focus sur le premier élément interactif de la boîte de dialogue.
• Faire disparaître la boîte de dialogue non modale s'il y a une action en dehors de la boîte. Si l'utilisateur clic ou déplace le focus en dehors de la boîte, fermer-là.

Note : Lorsqu'une boîte de dialogue reçoit le focus à son ouverture, le focus peut continuer à circuler jusqu'à ce que la boîte est fermée par l'utilisateur via le bouton de fermeture ou le bouton ESC. Pour les utilisateurs naviguant au clavier, ce type de boîte de dialogue non modale aura le même comportement qu'une fenêtre modale. Voir l'exemple sur le site Web de la ville de La Haye présenté sur cette page, ou l'exemple (un peu daté) présenté sur le site d'Athena technologies : ARIA Non-Modal Dialog Example.

Pour aller plus loin (ressources en anglais)

A ce jour nous n'avons pas identifié des ressources exhaustives permettant de créer des boîtes de dialogue non modales accessibles. Voici quelques références dont nous disposons :

• The current state of modal dialog accessibility (Scott o'Hara, Paciello Group, juin 2018)
• Non-modal dialog pour la gestion d'erreurs (Deque University, sans date)
• Outdated information on non-modal windows (W3C, WAI-ARIA Authoring practices 1.0)
• Keyboard method to jump out of NON-modal dialogs? (discussion Github à propos des raccourcis clavier permettant de déplacer le focus entre différents éléments de la page sans fermer les boîtes de dialogue)