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)
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
Comment 2•7 years ago
|
||
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)
Comment 3•7 years ago
|
||
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
![]() |
||
Updated•7 years ago
|
Flags: needinfo?(jmathies)
![]() |
||
Updated•7 years ago
|
Whiteboard: aes+
Comment 4•7 years ago
|
||
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.
Comment 5•5 years ago
|
||
Are we still tracking this issue?
Has Regression Range: --- → no
Has STR: --- → yes
status-firefox73:
--- → affected
status-firefox74:
--- → affected
status-firefox75:
--- → affected
Flags: needinfo?(mzehe)
Comment 6•5 years ago
|
||
Jamie, do we? Any actions you think can be performed here? What priority?
Flags: needinfo?(mzehe) → needinfo?(jteh)
Comment 7•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
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.
status-firefox76:
--- → affected
Updated•5 years ago
|
Updated•2 years ago
|
Severity: normal → S3
Comment 9•13 days ago
|
||
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.
Description
•