Depuis la récente mise à jour vers la version 2.8.0.beta2, le bouton du menu d’administration est surligné en jaune.
J’ai cru que Discourse voulait me dire quelque chose, mais même après avoir cherché sur le web et sur ce forum, je n’ai aucune idée de ce que cela pourrait signifier.
Quelqu’un pourrait-il m’éclairer ?
Je pense que cela vous indique que le focus du clavier est sur cet élément. Il s’agit d’un récent changement lié à l’#accessibilité :
Une fois le menu affiché, essayez d’appuyer sur Tab pour naviguer dans le menu.
Oui, c’est exact. Comme l’a noté @simonk, l’une des erreurs que nous commettions était de ne pas déplacer le focus vers les superpositions. Le focus doit se trouver à un endroit logique lorsque vous naviguez dans l’application.
Donc, c’est considéré comme « conforme au fonctionnement prévu » lorsque je vois ceci (survol de la souris sur « Badges ») ?
Hmm, pas sûr ; avons-nous besoin d’un état de survol là-bas @awesomerobot ?
Je pense que nous devrions peut-être passer de :focus à :focus-visible dans notre CSS. Il n’est pas encore pris en charge par Safari, mais il est facile de revenir à :focus dans ce cas.
Si l’élément actif correspond à :focus-visible et qu’un script provoque le déplacement du focus vers un autre élément, le nouvel élément focalisé doit correspondre à :focus-visible.
Cela signifie que si vous ouvrez le menu hamburger en naviguant dessus avec la touche Tab (ce qui active le style :focus-visible), le style :focus-visible s’affiche lorsque le menu est ouvert. En revanche, si vous ouvrez le menu avec un pointeur, le style :focus-visible ne s’affiche pas :
Il y a un inconvénient : dans un scénario d’entrée mixte où vous ouvrez le menu hamburger avec un pointeur puis tentez de naviguer avec la touche Tab… le style :focus-visible n’est pas visible sur le premier lien (même s’il est techniquement focalisé), ce qui donne l’impression qu’il est ignoré. Je ne sais pas s’il existe une solution de contournement pour cela…
Puisque je suis (pour la plupart) un utilisateur de souris, c’est exactement le comportement que je m’attendrais à voir.
D’un autre côté, parfois j’utilise mon smartphone avec un écran tactile : le même problème se produit là aussi, Admin est mis en surbrillance, ce qui indique qu’il pourrait y avoir quelque chose d’important dans la section administration qui nécessite une attention particulière.
D’après le sujet connexe sur les lecteurs d’écran, il semble qu’il y ait un besoin de définir le focus d’une manière ou d’une autre.
Je serais déjà satisfait du comportement mentionné ci-dessus pour les pointeurs.
Je rencontre le même problème.
Je ne pense pas que cet élément offre actuellement la valeur UX que vous aviez prévue : nous avons immédiatement reçu des signalements de bugs à ce sujet sur notre forum. Le focus disparaît lorsque vous cliquez avec le bouton droit n’importe où dans la fenêtre, et il y a un double focus lorsque vous survolez les boutons. Dans l’ensemble, cela semble buggé aux yeux des utilisateurs, d’autant plus que Discourse n’impose pas cette sélection dans aucune autre vue.
Il serait préférable d’afficher le focus clavier uniquement lorsque l’utilisateur appuie d’abord sur la touche Tab, ou uniquement lorsqu’il navigue pour ouvrir le menu hamburger via une action clavier.
Pourriez-vous publier une capture d’écran de cela ? Je ne suis pas au courant de ce problème.
Je vois la même chose dans Safari et Firefox (macOS), ce qui est également mentionné dans le message ci-dessus :
Si je comprends bien cette fonctionnalité, je devrais pouvoir ouvrir ce menu en cliquant ou en appuyant sur =, puis naviguer avec quelque chose (les flèches directionnelles ?) et appuyer sur une touche (Entrée ?) pour accéder à l’élément mis en surbrillance.
Sur Safari et Firefox sous macOS, que j’ouvre ce menu par un clic ou avec =, je ne parviens pas à naviguer à l’intérieur. Les flèches haut/bas font défiler la page vers le haut ou le bas, et les flèches gauche/droite ne semblent rien faire de visible.
La touche Tab déplace le focus vers autre chose, comme un bouton « J’aime » sur un message, et retire la surbrillance jaune du menu. Sous Firefox, la navigation avec Tab parcourait les éléments du menu avant que je ne commence à rédiger cette réponse, mais cela ne fonctionne plus maintenant ; une fenêtre privée a été fermée entre ces essais.
Je constate ces comportements ici sur Meta et sur ma propre instance mise à jour à efbc2481d8 (sauf que sous Firefox, la navigation avec Tab fonctionne correctement, ce que j’ai seulement observé ici).
Les flèches directionnelles ne devraient rien faire, mais Tab et Entrée devraient !
Donc, lorsque vous ouvrez le menu avec = et appuyez sur Tab, vous ne faites pas défiler les éléments du menu ? Je suis sur macOS et cela fonctionne comme prévu dans Safari, Firefox et Chrome, ce qui est un peu déroutant !
J’ai examiné de plus près ce qui se passe ici en général et l’idée d’utiliser focus-visible que j’ai mentionnée ci-dessus ne fonctionnera pas.
Le problème est que le menu hamburger apparaît dans notre HTML en dehors du conteneur du bouton du menu (le conteneur qui regroupe les boutons de recherche, du menu hamburger et de l’utilisateur). Cela signifie que le menu n’est pas le suivant dans l’ordre de tabulation naturel. Pour compenser, nous définissons focus sur le premier élément du menu à l’aide de JavaScript. Cela a pour effet secondaire de mettre l’élément en surbrillance (car nous devons également avoir des styles :focus).
Je ne pense pas que nous puissions nécessairement nous fier à la détection d’une pression sur Tab, car ce n’est pas la seule touche utilisée par les lecteurs d’écran pour naviguer, et nous interférerions avec d’autres raccourcis si nous captions toutes les pressions de touches…
Je peux envisager deux solutions possibles :
Déplacer le menu dans le HTML afin qu’il apparaisse immédiatement après le bouton qui le déclenche. Cela pourrait avoir certains effets secondaires sur la mise en page.
Piéger le focus dans le menu lorsqu’il est ouvert, mais ne pas définir le focus sur un élément particulier. Cela signifie que lorsque le menu est ouvert, vous ne pouvez tabuler que sur son contenu et rien d’autre sur la page. Je pense que c’est probablement la solution préférable…
C’est exact. Pour plus de précision, il s’agit de macOS 11.4 et Safari 14.1.1. Je consulte Meta dans une fenêtre privée et ma propre instance dans une fenêtre non privée.
Je dois avoir fait une erreur lors de mes tests initiaux avec Firefox. Cela fonctionne comme vous le décrivez si la préférence système « Utiliser la navigation au clavier pour déplacer le focus entre les contrôles » est activée, et cela permet de naviguer jusqu’au bouton J’aime comme je l’ai décrit précédemment si elle est désactivée.
Je peux basculer de manière fiable entre les deux comportements en activant ou désactivant cette préférence système sans avoir besoin de recharger la page dans Firefox.
Dans Safari, je constate qu’il navigue vers le bouton J’aime quelle que soit la préférence système, même après avoir rechargé la page. Je n’ai pas encore testé le redémarrage de Safari après l’avoir activée.
J’ai également examiné Chrome, qui fonctionne comme vous le décrivez, quelle que soit la préférence système.
J’ai trouvé la cause de mon problème dans Safari. J’ai remarqué que, contrairement à Chrome et Firefox, si je cliquais quelque part dans la barre d’en-tête et appuyais sur Tab, aucun élément de l’en-tête n’était sélectionné.
Cela m’a conduit à découvrir cette préférence dans Safari, sous Avancé :
Je suis à 99 % certain qu’il s’agit du paramètre par défaut avec une installation propre de Big Sur ; je ne pense pas avoir modifié ce réglage. Avec cette préférence activée, le comportement correspond à ce que vous décrivez. Comme l’indique le texte ci-dessus, cela fonctionne également de cette manière en utilisant Option-Tab lorsque la préférence est désactivée.
