Consider change to handling focus after dialog dismissal and removal of invoking element

[scottaohara]

Presently, if a dialog (modal or modeless) is invoked from an element in the DOM, dismissing the dialog (esc key or via a submit button contained within a form with a method=dialog) will return focus to the element which invoked the dialog. This is good, as it allows someone using keyboard / AT to return to navigating the page from their previous position prior to invoking the dialog.

However, if the element that invoked the dialog is removed from the DOM, focus does not return to the gap or 'hole' that the invoking element has left. Rather, focus lingers in the location where the dialog is included in the DOM. This will mean that someone using keyboard / AT, upon pressing the Tab key, may find themselves in a very different location, and they will have to re-orient themselves and re-navigate to their previous position.

This unwanted UX is often encountered with rows/lists of content, where an invoked dialog (or popup widget - i.e., role=menu) is rendered from an 'actions' or 'delete' button. The gap occurs because the dialog/popup UI is included at the bottom of the DOM (typically for styling or re-usability purposes), and positioned using JS/CSS to appear next to its invoking element (or in the case of a dialog, simply overlaying the content of the page).

To mitigate issues like this developers need to write JavaScript to force focus to another focusable element near where the hole now exits. Or they need to make an otherwise unfocusable element (e.g., a container element or heading) focusable via tabindex=-1, so that focus can be programmatically set to that. In many cases, developers do not do this, and it comes down to an accessibility audit to find this issue and call out the described manual fix they need to implement.

To help showcase what I've described here (because so many words, sorry), I've made a reduced testcase to demo the current behavior: https://codepen.io/scottohara/full/GRdXNEw

For further context, this issue originated in openui/open-ui#612

If there is anything else I can help clarify here, please let me know. Thanks!