search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

On mouse hover, NVDA reads behind an opaque overlay in Chrome #10847

Closed carsonpowers closed 3 months ago

carsonpowers commented 4 years ago

Steps to reproduce:

  1. turn on NVDA, open up Chrome, and navigate to https://jsfiddle.net/sabrick/gq4p71fw/1/
  2. hover over .frontImage (reads it correctly)
  3. while hovering over .frontImage, move the mouse to the right to hover over the image that's behind the overlay (.behindImage)

Actual behavior:

It reads .behindImage through the overlay as if the overlay was not there

Expected behavior:

It should read nothing, since .behindImage is BEHIND the overlay.

System configuration

NVDA installed/portable/running from source:

official website

NVDA version:

2019.3.1

Windows version:

Windows 10 Enterprise version 1809

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

80.0.3987.132 (Official Build) (64-bit) (cohort: 80_Win_132) Revision | fcea73228632975e052eb90fcf6cd1752d3b42b4-refs/branch-heads/3987@{#974}

Other information about your system:

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 addons are disabled, is your problem still occuring?

yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

no

additional info

This DOES NOT occur in any other browser (FF, edge, IE11)

larissamasson commented 4 years ago

I thought that is a problem in my code when I found this bug. I tried everthing and nothing worked... Today I found this post https://www.facebook.com/groups/nvdaforum/permalink/1259777424227917/ in a NVDA forum on facebook, the users are saiyng that is know bug from 80 version Chrome .

I don't n know for sure if is that of course rs...

carsonpowers commented 4 years ago

This bug is was also filed with chromium and is currently in triage: https://bugs.chromium.org/p/chromium/issues/detail?id=1058971

Adriani90 commented 4 years ago

cc: @Qchristensen, @feerrenrut maybe you can help here from a sighted people perspective.

Qchristensen commented 4 years ago

Is this still present? And is that original page still the same? I couldn't trigger anything to pop up on it to test with Chrome 83...

JulienCochuyt commented 4 years ago

@Qchristensen wrote:

Is this still present? And is that original page still the same? I couldn't trigger anything to pop up on it to test with Chrome 83...

What @carsonpowers refers to is displayed in the lower left hand corner of the screen.

@carsonpowers: First of all, yes, NVDA used to read behind modal web dialogs that missed to properly trap the focus. The identified scenario have been fixed, and you'd be welcome to point out a remaining faulty one. Nevertheless, in the example you provide, NVDA isn't doing anything wrong IMHO, as there isn't anything "modal" at all: The back image is even still visible as the front one is smaller. Furthermore, if you want to properly mark background elements as being hidden, you must set the aria-hidden attribute as per W3C's WAI-ARIA. For more information:

carsonpowers commented 4 years ago

@JulienCochuyt The scenario I identified is fixed in FireFox, but still occurring in chrome; I can still reproduce it in using NVDA 2020.1 in Chrome 83.0.4103.61 Chrome 85.0.4152.0

NVDA isn't doing anything wrong IMHO, as there isn't anything "modal" at all: The back image is even still visible as the front one is smaller.

Consider this: https://jsfiddle.net/sabrick/e80x6nzp/ In this example I've modified our original scenario, giving the "overlay" a proper modal role as well as solid background. The "behindImage" is now completely obscured by this modal sitting in front of it in the DOM. The user cannot click it (since the modal is in the way and will capture mouse click events). The user has absolutely no idea it's there yet NVDA still reads it out on hover. If this isn't a wrong then it at least definitely feels like it is, especially considering it seems to be causing other unexaplinable effects that were called out in the original chromium bug (i.e. 'pointer-events' being ignored)

Furthermore, if you want to properly mark background elements as being hidden, you must set the aria-hidden attribute as per W3C's WAI-ARIA.

What if a developer wants that "behind element" to be visible in the Accessibility Tree? You would had to conditionally add/remove the aria-hidden="true" attribute each time the modal pops up; if you had multiple behind elements you'd have to do it for each of them.

JulienCochuyt commented 4 years ago

@carsonpowers, Thanks for taking the time to dig further. All apologies I read your description too quickly earlier - as we indeed have had issues with "reading content behind modal dialogs", while I know understand you really mean "not announcing the top-most element in the Z-order on mouse hover", or at least "not considering the opaque background color of a div as an element in the Z-order".

Just to clarify: To my knowledge, "modal" describes the UX of a dialog, not the Z-order of an image, as described in WAI-ARIA Authoring Practices 1.1 ยง 3.9 Dialog (Modal).

The user cannot click it (since the modal is in the way and will capture mouse click events). The user has absolutely no idea it's there yet NVDA still reads it out on hover.

You are definitely right, this looks like a bug. For clarity, could you please re-title this issue something like "On mouse hover, NVDA reads behind an opaque overlay in Chrome" @michaelDCurran, @jcsteh, could you please help point out which of NVDA or Chrome is misbehaving here - given the expected behavior is observed in Firefox?

Furthermore, if you want to properly mark background elements as being hidden, you must set the aria-hidden attribute as per W3C's WAI-ARIA.

What if a developer wants that "behind element" to be visible in the Accessibility Tree? You would had to conditionally add/remove the aria-hidden="true" attribute each time the modal pops up; if you had multiple behind elements you'd have to do it for each of them.

Yes. If you consider - as you should - not only mouse navigation but also keyboard navigation and AT-specific navigation, you indeed would have to.

jcsteh commented 4 years ago

With respect to z-order and hit testing, that's a browser issue. I know Chrome does have some issues in this area.

That said, the situation with modal semantics is not well defined at the moment. There's aria-modal, but as far as I know, the spec doesn't require browsers to hide elements outside of the modal for the purposes of hit testing.

Adriani90 commented 3 months ago

This is not reproducible anymore with NvDA 2024.3 Beta on Chrome Canary 128. I am closing as works for me. if you are still having this issue, please comment with a working minimal test case and we can reopen.