New issue
Advanced search Search tips

Issue 919900 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 17
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Screen reader does not read new button options in Drive

Reported by peter.za...@oakland.k12.mi.us, Jan 8

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce the problem:
ChromeVox does not properly read options under the New Button.  Steps to reproduce:
1.  Press letter C to jump to New Button.
2.  Press the Down Arrow to expand menu.  
3.  Press up arrow and none of the menu choices are read out loud.  
4. Press right arrow on any of the menu choices such as Google Docs and you hear nothing, but if you press right arrow, the sub menu choices such as "Blank Document" are read out loud.  

What is the expected behavior?
All menu choices should be read out loud by ChromeVox.

What went wrong?
ChromeVox does not read the New Button menu choices such as Google docs, Google Forms, Google Slides, etc in Drive.

WebStore page: 

Did this work before? Yes Do not remember exact date, but it has been broken for at least 6 months.  

Chrome version: 71.0.3578.94   Channel: beta
OS Version: 71.0.3578.94 Beta 
Flash Version:
 
To clarify, this is on a Chromebook running the Chrome Os using the ChromeVox screen reader.  My Chrome OS version is 71.0.3578.94   Channel: beta.
Labels: OS-Windows
Status: Available (was: Unconfirmed)
Summary: Screen reader does not read new button options in Drive (was: ChromeVox Drive not reading new button options)
Version 73.0.3664.3 (Official Build) dev (64-bit)
This issue repros on Chrome desktop as well.
Does not repro in Firefox (tested as of 64.0.2)

Project Member

Comment 3 by bugdroid1@chromium.org, Jan 17 (5 days ago)

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

commit 76429cf690c3b5811b7b7ee868f62b4956d3cbea
Author: David Tseng <dtseng@chromium.org>
Date: Thu Jan 17 21:11:53 2019

trigger event generation for reparented nodes on attribute changes

AXTree currently only calls |CallNodesChangedCallbacks| for nodes that were not newly created or re-created.

This would exclude calling:
1. legitimately new nodes
2. reparented nodes
3. nodes that were destroyed as a result of |nodes_to_clear|, but that are subsequently re-created. This case is really just an internal "reparent", but no reparenting occurred.

By dropping attribute changes on these types of nodes, we can and do miss attributes like active descendant change. For case 3, if the lca was some ancestor of the changed node in Blink (as the event target), we end up clearing that ancestor subtree and never computing attribute changes.

Note that the correct behavior is to trigger node callbacks on 2 or 3 (not 1).

Bug:  919900 
Change-Id: I4679b7c7b3269a5f12ab1a4e8df1a9dfd2563123
Reviewed-on: https://chromium-review.googlesource.com/c/1412485
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623843}
[modify] https://crrev.com/76429cf690c3b5811b7b7ee868f62b4956d3cbea/ui/accessibility/ax_event_generator_unittest.cc
[modify] https://crrev.com/76429cf690c3b5811b7b7ee868f62b4956d3cbea/ui/accessibility/ax_node_data.cc
[modify] https://crrev.com/76429cf690c3b5811b7b7ee868f62b4956d3cbea/ui/accessibility/ax_node_data.h
[modify] https://crrev.com/76429cf690c3b5811b7b7ee868f62b4956d3cbea/ui/accessibility/ax_tree.cc
[modify] https://crrev.com/76429cf690c3b5811b7b7ee868f62b4956d3cbea/ui/accessibility/ax_tree.h

Comment 4 by dtseng@chromium.org, Jan 17 (5 days ago)

Status: Fixed (was: Available)

Sign in to add a comment