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

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 https://github.com/openui/open-ui/issues/612

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

Start with the reduced testcase at https://codepen.io/scottohara/full/GRdXNEw and the related Open UI issue 612, then review the HTML dialog dismissal and focus behavior described here. The work is done when the standard clearly defines how focus should be handled when the invoking element has been removed, including the keyboard and assistive-technology outcome.