1844151 - Threaded view: Statuses "Expanded" or "Collapsed" are announced at the end by the screen reader

Status: ASSIGNED

(Thunderbird :: Folder and Message Lists, defect, P2)

Description

[Ali Savas]

I was told by a user that the screen reader announces the states "Expanded" or "Collapsed" in the threaded view at the end. This was not the case in Thunderbird 102. There, the status was announced first, followed by the message.

I checked this with JAWS and NVDA and can reproduce this behavior.

Steps to reproduce

• Make sure you are using the "Topic View" or other grouping.
• Now navigate on a main node of a message using the arrow keys.

Result

The screen reader reads the entire contents of the message list and only then announces if the item is "Expanded" or "Collapsed".

Expected

The screen reader should first announce the status and then the contents of the message list.

Comment 1

[Peter Vágner]

Hmm, the only way on how to do it the way you are asking for is by stop using aria-expanded and just prepend the state to the aria-label. Otherwise screen reader is responsible for the order of information to present.

Comment 2

[Ali Savas]

Hmm, the only way on how to do it the way you are asking for is by stop using aria-expanded and just prepend the state to the aria-label. Otherwise screen reader is responsible for the order of information to present.

That's what I thought, but it's different with Thunderbird 102 and older. This behavior is with all screen readers, not only with JAWS or NVDA. But if this is not technically feasible otherwise, the manufacturers of screen readers must deal with it.

Comment 4

[Elizabeth Mitchell]

I am confirming this bug and raising its level of importance.

We would just need to rearrange the order that the column information is read for a message.

Showing whether an item is expanded or collapsed does more than just tell the state of the thread. It's used to help the user determine if this is a single message or a thread, which is important information as noted in Ali's comment below:

(In reply to Ali Guerler from bug 1846257 comment #0)

The screen reader reads the "Expanded" or "Collapsed" status of a grouped message as the very last piece of information. Therefore, the blind user is forced to listen to the entire entry to the end before knowing whether it is a single message or a thread of grouped messages. This information is also visible on a Braille display at the end of an entry in the message list.

Comment 5

[Elizabeth Mitchell]

This should be a relatively quick fix, so I'd like to get this in soon, if possible. Severity reduced because there is a workaround. The status is read. It just should be read a lot sooner.

Comment 6

[Ali Guerler]

Late or early reading of the expanded or collapsed status of the thread tree seems to be only part of the problem. Due to the hierarchical levels of the thread view not being represented by the screen reader, all messages and their replies are displayed at the same hierarchical level, so that the nesting level of a reply cannot be distinguished by the blind user. It would probably be better to forgo Aria labels and instead map the real thread view hierarchy tree for screen readers. This was done correctly until Thunderbird version 102. Dear Elizabeth, I would like to thank you very much for your great work and also your help.

Comment 7

[Elizabeth Mitchell]

(In reply to Ali Guerler from comment #6)

Late or early reading of the expanded or collapsed status of the thread tree seems to be only part of the problem. Due to the hierarchical levels of the thread view not being represented by the screen reader, all messages and their replies are displayed at the same hierarchical level, so that the nesting level of a reply cannot be distinguished by the blind user. It would probably be better to forgo Aria labels and instead map the real thread view hierarchy tree for screen readers. This was done correctly until Thunderbird version 102. Dear Elizabeth, I would like to thank you very much for your great work and also your help.

Thanks for your feedback. A separate bug would be best to address your suggestions.

Did this work the way you expected it to in Thunderbird 102?

Comment 8

[Ali Guerler]

Unfortunately, I don't know how to reply to comments in the bug tracker, so I'll just have to write my answer under your comment. Yes, until Thunderbird 102 it worked the way I and other blind people would like the current versions to. Screen readers displayed the threading view correctly and also rendered it correctly. You can try this out with both JAWS and NVDA and understand it if you compare the threading view of Thunderbird 102 and Thunderbird 115.

Comment 9

[Elizabeth Mitchell]

(In reply to Ali Guerler from comment #8)

Unfortunately, I don't know how to reply to comments in the bug tracker, so I'll just have to write my answer under your comment. Yes, until Thunderbird 102 it worked the way I and other blind people would like the current versions to. Screen readers displayed the threading view correctly and also rendered it correctly. You can try this out with both JAWS and NVDA and understand it if you compare the threading view of Thunderbird 102 and Thunderbird 115.

Thank you. I'll add a new bug to investigate the old functionality and how it works in 115. Thank you. Update: see bug 1854356.

Comment 10

[Elizabeth Mitchell]

A quick look into the code for this shows that it's not as simple as reordering a list of values. This would require more investigation to fix.

Coding notes:
I thought I could reorder the items at let cellTexts in about3Pane.js. However, threadLevel is an object and the order is not easily changed because of that.