Closed Bug 1398271 Opened 7 years ago Closed 13 days ago

NVDA/JAWS screenreader reads incorrect output from selections from dropdown box when navigated with mouse/arrow keys

Categories

(Core :: Disability Access APIs, defect, P3)

57 Branch
x86_64
Windows
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox57 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- fix-optional

People

(Reporter: u554753, Unassigned)

References

Details

Steps to Reproduce: 1. With NVDA screenreader on, Navigate to http://oaa-accessibility.org/example/10 2. Focus on the combobox by clicking on the drop-down arrow 3. Press the arrow keys up and down. Expected Result: The screenreader reads the correct name of the state Actual Result: The screenreader reads "Alabama", "Alaska" and the list is expanded. This is reproducible with the following screenreaders. NVDA - 2017.3 JAWS - 18.0.4315 Example: https://ranisharma22.tinytake.com/sf/MTkyMzE0MV82MTIzMTcx
Flags: needinfo?(jmathies)
NI'ing Marco for his input.
Flags: needinfo?(mzehe)
OK, I can now reproduce this. I used the following steps: 1. Brought up the example. 2. Tabbed to the combobox. Note I could also navigate to the Application line in the virtual buffer, press Enter and then tab once to focus the combobox, but simply tabbing will do just fine. 3. Press Alt+DownArrow to drop down the combo box. This is similar to the clicking of that arrow thing, which I as a blind person cannot do. 4. Note that NVDA does not announce that the list has been expanded. Now, press DownArrow. Result: NVDA speaks "List expanded", and then "AlabamaAlaska". 5. Press up or down arrows. Result: NVDA will repeat AlabamaAlaska, but not speak the actually highlighted item.
Flags: needinfo?(mzehe)
We should fix this, but it isn't critical for the 57 release (if we make it), but should be addressed soon after. There is a workaround which is: Use the arrow keys and don't drop down the combobox.
Blocks: 1258839
Priority: -- → P2
Flags: needinfo?(jmathies)
Whiteboard: aes+
I don't think this is e10s specific. I tried this in a non-e10s window and got the same behaviour. FWIW, the reason this occurs is that the listbox is owned (using aria-owns) by the combobox. That means that the listbox is included as part of the text of the combobox. When the caret is at the end of the textbox, the caret offset ends up pointing at the embedded object for the listbox, which means that the first line of the listbox gets read. I reported this in bug 1280188 and suggested a workaround.
No longer blocks: 1258839

Are we still tracking this issue?

Has Regression Range: --- → no
Has STR: --- → yes
Flags: needinfo?(mzehe)

Jamie, do we? Any actions you think can be performed here? What priority?

Flags: needinfo?(mzehe) → needinfo?(jteh)

I updated bug 1280188 with further details on how we could solve this. That said, I don't see many complaints about this in the wild.

Depends on: 1280188
Flags: needinfo?(jteh)
Priority: P2 → P3

Can also reproduce this for the search results in the address bar but only for mouse highlights. NVDA will read the previously highlighted items from the search results, not the current one on which the cursor is placed.

Severity: normal → S3

The test case for this bug no longer exists. I'm fairly sure it should be fixed by bug 1280188 (now fixed), but unfortunately, I can't be sure without the test case.

Status: NEW → RESOLVED
Closed: 13 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.