New issue
Advanced search Search tips

Issue 761857 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

Auto-fill menu steals accessible focus

Project Member Reported by ja...@nvaccess.org, Sep 5 2017

Issue description

Chrome Version: 63.0.3205.0 (Official Build) canary (64-bit)
OS: Windows 10 Version 1703 (OS Build 16251.0) 64-bit

What steps will reproduce the problem?
(1) Open Chrome and the NVDA screen reader.
(2) Oepn this URL: data:text/html,<form><input type="text" name="zzz"><input type="submit"></form>
(3) In the text box, type "zzz".
(4) Press Submit.
(5) In the text box, type "z".
Expected: NVDA should just report the letter you typed (or nothing if you have speak typed characters disabled).
Actual: NVDA reports "Auto-fill menu".
(6) Press left arrow to move to the previous character.
Expected: NVDA should report "z".
Actual: NVDA reports nothing.

When the auto-fill menu appears in (5), a menu start event is fired. NVDA maps this to a focus event, since this event means that the menu is now handling input as far as the user is concerned (as is the case for context menus, etc.). This effectively takes focus away from the text box as far as accessibility is concerned.

This event should only be fired if the user performs an explicit action to interact with the menu; e.g. pressing down arrow. It should not be fired simply due to typing.

It's worth noting that this menu is also broken in other ways; e.g. there is no indication of the active item. That might need to be field as a separate issue.

Impact: It is very disruptive when a user is trying to fill in a form and this menu appears.
 
Owner: nek...@chromium.org
Status: Available (was: Untriaged)
Chrome 63.0.3212.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 10.0.14393 Build 14393.1593
NVDA 2017.3 
JAWS 2018 Beta 
Firefox 55.0.3 (64-bit)

Hi Jamie,

Thanks as always for reporting this. I am able to reproduce the issue using your above steps. 

Chrome + NVDA, can repro. 

Firefox + NVDA, cannot repro. Letter Z (zed) read as expected after autofill. 

Chrome + JAWS, cannot repro. Letter Z read as expected after autofill.

Owner: ----
Labels: win-a11y

Comment 4 by nek...@chromium.org, Dec 15 2017

Labels: editing
Labels: -Pri-3 Pri-1
Owner: dmazz...@chromium.org
Owner: aleventhal@chromium.org
Status: Started (was: Available)
Project Member

Comment 8 by bugdroid1@chromium.org, Mar 5 2018

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

commit 84d400ad83a8c81d29db85700573adcdeea34b1b
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Mon Mar 05 20:01:10 2018

Improve autofill accessibility semantics and events

Fix a number of autofill issues with screen readers, including:
- Left/right arrow in textfield not reading chars when autofill visible
- Nothing read for up/down arrow in autofill
- Positional n/m (posinset/setsize) info not provided with entries

Bug:  761857 
Change-Id: I0052fa2edf2dd1d68d2cbf5ec039ae89423f4c14
Reviewed-on: https://chromium-review.googlesource.com/947748
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540907}
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/chrome/browser/ui/views/autofill/autofill_popup_view_views.cc
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/chrome/browser/ui/views/autofill/autofill_popup_view_views.h
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/accessibility/platform/ax_platform_node.cc
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/accessibility/platform/ax_platform_node.h
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/accessibility/platform/ax_platform_node_base.h
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/accessibility/platform/ax_platform_node_win.cc
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/views/accessibility/native_view_accessibility_base.cc
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/views/accessibility/native_view_accessibility_base.h
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/views/accessibility/native_view_accessibility_win.cc
[modify] https://crrev.com/84d400ad83a8c81d29db85700573adcdeea34b1b/ui/views/accessibility/view_accessibility.h

Labels: a11y-testers
Status: Fixed (was: Started)
Testers, the autofill experience should be very good overall now.
Notes on what changed:
1. There was a menustart event that was fired as soon as autofill showed up
this confused NVDA regarding the current textfield's focus. Now it only fires the menustart once the first item gets focused from down arrow.
2. In addition, nvda did not read the names of the items in the autofill menu when you pressed down arrow, as we were firing selection events instead of focus, which it ignored
3. Next, I added positional "n of m" information to each item in the autofill list
so that the user could hear where they were in the list
4. Finally, there are separator items that can show up in the list. I marked them with the correct role and as unfocusable
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 7 2018

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

commit a736aec54a12991950552471dda7ab3127fe58cb
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Wed Mar 07 04:49:51 2018

Include autocomplete semantics for autofill textfields

In addition to the HASPOPUP state, expose autocomplete semantics for
autofill fields, including IA2_STATE_SUPPORTS_AUTOCOMPLETION and
the "autocomplete:list" object attribute.

This allows NVDA to read "has autocomplete" instead of just "has popup",
which is a slightly better experience. JAWS does not currently say
anything different in this situation.

Bug:  761857 
Change-Id: I2372e6bd0cc07cf63cdce7553fd70e908d57608b
Reviewed-on: https://chromium-review.googlesource.com/952242
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541348}
[modify] https://crrev.com/a736aec54a12991950552471dda7ab3127fe58cb/ui/accessibility/platform/ax_platform_node_win.cc
[modify] https://crrev.com/a736aec54a12991950552471dda7ab3127fe58cb/ui/accessibility/platform/ax_platform_node_win.h

Labels: TE-NeedsTriageFromHYD
Unable to reproduce the issue on Win-10 pro edition using chrome reported version #63.0.3205.0 as per comment #0. Observed that NVDA reported the letter typed i.e Z.
Attaching screen cast for reference of reported version.

As the Windows 10 Enterprise Version is not available at ET-end. Hence, forwarding the issue to inhouse team for verifying the issue.

Thanks...!!



761857.webm
2.2 MB View Download
Cc: jmukthavaram@chromium.org
Labels: -TE-NeedsTriageFromHYD Needs-Feedback
Unable to reproduce the issue on Win-10 Enterprise edition using chrome reported version #63.0.3205.0 as per comment #0. Observed that NVDA reported the letter typed i.e Z.
Attaching screen cast for reference of reported version and let us know if we miss anything from our end to verify this issue.

Note:No issue observed on latest Canary#67.0.3365.0 also.

Thanks...!!
761857-WIN 10.webm
2.5 MB View Download
Labels: -Needs-Feedback -a11y-testers
Status: Verified (was: Fixed)

Sign in to add a comment