New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 621510 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Inline choice expands, but loses keyboard focus when options selected using the up/down arrow and then hit enter

Reported by james.se...@pearson.com, Jun 20 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36

Steps to reproduce the problem:
1. Generate user for test/form# - "clab7" published to test87, refqc 
2. Bring up JAWS17 on win7 
3. Login to test87 on desktop or on chrome browser 
4. Start the test and navigate to section 2, question 1 
5. Tab to inlinechoice and select the options using the down arrow key as expected 
6. Still on the inlinechoice, hit enter key => inline choice expands as expected 
7. Now, arrow up or down key => Notice, at this point jaws looses the keyboard focus and starts reading the content on the screen while inline choice dropdown expanded. 

What is the expected behavior?
Expectation would be for JAWS to be able to arrow up/down within the inline choice when enter key pressed. 

What went wrong?
jaws looses the keyboard focus and starts reading the content on the screen while inline choice dropdown expanded. 

Did this work before? N/A 

Chrome version: 51.0.2704.84  Channel: stable
OS Version: 7
Flash Version: Shockwave Flash 21.0 r0

You can try it here:
http://nextgen-styleguide.elasticbeanstalk.com/choice-inline.php?hidemeta
 
Sorry for the mess on the steps to reproduce. Here is a clearer list:

Go here
http://nextgen-styleguide.elasticbeanstalk.com/choice-inline.php?hidemeta
Tab to select and select the options using the down arrow key as expected 
Still on the select, hit enter key => select expands as expected 
Now, arrow up or down key => Notice, at this point jaws looses the keyboard focus and starts reading the content on the screen while select dropdown expanded.

I would expect it to read the options. 

Any updates on this?
Owner: nek...@chromium.org
Status: Available (was: Unconfirmed)
Summary: Inline choice expands, but loses keyboard focus when options selected using the up/down arrow and then hit enter (was: Inlinechoice expands, but loses keyboard focus when options selected using the up/down arrow and then hit enter)
If the select you are talking about is the one that says:
"Made glorious summer by this sun of York; combo box"
Then, I can't reproduce with Chrome 59 and Jaws 18.

The dropdown has the below options 

Choose...
Glouster
Lancaster
York

When the dropdown has the focus, hitting enter key expands the menu and when arrowed down to Glouster for example, JAWS loses the keyboard focus and starts reading text other than the above listed options. 

Hope this helps. 
Status: Started (was: Available)
Pressing enter doesn't work with NVDA but works with Jaws. Only escape works with NVDA.
To clarify, using NVDA and a standard <select> element, use Browse Mode to get to the combo box, press enter to switch to Focus Mode, use down arrow to select an option and press enter to select it and return to Browse Mode.
Observe that enter doesn't work and that only escape and tab do.

Status: ExternalDependency (was: Started)
This doesn't appear to be a Chrome bug. Same behavior is observed in Firefox. Reported to NVAccess and waiting for a response.

Comment 9 by nek...@chromium.org, Dec 11 2017

Labels: a11y-secondary
Project Member

Comment 10 by bugdroid1@chromium.org, Feb 13 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b3051fc65687ffb51c95ce85c8f355ac23dfb046

commit b3051fc65687ffb51c95ce85c8f355ac23dfb046
Author: Nektarios Paisios <nektar@chromium.org>
Date: Tue Feb 13 20:53:25 2018

Stops exposing the active descendant if thecombo box is not focused

This gets around the problem whereby NVDA gets confused when it tries to retrieve the focused item right after it calls accSelect(SET_FOCUS) on a combo box and it gets back the active descendant instead of the combo box.
1. NVDA calls accSelect(SET_FOCUS) on the combo box when the user press enter while the virtual cursor is on the combo box.
2. NVDA switches to Focus Mode and tries to retrieve the focused object.
3. Since Blink's focus action is asynchronous, the focus hasn't yet been set to the combo box, so active descendant would return nullptr.
R=dmazzoni@chromium.org, aleventhal@chromium.org

Bug:  621510 
Change-Id: Icd7e925ced6a456ff6c99e76eddff8cce9caa85a
Tested: manually with Jaws and NVDA
Reviewed-on: https://chromium-review.googlesource.com/833153
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536467}
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/shell/test_runner/web_ax_object_proxy.cc
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/shell/test_runner/web_ax_object_proxy.h
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/test/data/accessibility/event/menulist-focus-expected-mac.txt
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/test/data/accessibility/event/menulist-focus-expected-win.txt
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/test/data/accessibility/html/action-verbs-expected-blink.txt
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/test/data/accessibility/html/modal-dialog-closed-expected-blink.txt
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/content/test/data/accessibility/html/select-expected-blink.txt
[add] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/third_party/WebKit/LayoutTests/accessibility/native-select-activedescendant.html
[modify] https://crrev.com/b3051fc65687ffb51c95ce85c8f355ac23dfb046/third_party/WebKit/Source/modules/accessibility/AXMenuListPopup.cpp

Cc: aleventhal@chromium.org
Components: -UI UI>Accessibility
Status: Started (was: ExternalDependency)
After discussing with NVAccess:
NVDA fires a |DoDefaultAction| on the selected option. We should deliver this to the <select> element causing it to close. NVDA doesn't send the enter key through.
In other words, |DoDefaultAction| on an option should not only select it but should also close the combo box.

More changes that should be made to Chrome may include:
1. NVDA gets confused if focus moves to an option when the combo box is still closed. If the combo box hasn't expanded visually, then focus should stay on the combo box itself and not move to any of its descendants. Similarly, only the value changed event should be used to tell NVDA that the selected item has changed, when the user uses up / down to move through a collapsed combo box.
2. Only after the combo box expands, using Alt+Down, should the focus move to the selected option in the combo box. Unlike when the combo box is collapsed, focus and selected changed events should fire every time the selected item changes while the combo box is expanded.
You can repro with NVDA and any <select size=1> if you use Alt+Down arrow to open, rather than Enter or space.
Cc: -aleventhal@chromium.org nek...@chromium.org
Owner: aleventhal@chromium.org
Project Member

Comment 15 by bugdroid1@chromium.org, Aug 15

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/323b3ec67ab876f190ca4f0a1738e5813a48bb16

commit 323b3ec67ab876f190ca4f0a1738e5813a48bb16
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Wed Aug 15 19:59:13 2018

Normalize <select> focus events with other accessibility implementations

When a <select size=1> receives focus, a focus event should be fired on
the combobox/menupopupbutton object.

When the value changes in a collapsed state, only the value change event
should be fired, but not a focus or activedescendantchanged event.

When the value changes in an expanded state, then the focus and/or
activedescendantchanged events can be fired.

This fixes some strange behavior with NVDA when Alt+Down is used to open
the select.

Bug:  621510 
Change-Id: I30fd744157ecbb5180d5c77f2713a73fa168397a
Reviewed-on: https://chromium-review.googlesource.com/1175034
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583367}
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/browser/accessibility/browser_accessibility_manager.cc
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/browser/accessibility/dump_accessibility_events_browsertest.cc
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-collapse-expected-win.txt
[add] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-collapse-next-expected-mac.txt
[add] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-collapse-next-expected-win.txt
[add] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-collapse-next.html
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-focus-expected-mac.txt
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/content/test/data/accessibility/event/menulist-focus-expected-win.txt
[modify] https://crrev.com/323b3ec67ab876f190ca4f0a1738e5813a48bb16/ui/accessibility/ax_event_generator.cc

Status: Fixed (was: Started)

Sign in to add a comment