1871369 - VoiceOver jumps to the Top of a document after opening a link in a background tab (doesn't happen in Safari)

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Rares Doghi, Desktop QA]

Attachment: VoiceOverJumpsBack.mp4

Found in

• Nightly 123.0a1 (2023-12-20)

Affected versions

• Nightly 123.0a1 (2023-12-20)
• Beta 122.0b1
• Rellease 121

Affected platforms

• macOS

Preconditions:
Set the browser.shopping.experience2023.enabled - TRUE
Set the browser.shopping.experience2023.optedIn - 0

Enable Voice Over

Steps to reproduce

1. Reach any Product Details page.
2. Use Voice OVer commands in order to reach any link from the Review Checker Onboarding card.
3. Use Vo + Space in order to Select the link.

Expected result

• The Voice Over Highlight should remain on the URL.

Actual result

• The Voice Over Highlight jumps back at the beginning of the Review Checker.

Regression range
This happens in Release 119 as well. Its not a regression.

Comment 1

[Emily McMinn :emcminn]

Is it possible that what's happening here is the links are opening in a background tab, causing the selected link to briefly lose focus? I can duplicate the bug, but if I change the links to be tabshifted or window VO behaves normally (i.e. focus moves to the newly opened tab or window.)

I've done some looking and it seems this might be a bit of a known bug with VO where interacting with clickable elements causes VO to lose track of focus and behave as if the page has been refreshed. We might be able to find a workaround, but we might be stuck with this if we want to keep the background tab behaviour.

As an aside, @Jamie is there a way to have VoiceOver announce that the links have opened in background tabs? Right now it's happening silently which probably makes for a confusing experience, as though the links don't work.

Comment 2

[James Teh [:Jamie]]

(In reply to Emily McMinn :emcminn from comment #1)

Is it possible that what's happening here is the links are opening in a background tab, causing the selected link to briefly lose focus?
...
I've done some looking and it seems this might be a bit of a known bug with VO where interacting with clickable elements causes VO to lose track of focus and behave as if the page has been refreshed.

That answer seems to relate to a link with an anchor. Is that the case here? I would have thought the link was a real external link?

Does this happen if you focus a link on a normal web page and press command+enter? (I assume it's command+enter on Mac; I'm not a Mac user. On Windows, it's control+enter.)

As an aside, @Jamie is there a way to have VoiceOver announce that the links have opened in background tabs? Right now it's happening silently which probably makes for a confusing experience, as though the links don't work.

This feels like a much broader discussion across the entire browser rather than a specific entry point. We could use A11yUtils.announce, but it's tricky because some screen readers on other platforms might already report this and we wouldn't want to double up. It might also become somewhat annoying in some cases.

How does a sighted user know that the page has opened in a new background tab without explicitly keeping their eyes on the tab bar? I'm wondering whether this is a broader UX problem in this case, not just for screen reader users. If a user explicitly chooses to open in a new tab, it's reasonable not to explicitly indicate that because they explicitly made that choice. But if a user clicks a link expecting it to open in the same tab and it opens in a background tab, how do they (even if sighted) know that this is what happened?

Comment 3

[Emily McMinn :emcminn]

These links are dynamically generated for the onboarding card by the LinkParagraph component, so the href is remotely configurable and passed in by JSON.

I actually do see this behaviour on normal web pages, if the link opens in a background tab. Default behaviour of ctrl-opt-space (voiceover key + space) is to open the link in the current tab, which triggers VO to read the new page from the top. Forcing the link to open in a new (background) tab using the context menu creates this behaviour, where VO starts to read the current page over again.

Most of the onboarding content (about:welcome does this too) opens links in the background, with the intention that we try not to pull people out of the onboarding flow by switching them to a new tab. Your thinking is correct that even sighted users may not notice the tab opening, unless they happen to be looking for a new tab in the tab bar. I guess we're balancing that with the desire to keep users engaged with the onboarding content instead of navigating away.

Comment 4

[James Teh [:Jamie]]

(In reply to Emily McMinn :emcminn from comment #3)

I actually do see this behaviour on normal web pages, if the link opens in a background tab. ...
Forcing the link to open in a new (background) tab using the context menu creates this behaviour, where VO starts to read the current page over again.

The context menu could be a slightly different use case, since the context menu takes "focus" (from an a11y perspective) away from the document while the menu is open. Is there a keyboard shortcut (cmd+enter maybe?) to open in a background tab on Mac without using the context menu?

Your thinking is correct that even sighted users may not notice the tab opening, unless they happen to be looking for a new tab in the tab bar.

Given this:

1. If we are certain that opening a link in a background tab in normal content causes the same behaviour, it's reasonable to move this bug somewhere else, probably Core: Disability Access APIs.
2. If opening a link in a background tab in Safari also reproduces this behaviour, we can probably close this altogether, since it's almost certainly a VoiceOver bug we can't fix. We'd ideally notify Apple in the hopes that they might fix it.
3. We could consider a core enhancement to notify screen reader users about documents opening in background tabs. Edge does this for example. Again, this would belong in Core: Disability Access APIs. I consider this an enhancement because sighted users don't necessarily get any explicit indication either, as noted above.

Comment 5

[Shane Hughes [:aminomancer]]

Do we already know for sure this (the initially reported STR and result) doesn't affect NVDA or JAWS on Windows 10/11?

Comment 6

[Emily McMinn :emcminn]

(In reply to Shane Hughes [:aminomancer] from comment #5)

Do we already know for sure this (the initially reported STR and result) doesn't affect NVDA or JAWS on Windows 10/11?

Yep, on my Windows machine (Win10 + NVDA) the focus remains on the link as expected; same in Narrator.

Comment 7

[Emily McMinn :emcminn]

I'm going to move this bug to Disability Access as per Jamie's comment; since this happens on all content when background tabs are opened, but I've been unable to reproduce in Safari.