The status message for collapsed or expanded threads is spoken by the screen reader as the last piece of information or displayed on a braille display
Categories
(Thunderbird :: Disability Access, defect, P3)
Tracking
(thunderbird_esr115? affected)
People
(Reporter: a.guerler, Assigned: elijmitchell)
Details
(Keywords: access)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Steps to reproduce:
- Enabling a screen reader such as JAWS for Windows or NVDA
- Navigating through Thunderbird's message list, listening the screen reader's spoken information
Actual results:
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.
Expected results:
Screen readers should read the status of whether a thread is collapsed or expanded as the first information, otherwise the difference between a single message or a thread is indistinguishable for blind users.
|
Reporter | |
Comment 1•1 years ago
|
||
Up to Thunderbird version 102, the display of grouped messages was fine, with the new Thunderbird interface the information read out by a screen reader has changed.
|
||
Comment 2•1 years ago
|
||
Elizabeth, would you be able to investigate if it's possible to control when the expanded/collapsed state of the row is communicated to screen readers?
Puling in Ali and Peter to get more information and guidance on this.
|
||
Comment 3•1 years ago
•
|
||
This came up in the matrix Accessibility chat thanks to Peter. I'll summarise the chat:
It is usual for a screen reader to announce the expanded state information after reading out the text content (which is the entire row). In principle a screen readers could make it a configuration option to announce this beforehand, but we're not aware of any.
The old tree-grid in 102 had a separate column for the expanded/collapsed state, which had accessible names. Basically the "Thread" cells had three states:
- "Expanded" when the row had expanded children.
- "Collapsed" when the row had collapsed children.
- Empty when the row had no children.
This was maybe a slight misuse of the "Thread" column, since both the first two states are visually indistinct: both are the same thread icon. I.e. visually the "Thread" column only distinguishes between "threaded" and "not threaded", but for screen readers it would also distinguish between the expanded and collapsed state when it was threaded.
Note that the "twisty" arrow icon did not have an accessible name in 102 (as expected).
As a result, screen reader uses (with the default view) in 102 would have had the row read out as "Expanded. My subject. person@email.org 01/01/2023, 10:00", followed by their screen reader reading out state information like the tree-depth, row number and the expanded state. This state information may be read out in a different tone or voice to distinguish it from the text content. However, since the default view had such a verbose ending with the email and date, I wouldn't be surprised if a lot of screen reader users ended the speech or moved on before the state information was read out, so the repeated expanded state wouldn't have been that prominent.
In 115, the "Thread" cell has no accessible name (and is explicitly hidden with "aria-hidden").
I think this is why this is being reported as a regression here: screen reader users from 102 would be used to this "Thread" column having this information being presented first.
|
Assignee | |
Comment 4•1 years ago
|
||
(In reply to Alessandro Castellani [:aleca] from comment #2)
Elizabeth, would you be able to investigate if it's possible to control when the expanded/collapsed state of the row is communicated to screen readers?
Puling in Ali and Peter to get more information and guidance on this.
Yes, I can look into this. I will assign this to myself.
(In reply to Henry Wilkes (they/them) [:henry-x] from comment #3)
Thanks so much for this information and context.
This appears to be a duplicate of bug 1844151 that I reported some time ago.
|
|
||
Comment 6•1 year ago
|
||
Indeed, thanks Ali
Description
•