Prevent a11y events after focus changes

[jessegreenberg]

From #939 @pixelzoom said

Here's something else that makes no sense to me, observed in the current implementation of ComboBox. If the combo box button has focus, pressing Enter pops up the listbox, and releasing Enter immediately pops down the listbox.

Demonstrated in Molarity:

Tab to the combo box, so that its button has focus.
Press and hold the Enter key. The button's click listener fires. The listbox pops up and the item that is currently selected is given focus.
Release the Enter key. The selected item's keyup listener fires, and the listbox pops down.
So by clicking Enter (which supposedly means "accept") the related events get sent to whatever UI component happens to have focus at the time. That Enter was meant for the button, and only the button. The listbox and its items shouldn't be receiving anything related to that user action.

And this issue is not specific to keyup but for most alternative input events like click, see https://jsfiddle.net/3bgkcdes/

We should try to find a general solution to this problem. A solution that works with screen readers may be difficult to find because we usually don't receive keyup keydown events when click is sent.

[jessegreenberg]

I wonder if we can use this somehow: https://developer.mozilla.org/en-US/docs/Web/API/UIEvent/detail

For click or dblclick events, UIEvent.detail is the current click count.

EDIT: in cases like https://jsfiddle.net/9owd5L3m/1/, event.detail is always zero as focus jumps between the two buttons.

[jessegreenberg]

I can't think of any way to catch this generally. The click events that are triggered on each button have no knowledge of each other even though they were initiated from the same key press.

As a side note, I also noticed that this accessible combo box example from W3C has the same issue:
https://w3c.github.io/aria-practices/examples/listbox/listbox-collapsible.html

[jessegreenberg]

If we can't catch this generally for all events, maybe our best option is to do this for certain events like keyup. For instance, we could not fire any keyup listeners if focus changes so that keyup is triggered before a keydown is triggered on a node.

[pixelzoom]

That sounds like a reasonable approach to investigate. And ideally, that would be handled by scenery.

[jessegreenberg]

@zepumph and I took a look at this last night, we made a change to A11yPointer that aborts the keyup event if fired on a Node that didn't first receive a keydown event. This works OK, but we would like to continue to consider something that would work more generally than just for the keyup event.

[jessegreenberg]

Reviewing this with @zepumph, f1ce6d9 has been working OK and we haven't needed this for more events since 2019.

We realized that this is important for keydown/keyup pairs because focus can change between them. But it was not needed for single events like input change or click.

Closing.