New issue
Advanced search Search tips

Issue 769940 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature
Team-Accessibility



Sign in to add a comment

[A11y] Autoscroll PDFs when reading with Screen Reader

Project Member Reported by leberly@chromium.org, Sep 28 2017

Issue description

Chrome 63.0.3226.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 10.0.14393 Build 14393.1715
JAWS 2018.1709.17 Private Beta

What steps will reproduce the problem?
(1) Open a PDF in Chrome such as this one: http://files.accuvant.com/web/files/AccuvantBrowserSecCompar_FINAL.pdf 
(2) Start JAWS or screenreader of choice 
(3) Start to read, for example, press h to navigate by heading and then use the arrow keys to navigate down after the heading 
(4) Compare what's on the screen to what's being read by the screenreader. 

What is the expected result? The PDF auto-scrolls to line up with where the screen reader is reading. 

What happens instead? The screen reader is reading part of the PDF that is far off screen. 

 
Cc: dmazz...@chromium.org
Labels: -good-first-bug
dmazzoni: Can you help figure out what the PDF Viewer needs to do to better help screen readers here?
I think this bug is all in accessibility code.

I think it may be as simple as modifying  RenderAccessibilityImpl::OnPerformAction to call RenderAccessibilityImpl::ScrollPlugin when the action is AX_ACTION_SCROLL_TO_MAKE_VISIBLE and the id is within the plugin range.

I suspect it used to work and then accidentally broke during a refactoring.

Writing a good regression test for this would involve a combination of PDFExtensionTest.PdfAccessibility and AccessibilityActionBrowserTest.

Labels: good-first-bug
Update from Nektarios:
I think I know what's going on. If I open the PDF and wait something like a minute, the virtual buffer starts working. So the bug is with user perception, my perception in particular, and not with the virtual buffer.

Firefox doesn't have this issue. I think it starts loading the PDF and makes at least part of it available to the virtual buffer. Whilst with Chrome, one forms the impression that nothing is being loaded. After 20 seconds or so, I give up and think that the virtual buffer is broken.

We should see how to improve this. Perhaps fire a loaded event sooner, or add some text that says "Loading ...".
Cc: hnakashima@chromium.org
Labels: a11y-secondary
Project Member

Comment 6 by sheriffbot@chromium.org, Dec 17

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment