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

Issue 760352 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

[Accessibility] TalkBack does not navigate backwards in tab order through a webview

Reported by raharris...@gmail.com, Aug 29 2017

Issue description

Steps to reproduce the problem:
1. Open an app that has a webview with native content before and after in the tab order (the Amazon shopping app fits this description, or I have a demo here: https://github.com/RAHarris/webview-layout-example)
2. Turn on TalkBack
3. Use TalkBack's swipe to navigate forward through the webview and to the native content after
4. Still using TalkBack's swipe, navigate back to the webview again

What is the expected behavior?
Navigating "backwards" into the webview should start at the end of the tab order for that webview to match the native behavior

What went wrong?
TalkBack picked up the webview as a whole and skipped over the entire thing, meaning that if you navigate through the whole app the tab order went something like this: A-> B-> C-> D-> E-> F-> G-> F-> B-> A.

The attached video shows this with the movement of the green outline

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 60.0.3112.107  Channel: stable
OS Version: 6.0.1
Flash Version:
 
2017_08_29_15_31_53.mp4
2.1 MB View Download
Components: UI>Accessibility Mobile>WebView
Cc: paulmiller@chromium.org gsennton@chromium.org dmazz...@chromium.org
Status: WontFix (was: Unconfirmed)
raharris001@gmail.com, has this ever worked on Android? AFAICT this is working as intended:

both when we navigate to WebView either by a 'next' swipe, or a 'previous' swipe, WebView (or rather the AccessibilityNodeProvider returned by WebView) receives the Accessibility event ACTION_ACCESSIBILITY_FOCUS - so WebView itself doesn't know whether the swipe causing us to focus on WebView was a backwards ('previous') swipe, or a forwards ('next') swipe. So all that happens in this scenario is that WebView is focused. Now, if you swipe 'next' we will step into WebView because WebView receives a ACTION_NEXT_HTML_ELEMENT event, this will happen regardless of whether the last swipe was a backwards or forwards swipe.

cc'ing dmazzoni@, and paulmiller@ in case I've interpreted this incorrectly.


I'm closing this as working as intended - if you think this is wrong, please reply on this bug (or open a new one if you can't touch this one).
So basically, you can see the hierarchy as:

<TextView> </TextView>
<WebView>
    <h2>Title</h2>
    <div>Using a webview to present some information</div>
    ...
</WebView>
<TextView> </TextView>

to me it makes sense that swiping backwards from the second TextView puts the focus on the WebView - you can then reach into the WebView's html elements by swiping forwards.

Sign in to add a comment