NVDA does not toggle browse mode on when focus is moved to a button inside an ARIA document

[kloots]

Steps to reproduce:

1. Open the CodePen example
2. Use tab-key navigation to move focus to the first ARIA listitem of the ARIA list representing the list of messages
3. Observe NVDA automatically toggles focus mode on when the ARIA listitem is focused (this is thanks to the fix for issue 13357)
4. Press tab to move focus to the button representing the message sender
5. Observe NVDA does not toggle browse mode on despite the button being contained within an element with role="document"
6. Press tab once more to move focus to the anchor element representing the time
7. Observe NVDA toggles browse mode on when the anchor is focused

Actual behavior:

NVDA does not toggle browse mode on when focus is moved to a button contained within an element with role="document"

Expected behavior:

NVDA should toggle browse mode on when focus is moved to a button (or any element) contained within an element with role="document"

System configuration

NVDA installed/portable/running from source: Installed

NVDA version: 2022.3.3

Windows version: 10

[kloots]

If it helps I've made a screen recording to demo this issue.

[michaelDCurran]

@kloots I acknowledge your expectation that NVDA should automatically switch back to browse mode when focus hits something inside an ARIA document that would not normally force focus mode. However, i just want to confirm that it is okay that once in browse mode, the user will be able to arrow through the ARIA document content and also totally outside it. I.e. browse mode arrow keys will not be confined to the ARIA document? So in your coase, the user would read the content of the message, but then keep arrowing out and through other list items etc.
If you are expecting confinement to the ARIA document, then the scenario would have to be such that the list itself be inside an ARIA application, as this would mean that NVDA would not create a virtual document here, but only for the embedded ARIA document. Or we could consider never including embedded ARIA documents in parent browse mode content, and therefore always forcing an isolated browse mode for embedded ARIA documents.
If on the other hand you are not concerned about confining browse mode to the ARIA document, then I shall work on a more general solution to simply ensure that browse mode is automatically re-enabled if focus hits any element inside an embedded ARIA document, as long as that element normally would not automatically enable focus mode.

[kloots]

@michaelDCurran the first behavior you describe ("once in browse mode, the user will be able to arrow through the ARIA document content and also totally outside it") sounds reasonable to me. And I say that only because that is the behavior in JAWS. That said, the idealist in me says it'd be cool if there was confinement to the ARIA document without the need for wrapping the list in role="application" as this would yield what I think would be two benefits:

1. Less verbosity for the user (user doesn't have to hear "application" when entering the list)
2. A functional reinforcement of the document boundary

Of course, I want to be sure to call out my own bias here: I'm a sighted developer who isn't using NVDA full time. I say that only because I want to be sure my bias doesn't negatively impact what might be the expected user experience of someone using NVDA full time. If the first experience you describe is what would be expected by or more intuitive for an NVDA user - go with that.

[jscholes]

@michaelDCurran

we could consider never including embedded ARIA documents in parent browse mode content, and therefore always forcing an isolated browse mode for embedded ARIA documents.

I think this would overcomplicate the relatively simple ask by @kloots, which seems to be aimed more at increasing behavioural consistency. The idea of NVDA isolating embedded documents in that way also makes me feel uncomfortable; it would almost create a non-modal-style dialog scenario if I'm understanding your suggestion correctly, but without the associated role/name to create that impression for the user.

I shall work on a more general solution to simply ensure that browse mode is automatically re-enabled if focus hits any element inside an embedded ARIA document, as long as that element normally would not automatically enable focus mode.

This seems like the way to go.

[michaelDCurran]

@kloots I have created pr #14611 which should address both this issue and #14495

You can test the following try build: https://ci.appveyor.com/api/buildjobs/1mpo99fbacj9cr0p/artifacts/output%2Fnvda_snapshot_try-i14494-27635%2Caa53b889.exe

Please note that when testing, the browse mode option Automatically set focus to focusable elements must remain turned off (which has been the default for several years now). We are planning on removing this option completely in the near future.