Closing a dialog by Escape key is also being considered as keyboard navigation

[saschanaz]

WAI-ARIA suggests returning focus to the previously focused element when closing a modal dialog, with an example:

When a dialog closes, focus returns to the element that invoked the dialog unless either:

Using focus-visible here is tricky as currently the polyfill responds to all keydown events and adds .focus-visible class when the ARIA refocusing happens by tapping Escape key to close a dialog.

Maybe we can exclude Escape key from onKeyDown, what do you think?

https://github.com/WICG/focus-visible/blob/1756d66f733ef1fc67514e985489867281f719c4/src/focus-visible.js#L102-L108

[saschanaz]

#88 suggests closing by keyboard should cause focus-visible, but think about this situation:

1. User clicks a button with a mouse to open a dialog, which includes a textarea and closes by Enter key.
2. User types some text in the textarea and taps Enter to complete submission, which closes the dialog.
3. User now restarts using mouse.

I would suggest that we keep the previous focus visibility, in other words the focus should be visible only if it was before opening a dialog.

[robdodson]

in other words the focus should be visible only if it was before opening a dialog.

I definitely understand the dilemma. The issue is that I'm not sure how we would know that a dialog is being opened or closed. As mentioned in this comment it seems like there is probably a need for some kind of mechanism to manually control the behavior of focus-visible.

Currently focus() can take a dictionary argument

focus({preventScroll: true })

I wonder if that dictionary could be expanded to include a flag to manually override focus-visible behavior.

focus({preventScroll: true, focusVisible: false })

@alice wdyt?

edit also cc'ing @domenic since he was involved in the focus scroll options discussions.

[robdodson]

@saschanaz can you tell me what's the negative impact of showing the focus indicator if the user pressed escape to close the dialog?

[alice]

I think this comes down to "can we anticipate when mixed-mode users are about to change mode" (e.g. from using the keyboard to submit a form, to using the mouse to navigate the non-modal part of the page), and I think the answer is simply that we can't.

As Rob asks, what is the impact of showing a focus ring around the element which triggered the dialog to open, in the case where the user has used the keyboard to close the dialog? Are we concerned that it might cause confusion for users, or cause page authors to disable the focus ring?

[saschanaz]

I think tapping Escape key is like tapping back button on my phone. Getting an indicator whenever tapping back button is just unexpected.

[alice]

That makes sense to me, to be honest.

I don't think we can reasonably detect the case where the user is "returning" to a pointer-based modality from using a dialog, but if the user only used the escape key after being in a pointer-based modality, we can probably guess that they are going to keep using a pointer.