since today I have the problem that the message list is displayed in a tree view, although I do not group my messages. This is misinformation as it suggests to the blind user as if there is something to expand or collapse.

However, this seems to be a very new phenomenon as I did not have this problem a few days ago. Unfortunately, I wasn't home so I can't tell you exactly which version this problem started with. I am using Thunderbird Daily 115.0a1 (2023-05-17) (64-bit)

Steps to reproduce

• Make sure you are not grouping messages.
• Focus on the message list.

Result

JAWS says "tree view"

Expected

JAWS should say something like "List View".

Got you Ali. I think you mean that you're not using threaded mode, so it's just a plain vanilla list of messages, and you would prefer your screenreader to consider "unthreaded" and then announce it as a "List View" instead of "Tree view", because there's nothing to expand or collapse.

Elizabeth, would you agree? If yes, pls confirm the bug.

I assume this has landed as a result of the bug 1822057 yesterday.
However it does not appear to work as intended at least for me on linux.
I can use up and down to navigate in both the cases when message list is threaded and when it is not.
I can use left and right arrow keys to expand and collapse threads in the threading mode.
Only thing which has changed for me with orca on linux is that now the expandable items are reported as pannel to me. The fact an item is expanded or collapsed is not reported with orca.
I can't really say if the aria-expanded state is missing or role is wrong, or it's set on a different object than the one which receives the focus, but this is how it currently works for me.

Correct that the change was done in bug bug 1822057 since the tree view aria pattern is the correct one for the current widget.
Is presenting the widget as "List View" the correct/expected behaviour when the list is presented unthreaded? I'm asking for confirmation because achieving that creates a bit of complexity I would like to avoid, but if indeed is the correct accessible solution, we have to do it.

Testing with NVDA and JAWS the tree view is reported correctly and the expanded/collapsed state.
Threads are presented with role="group" while single messages are presented as role="treeitem" as per specifications.
The aria-expanded attribute is updated correctly whenever that state changes.

Micah, can you investigate this and report how Orca reads this widget?

Hello,
I think focusable items should all have role="treeitem" the children at nesting level should be grouped inside the grouping. See this example.

Hi,

the problem is that if you don't use the threaded view and the role is still as tree view, the screen reader presents too much information on the braille display. For example, it shows on which level you are in the tree view.

It also suggests to the user that he has to expand or reduce something, which is not true in that case.

So: if the threaded view is not used, list view should still be used, otherwise tree view should be used.

All right, I see a bunch of issues here that I will try to fix.

First, we can detect if the message list is threaded or not, as well as it's grouped sorted or not, and change the role of the widget from tree to list. This is the easy part.

Unfortunately we can't strictly follow the example in the ARIA pattern guide, because those examples use the the <a> (link) element as treeitem and then an adjacent ul element with role="group", which is hidden by default if the aria-expanded is false.

Our virtualized message list can't handle that, because each row (message) need to be always the same widget and can't have hidden widgets that don't respect the flow of rows.
That's why when a row is a thread, we can its role to group as it encapsulates the other rows without any extra widget as container.

The good news is, I think I can mitigate the issue and fix it.
First I need to update the main role from treeview to tree, my mistake.
Then, I need to see if keeping the items always as treeitem and rely only on the aria-expanded is enough.
If it is, we can use the role="group" only if the "Grouped by Sort" is active.

Peter, if I provide a link to a Linux tarball could you test those changes?
Ali, which OS are you running, and could I give you a temporary build to test?

These builds will not overwrite your current installation, and you will need to login again with your email account credentials.

