Popover: focusOnMount shouldn't be specific to keyboard interaction

[afercia]

Many users are not exclusively "mouse users" or "keyboard users". Actually, many users make a mixed use of mouse and keyboard. Implementing software features that work just with mouse or keyboard interaction, is often just an assumption.

In the Popover component there's some code intentionally used to move focus to the Popover only when a keyboard is used.

This seems to me a big assumption, as focus should always be moved to the Popover regardless of the device used. Anecdotally, I personally often make a mixed use of mouse and keyboard, as that's the fastest way to interact with an interface for me. I'm pretty sure I'm not the only one.

So what happens with the Popover? Let's consider one of the Popover implementations: the more options menu. When using the mouse (screenshot on the left) focus is not moved to the Popover. Instead, when using a keyboard (screenshot on the right) focus is moved to the Popover:

This doesn't allow mixed use of mouse and keyboard: for example, users might want to click to open the menu and then quickly use the Tab key to select a menu item. Users often find unexpected ways to interact with an UI, an the UI shouldn't make any assumption on the expected behaviors.

I don't see a good reason for this distinction between mouse and keyboard interaction other than the will to not display the focus style on the first item. If this is the case, I'd like to remind everyone the focus style is a native accessibility feature that should always work for all users, regardless of the device they use.

From a technical perspective, removing this different behavior would also help in reducing the number of keyboard events used in Gutenberg, which have recently come to a point where they seem rather convoluted and fragile. /cc @aduth

[aduth]

focus should always be moved to the Popover regardless of the device used

In retrospect, I can agree with this point. The problem I'd encountered, as demonstrated in the "Before" screenshots of #5318, is that the styling applied in shifting focus to the first item can confuse intention between states of selection and focus.

Perhaps to address this (and arguably for better consistency with other similar native UIs), could it be that opening the menu would still shift focus to the popover, but to its container, not the first item? Then the user could still proceed to tab/arrow would navigate options in the list.

In the meantime, I would be fine to revert #5318, and can plan to take a look at an alternate implementation this week.

[afercia]

for better consistency with other similar native UIs)

The Finder example works a bit differently when using the keyboard:

• Ctrl + F5 to focus the finder window menu bar
• Tab to move to the "Arrange" button
• press spacebar or arrow down to open the menu
• see below: focus stays on the Arrange button (notice the outline)

Of course, finder is a desktop application and works differently from a web application, but this behavior is more similar to what we've described a few times for toggles and panels: ideally, the expanded panel (or popup, whatever we want to call it) should immediately follow the control that opened it. This way, it is just placed in the natural tab order.

Instead, when it's placed far in the source, there's the need to manage focus. I can only refer to the expected behaviors listed in the ARIA authoring practices for similar UIs and they all ask to set initial focus on an element inside the panel/menu/dialog:

https://www.w3.org/TR/wai-aria-practices/#menubutton

opens the menu and places focus on the first menu item.

https://www.w3.org/TR/wai-aria-practices/#dialog_modal

When a dialog opens, focus moves to an element inside the dialog. See notes below ...

The issue in #5318 seems to me a styling issue, can we try to solve it on the styling side, trying to clearly differentiate the "fcused" and "active" styles?

[afercia]

For completeness, looking at similar UI on Windows (Windows 10 Task Manager window):

when opening a menu with the mouse, focus is not moved inside the menu (but then using the arrows, focus moves to the menu items):

Instead, when opening the same menu with the keyboard, focus is moved to the first menu item:

I'd rather keep it simple though, and meet the ARIA authoring practices.

[aduth]

https://www.w3.org/TR/wai-aria-practices/#menubutton

opens the menu and places focus on the first menu item.

The full context of the quote is in pressing Enter/Space/Up/Down while the button is already focused:

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.

Assuming the act of clicking on the button as its focusing, would it then not stand to reason the first menu item would only become focused after then proceeding to press one of these keys?

[afercia]

To be honest, mouse interaction is not described in the ARIA authoring practices. I see their examples (there are a few linked on the menu and menubar sections) work differently with mouse; they all reveal the menu on hover 😬 Just some of them work on mouse click too and move focus to the first menu item:
https://www.w3.org/TR/wai-aria-practices/examples/menu-button/menu-button-actions.html
https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-2/menubar-2.html

I'd rather try to keep the functionality as simple as possible, without assumptions. Styling issues should be solved on the presentation side.

[aduth]

The simplest approach would be to assume that the button should first become focused, then navigation to menu item occurs when proceeding to press one of the above-mentioned buttons.

[afercia]

Technically, the button receives focus while it's clicked.
I can only recommend again to not assume anything 🙂 I'd just pair mouse and keyboard interaction, and always focus the first menu item.

I'd also consider the advantage given by removing those 2 keyboard events attached to the document.

navigation to menu item occurs when proceeding to press one of the above-mentioned buttons.

In that case, it should work also with the Tab key.

[aduth]

Technically, the button receives focus while it's clicked.

Precisely, so the first step is satisfied. The user can then press [some aforementioned button] to navigate to the first item in the list.

I intentionally avoided mention of interaction device in my previous comment to align behaviors on "in focus, and out of focus".

[afercia]

Just tested again and went a bit in depth. Interestingly (and I should have noted this before) when a screen reader is running, DOM events (especially keyboard events) may not work the way one would expect. This happens especially with keyboard events attached to elements that are not focusable or don't have a specific ARIA role.

Note: the same issue happens in a few places in core, see this Trac ticket: https://core.trac.wordpress.org/ticket/34668#comment:3

Tested with:
Firefox ESR and NVDA 2018.1
Latest Safari and VoiceOver

and the keydown / keyup events attached to document don't fire at all. This is expected with screen readers, not a bug. As a consequence, focus is not moved to the first focusable element in the Popover for a group of users who would need that the most.

Reproducing the issue is simpler on Windows but can be done also with Safari and VoiceOver (needs just a minute to be reproduced), just be sure to use the right keys combination:

• use Safari and press Cmd + F5 to activate VoiceOver
• tab to the "More" button in the top right
• hear VoiceOver announcing the button and giving instructions on the default keys to use to activate the button:

• notice VoiceOver instructs to use Control-Option-Space to activate the button, as these are the standard keys VoiceOver uses; the behavior will be different if using only Spacebar or Enter, more about this later
• press the key combination Control-Option-Space
• the menu opens
• focus is not moved to the first focusable element:

• switch off VoiceOver pressing Cmd+F5
• repeat the steps above using only Spacebar or Enter to activate the button
• the menu opens
• this time, focus is correctly moved to the first focusable element

Regardless of the fact VoiceOver asks to use Control-Option-Space, this happens also on Windows with other screen readers that use the standard Enter or Spacebar to activate buttons.

I've also dumped to the console the event.type of the document and button events and when NVDA is running, keydown and keyup don't fire at all when pressing the button:

In the screenshot above you can see:

• when NVDA is not running, all the 3 events fire in the order: keydown, click, keyup, as expected
• then I've launched NVDA
• I've pressed multiple times (15) Spacebar or Enter to activate the button
• only click fires
• thus, focus is not moved to the first focusable element
• (for clarity, the last keydown is when I've pressed the keys to take the screenshot)

Sorry for the long explanation but this is an important point to keep in mind.

Given that moving focus fails for one of the users group it's specifically intended to work for, I'd propose to just remove the check for isKeyDown and don't assume moving focus is a feature for keyboard users only.
This would also help to simplify the code and remove the 2 events attached to the document (noticed they normally fire at any key press anywhere in the UI, not sure that's a good thing).

[aduth]

Related: #5595