First text node is read after closing a modal which uses <dialog> HTML element

[dhaval-sri]

Steps to reproduce:

1. With NVDA running, open URL : NVDA-Dialog showModal() Example
2. Navigate to the button that opens the dialog which uses the showModal() method of the HTMLDialogElement
3. Press Enter or Space to open the dialog
4. Dismiss the dialog box using the Escape key or the Close button within the dialog

Actual behavior:

NVDA reads the first element on the page after dismissing the dialog box and then the button that opened the dialog.

NVDA Speech: "This will be read Show the dialog button"

Expected behavior:

Only the element which opened the dialog box should be read by NVDA.

NVDA Speech: "Show the dialog button"

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

release 2023.3.1 (2023.3.1.30639)

Windows version:

Version 10.0.19045 Build 19045

Name and version of other software in use when reproducing the issue:

Chrome version: 122.0.6261.70 (Official Build) (64-bit) Edge Version: 122.0.2365.59 (Official build) (64-bit)

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

no

If NVDA add-ons are disabled, is your problem still occurring?

yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[dhaval-sri]

When closing a dialog created using the showModal() method of HTMLDialogElement, the first element which contains a text node is read before reading the button which opened the dialog. The first element doesn't need to be focusable, it happens for any element.

[seanbudd]

This is intended behaviour - focus is returning to the document, before shifting to the button. Can you explain what the negative user impact is here? You should be able to work around this by forcing focus in the close event listener.

[dhaval-sri]

@seanbudd,

1. Negative user impact: Generally, the first accessible element in a website is the Skip to main content link. Whenever a dialog is closed, the Skip to main link is announced before announcing the button which triggered the dialog. This fails in 1.3.2 - Meaningful Sequence.
2. Sadly, workaround doesn't work. Please refer to this CodePen - NVDA-Dialog-Announcing Skip to main (codepen.io)

Additionally, I disagree that we should rely on a workaround to manage focus. One of the key reason of using the <dialog> element is its baked-in accessibility features (escape to close, focus management - while opening or closing, making other content inaccessible etc.). Implementing the focus management for all the dialogs is cumbersome when we're not supporting older browsers.

I've also tested the same in JAWS, but this issue is not reproducible while using it.

[seanbudd]

Thanks for your information - can you also test Firefox and let us know if the behaviour is any better or different?

[dhaval-sri]

NVDA behaves the same in Firefox (123.0.1) as well.

[Adriani90]

I am ccing @jcsteh here for firefox. In fact I think the cancellable speech feature for expired focus events should handle this case in NVDA.

Note, this issue happens only in browse mode. When enabling focus mode with NVDA+space bar and pressing the "show dialog button", NVDA will behave as expected after pressing the close button.

Not sure why the virtual document behaves differently here.

cc: @SaschaCowley

[jcsteh]

This occurs because when the modal dialog appears, the entire content of the document behind it gets removed from the accessibility tree, since it is effectively "hidden". That means NVDA has no idea where the browse mode cursor should go, so it snaps to the top. When the dialog closes and the document content re-appears, NVDA reads the line at the browse mode cursor (as it always does when a browse mode document regains focus), which is now the top line. What I don't quite understand is why the focus event doesn't cause the browse mode cursor to update before that happens. I'm guessing there is some weirdness with event_treeInterceptor_gainFocus here.