0

Background: When focused on a WebView control, TalkBack announces something to the effect of "Bing. WebView. Double tap and hold to long press" (note that focus is on the WebView control itself, not the content within the webview). However, as best I can tell, double tap and long pressing doesn't seem to do anything other than pass TalkBack focus into a control within the WebView itself. Our team has testers that specialize in accessibility which filed a bug on us for this "Double tap and hold to long press" announcement. The rationale within the bug states that since this action doesn't appear to do anything, the announcement will only serve to confuse TalkBack users.

This announcement doesn't appear to be specific to our app as I was able to reproduce this behavior on a new, blank Android app with a WebView that points to Google (there it announces "Google. WebView. Double tap and hold to long press"). As I think it helps show what focus I'm talking about, I have added a screenshot of the prototype app I built with the green TalkBack focus indicator below:

Android app with TalkBack focus shown on WebView.

Questions:

  1. Is there a reason for why Android insists on announcing the "double tap and hold to long press" piece for a WebView? If there is a functional reason for this, then any attempt to fix this issue may be moot.
  2. Does anyone know of a way to stop TalkBack from reading the "double tap and long press"? Alternatively, is there a way to hide the WebView control itself from TalkBack without hiding the html content within?

What I've tried: Unfortunately saw no luck setting isLongClickable to false, setting empty onLongClickListeners, and worked with a few of the suggestions in the stackoverflows here, here, here, and here. I tried all of the mentioned changes on a blank app to reduce the possibility that the complexities of our production app has interfered with the experiments I was running. Setting the ImportantForAccessibility field to "No" hides all of the inner html of the webview from Talkback so that is not an option either.

Sidenote that I find interesting: in my experimentation, I also tried setting the WebView's isClickable property to false and yet it was still clickable. So I am wondering if I am possibly focusing on setting properties on the wrong control (or if Android just completely ignores those properties on a WebView control).

evve
  • 2,806
  • 2
  • 14
  • 11
  • pretty sure this is standard behaviour for any webview, in the past I have tested a few apps (even though I am primarily web) and always seem to get that announcement from what I remember. If that is the case (every webview announces “Double tap and hold to long press”) then **do nothing** - expected behaviour is key for accessibility. Perhaps someone who tests android apps can confirm this is the case as I am a) working from memory and b) only tested a handful of apps. If it is indeed baked in functionality it is so that users can access context menus / select text. – GrahamTheDev Jan 11 '21 at 19:15
  • Thanks @GrahamRitchie. Yep, as mentioned in the question, it does appear that this is standard behavior with WebViews. It doesn't appear that there is a context menu/text to select on the WebView control itself. Hence the Question #1 about whether there is a functional reason behind this. I agree that when it comes to accessibility, always going with the system defaults is ideal. However, in this instance, the system defaults appear to be giving guidance that there is functionality available to the user that does not exist. – evve Jan 11 '21 at 22:33
  • 1
    If this is the same behaviour for all webviews then leave it alone, doesn't matter if we think it is a good announcement it is expected behaviour, which is more important (to avoid confusion). I would imagine it is to explain that long press is an option on the webview as the page contains text that can be selected. It would be interesting that if the webview contained a page with `role="application"` if the same behaviour exists (as with `role="application"` all functionality is developer controlled so default behaviours should technically not exist, a fun experiment for someone to try.) – GrahamTheDev Jan 11 '21 at 23:03

0 Answers0