Où doit se concentrer le clavier après avoir activé un bouton qui fait apparaître une boîte de dialogue non modale?
J'ai un bouton qui affiche une boîte de dialogue non modale, comme ceci:
Le bouton "Afficher le sélecteur de symboles" fait apparaître la boîte de dialogue non modale du sélecteur de symboles. Si vous appuyez à nouveau sur le bouton, la boîte de dialogue reste ouverte et la place au premier plan si elle se trouve derrière d'autres boîtes de dialogue non modales.
Le bouton peut être focalisé en utilisant le Tab clé. Si l'utilisateur appuie sur la touche Enter pendant la mise au point, le sélecteur de symboles non modal apparaît comme décrit ci-dessus.
Cependant, je ne sais pas où la mise au point doit être effectuée après que l'utilisateur a appuyé sur la touche Enter clé. Doit-il être sur la boîte de dialogue ou sur le bouton? Que se passe-t-il si la boîte de dialogue modale est déjà ouverte et que le bouton est à nouveau enfoncé (une action qui normalement fait passer la boîte de dialogue ouverte au premier plan)?
J'aimerais trouver une source faisant autorité sur l'accessibilité au clavier. De plus, je ne recherche pas une conception alternative qui élimine le bouton ou la boîte de dialogue non modale (c'est une exigence métier dans une conception existante, que je n'ai pas le pouvoir de modifier pour le moment).
Besoin de plus de contexte ici. Le comportement est différent pour l'application de bureau (Windows, Mac) par rapport au Web.
Bureau
La boîte de dialogue s'ouvre dans une nouvelle fenêtre. En règle générale, la nouvelle fenêtre obtient le focus. L'utilisateur peut tabuler pour retourner le focus à la fenêtre principale, tout en conservant la petite boîte de dialogue. Ou fermez la fenêtre à l'aide du raccourci de fermeture de fenêtre (Windows: Ctrl + W, Mac: Cmd + W)
Web
Le comportement Web est un peu plus varié, mais l'utilisation de la touche "Echap" pour fermer une boîte de dialogue est assez courante. Comme d'habitude, si un utilisateur choisit d'effectuer une action qui ouvre une nouvelle boîte de dialogue, l'hypothèse serait qu'il souhaite interagir avec les éléments de la nouvelle boîte de dialogue. Placez donc le focus sur le premier bouton de la boîte de dialogue. L'onglet passera par tous les boutons de la boîte de dialogue. La boîte de dialogue "X" pour ignorer doit également être tabulable. L'utilisateur peut "Shift + Tab" pour accéder au "X" ou tabuler à travers tous les boutons pour revenir au "X" ou appuyer sur "Esc" pour rejeter directement le modal.
Mise à jour D'après les commentaires, OP a indiqué que les utilisateurs gagneraient réellement à pouvoir visualiser les symboles dans la fenêtre principale. Par conséquent, nous devons envisager de traiter la boîte de dialogue comme un volet latéral directement affiché à l'écran. Ou un "groupe" tel que défini par WAI_ARIA http://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#kbd_layout_whatgroup Peut-être lier le groupe au "Show" Bouton Sélecteur de symboles ". S'il est ouvert, mettez le 1er bouton en surbrillance, mais permettez aux utilisateurs de déplacer l'onglet pour revenir au bouton Afficher le sélecteur ou si l'utilisateur est à la fin de la liste des boutons, l'onglet mettra le focus sur l'élément suivant après le bouton Afficher le sélecteur sur l'écran principal.
Contenu ajouté/nouveau de manière dynamique:
Si vous prétendez qu'il ne s'agit pas d'une "boîte de dialogue modale", mais plutôt d'un contenu créé par un élément déclencheur (lien ou bouton), alors WCAG a un guide légèrement différent sur la façon de gérer le nouveau contenu.
Voir cette ressource WCAG sur l'implémentation de "Insertion de contenu dynamique dans le modèle d'objet de document immédiatement après son élément déclencheur"
L'ordre de lecture dans un lecteur d'écran est basé sur l'ordre des éléments HTML ou XHTML dans le modèle d'objet de document, tout comme l'ordre de tabulation par défaut. Cette technique insère un nouveau contenu dans le DOM immédiatement après l'élément qui a été activé pour déclencher le script. L'élément déclencheur doit être un lien ou un bouton, et le script doit être appelé à partir de son événement onclick. Ces éléments sont nativement focalisables et leur événement onclick est indépendant du périphérique. Le focus reste sur l'élément activé et le nouveau contenu, inséré après, devient la prochaine chose à la fois dans l'ordre de tabulation et dans l'ordre de lecture du lecteur d'écran.
Semble impliquer, dans la section "description", que pour être conforme aux WCAG, il vous suffit d'insérer le nouveau DOM immédiatement après le DOM pour le bouton de déclenchement. Cela s'applique plus généralement à ce que vous essayez d'accomplir et semble répondre aux exigences de votre entreprise. Il fournit même des informations sur l'ordre de tabulation et le focus actuel après votre clic immédiat.
Dialogues:
Cliquer sur le bouton ajoute du contenu à l'écran. Le focus doit être déplacé vers le nouveau contenu, sinon les utilisateurs de lecture d'écran seront perdus. Tant que la boîte de dialogue n'a pas été fermée, l'utilisateur ne doit pas pouvoir tabuler en dehors de la boîte de dialogue.
Voir cette ressource WCAG dans les dialogues
Le nouveau contenu HTML comme les boîtes de dialogue doit être inséré dans le DOM directement après l'élément qui l'a activé. Le focus doit être envoyé et piégé dans la nouvelle boîte de dialogue. La touche ESC doit fermer la boîte de dialogue. Assurez-vous que le bouton X (fermer) est accessible au clavier et possède une alternative textuelle. Lorsque la boîte de dialogue se ferme, le focus doit revenir à l'élément qui l'a activé.
J'ai été dirigé vers cette ressource par un Wiki géré par le groupe de travail WCAG. Le wiki/source peut être trouvé ici: http://www.w3.org/WAI/GL/wiki/Managing_focus_for_modal_dialogs
Il existe des ressources supplémentaires disponibles et quelques instructions/guides sur la mise en œuvre. Si votre application n'est pas une application Web, la plupart des plats à emporter s'appliquent toujours.