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

Issue 823008 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Mar 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

a11y: Screen reader not reading the zoom percentage when changing zoom level in the Chrome menu

Project Member Reported by leberly@chromium.org, Mar 17 2018

Issue description

Google Chrome	67.0.3372.1 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version
NVDA 2018.1
JAWS 2018.1803.38 64-bit English 

This bug came in from a vendor. Steps to repro:

# Launch screen reader
# Navigate to the Customize and Control Chrome menu 
# Navigate to the Zoom section of this menu 
# Press plus or minus 
Expected: percentage announced
Actual: percentage not announced
 
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1bcb2e391be97cd6542acd433a210a47a337771e

commit 1bcb2e391be97cd6542acd433a210a47a337771e
Author: Nektarios Paisios <nektar@chromium.org>
Date: Mon Mar 12 22:42:14 2018

Makes zoom buttons in Chrome main menu accessible to Jaws and NVDA

Screen readers now announce the correct role for the zoom in and zoom out buttons and also announce the zoom level if changed.
Announcing that these controls are buttons sends a signal to screen reader users that the menu will not close when these controls are activated.
The drawback is that the word "Alert" is prepended to the announcement of the new zoom level.

R=aleventhal@chromium.org, pbos@chromium.org

Bug:   779304  
Change-Id: Ie078d63c318a70fa64db268ac748dc2700995f55
Tested: Use zoom in and zoom out while Jaws and NVDA are running
Reviewed-on: https://chromium-review.googlesource.com/957902
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542636}
[modify] https://crrev.com/1bcb2e391be97cd6542acd433a210a47a337771e/chrome/browser/ui/views/toolbar/app_menu.cc
[modify] https://crrev.com/1bcb2e391be97cd6542acd433a210a47a337771e/ui/accessibility/platform/ax_platform_node_win.cc
Labels: dialogs win-a11y
Note, the above commit is pasted in from another bug. The commit itself has the wrong bug number in it but applies to this bug. 

Update from Nektarios: 
Now, whenever the zoom level changes while using the plus or minus button in the menu, the new zoom level is announced by an alert.
Cc: -nek...@chromium.org
Labels: JAWS-specific
Owner: nek...@chromium.org
Status: Assigned (was: Available)
Reverting to Nektarios as not fixed due to JAWS behavior below. Please be sure to update your commit above using this new bug number 823008. 

Google Chrome 67.0.3372.1 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607
JAWS 2018.1803.38 64-bit English 
NVDA 2018.1  

# Launch screen reader
# Navigate to the Customize and Control Chrome menu 
# Navigate to the Zoom section of this menu 
# Press plus or minus 
Expected: percentage announced
Actual:

With JAWS the time it takes to read the contents of the alert is too long. It's reasonable that a user would want to press the plus or minus several times in a row and then the user only hears "alert" several times. After the last alert is mentioned, there is a pause of a few seconds before the percentage is read. 

With NVDA there is no problem, the percentage is announced right away and doesn't contain the word "alert" before it. 

We may need to resolve this bug and open another one for the JAWS alert slowness issue on its own, please let me know if you'd like me to do that by adding label a11y-testers. 

Comment 4 by nek...@chromium.org, Mar 29 2018

Labels: a11y-testers
Status: Fixed (was: Assigned)
Unable to reproduce Jaws slowness.
Status: Verified (was: Fixed)
I am deciding that this no longer repros because I am using a voice that is slower/less responsive in general than Eloquence. Therefore, it would be the user's prerogative to choose a more or less responsive voice. Since it is indeed spoken, I'm going to verify this bug. 
Labels: -a11y-testers

Sign in to add a comment