1466550 - Accessibility regression: Attachment list is no longer announced as a list by screen readers.

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect)

Description

[Marco Zehe (:MarcoZ)]

Found in Thunderbird 60.0b6.

STR:
1. Using the NVDA screen reader on Windows, or Orca on Linux, open Thunderbird, and open a message that has attachments.
2. Tab through the message until you land on the attachments checkbox.

First problem: There is no label spoken for it, it just says "Checkbox not checked".

3. Press Space to check.
4. Tab forward.
You'll land on the list of attachments.

Expected: Screen reader should say something like "Attachments list", <file name> selected, 1 of 1.
or similar.

Actual: Screen reader says "unknown".

The attachments widget has changed from being a richlistbox to something with a tag of attachmentlist. This new widget does not include proper accessibility type information for a screen reader to determine what that element is. Gecko does not know what to expose for this widget.

4. Moreover, the labels inside this widget are just labels, not actual list items. There are two xul:label elements inside this attachmentlist tag, one has the file name, the other has the size. These used to be one list item that the keyboard could navigate. The way I see it now, there is only one tabstop, and with more than one file, these aren't easily navigable.

Comment 1

[Wayne Mery (:wsmwk)]

Likely caused by bug 1428631 or bug 1461170

Comment 2

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> Likely caused by bug 1428631 or bug 1461170

Possible, but unlikely for the major part of this bug if reporter's comment 0 is correct. In bug 1461170 I did remove the control attribute associated with the "N attachments" label, so that would probably break the screenreader-detectable link between those two elements. I did so to work around a bug that focusing the list via access key will clear the selection, but focusing via TAB key won't, which is inconsistent and unexpected (to preserve selection all along and then suddenly clear it when you focus the list). We could try re-adding the control attribute (along with re-introducing that minor bug) which would probably re-establish the link, but would not fix all the other problems of this bug, which are unrelated to my two bugs mentioned by Wayne.

Comment 3

[Jorg K (CEST = GMT+2)]

We should re-establish the accessibility somehow.

Comment 4

[Wayne Mery (:wsmwk)]

Sebastian is this something you could sort out?

Comment 5

[Thomas D. (:thomas8)]

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Found in Thunderbird 60.0b6.
> 
> STR:
> 1. Using the NVDA screen reader on Windows, or Orca on Linux, open
> Thunderbird, and open a message that has attachments.
> 2. Tab through the message until you land on the attachments checkbox.

Can you pls attach a screenshot of "attachments checkbox"? Is this something added by screenreaders?

Comment 6

[Thomas D. (:thomas8)]