(In reply to Alessandro Castellani [:aleca] from comment #6)

Then, I need to see if keeping the items always as treeitem and rely only on the aria-expanded is enough.
If it is, we can use the role="group" only if the "Grouped by Sort" is active.
Actually I think the role="pannel" or role="group" is mainly used for giving ancestors an accessible name. So when tabbing away and then coming back we may get more verbose feetback. I think this is going to be nice compromise as we have enough verbosity already in the message list. I don't yet have complete understanding, I am not sure where the role="group" comes into place, but I'll see.

Peter, if I provide a link to a Linux tarball could you test those changes?
Yes definatelly I am fine with a try build.
Ali, which OS are you running, and could I give you a temporary build to test?
He is on Windows 10 if I remember correctly.

How to test this

• Use a screen reader, or simply the code inspector
• Switch between threaded, unthreaded, and Grouped by Sort
• Ensure that the table body role changes between tree and listbox respecting this patter:
  • Threded: tree
  • Unthreded: listbox
  • Grouped by Sort: tree

I also improved a bit the handling of the dummy row.

Sorry for the delay in replying, I was traveling for work and didn't have time.

Ali, which OS are you running, and could I give you a temporary build to test?

I use Windows 10 and Windows 11, you can very gladly send me a build what I can test.

Hi Peter, here's the Linux tarball with my patch applied: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HxEBoJsnQgil8qcG6YbujA/runs/0/artifacts/public/build/target.tar.bz2

Ali, here's the Windows installer: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/avAdGijURNO4BqO5NQsBXQ/runs/0/artifacts/public/build/setup.exe
It's not packaged as shippable so Windows will complaint during installation as "unsafe". You should be able to press on "more info" and then on the "Run anyway" button, or something like that, in the security alert.

This build has my patch applied, which should take care of dynamically switching the message list from Tree to Listbox depending on the threaded, unthreaded, and grouped by sort state.
Grouped by sort should also be the only state that creates a dummy first row presented as "group" role.

Let me know if you find something that doesn't work correctly.
Thank you so much for your help!

Something seems to have gone wrong with the build. I can't get this build to install properly. Do I need to have Daily installed first? Because I have it only as a kind of "portable".

I have now re-downloaded and reinstalled Daily, and then installed the patch. However, this patch does not install properly. The file is also very small.

I built a shippable version of Windows.
We have 2 installers that are generated, and I never remember which one is the correct one.

setup.exe: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GQ9uFf_qRUi-OM6bSzI7rg/runs/0/artifacts/public/build/setup.exe

target.installer.exe: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GQ9uFf_qRUi-OM6bSzI7rg/runs/0/artifacts/public/build/install/sea/target.installer.exe

Let me know if any of these work

Thanks, the "target.installer.exe" finally worked.

Basically everything works as it should now, however there is something to note in the last point of my enumeration.

• If I select "Threaded", the messages are displayed to me in a tree view as expected. Also, the "Expanded" and "Collapsed" states are announced to me correctly.
• If I select "Unthreaded", all messages are displayed in a list view as expected.
• If I activate "Grouped By Sort", all messages are displayed in a tree view as expected. However, the states "Expanded" and "Collapsed" are not always announced immediately, as soon as I press arrow right or arrow left. Only when I press Arrow up or Arrow down, the states are updated and announced correctly. This usually only happens when the entries are collapsed.

Hello,
Huge thanks Allesandro, it's almost completelly awesome.
On linux I do have the same experience Ali has described.

• When the message list is unthreaded it's reported as a table. That's the correct mapping of the list and list item aria roles I guess.
• When it's configured to threaded all the tree items have correct role of tree item and collapsed / expanded state is reported when changed and when focused.
• When the message list is configured to be grouped by sort, the top level items such as today, yesterday and similar (when sorted by date) don't have the role tree item but something else what's mapped to pannel on linux. I think this is the part of your comments you have posted last week I was not able to understand. If possible I'd like if you could change role of these items to tree item the same way than the rest.

Damn guys, I verry much like these accessibility related improvements you have prepared for Thunderbird 115. I'm verry happy. I see a lot of things is also being approved and added into beta. I'm tempted to try asking more screen reader users to test thunderbird to find out if me and Ali may have overlooked something very obvious.

When the message list is configured to be grouped by sort, the top level items such as today, yesterday and similar (when sorted by date) don't have the role tree item but something else what's mapped to pannel on linux. I think this is the part of your comments you have posted last week I was not able to understand. If possible I'd like if you could change role of these items to tree item the same way than the rest.

Those elements have an aria role group. I guess that's the issue with Orca, and technically that row is not a group as it doesn't encapsulates the child messages, so maybe leaving it as treeitem is correct.
That will solve also the "Expanded" and "Collapsed" states issue reported by Ali.

Damn guys, I verry much like these accessibility related improvements you have prepared for Thunderbird 115. I'm verry happy. I see a lot of things is also being approved and added into beta.

This warms my heart.
We spent almost 2 years to move away from the old architecture and implement a new native HTML listview widget. Even if we broke a lot of things, now we have much more flexibility to easily fix and improve issues, and a total control on the accessibility compatibility layer.

I'm tempted to try asking more screen reader users to test thunderbird to find out if me and Ali may have overlooked something very obvious.

Yes, please!
The entire Mail Tab was rebuilt from scratch so I'm sure we might have missed something. If we can get as many feedback and reports during the beta cycle before releasing 115 ESR it'll make our life much easier.

Thank you again for your help and contribution!

Pushed by martin@humanoids.be:
https://hg.mozilla.org/comm-central/rev/41650df9cde7
Update message list ARIA role from listbox to tree if needed. r=darktrojan