Firefox CSS transform: element not read with mouse

[caseyjhol]

Steps to reproduce:

1. Visit https://codepen.io/caseyjhol/full/eoeEOK in Firefox (66.0.2 and 66.0.3)
2. Hover over text in the black box
3. Hover over text in the red box

Actual behavior:

Text in the black box is read aloud. Text in the red box is not.

Expected behavior:

Text in the red box should also be read aloud.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2019.1

Windows version:

Windows 10 Pro

Other questions

Does the issue still occur after restarting your PC?

Yes

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

No

[tapper82]

What is that site? If I am blind how do i know red from green? When I open that site it just says Neptunium Neptunium. What is it? Users of screen readers don't Hover over anything!

[caseyjhol]

@tapper82 Are you not familiar with the concept of a reduced test case? I've updated the colors to hopefully make it a bit clearer. Are you implying that users who are only partially visually impaired do not use screen readers? Am I to believe NVDA is strictly for users who do not use a mouse?

[Adriani90]

Here I think we need suport from some sighted people. Maybe @Qchristensen or @feerrenrut can help here.

[Adriani90]

@caseyjhol of course NVDA is also meat to allow users to use the mouse. It's just that this test case is not very intuitive for blind users. In which browser did you reproduce this?

[caseyjhol]

@Adriani90 When I initially posted, I had tested in Firefox 66. I've also tested in Firefox 75.0. I tested in Chrome also, but hovering over the text in either box doesn't work.

[feerrenrut]

This may be clear now to @caseyjhol but for the benefit of anyone else wondering about the reaction from @tapper82

While NVDA is also for mouse users, low vision users, and fully sighted users (often A11y testers). Many of the developers who contribute code to NVDA or fix bugs are blind, and will not be able to work on an issue when it is described in a visual way. In some cases a problem truly requires sight, or the use of the mouse, but most issues can be reproduced with the use of the keyboard. If not it is very useful to mention that it ONLY affects the mouse. Because most NVDA developers are blind, it is probably clear that blind friendly issue descriptions are more likely to get attention. More so, well described visual issues can often be fixed by blind developers.

This issue / test case could certainly be described better.

Quick investigation:

This issue / test case could certainly be described better. Without delving into it, it looks like this issue is related to translate3d. Here is a simpler test case: https://codepen.io/reefturner/full/vYLXaOq

Navigating by keyboard, pressing down arrow, you will hear something like:

• blue option 1
• blue option 2
out of list  list  with 2 items  • red option 1
• red option 2

Firefox 77.0.1

Hover the mouse over "blue option 1" and it is spoken. Hovering the mouse over "red option 1", and nothing is spoken by NVDA

Chrome 83.0.4103.97

None of the bullets can be read with the mouse.

[Qchristensen]

Not much to add except that I can reproduce the same as @feerrenrut using the same build of Firefox, and a very slightly newer build of Chrome: Version 83.0.4103.116 (Official Build) (64-bit)

[jcsteh]

Would someone with some sight be able to re-test this in latest Firefox release and report whether the problem persists? The recent re-architecture fixed a lot of bugs related to transforms, so this may well be fixed now.

[Adriani90]

Tested in firefox:

1. Routing the mouse with nvda+shift+m (laptop keyboard layout) to blue option 1: NVDA routes correctly the mouse to the blue option and reads it.
   • Once routed to the blue options, moving the mouse physically does not read the red options.
2. In contrast, when routing the mouse with nvda+shift+m to a red option, NVDA reads it as expected
   • However, then it doesn't read the blue options when moving the mouse physically.

In chrome:

1. Routing the mouse with nvda+shift+m (laptop keyboard layout) to blue option 1: NVDA does not route the mouse to the blue option as expected
2. Moving the mouse physically does not read the options, I hear only "list, list item" etc.
3. Clicking with the left mouse click on a list item: NVDA reads both options in that list (e.g. blue option 1; blue option 2)
4. At this stage navigating with object navigation it seems "blue option 1; blue option 2" became a label for the parent object of the blue options list items, so NVDA announces both options at once
5. Navigating with object navigation further to the right, the parent of the red options where no click event was performed is only "list"
6. Clicking on the list item with the red options: the parent of the list items becomes "red option 1; red option 2" and the parent of the blue options becomes "list"

In Chrome, moving the mouse physically does not read any of the options.