Attachment: [#1] Patch V.1: Restore control attribute of attachmentBucketCount label

So here's a patch which restores the control attribute of attachmentBucketCount label, i.e. the direct link between the label and the attachment list.

Marco (reporter), I'll be curious to know if this fixes any of the problems mentioned by you in comment 0? I'm inclined to think that it doesn't.

But looking at the German localization of 60b7, it's wise to this not only for screen readers, but also for ux-error-prevention in deviant localizations which don't make the access key the same as the shortcut key: German has Alt+N as access key, and Alt+M as shortcut key. Without this patch, this causes the access key to do nothing; with this patch, both access key AND deviant shortcut key will provide full access to the new bucket magic (focus/show or hide attachment pane).

Aceman, I have added a detailed comment in code which describes why this is needed and how things interact. It's a bit delicate so imo we should be clear about this.

Richard, can you please test the following for MAC and windows, both English and German localization:

1 New msg
2 Add some attachments, and select at least one.
3 Place cursor in msg body (important)
4a EN/DE: press Alt+M 3 times
4b (repeat step 3, then) DE: press Alt+N 3 times

Expected:
4a 1st Alt+M: attachment pane focused, selection cleared (XUL mini-bug, re-introduced by this patch)
   2nd Alt+M: attachment pane hidden with placeholder
   3rd Alt+M: attachment shown again, with focus
4b DE: Alt+N should do the same as Alt+M (see 4a expected).

I think German should make the shortcut key and access key identical as we do in English, because composition access keys are in short supply (Bug 1469835).

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #6)
> Created attachment 8987352 [details] [diff] [review]

> Marco (reporter), I'll be curious to know if this fixes any of the problems
> mentioned by you in comment 0? I'm inclined to think that it doesn't.

Jörg, maybe Marco needs a try build to test the patch?

Comment 8

[Thomas D. (:thomas8)]

Aceman, fwiw, in theory after this patch we could eliminate the shortcut key altogether but then it becomes harder to advertise the access key (aka shortcut key) on the View menu. Having <key> makes it simple for menu advertising, but then we must also let the key trigger the action because if we don't, we'll just reverse the problem currently seen in German locale, namely that now the access key would work but the deviant shortcut key wouldn't.

Comment 9

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #7)
> Jörg, maybe Marco needs a try build to test the patch?
Sure. Which platform is preferred?

Comment 10

[Richard Marti (:Paenglab)]

Comment on attachment 8987352 [details] [diff] [review]
[#1] Patch V.1: Restore control attribute of attachmentBucketCount label

I only checked EN build because I build only these. This is a debasement to the actual state, so ui-r-.

I'm almost sure, Marco didn't meant this with this bug. He meant more that the attachmentBucket doesn't expose an aria role like role="listbox" and the attachmentitems should get the role="listitem". Is this correct, Marco?

Comment 11

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #10)
> Comment on attachment 8987352 [details] [diff] [review]
> [#1] Patch V.1: Restore control attribute of attachmentBucketCount label
> 
> I only checked EN build because I build only these. This is a debasement to
> the actual state, so ui-r-.

Can you please elaborate on what you mean with "debasement"? Because this patch does not change the UX except for the trivial, pre-existing flaw that Alt+M accesskey will clear selection before focusing. That's an XUL bug which must be fixed in XUL.
Imho, this patch is a net improvement because it avoids bigger problems as seen in the German translation on 60b7 (haven't checked b8).

> I'm almost sure, Marco didn't meant this with this bug.

Have you tried the patch with a screenreader?
I have tried it now and it actually does bring some improvement to screen reading.

Here's the NVDA screenreader download link for windows:
https://www.nvaccess.org/download/

> He meant more that
> the attachmentBucket doesn't expose an aria role like role="listbox" and the
> attachmentitems should get the role="listitem". Is this correct, Marco?

But I don't recall that we had these attributes before but it's working much better in TB52.
The problem seems to be the new tooltip on the whitespace, or maybe changed onselection routines.
When using cursor up/down on items, it's always announcing the listbox tooltip (Clear selection), whereas the selected item has its own tooltip which is not read out.
I'm also missing the useful Explorer behaviour that item tooltip gets shown when an item is selected via keyboard (strangely not when selected by mouse, but it's already shown upon mouse move). Maybe if we'd force the tooltip to appear upon selection, the screen reader might respond better. Aria roles as you said might also help.

Comment 12

[Marco Zehe (:MarcoZ)]

(In reply to Richard Marti (:Paenglab) from comment #10)
> I'm almost sure, Marco didn't meant this with this bug. He meant more that
> the attachmentBucket doesn't expose an aria role like role="listbox" and the
> attachmentitems should get the role="listitem". Is this correct, Marco?

Yes, this is correct, and I was actually talking about reading messages, not composing. ;) The problems with this current widget are as follows:

a) The checkbox to toggle the attachments list, a <button> element with an ID of "attachmentToggle" has no label. The name property, when viewing accessibility properties, is empty "". This should never happen with a focusable control. If the visual name is provided via some sort of icon, the aria-label attribute must be added to the <button> element with a localizable string saying something like "Attachments list" or similar. If there is a visual label, that should be associated with this button so it actually gets associated with it.

2. Once the button is toggled (the screen reader actually views it as a checkbox), a new element appears in the tab order, an item with an id and tag of "attachmentlist". This is not part of the standard XUL library, so needs to be explicitly tagged with an ARIA role="listbox".

3. Its children are labels, which contain name and size of each attachment. I don't know if there is any element that encompasses each of the label pairs. If so, it's one that is currently completely being ignored by the accessibility APIs.

4. HOWEVER, there is a second place where the attachment name, size, and a toolbar with a button menu child and another child to save the attachment appear, and that is *between* the checkbox of 1 and the container that gets toggled by activating and deactivating that. That seems to be visible always, also contains two labels, and that said toolbar with one child. This is very confusing, since the attachments seem to appear in two places.

Comment 13

[Richard Marti (:Paenglab)]

(In reply to Thomas D. (currently busy elsewhere) from comment #11)
> 
> Can you please elaborate on what you mean with "debasement"? Because this
> patch does not change the UX except for the trivial, pre-existing flaw that
> Alt+M accesskey will clear selection before focusing. That's an XUL bug
> which must be fixed in XUL.

The clear selection is a step backwards to the actual behavior.

> Imho, this patch is a net improvement because it avoids bigger problems as
> seen in the German translation on 60b7 (haven't checked b8).

Bug #? Then this patch should go into this bug.
> But I don't recall that we had these attributes before but it's working much
> better in TB52.

TB52 had -moz-appearance: listbox; for the attachmentList. This part could be fixed in XUL by adding role="listbox". For the listitems this would need adding the attribute through JS.

Comment 14

[Jorg K (CEST = GMT+2)]

I don't understand this bug. It's not about composing, but about *reading* messages with attachments, see comment #12. That hasn't changed for a while and would also be an issue in TB 52. It's also not related to recent attachment pane improvements in the compose window.

So what's the way forward here?

Comment 15

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #13)
> (In reply to Thomas D. (currently busy elsewhere) from comment #11)
> > 
> > Can you please elaborate on what you mean with "debasement"? Because this
> > patch does not change the UX except for the trivial, pre-existing flaw that
> > Alt+M accesskey will clear selection before focusing. That's an XUL bug
> > which must be fixed in XUL.
> 
> The clear selection is a step backwards to the actual behavior.

Well, as I said, that's a pre-existing XUL bug and removing control attributes from elements that control trees cannot be a sustainable workaround. Losing selection when focusing attachment list with access key is trivial, and no one except myself has ever complained about that. By comparison, the risk of ending up with a completely disfunctional access key for attachments list altogether (when translations ignore our instruction to make access key and shortcut key the same, as seen in German TB60b7) is real and entails significant loss of accessibility. So my patch is just replacing a nasty workaround (removing control attribute) with a much safer workaround (making the access key trigger the shortcut key action when attachment list has focus, via onkeypress event of the bucket). On top of that, restoring the control attribute, while not entirely fixing the screen reader access to *composition's* attachment pane, at least restores some announcement of the list by its label (compared to no announcement without this patch). Try it yourself: screen reader download link -> see URL of this bug.

In view of this analysis, I think we should go for the lesser evil, so I am asking Richard to reconsider on his ui-review.
Richard?

> > Imho, this patch is a net improvement because it avoids bigger problems as
> > seen in the German translation on 60b7 (haven't checked b8).
> 
> Bug #? Then this patch should go into this bug.

Bug 1469835, already mentioned in my comment 6.
I don't think my patch would fit well into that bug because it's only indirectly related to the German failure of defining matching accesskey and shortcut key. It fits well here because it improves the screen reader access (notwithstanding that this bug was reported against message reader, which wasn't clear when I provided the patch).

> > But I don't recall that we had these attributes before but it's working much
> > better in TB52.
> 
> TB52 had -moz-appearance: listbox; for the attachmentList. This part could
> be fixed in XUL by adding role="listbox". For the listitems this would need
> adding the attribute through JS.

Thank you, these are helpful hints for addressing this bug. Does this apply to message reader, composition, or both? Should be both.

Comment 16

[Richard Marti (:Paenglab)]

Marco, please could you try one build of this try push https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=29566ed7741f802e516319178001cb0672f812c0 ? There are builds for all three platforms (all 64 bit).

I added the roles to the list and the attachment item. This should work for both, the list in the message pane and the list in composer window. I tried it with the accessibility tab of the DevTools and they show now this roles.

I moved the attachmentList rules from content/messenger.css to its own file because somehow the messenger.css are no more all used in composer window and the attachmentitem itself.

Comment 17

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #14)
> I don't understand this bug. It's not about composing, but about *reading*
> messages with attachments, see comment #12.

Yes, it was originally filed against message reader, which however wasn't clear from comment 0 at all.
And the same/similar set of accessibility problems also applies to composition, so we might as well try to fix that here.

> That hasn't changed for a while
> and would also be an issue in TB 52. It's also not related to recent
> attachment pane improvements in the compose window.

Yeah, but recent attachment pane changes have not made accessibility better.

> So what's the way forward here?

Richard has added the roles. My patch is also needed for all the reasons spelled out in comment 6 and comment 15.

Comment 18

[Richard Marti (:Paenglab)]

Comment on attachment 8987352 [details] [diff] [review]
[#1] Patch V.1: Restore control attribute of attachmentBucketCount label

Let's remove now the ui-r and wait what aceman says to this patch. I'm still for moving this patch to a new bug as the main focus of it is not accessibility but access key problems.

Comment 19

[Marco Zehe (:MarcoZ)]

(In reply to Richard Marti (:Paenglab) from comment #10)
> I'm almost sure, Marco didn't meant this with this bug. He meant more that
> the attachmentBucket doesn't expose an aria role like role="listbox" and the
> attachmentitems should get the role="listitem". Is this correct, Marco?

Almost. Listitem is the equivalent of an <li> within an <ul> or <ol>. What you want is role="option". And you will want to make sure it's focusable, has a tabindex of 0. I know tab stops at the list bucket when *composing* a message, but because of listitem instead of option, these are currently being treated as readonly, non-focusable items. Strictly speaking, this is even invalid ARIA markup in the try build. But aside from that little change, composition looks OK.

When *reading* a message, the list now also has a role of listbox, however there is no equivalent child with a role of option. The children are label elements that wrap other label elements and a tool bar which has a Save Attachment button as its only child. And once you focus an item within that, another item becomes visible at the same level as the list bucket, which also only consists of a label, and a tooltip that says "Open this attachment". So the attachment is present twice in the accessibility tree.

This is going in the right direction on both counts! :)

Comment 20

[Richard Marti (:Paenglab)]

Marco, please can you test this new try build https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=0e5928fc556409c1f75a05c97d2b8750c2d26f29 ?

(In reply to Marco Zehe (:MarcoZ) from comment #19)
> Almost. Listitem is the equivalent of an <li> within an <ul> or <ol>. What
> you want is role="option". And you will want to make sure it's focusable,
> has a tabindex of 0. I know tab stops at the list bucket when *composing* a
> message, but because of listitem instead of option, these are currently
> being treated as readonly, non-focusable items. Strictly speaking, this is
> even invalid ARIA markup in the try build. But aside from that little
> change, composition looks OK.

Okay, I changed it now to "option" and tabindex="0". The accessible inspector shows now "listbox option". Is this correct now?

> When *reading* a message, the list now also has a role of listbox, however
> there is no equivalent child with a role of option. The children are label
> elements that wrap other label elements and a tool bar which has a Save
> Attachment button as its only child. And once you focus an item within that,
> another item becomes visible at the same level as the list bucket, which
> also only consists of a label, and a tooltip that says "Open this
> attachment". So the attachment is present twice in the accessibility tree.

This isn't the list. This label is only shown, when there is only one attachment. I gave it the role="button" because you can click it to open/save the attachment, okay like this?

Comment 21

[Marco Zehe (:MarcoZ)]

(In reply to Richard Marti (:Paenglab) from comment #20)
> (In reply to Marco Zehe (:MarcoZ) from comment #19)
> Okay, I changed it now to "option" and tabindex="0". The accessible
> inspector shows now "listbox option". Is this correct now?

Yes! :)

> This isn't the list. This label is only shown, when there is only one
> attachment. I gave it the role="button" because you can click it to
> open/save the attachment, okay like this?

Yes, this is great, thanks!

Comment 22

[Richard Marti (:Paenglab)]

Many thanks, Marco.

Comment 23

[Richard Marti (:Paenglab)]

Attachment: Bug1466550-accessible.patch

Marco confirmed this will fix the issues.

Comment 24

[Richard Marti (:Paenglab)]

Attachment: Bug1466550-accessible-ESR60.patch

The same patch that applies on BETA_60_CONTINUATION.

Comment 25

[Jorg K (CEST = GMT+2)]

Comment on attachment 8989734 [details] [diff] [review]
Bug1466550-accessible.patch

Looks straight forward to me.

Comment 26

[Jorg K (CEST = GMT+2)]

Comment on attachment 8989740 [details] [diff] [review]
Bug1466550-accessible-ESR60.patch

Thanks.

Comment 27

[Jorg K (CEST = GMT+2)]

Comment on attachment 8987352 [details] [diff] [review]
[#1] Patch V.1: Restore control attribute of attachmentBucketCount label

Thomas, looks like this bug got hijacked. With all the uplifts involved, I prefer not to handle another patch here. Please file a new bug for it.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b95a9703b640
Make the attachment list accessible again. r=jorgk DONTBUILD

Comment 29

[Jorg K (CEST = GMT+2)]

TB 60 beta 10 (BETA_60_CONTINUATION branch):
https://hg.mozilla.org/releases/comm-beta/rev/3e49aaf7ec0d550e8781f10df1e495292c489428

Beta (TB 62):
https://hg.mozilla.org/releases/comm-beta/rev/786fde95a0451e7bb4fdb460b32806882de0b0bc

Comment 30

[Jorg K (CEST = GMT+2)]

Marco, please also confirm that this works on beta 60 which will move to ESR 60. Build here:
https://treeherder.mozilla.org/#/jobs?repo=comm-beta&revision=3e49aaf7ec0d550e8781f10df1e495292c489428

Comment 32

[Jorg K (CEST = GMT+2)]

This caused loss of the delete function for attachments when reading and composing, see bug 1473385.

Apparently caused by:
https://hg.mozilla.org/comm-central/rev/b95a9703b640#l2.13
item.setAttribute("tabindex", "0");

So we need to fix this quickly or I'll have to back out the whole lot from tree repos/branches :-(

Comment 33

[Richard Marti (:Paenglab)]

Attachment: Bug1466550-noTabindex.patch

Remove the tabindex="0" because it makes the attachment no more deletable (bug 1473385).

Comment 34

[Jorg K (CEST = GMT+2)]

Comment on attachment 8989846 [details] [diff] [review]
Bug1466550-noTabindex.patch

Yes, fixes the test failure. We should still understand what's going on. This doesn't necessarily help:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex

I'll get this landed here and on the branches.

Comment 35

[Jorg K (CEST = GMT+2)]

TB 60 beta 10:
https://hg.mozilla.org/releases/comm-beta/rev/a1413e9df7df2e85e375cfb5fb981cf86a1f2cd6

Beta (TB 62):
https://hg.mozilla.org/releases/comm-beta/rev/6aec4094005eb80286863cf4af08886af2f74a29

Will land in trunk in a while.

Comment 36

[Jorg K (CEST = GMT+2)]

Marco, I had to remove the tabindex=0 again, to the build you want to try is this one:
https://treeherder.mozilla.org/#/jobs?repo=comm-beta&revision=d72158ae7100854cfa522c7acedba1e6f300ae22

Comment 37

[Marco Zehe (:MarcoZ)]

(In reply to Jorg K (GMT+2) from comment #36)
> Marco, I had to remove the tabindex=0 again, to the build you want to try is
> this one:
> https://treeherder.mozilla.org/#/jobs?repo=comm-
> beta&revision=d72158ae7100854cfa522c7acedba1e6f300ae22

That's very unfortunate, because there is now no way to focus these with the keyboard. What tabindex="0" does is insert the given element in the tab order at the DOM order level. So, it increases the number of times one has to press tab to get somewhere. So what I could imagine happening is that the test makes some assumptions on how many times it has to press tab to get somewhere, then lands on the wrong item due to an increased number of tabstops. So if that's the case, the test must be adjusted to accomodate the new number of tab stops.

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ee74e29c60b8
Follow-up: Remove tabindex="0" on attachmentitem to restore the ability to delete it. r=jorgk

Comment 39

[Jorg K (CEST = GMT+2)]

(In reply to Marco Zehe (:MarcoZ) from comment #37)
> So what I could imagine happening is that the
> test makes some assumptions on how many times it has to press tab to get
> somewhere, then lands on the wrong item due to an increased number of
> tabstops.
No. The test detects the functional *failures* that with tabindex="0" ...
a) you cannot delete an attachment from the attachment pane in the compose
   window any more.
b) when you select an attachment in the attachment area when reading a message
   and hit the delete button, the entire message is deleted :-(

You will understand that both are absolutely not acceptable. I'll leave this to someone else to investigate in a new bug.

Comment 40

[Marco Zehe (:MarcoZ)]

(In reply to Jorg K (GMT+2) from comment #39)
> You will understand that both are absolutely not acceptable. I'll leave this
> to someone else to investigate in a new bug.

I totally understand that. And yes, this should be investigated and fixed properly. This is still better than what is in 60Beta9, so dealing with that bit in a separate bug makes total sense.

And again, what this attribute does is make the item focusable, and include it in the tab order in DOM order.

Comment 41

[Richard Marti (:Paenglab)]

(In reply to Marco Zehe (:MarcoZ) from comment #40)
> 
> And again, what this attribute does is make the item focusable, and include
> it in the tab order in DOM order.

It's already focusable. When you tabbed to the attachmentItem, using the arrow keys works. Yes, it's not as comfortable like with tabs but it's the same behavior as in a tree.

And yes, this should be investigated in a new bug, but this would be nothing I could do.

Comment 42

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #41)
> (In reply to Marco Zehe (:MarcoZ) from comment #40)
> > 
> > And again, what this attribute does is make the item focusable, and include
> > it in the tab order in DOM order.
> 
> It's already focusable. When you tabbed to the attachmentItem, using the
> arrow keys works. Yes, it's not as comfortable like with tabs but it's the
> same behavior as in a tree.

I agree with Richard and I'm failing to see the focus problem.
With focus in subject, press Tab once and the item which last had focus ring (currentItem) will be focused. From there, you can use cursor up or down keys to focus any item in the list. That should suffice for access, no?

Comment 43

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #27)
> Comment on attachment 8987352 [details] [diff] [review]
> [#1] Patch V.1: Restore control attribute of attachmentBucketCount label
> 
> Thomas, looks like this bug got hijacked. With all the uplifts involved, I
> prefer not to handle another patch here. Please file a new bug for it.

No problem, and thanks for the friendly information. I had earmarked this already after Richard's Comment 18 suggested the same.

--> Filed bug 1473488.

Comment 44

[Thomas D. (:thomas8)]

Comment on attachment 8987352 [details] [diff] [review]
[#1] Patch V.1: Restore control attribute of attachmentBucketCount label

Let's hide this patch here because it's now in bug 1473488.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a933eaed53bf
Restore control attribute of attachmentBucketCount label for screen reader access and ux-error-prevention in deviant localizations. ui-r=Paenglab, r=aceman.

Comment 46

[Jorg K (CEST = GMT+2)]

Grrrr, wrong bug number, this was meant to go into bug 1473488 :-(((

Comment 47

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-esr60/rev/ba9cf14df369
https://hg.mozilla.org/releases/comm-esr60/rev/fb8dde71d938

Comment 48

[James Teh [:Jamie]]

(In reply to Thomas D. (currently busy elsewhere) from comment #42)

It's already focusable. When you tabbed to the attachmentItem, using the
arrow keys works.
I agree with Richard and I'm failing to see the focus problem.
With focus in subject, press Tab once and the item which last had focus ring
(currentItem) will be focused.

My guess is that while it is visually focused, accessibility doesn't know about that. Accessibility can't know about visual-only focus. In order for accessibility to know that something is focused:

1. The element must have DOM focus; or
2. For XUL elements, a DOMMenuItemActive event event can be fired on the "focused" element; or
3. The element with DOM focus must set the aria-activedescendant attribute to the id of the "focused" item. (That might mean you need to add an id to the focused item.)

Note that neither Marco nor I are Thunderbird users now (I don't even have it set up) and MoCo doesn't work on Thunderbird. Thus, I haven't filed a separate bug for this because I cannot give time to testing, etc. I provide this information because I see that NVDA screen reader users are still hoping for a fix and I'm hoping this might be a nudge in the right direction. NVDA is tracking this problem here:
https://github.com/nvaccess/nvda/issues/8698