Talkback screen reader can't read some messages

[coppelletti]

Checklist

• I have used the search function to see if someone else has already submitted the same bug report.
• I will describe the problem with as much detail as possible.

App

Thunderbird for Android

App version

8.1

Where did you get the app from?

Google Play

Android version

14

Device model

Samsung Galaxy A54

Steps to reproduce

1. open Thunderbird with Talkback enabled; 2. open a message; 3 swipe to the right 9-10 times to move the focus to the web views which containse the text of the message. Sometimes the screen can't read the message and announces "no next default element".

Expected behavior

The screen reader should read the text of the message like in other apps.

Actual behavior

The screen reader says: "no nex default element".

Logs

I am a blind Android user on a Galaxy A54 with Android 14. It happens that when scrolling through an open message with the appropriate gestures of the Talkback screen reader, the text content in the web view is sometimes not spoken. The screen reader announces something like: "no next default element". This happens both when using swipes to move to the next element or paragraph, and when using the continue reading command. A sighted person told me that in some messages, when this problem occurs, a few characters per line or one or two words are shown. The problem occurs sometimes when opening messages one at a time, other times when scrolling to the next message with two fingers, but having disabled the Thunderbird scrolling gestures. Sometimes, but not always, closing the message and reopening it is possible to read it. I have not detected a regularity in the occurrence of the problem or even a specific type of message in which this happens more frequently, except perhaps the very long ones. It can happen that I can read many messages before the screen reader can't read the content, but sometimes it's two or three messages in sequence that aren't read. The other parts of the screen in a message are read correctly and it's only the web view that gives problems. The app is very good for me and could replace the others I use as an alternative, but unfortunately I can't rely on it for now. I hope it can be solved even if I'm not sure I've provided enough information. Thanks.

[kewisch]

Thank you for letting us know. If you swipe back and forth, is it always the same message that does not work? Or is it just every 9-10 messages where it randomly does not work?

[louderpages]

I offer this comment in case it is helpful in pointing to this report being a more general, non-Thunderbird one.

I am involved in the development of another Android App and its interaction with the TalkBack screen-reader.

We observe that when our App launches a webview, there is some chance (perhaps 20% ) that TalkBack regards the webview as empty. (On my Samsung phone, TalkBack says "No next default", whereas on another, Nokia phone, it is completely silent.)

We assume that this is the result of some Race Condition and are investigating on that basis.

We fear that sometimes the content is not loaded before TalkBack examines and builds some accessible map of the page. And, that TalkBack does not look again once the page completes loading.

We want to try to have the webview complete loading of is content BEFORE making it available to TalkBack. Or, to find some method of calling on TalkBack to re-examine the web-view content once it has completed loading (and, indeed if it refreshes its content with a page-reload - something our App does and which causes TalkBack to lose track of the webbview content internals).

Hope this helps.

[kewisch]

@louderpages This is great context, thanks for sharing your expertise! I'm very interested to hear the results of your experiments, do let us know what you find. Your explanation sounds very plausible.

[louderpages]

Hi. @kewisch and @coppelletti. More findings, but no solution for you. There seems to be one or more bugs related to Android Chrome's tracking of the accessibility focus for screen-readers. There are two features, and they seem like they might stem from different bugs.

First feature is the screen-reader reporting an empty web-page. We find this both in Chome Web-views and in the stand-alone Chrome Browser. It seem to occur only on a page refresh. This discounts the race condition theory based on http request delay.

One of our team came across this in Gmail on her Android phone. Perhaps it had happened before but now she was aware of this bug.

The second. more insidious bug is where parts of the page were not found by the screen-reader. Onlyy parts. Without visual comparison, a screen-reader user will be unaware of this. Very dangerous. Connected with this is that sometimes those parts disappear and re-appear without a page reload.

We have a couple of logged error messages but then there are hundreds of Android error messages logged every second on a phone.

I have never submitted a bug report to Chrome - any advice?

Also, would a Thunderbird bug report provoke more attention?

[kewisch]

For the case of a blank page appearing, one thing I've seen in the past on Desktop is that when pages load, the browser sometimes points to about:blank for a short moment before the actual page loads. If something similar is happening on mobile (though of course that is completely different code), then it could be the screen readers is picking up the about:blank state. I'm not sure about the partial content though, this would seem more like something is not waiting for page load to complete, or there are dynamic updates of sorts.

I don't think filing a Thunderbird Desktop bug would help here, for Android you already have the right repo. I've not yet filed a Chrome bug either, I'd just give it a try and see how far you get. Try to reduce the problem as much as possible so they don't just refer back to Thunderbird and it gets stuck in between.