Description

If a message is deleted with Shift+Delete, the screen reader does not announce the next message. The strange thing about this is that it occurs from the second time Shift+Delete is pressed.

I was able to reproduce this behavior with JAWS, how other screen readers behave I do not know.

Steps to reproduce

Note: Thunderbird should be set to not ask to delete messages every time Shift+Delete is pressed.

1. Go to the message list where there are more than two or three messages and where you are ready to delete them permanently.
2. Now press Shift+Delete once to permanently delete the selected message and then press Shift+Delete again to permanently delete the next selected message.

Result

Pressing Shift+Delete the first time selects the next message and JAWS announces it as expected. If you press Shift+Delete again, nothing is announced.

Expected

Each time Shift+Delete is pressed, the next selected message should be announced, as in previous versions (up to version 111).

I Mean Thunderbird 110 not 111.

Hello,
When the deletion has to be confirmed with a dialog this is not a problem.
This can also be easily reproduced when moving messages to the trash by pressing the delete key alone.

Steps

• Open Thunderbird, navigate to a folder where you have test messages so deleting them is not a problem for you and focus the message list by pressing F6 or shift+F6.
• Press the delete key, observe how the message you were on before pressing the delete key has dissapeared, message below received the focus and your screen reader reported the item that has received the focus.
• Now press the delete key again and observe the results.

Actual

By repeatedly pressing the delete key selected message is moved to the trash however only the first press of the delete key causes assistive tools to know which item received the focus as a result of the delete action.

Expected:

It would be nice if screen readers were notified to the fact new item became selected and received the focus.
I made sure new messages are being selected because pressing enter key to open or shift+F10 to bring up a context menu is working in such a state.

Confirming based on two independent user reports.

Elizabeth, if you have time to try, do you see this happening as described?
Would you agree that this constitutes a pretty serious regression for screen-reader access dependent users?

Tentatively setting P2 to keep this on the agenda.

Geoff recently made some changes in bug 1823637 that might affect this.

I will test Delete and Shift+Delete today and send an update.

I can still reproduce this with Thunderbird 114.0a1 (2023-04-18) (64-bit version).
I am afraid this might be dangerous for less experienced computer users relying on assistive tools as by repeatedly pressing the delete key messages are being moved into the trash but user has no idea which messages.

Unassigning myself, but will test this.

(In reply to Thomas D. (:thomas8) from comment #3)

Confirming based on two independent user reports.

Elizabeth, if you have time to try, do you see this happening as described?
Would you agree that this constitutes a pretty serious regression for screen-reader access dependent users?

Tentatively setting P2 to keep this on the agenda.

I still need to test this.

Yes, this is a significant regression.

Hi,

I am confirming this is broken as described for Delete. This probably works the same as Shift + Delete if you do not have a confirmation dialog to confirm deletion. This happens for the second item and next items that are deleted after the first deletion.

More info about results

I just tested this with the most recent daily on Windows 11 using NVDA.

Using Shift + Delete, I am not able to duplicate. I have a confirmation dialog before deletion. (I have not selected "do not show me this dialog again" so there may be people who do not see the dialog.) The screen reader announces that I am in the inbox for my email and then announces the next email in the list (the expected email). It does take longer to hear the email information because the inbox information is announced, but

However, I can duplicate this with Delete. For the first message I delete with the Delete key, the next message is announced by the screen reader. But the next messages I delete after that do not announce the next message.

Conclusion

This is a significant regression. In 102, the next message is announced.

I just made the following interesting observation:

If I press the Delete key three times in quick succession, the next but one message is read out to me. So there seems to be a timing or event problem here.

I also noticed that this problem does not seem to occur in the Junk folder.

(In reply to Ali Savas from comment #8)

I just made the following interesting observation:

If I press the Delete key three times in quick succession, the next but one message is read out to me. So there seems to be a timing or event problem here.

I also noticed that this problem does not seem to occur in the Junk folder.

Thank you, Ali!

(In reply to Ali Savas from comment #8)

I just made the following interesting observation:

If I press the Delete key three times in quick succession, the next but one message is read out to me. So there seems to be a timing or event problem here.

With 114.0b1, gmail imap, on Mac, in a non-screen reader environment, I am seeing a problem where deletions (or quick deletions) results in the reader pane being stuck on the last message displayed, or delayed display change. Changing to different thread or different folder sometimes frees it the stuck condition.

The release of Thunderbird 115 for all users is getting closer. However, this bug should be fixed before Thunderbird 115 is released for all. Unfortunately, nothing has happened (as of today) for 18 days regarding this bug.

Otherwise Thunderbird looks better and better from the accessibility with each beta version!

Hi Ali, I am currently working on this bug. I don't have a patch yet though. Once I have an update, I will let you know. Thank you!

Update: the problem is the focused item varies before deletion and on deletion. The focused item should be the specific email and it should move to the next email after deletion. However, the focus is currently inconsistent (sometimes jumping to the list rather than a specific item). I'm working on a patch to standardize this so that the correct information is read.

We found out that the aria-activedescendant is not updated when a message is deleted

Update 1: I looked into this. aria-activedescendant is being updated correctly. The screen reader is not reading the correct information on delete on the second and later times items are deleted.

Update 2: I am confirming that yes, aria-activedescendant is not updating even directly after the first item has been deleted.

Update 3: aria-activedescendant has the same id when a message is deleted because the rows are updated, so it may look like the id is not being updated, but it is. Because of the same id being used more than once, screen readers don't know that the attribute has changed. This is updating correctly as I initially thought. I have a simple fix for this.

r=#thunderbird-front-end-reviewers

I just see that this fix is supposed to be in 116 or is that only for Daily? It is very important that this is also fixed in 115 because this will be a very big problem for blind people who do not know the problem.

(In reply to Ali Savas from comment #18)

I just see that this fix is supposed to be in 116 or is that only for Daily?

Alex set a flag that this affects version 115 - so it is noted as a need for version 115. And as we have been doing with previous beta versions (112, 113, etc) we will uplift important patches from any development channel to version 115, to be as trouble free as possible.

Accidentally added the check-in flag, the patch needs a quick comment addition before landing.

I will be making the update tonight my time and marking this as check-in needed.

Yes, this will be flagged as needing uplift into 115.

Thank you so much, Ali, for your patience as we worked to fix this problem.

Pushed by martin@humanoids.be:
https://hg.mozilla.org/comm-central/rev/7b59159d22dd
Ensure screen readers read next message after delete. r=aleca

(In reply to Elizabeth Mitchell from comment #21)

Thank you so much, Ali, for your patience as we worked to fix this problem.

And I thank you very much for your efforts so that you could fix the problem. Thank you very much!

Comment on attachment 9338055 [details]
Bug 1825588 - Ensure screen readers read next message after delete. r=#thunderbird-front-end-reviewers

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: This would make the message list delete message not usable for screen reader users if declined. This fixes a significant accessibility issue for screen reader users.
Testing completed (on c-c, etc.): Manual, try-comm, and c-c tested
Risk to taking this patch (and alternatives if risky): Low. This is a minor code change with huge impact.

Comment on attachment 9338055 [details]
Bug 1825588 - Ensure screen readers read next message after delete. r=#thunderbird-front-end-reviewers

[Triage Comment]
Approved for beta

Thunderbird 115.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/6e6ddd2f7ffd