Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates incorrectly reported for lie regions in background tabs in Firefox #1318

Closed
nvaccessAuto opened this issue Jan 11, 2011 · 10 comments

Comments

@nvaccessAuto
Copy link

commented Jan 11, 2011

Updated description for clarity:

Currently, NVDA reports off-screen live regions. This is because we want to report regions which have been placed off-screen so they are only read by screen readers. Unfortunately, content in background tabs is also marked off-screen. And in Firefox, all tabs share the same HWND, so we can't use the HWND to determine whether a tab is in the background. This means we can't tell the difference between author off-screen live regions and live regions in background tabs in an efficient, standard way. However, we definitely shouldn't be reading live regions in the background.

STR:

  1. Open this test case in Firefox:
    data:text/html,<div id="live" aria-live="polite">Initial content</div><script>setTimeout(() => live.textContent = "Updated live content", 2000);</script>
  2. Quickly (within 2 seconds), press control+t to open a new tab.
  3. Wait 2 seconds.
    • Expected: NVDA should not say "Updated live content"
    • Actual: Within 2 seconds, NVDA says "Updated live content"

Original description (for historical purposes):

Reported by modulus on 2011-01-11 19:54
When reading changes taking place on the Chatzilla window (and presumably on Firefox in general) the tab where those changes take place (which in Chatzilla's case represents the channel) is not announced. This makes it difficult to join several channels.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

commented Jan 12, 2011

Comment 1 by jteh on 2011-01-12 00:21
Tabs other than the currently active tab are not supposed to be read at all. Are you seeing cases where this happens? If so, this would seem to be a reappearance of #138.
Changes:
Milestone changed from None to None

@nvaccessAuto

This comment has been minimized.

Copy link
Author

commented Jan 12, 2011

Comment 2 by pvagner on 2011-01-12 12:41
Hello,
I have just tested and it really looks as if that issue is back again.
I've just tried to use ChatZilla 0.9.86 in Firefox/3.6.13. Except of the default chatzilla window, I've connected to the irc.mozilla.org server, joined several channels one after the other and while idling having the focus inside the tab for the second channel, events from the first channel were spoken.
I need to take a look on that issue and try if I can do something.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

commented Jan 12, 2011

Comment 3 by jteh on 2011-01-12 15:36
Is this with Gecko 2/Firefox 4? If so, the problem is that all tabs are in the same window in Gecko 2, so the window states can't be used anymore. This means that it is really important that Mozilla fix the bug with states on their side.

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015

@dkager

This comment has been minimized.

Copy link
Collaborator

commented Jul 2, 2017

Maybe worth re-testing, unless Gecko experts can confirm that this is fixed in later versions than FF 3.

@jcsteh

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2017

As far as I know, this bug still exists.

@ehollig ehollig added the Firefox label Oct 10, 2017

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented May 27, 2019

@Modulus, @pvagner are you still seeing this issue in NVDA 2019.1.1 and Firefox 67?

@pvagner

This comment has been minimized.

Copy link

commented May 28, 2019

Hello,

On my end This can still be reproduced with NVDA 2019.1 and Firefox 67 on Windows and Firefox 69 and Orca master on linux.

Easier steps to reproduce than chatzilla:

  • Open the page at https://terrillthompson.com/tests/aria/live-scores.html
  • 2 Hit Start game 2 button and notice how your screen reader of choice announces the region changes.
  • Press ctrl+t to open a new tab.
  • 4 navigate a bit on the new tab to make sure the focus is in the document content.

Results:
Aria-live region announcements continue even when the tab where they are originated from is no longer in focus.

It would be interesting to find out a corresponding Mozilla bug for this one.

To me it looks platform neutral or at least it may affect even more users than we have expected.

@jcsteh

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

There isn't a Mozilla bug at this stage. The problem is that there's no clear way to map this in current accessibility APIs.

objects in background tabs do get the offscreen state. Unfortunately, web authors use off-screen live regions to make screen readers speak information which isn't visible, so screen readers can't ignore off-screen live regions. We still need to fire the events because otherwise, screen reader virtual buffers wouldn't be updated. (Granted, this last point isn't an issue on Linux.)

To solve this, we need some other way to generically communicate that an accessible is in the background. This needs to be something standard; there are hacks NVDA could use to detect this in Firefox specifically, but that wouldn't work for other IA2 implementations.

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

It seems @derekriemer is also looking into this. See #9079.

@jcsteh jcsteh changed the title Tab announcement when reading changes Updates incorrectly reported for lie regions in background tabs in Firefox May 28, 2019

@jcsteh

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

I updated the issue description for clarity.

It seems @derekriemer is also looking into this. See #9079.

That PR is indeed about live regions, but this problem is out of scope there.

I just realised this isn't an issue for Chrome, since Chrome uses different HWNDs for different tabs. That makes it less important to try to standardise a new solution. Also, Firefox already provides a relation to get the tab document for a given accessible, as well as a relation to get the currently active document from the root. We could use those to fix this. I'll try to find time to submit a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.