This test page was originally created in March 2019 and the quoted text may have changed since then. Please see updated notes towards the bottom of this document for more recent (2021) behaviors.
This test only works in browsers that support the dialog element.
This test uses nothing more than the dialog element, and the default
functionality of the .showModal() and .close() methods.
This particular test has no focusable element within the dialog to test
the fall back step of the focus algorithm.
The step in question states: (bold emphasis and parentheticals are mine)
Let control be the first descendant element of subject (the dialog), in tree order, that is not inert and has the autofocus attribute specified.
If there isn't one, then let control be the first non-inert descendant element of subject, in tree order.
If there isn't one of those either, then let control be subject.
In other words, if control is not an autofocused element, or a natively focusable element is not found, then let control be the dialog itself.
Note: nov-2-2021 - results have changed since 2019. For instance, if attempting to open one of these dialogs with latest Chrome/Edge and JAWS or NVDA,
the screen readers will not automatically entre the invoked dialog. Instead, keyboard focus / the screen reader's virtual cursors will announce nothing after hitting Enter, and remain on the invoking button.
Without a screen reader active, there is no visible focus placement. Querying the
Android Chrome with TalkBack sends focus to the web view.
macOS Chrome with VoiceOver focuses the web view.
Chrome with JAWS 2019 sends the virtual cursor within the
dialog, but "modal dialog" is not announced.
Chrome with NVDA 2018.4.1 sends the virtual cursor to the document root. Hitting down arrow will announce "dialog", but the virtual cursor will fail to enter the dialog. Instead just announcing "blank".
Results (March 2019)
activeElement after the modal dialog is opened returns the body element.