Pointer-activated menu should not focus the first element in the menu as default?

[johanrd]

1. Go here https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/
2. Click a trigger
3. See that the trigger is kept in focus, and that the first item in the menu is not focused
4. Activate the item with a keyboard interaction and see that the first item in the menu is focused.

With aria-voyager both click and keybord interaction ends up with the first item in the list being focused. This felt a bit unexpected.

[johanrd]

Hmm, differentiating between wether a popover was click-triggered or keyboard-triggered may be theoretically impossible to detect from a modifier on the menu alone…? :/

[johanrd]

The only thing I can think is to set up an event listener on the element with popovertarget=element.id. Something along these lines:

const triggerElement = document.querySelector(`[popovertarget=${element.id}]`);

if (triggerElement) {
  triggerElement.addEventListener('click', (event) => {
     menu[FOCUS_ON_OPEN] = false;
  });

  triggerElement.addEventListener('keydown', (event) => {
     menu[FOCUS_ON_OPEN] = true;
  });
}

[gossi]

For references use the best practices and then verify the samples. Some of them are ~15yrs old and haven't been updated (yet). The best practices are listing the up-to-date interactions, so the ones I used:

1) https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

Keyboard Interaction > Space

(Optional): When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.

2) https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/

Keyboard Interaction

With focus on the button:

Enter: opens the menu and places focus on the first menu item. Space: Opens the menu and places focus on the first menu item. (Optional) Down Arrow: opens the menu and moves focus to the first menu item. (Optional) Up Arrow: opens the menu and moves focus to the last menu item.

But already when implementing this, I realized the spec leaves some options open for implementors to make a decision.

I think, the hover behavior is one where I realized there could be different ways to do that. During implementation I was already toying with the idea of having a behavior option in which consumers may be able to configure what they want - though I was hoping for issues like this :)

Some of this is also encoded in different roles, e.g. role="menu" and role="menubar" would be two different here. And so the role can make a prejudgement already and configure the MenuNavigationPattern.

My thinking here is:

• Make the navigation patterns most configurable
• The controls can configure the navigation patterns they use
• The controls can make behavior customizable by consumers

Can you maybe collect some of the behaviors you wanna see/want to configure? Are you looking for a {{menubar}} modifier?

Happy to hear :)

[johanrd]

Hmm, yes. However: I started noticing this because of feeling a different UX than expected.

My 'expected' behavior can also be reproduced on the menu buttons in github:

1) When you click-to-open it, the focus stays on the button 2) Only when you keyboard-to-open the focus is moved to the menu itself

However, with aria-voyager the focus is always moved to the menu (i.e. aria-voyager moves focus from the trigger on click, which is not expected)

[gossi]

Ah I see now. I've checked a aria-voyager menu in action. So it is about the invoking trigger. I agree, when invoked via pointer, it shouldn't focus the first item 👍

Technically a challenge, as the popover is not part of aria-voyager. Hmm 🤔

[johanrd]

yeah, a bit unfortunate, but the only thing i could think of was to add a listener to the element referring to the popover with the popovertarget attribute :

const triggerElement = document.querySelector(`[popovertarget=${element.id}]`)

(or if a reference element selector is passed in).