UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Example URL:
www.google.com
Steps to reproduce the problem:
I am on Windows 10 and using NVDA 2015.4
This issue occurs on the Google homepage, but there are at least three distinct issues that I show with the attached sample.
Steps to reproduce on the Google homepage:
- open www.google.com
- type hello
- use arrow left/right to move cursor
- notice how NVDA reads each individual character (this is good)
- I get 10 suggestions showing up. They aren't really announced to the screen reader (this is somewhat bad, but not the main issue)
- press arrow down once or twice to choose a suggestion
- notice how NVDA reads each individual suggestion (this is good)
- I get "hello adele lyrics" placed in the search box
- use arrow left/right to move cursor or try to edit the suggestion
- notice how NVDA no longer reads each individual character (this is very bad)
- click somewhere else on the page
- click back in the search box
- now NVDA reads each individual character again.
What I actually want to do:
I'm working on VSCode (https://github.com/Microsoft/vscode) (https://code.visualstudio.com/). VSCode is built on Electron (https://github.com/atom/electron) that is built on Chromium. We want to make VSCode screen reader friendly.
I'm working on the text editor component. You can find a recent incarnation of it at http://www.typescriptlang.org/Playground for example (it is a few months old). I want to make the suggestion list that pops up when you press Ctrl+Space screen reader accessible.
I am really trying hard to workaround these issues, but there is only so much I can do on my side (JS) and the 3rd issue is forcing me to use aria alerts, which are probably the worst way to do accessibility.
Here are the issues:
1. aria-activedescendant is ignored when role="textbox". I think https://www.w3.org/TR/wai-aria/states_and_properties#aria-activedescendant lists that "textbox" should also have this property. Please see also https://www.w3.org/TR/wai-aria/roles#textbox. If you edit the attached sample and change the role from "combobox" to "textbox", please notice how things work the same in FF or IE, but no longer in Chrome. I have tracked this down to /src/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.cpp around line 1269: bool AXLayoutObject::shouldFocusActiveDescendant() const. but there might be other places in code. I can workaround this issue by making my <textarea> have role="combobox", which is wrong, but would work.
2. when having an aria-activedescendant the arrow left / right are not reported to the screen reader. I have noticed that all browsers have this behaviour. IMHO, this is wrong, if the text is freely-editable I think each character should be announced as cursor moves around, regardless of having an aria-activedescendant. I cannot workaround this, but let's say I can add an option to VSCode to show the suggestion only on demand and not have it pop up all the time. This would limit the impact of this issue.
3. when accepting a suggestion, the arrow left / right are not reported to the screen reader until focusing somewhere else on the page and focusing back. This works correctly in IE and FF and only fails in Chrome. I think that the problem is in src/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.cpp around line 2034: void AXLayoutObject::handleActiveDescendantChanged(). I think this method does not really handle the case when a dom node had an aria-activedescendant and the aria-activedescendant attribute has been removed. In other words, I think it handles adding or changing the active descendant, but not removing it. This issue is blocking me in using aria roles because as soon as the suggestions are shown once, the words / characters in the textarea no longer get read when using arrow keys whatsoever. This is also the issue being hit on the Google homepage.
The attached sample shows the 3 issues. Issues #1 and #3 are Chrome specific, while issue #2 happens on all browsers. Is there a reason for this (i.e. is it specified in the standard)? I think having a suggestion (active descendant) and changing the text should be possible at the same time.
What is the expected behavior?
What went wrong?
Please read above
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 48.0.2564.116 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 20.0 r0
|
Deleted:
left-right.html
3.4 KB
|
Comment 1 by dglazkov@chromium.org
, Mar 10 2016Status: Untriaged (was: Unconfirmed)