I believe we've had this bug already and tried to do as much as we could (which may not be enough), so we should find the duplicate of this and check. I know nothing about accessibility events and I doubt that it's me who broke it. Maybe caused by replacing XUL elements as they become extinct. So unfortunately, I can't assist here.
(In reply to Alex ARNAUD from comment #0)
- Add two attachment to it
- Move the cursor to the attachment if it's not the case
In TB 60, after adding attachments, focus is always already on an attachment (so this step is not needed).
Interesting. In bug 1519328, reporter of this bug 1519346 does NOT like it that we now focus attachments after adding them. Here, he presents a workflow which involves focusing of attachments to act on them right after adding. So for the workflow of this bug 1519346, auto-focus seems helpful, somewhat against the other bug. Indeed there are a lot of scenarios where auto-focus on attachments after adding is helpful, e.g.:
- check if the right files were added (number and names)
- rename just added files
- open just added files to double-check the content if it's the correct version of file etc. (I do that all the time)
- reorder just added files (new feature in TB 60)
- Move between attachments with arrow keys
The screen reader stays silent because Thunderbird no longer sending accessibility events so a blind person couldn't verify attachment list anymore.
That's the real problem which is also underlying bug 1519328: The problem is not that focus follows the action of adding attachments, but that screenreaders get disoriented when they are in attachment pane because the pane and/or its children don't communicate correctly. (I don't have time to test, but I believe that it does happen).