3

I have a WebView in my Android app but when TalkBack is enabled, it focuses on the entire view and the user has to swipe to the next item to begin hearing the WebView content. Is there any way to skip the selection of the WebView and jump to straight to selecting the content?

owenlejeune
  • 135
  • 1
  • 7
  • In the future, it will be helpful to see what you have done (even if you create a toy project) and what you have already tried. Please consider reading https://stackoverflow.com/help/how-to-ask. – Quintin Balsdon Jun 20 '21 at 09:54

1 Answers1

3

I don't think so, after giving this a try (see below). At least not for now (I think you should consider lodging an issue on Google's IssueTracker, but you will need to provide them with more details). The best you might do is assign the Role attribute to something else, or maybe set the ContentDescription, but I had no luck with these either.

After looking at this problem for a while. I think the main reason that Google has not catered for this is that perhaps users should be aware that a WebView is in use (a possible dig at Web-based cross platform?).

The main issue here is that you're trying to hide something from accessibility users, and programmatically change focus when it's not necessary. The WCAG guidelines 3.2.1 "On Focus" state:

No contextual changes that can disorient anyone should occur from focusing on any element in the interface (e.g., opening a modal window) without direct confirmation (e.g., a confirmation button).

Why this is important is that when a user navigates a WebPage, they enter into a new "mode" of navigation which may differ slightly from the native Android experience. It could be disorienting for the user if they are unaware that they are navigating web content. That's a pure guess though, I'm just a developer not an accessibility expert.

Below is a little of what I tried when looking into the problem.

I created a WebView inside a layout and was able to replicate the behaviour you mention:

<WebView
    android:id="@+id/webView"
    android:layout_width="match_parent"
    android:layout_height="200dp"
    tools:ignore="WebViewLayout" />

And initially I tried android:importantForAccessibility="no" but that meant the entire view and children were skipped.

So I attached an AccessibilityDelegate to the WebView and made some logs to all the possible events to see which one fired on focus, and the only one that fires every time is onInitializeAccessibilityNodeInfo:

override fun onResume() {
    super.onResume()
    ViewCompat.setAccessibilityDelegate(webView, a11yDelegate)
}

val a11yDelegate = object:AccessibilityDelegateCompat() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View?,
        info: AccessibilityNodeInfoCompat?
    ) {
        log("a11yDelegate", "a11yDelegate onInitializeAccessibilityNodeInfo")
        //Now we know focus has occurred
        super.onInitializeAccessibilityNodeInfo(host, info)
    }
}

But I also noticed that this is fired when the "sibling" elements are focussed, as well as when the child elements are focussed. This is TalkBack's method of preparing itself for navigation. It's also a cautious reminder that there is the concept of focus direction when highlighting a component. If you are going to bypass the webview, are you going to automatically select the FIRST element or the LAST element? (Assuming of course you can find the elements and assign them focus).

There is another issue: time to load. If the WebView is delayed in reading the content, are you going to indicate that the user needs to wait? If there is a loading animation / announcement, there are a whole load of complexities to consider there, like ensuring users can turn off animations, and that it doesn't just announce "Loading" but what is being loaded, and that users are kept informed if it takes a long time to load...

Quintin Balsdon
  • 5,484
  • 10
  • 54
  • 95
  • 1
    Great answer! Thanks for investigating this. In our case we are using a Webview to render HTML that is a copy/paste from our website, so even though it's a Webview it shouldn't look like it to the user. It would be nice if we could just disable the Talkbalk Webview announcement, but I guess our only option is to convert our Webview to other native components. – Mitch Downey Sep 05 '21 at 06:02