The attachment area is meant to open/close on clicking the attachment bar. However, it cannot be focussed through the keyboard. Nor is this expanding behaviour advertised to the accessibility tree (e.g. with aria-expanded).

We can replace this area with a <html:details>, which handles the semantics and behaviour for us.

affects version 91?

(In reply to Wayne Mery (:wsmwk) from comment #2)

affects version 91?

Yes, this isn't a regression. The attachment toolbar is old markup.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/59c602cfd601
Make attachment pane more accessible. r=aleca

This fix introduces some string changes so we can't uplift it to 91.

Doesn't a XUL splitter need to be placed between two XUL "boxes" to work?
https://hg.mozilla.org/comm-central/rev/59c602cfd601#l2.28
And wouldn't flexing the <html:details> work with CSS display: contents? Maybe some inspiration here.

The expensive height calculation https://hg.mozilla.org/comm-central/rev/59c602cfd601#l1.42 appears a bit complicated, it would be good if it could be avoided.

Also see: https://searchfox.org/comm-central/rev/448509150fd85253759d37a2777cb99d93594971/mail/base/content/widgets/pane-splitter.js#145

Please, avoid writing on a closed bug unless the patch caused a regression.
Feel free to open a new bug with the issue or enhancement request you'd like to highlight.

Just for my understanding: Wouldn't the staff developer in charge evaluate any comment and then file a follow-up bug himself in case an improvement/simplification can be made?

Is good practice to no write on a closed bug as the conversation might get lost if it doesn't fully belong to the context of the patch.
The bag is also marked with "See also: bug 1732260", which is a continuation of the work done on this bug to convert the whole attachment view to pure HTML, so the work is not done.

Unless this patch caused a breakage, an issue, or a regression, it's good practice to open a new bug with the depends flag pointing at this one, to state your enhancement propositions.
Doing so helps keep the bug history clean, and properly notifies all the developers that worked on this bug that a "follow up" was opened, and the conversation can be done in the new bug without polluting a closed one.

No one disputes what a new bug should be filed. The question is just who should file it. I still think the developer in charge knows best what to do, especially given the other work panned in that area.