1519328 - Adding attachment moves the keyboard focus from the body to the attachment pane since version 60

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Alex ARNAUD]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

1. Write a new message
2. Move the cursor to the body pane
3. Add an attachment with the menu via mouse or keyboard

Actual results:

The focus moves from body pane to the attachment pane

Expected results:

The focus stays what it was before the attachment (the behavior of version 52 or below)

This is really annoying issue for keyboard-only users like blind people who have a line by line representation of screen. Moving the caret/keyboard focus unexpectedly could make them unable to understand what's happen and how to come back on the body of the message (or subject).

Comment 1

[Jorg K (CEST = GMT+2)]

Surely a regression of all the attachment changes.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #1)

Surely a regression of all the attachment changes.

Hmm, no, this is actually by design, and we even have plans to enhance the auto-focus/selection behaviour of newly added attachments even further (bug 1428977).

Interestingly, reporter of this bug 1519328 also filed bug 1519346 whose STR involve focusing newly added attachments to act on them, which seems somewhat contrary to the demand of this bug.

(In reply to Thomas D. from bug 1519346 comment #3)

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 (select, then F2)
• 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)

• focus in attachment pane also assists to add more attachments (if we fix a tree bug that when no attachments are selected, we don't show the attachment list context menu).

As laid out in Bug 1428977 comment 0, it's common practice in other widespread software that newly added items get focus, e.g. files which you just pasted into Explorer, or images just inserted into MS Word, so we're both ux-consistent and helpful here.

(In reply to Alex ARNAUD from bug 1519346 comment #0)

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 screen readers get disoriented when they are in attachment pane because the pane and/or its children don't communicate correctly. We should fix that instead of this bug.

(In reply to Alex ARNAUD from comment #0)

This is really annoying issue for keyboard-only users like blind people who have a line by line representation of screen.

Looking at the above list of feasible actions after adding, I'd believe that keyboard-only users including the blind can actually benefit a lot from the new behaviour of focusing attachments after adding them, e.g. to check using their screen readers if the right attachments were added.

Moving the caret/keyboard focus unexpectedly could make them unable to understand what's happen and how to come back on the body of the message

The only unexpected thing about moving focus is bug 1519346; nothing special about focus following the action, actually consistent with other apps, see above.

There are two simple ways to move focus from attachment pane (back) into body:

1. press ESC in focused attachment pane (will first clear selection of attachments if any, then move focus into body)
2. press TAB once, as body is the next element in the TAB sequence

(or subject)

Two easy ways to move focus from attachment pane to subject:

• Shift+TAB
• Subject Access Key (alt+S in en-US)

I recommend wontfix for this bug 1519328.

Comment 3

[Jean-Philippe MENGUAL]

Hi,

Interestingly, reporter of this bug 1519328 also filed bug 1519346 whose STR involve focusing newly added attachments to act on them, which seems somewhat contrary to the demand of this bug.

No it is not, it is perfectly consistent.

• when a blind person adds an attached file to a message, it is really not easy for him/her to loose its localisation in his/her message body due to the movement of the caret from the message to the attached files area.
• however, once finished his/her message, or at any desird time actually, the user may need to know the list of the attached files. In such case, while you just need to have a look on the list, a blind user needs to bring the caret in the list with shift-tab. When he does this, of course, he browses such list via arrow keys as the screen reader reads just one line per line (expected). And to get this browse possible (even if there is just one line), the blind person needs to have the information about the attached filename when bringing the caret/focus on the attachments list.

Hence 2 bugs: one because the automatic movement is really confusing; the other because having no feedback on the attached filenames when the user requests this via shift-tab then arrow key is worse, he does not know the files he attached and cannot check them.

(In reply to Thomas D. from bug 1519346 comment #3)

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 (select, then F2)
• 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)

• focus in attachment pane also assists to add more attachments (if we fix a tree bug that when no attachments are selected, we don't show the attachment list context menu).

Well either the user uses the mouse, then he places the pionter on the area and enable the context menu; or he uses the keyboard only, then he will prefer menu via alt-m then Attachments command. Moving the focus/caret itself in the area does not seem useful for any usecase I experience with users of Thunderbird.

As laid out in Bug 1428977 comment 0, it's common practice in other widespread software that newly added items get focus, e.g. files which you just pasted into Explorer, or images just inserted into MS Word, so we're both ux-consistent and helpful here.

Because in such contexts, the focus does not change the context, it stays in the document or the file manager. In a message, moving the focus out of the body results a high context change, somewhat confusing when inserting an attachment while writing a message.

(In reply to Alex ARNAUD from bug 1519346 comment #0)

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 screen readers get disoriented when they are in attachment pane because the pane and/or its children don't communicate correctly. We should fix that instead of this bug.

(In reply to Alex ARNAUD from comment #0)

This is really annoying issue for keyboard-only users like blind people who have a line by line representation of screen.

Looking at the above list of feasible actions after adding, I'd believe that keyboard-only users including the blind can actually benefit a lot from the new behaviour of focusing attachments after adding them, e.g. to check using their screen readers if the right attachments were added.

That is necessary, indeed. But if not done on-demand and if done "forced" by the program, some users will be confused. The usual case is: I write a message, I attache some file when I am writing because I think of it and don't want to forget, I go on writing. With this behavior, the user continues but... argh the focus is no longer in the message body area. Without this behavior, the users continues writing and once finished: "hmmm do I have all the attachmens I desire"? shift-tab and arrow keys to browse the list.

Moving the caret/keyboard focus unexpectedly could make them unable to understand what's happen and how to come back on the body of the message

The only unexpected thing about moving focus is bug 1519346; nothing special about focus following the action, actually consistent with other apps, see above.

There are two simple ways to move focus from attachment pane (back) into body:

1. press ESC in focused attachment pane (will first clear selection of attachments if any, then move focus into body)
2. press TAB once, as body is the next element in the TAB sequence

Indeed. I have just tested that the focus, after having pressed ESC or Tab, is back to the appropriate location in the mody mesage window. The user just needs to be aware of this, and change his habits as mail clients usually do differently and the user expects such behavior, not this in Thunderbird.

(or subject)

Two easy ways to move focus from attachment pane to subject:

• Shift+TAB
• Subject Access Key (alt+S in en-US)

I recommend wontfix for this bug 1519328.

I recommend to fix in order not to confuse newbie users or those coming from other mail clients.

Regards

Comment 4

[Thomas D. (:thomas8)]

(In reply to Jean-Philippe MENGUAL from comment #3)

Thanks Jean-Philippe for your user feedback.

No it is not, it is perfectly consistent.

• when a blind person adds an attached file to a message, it is really not easy for him/her to loose its localisation in his/her message body due to the movement of the caret from the message to the attached files area.
  [snip]
  Indeed. I have just tested that the focus, after having pressed ESC or Tab, is back to the appropriate location in the mody mesage window. The user just needs to be aware of this, and change his habits as mail clients usually do differently and the user expects such behavior, not this in Thunderbird.

If we fix bug 1519346, focus will be correctly reported to be in attachment pane. Otherwise, apart from habit formation, I am still failing to see the big element of surprise that adding attachments ends up with focus on the just added attachments. After adding recipients, your focus is in recipients. After adding subject, it's in subject. After adding attachments, it's in attachments. And msg body is just one TAB or ESC away.

I recommend wontfix for this bug 1519328.

I recommend to fix in order not to confuse newbie users or those coming from other mail clients.

Imho newbie users can't be affected because there's no habit formation yet. Sometimes we want to be better than other mail clients. Other mail clients have less attachment-related actions, we have a lot. So I'd maintain that focusing just added attachments is helpful/efficient for many attachment-related scenarios which are likely to occur after adding, plus it's simple to remove focus again. There's no difference between pressing TAB (once/twice) to go from subject to body or pressing TAB to go from attachments to body. And ESC is a no-brainer once discovered (unfortunately not yet documented).

Comment 5

[Thomas D. (:thomas8)]

Richard, I suggest wontfix for this bug, or perhaps a pref if we want to preserve the legacy behaviour. What do you think?
We implemented a small change of focus behaviour in bug 1428631, so the current behaviour is intentional / by design. It has also been with users for some time now since TB 60, and I'm not aware of any other complaints except reporter's, who has also softened his stance and admitted that it's more about habit formation.

Current behaviour:
Just after adding attachment(s), focus attachment list (typically 1st item has focus)
to allow immediate further action on attachments:

• Rename

• Reorder

• Browse the list to check if all the right files were added (number, file names)

• Open attached files to double-check if it's the correct file / file version / content

• Remove accidentally/wrongly added attachments

• ux-consistent externally with similar action of pasting files into file manager (or inserting elements like images into word processor): just-added item has focus

• ux-consistent internally: focus follows action:

  • add recipient -> focus in recipients;
  • add subject -> focus in subject;
  • add attachments -> focus in attachments;
  • press TAB when done with one element to proceed to the next

• Easy to de-focus and focus message body (next in tab sequence): TAB or ESC (for folks used to the legacy behaviour, this might appear as an extra step, but it really isn't because they'll do their extra steps either when they need to act on attachments, or when they have to move on to other elements (e.g. from subject to body), except if coming from and going back to body).

• Stable, predictable focus position when adding attachments (allows for habit formation / muscle memory patterns).

• Whenever the attachment pane gets shown, it has focus (also after drag and drop, or click on minimized pane's paperclip to restore).

• Note that we have plans to enhance the auto-focus/selection behaviour of newly added attachments even further (bug 1428977).

• I maintain that if the focus on attachment pane is announced correctly (seems to work currently), this can be especially helpful for people like reporter who rely on screen readers, e.g. to double-check or otherwise act on just-added attachments in one go and then proceed with the next action. There's nothing "annoying"/"unpredictable"/"unwarranted" about focus following your actions, that's actually quite predictable and reliable.

• That said, of course all the other current accessibility bugs (in the context of de-XUL / de-XBL) must be fixed by those who have that knowledge (I don't): e.g. trunk's failure to cursor down in attachment list, or failure to announce attachment names.

Legacy behaviour:
Just after adding attachment(s), return focus to where it was before
(e.g. recipients | subject | message body), assuming that attachments are done with:

• Focus back to previous control: if that's already done, requiring extra key presses to move focus to the next element
• Harder to act on just-added attachments: Any further action requires extra step of focusing the attachment list first (Alt+M).
• Easy to add attachments as a peripheral action while working on msg body: Back to cursor position in msg body right after adding attachment(s).

It's hard to tell how people are actually using focus without doing mass metrics, but surely focusing what you've just added can't be wrong, whereas going back to your previous focus location may or may not be the helpful thing to do, depending on workflows.
I personally rename and content-check attachments immediately after adding quite often, but someone who adds attachments on-the-fly while editing message body and never touches them again might prefer the legacy behaviour.

Comment 6

[Richard Marti (:Paenglab)]

It's not so easy to decide here as a normal sighting. But yes, focus follows action is normally the standard. With bug 1519346 and bug 1526811 it should be better to know where the focus is.

Comment 7

[Jorg K (CEST = GMT+2)]

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

We implemented a small change of focus behaviour in bug 1428631, so the current behaviour is intentional / by design. It has also been with users for some time now since TB 60, and I'm not aware of any other complaints except reporter's, who has also softened his stance and admitted that it's more about habit formation.

Sorry guys, it is NOT OK AT ALL to ignore the input from our vision-impaired users here. Alex and Jean-Philippe represent this group of users.

It is simply untrue that the reporter Alex, who only commented ONCE, "softened his stance". Impossible since he only commented once.

So please get this fixed. I tried TB 52 and when adding an attachment via the menu, the cursor is left where is was before. We must restore this behaviour, be it with an option.

Comment 8

[:aceman]

Attachment: 1519328.patch

OK, what about this? Based on a pref, not focus the attachment pane when attachments are added, but focus it when toggling the pane manually.

Comment 9

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #7)

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

We implemented a small change of focus behaviour in bug 1428631, so the current behaviour is intentional / by design. It has also been with users for some time now since TB 60, and I'm not aware of any other complaints except reporter's, who has also softened his stance and admitted that it's more about habit formation.

Sorry guys, it is NOT OK AT ALL to ignore the input from our vision-impaired users here. Alex and Jean-Philippe represent this group of users.

It is also NOT OK AT ALL to just ignore the painstaking UX discussion which has taken place in this bug and falsely claim that we have ignored the input of our vision-impaired users, whereas all of my detailed comments in this bug have responded to every aspect which was brought forward.

It is simply untrue that the reporter Alex, who only commented ONCE, "softened his stance". Impossible since he only commented once.

Sorry, it was Jean-Philippe and not Alex (reporter), but as you said they represent the same group of users. Jean-Philippe said in comment 3:

Indeed. I have just tested that the focus, after having pressed ESC or Tab, is back to the appropriate location in the [message body] window. The user just needs to be aware of this, and change his habits.

So imho "habit formation" is a different story and does not in itself constitute an actual accessibility problem or even inaccessibility. As soon as we fix the real access problems where the attachment pane and its items do not properly communicate themselves to screenreaders, and even cursor fails on trunk, there's no significant access problem here. It's just not true that vision-impaired users will "get lost" if we focus attachment pane after adding attachments and the screen reader properly communicates that. Unless if you can tell me why having to use Shift+Tab or Alt+M to go back into attachment pane (legacy) is better/easier than having to use Tab or ESC to get back into body (current). For any type of user, that looks more like a question of personal preference and individual workflows.

So please get this fixed. I tried TB 52 and when adding an attachment via the menu, the cursor is left where is was before. We must restore this behaviour, be it with an option.

As I have shown in the discussion of this bug, there's no access problem here which would actually necessitate restoration of the legacy behaviour. At best, it's a matter of habit formation, personal preference, maybe convenience depending on scenario, but we don't have any mass metrics to know the focus patterns which are best for the majority of users. Just leaving focus "where it was before" is not necessarily helpful, e.g. for all cases where the previous element in the tab sequence has already been completed (recipient or subject). On the other hand, my comment 5 has an extensive list of advantages of the current behaviour over the legacy behaviour (for any type of users).

I'm not against a pref for this if we agree that it's needed, but whilst the personal experience input of our vision-impaired users is appreciated, it must be subject to the same general processes of UX analysis, informed by UX principles. "Focus follows action" is one such principle, and it doesn't prejudice accessibility in any way.

Comment 10

[Thomas D. (:thomas8)]

Comment on attachment 9046169 [details] [diff] [review]
1519328.patch

Review of attachment 9046169 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, if we want the pref, we need something like this.
I'll add a patch with some nits changed, and some more edge cases covered.

::: mail/components/compose/content/MsgComposeCommands.js
@@ +4998,4 @@
>   *                         "hide":   hide attachment pane
>   *                         "toggle": toggle attachment pane visibility
> + * @param {Boolean} aForceFocus  If true, always focus the opened attachment pane.
> + *                               If false, never focus attachment pane.

If omitted, controlled by pref.

@@ +5014,5 @@
>        // If attachment pane is currently shown:
>        if (!bucketHasFocus && eventSource == "key") {
>          // If we get here via key_toggleAttachmentPane, here's where we mimick
>          // access key functionality: First focus the pane if it isn't focused yet.
> +        if (aForceFocus !== false)

This case constitutes access key functionality, which must focus always.

@@ +5033,5 @@
>        attachmentsBox.collapsed = false;
>        attachmentBucketSizer.collapsed = false;
>        attachmentBucketSizer.setAttribute("state", "");
> +      if (aForceFocus ||
> +          (aForceFocus === undefined && !bucketHasFocus &&

We only want to focus if the bucket doesn't have focus yet, so !bucketHasFocus must be the leading conditio sine qua non.

Comment 11

[Thomas D. (:thomas8)]

Attachment: 1519328 add-attachments-focus-pref.patch

This is Aceman's patch with some minor adjustments.

Comment 12

[Jorg K (CEST = GMT+2)]

Comment on attachment 9046179 [details] [diff] [review]
1519328 add-attachments-focus-pref.patch

Review of attachment 9046179 [details] [diff] [review]:
-----------------------------------------------------------------

Common practise to ask the original author for feedback.

::: mail/components/compose/content/MsgComposeCommands.js
@@ +5033,5 @@
>        attachmentsBox.collapsed = false;
>        attachmentBucketSizer.collapsed = false;
>        attachmentBucketSizer.setAttribute("state", "");
> +      if (!bucketHasFocus &&
> +          (aForceFocus || aForceFocus === undefined &&

This is a little ugly. You're testing truthy or a specific falsy. Why do you need to test for `undefined`?

Comment 13

[Magnus Melin [:mkmelin]]

Lt's try to avoid strange hidden prefs for things like this. They are not useful for the average user who will never ever find out, even more so in this case I'd think.

Seems to me, the current behaviour is ok, but we need to fix the other bugs so that it's clear to someone visually impaired where they are. After that, it's one tab away from being back in the body, unless I'm missing something.

Comment 14

[Jorg K (CEST = GMT+2)]

Yes, I know that you dislike extra prefs, but in this case it's the only way to restore the old behaviour for some users (like we did for the mailing list munging). It would have to go into the release notes and be spread by word of mouth for those affected.

To get back to the body, hitting tab does the trick, it's more difficult for the subject or other parts of the addressing widget. Shift-tab seems to select the subject, so quite fatal if you simply continue typing.

Comment 15

[Magnus Melin [:mkmelin]]

But restoring behaviour behind a pref isn't going to help people, since the won't find that. And it's unreasonable to have UI to select such a thing.

I'd suggest putting this on hold until the other bugs are fixed. Then we can figure out if there is a change needed.

The attachment list problems may (or may not) be different after we de-xbl those (bug 1523607)

Comment 16

[Jorg K (CEST = GMT+2)]

Comment on attachment 9046179 [details] [diff] [review]
1519328 add-attachments-focus-pref.patch

OK, let's clear the review for now.

Comment 17

[Alex ARNAUD]

Hello all,

Thanks for your involvement in this topic.

I've taken the time before answering to this to ensure to send you a message as useful as possible.

0. Context
   As stated by Jorg I'm myself visual-impaired (I'm using both screen magnifier and screen reader) and I'm teaching IT and Thunderbird to visual-impaired, beginners and elderly people.
   When I think of a feature, I think "how could it be logical to teach that to a user".

1. Comparison with other mail client
   I've tested both Windows 10 mail default client and Gmail and both of them don't move the caret after adding attachment. As I remember when I used Outlook it doesn't move the caret.

2. About the argument of "no user complain"
   a) I'm not sure it's the good way to debate about this behavior, most of the time users stop using software when it doesn't fit their needs or just don't have the technical and languages skills to report issues.
   Also I can argue: the old behavior doesn't create frustration that has created plenty of reported issue, isn't it?

b) As your feedback made me have a doubt, I requested the opinion to the users I trained: 80 persons since 2017. 15 answered. The result is:

• beginners who learned TB 52 behavior would be somewhat disturbed by the new behavior. Because TB, according some words in a message, reports that an attachment seems to be needed. People tend to attach it immediately. If they would attach it before or after writing the message, this new behavior would not be a disturb. As this notification makes them attach the file during the writing, they do not understand why they cannot just go on writing. And I can tell you that the fact to press esc or tab to be back to the body of the message is hard to explain to a non computing and beginner user. He feels confused.
• former Windows users say that it is a change of habit and say "hmmm useless but if there are good reasons, we are usual with this kind of weird changes..."
• advanced users don't care.

3. Restoring the old behavior seems reasonable to me
   To be consistent with the behavior of other mail clients and what Thunderbird has always done, I suggest to restore the old behavior.
   I found the new behavior not representative of what I see with the user I help (especially blind). They add an attachment and continue to write their mail, they rarely drop or remove the the attachment. Pressing a shortcut to move inside the attachments lists is what I consider logical.

4. To balance: make the new feature optional
   I understand some of you want to make design changes. So why not creating an option to let user choose the desired behavior? Such approach has success (eg. option to open messages in a tab or a new window, very useful for accessibility).

Best regards,
Alex.

Comment 18

[Patrick ZAJDA]

As a blind user, I find old behavior more reasonnable. When I am on a field and decide to add an attachment, when it is done the first thing I think is to continue what I did before so continue to use the field which was focused. Letting user to decide when they want to focus the attachment list avoid mistakes for beginners in particular.
Having the ability to choose the desired behavior is surely the best thing, with not focusing attachment list by default to avoid beginer users to make mistakes.

Comment 19

[Alex ARNAUD]

(In reply to Patrick ZAJDA from comment #18)

As a blind user, I find old behavior more reasonnable. When I am on a field
and decide to add an attachment, when it is done the first thing I think is
to continue what I did before so continue to use the field which was
focused. Letting user to decide when they want to focus the attachment list
avoid mistakes for beginners in particular.
Having the ability to choose the desired behavior is surely the best thing,
with not focusing attachment list by default to avoid beginer users to make
mistakes.

Thanks Patrick.

@Jorgk: Do you think we can move forward on the subject ? I hope my comment #17 was sufficient to help you to take a decision.

Best regards,
Alex.

Comment 20

[Jorg K (CEST = GMT+2)]

Alex, as you can see, I reopened the bug in comment #7 with fairly drastic words. Some action came after that and I'm in favour of restoring the original behaviour with an option, but options aren't always easy to discover.

Now the issue is sadly blocked by Magnus, the Thunderbird technical manager and module owner, see comment #15. So please direct all queries to him. I actually do not agree with his assessment that we should wait here as restoring the original behaviour or making it available with an option does not depend on fixing other breakage surrounding our de-XBL effort. In my opinion we could even ship that option in TB 60 ESR in the next point release or the one thereafter.

Comment 21

[Alex ARNAUD]

(In reply to Jorg K (GMT+1) from comment #20)

Alex, as you can see, I reopened the bug in comment #7 with fairly drastic
words.

I've seen, thanks a lot for that. It's why I've made testes and take time to answer.

Some action came after that and I'm in favour of restoring the
original behaviour with an option, but options aren't always easy to
discover.

As others mail client has the old behavior by default and as It is easier for keyboard-only users like blind I'm in favor to restore the old behavior by default.

Now the issue is sadly blocked by Magnus, the Thunderbird technical manager
and module owner, see comment #15. So please direct all queries to him. I
actually do not agree with his assessment that we should wait here as

OK. Can we discuss about that on IRC?

restoring the original behaviour or making it available with an option does
not depend on fixing other breakage surrounding our de-XBL effort. In my
opinion we could even ship that option in TB 60 ESR in the next point
release or the one thereafter.

I hope so. In the mean time, we're on TB 52.

Best regards,
Alex.

Comment 22

[Magnus Melin [:mkmelin]]

My comment 15 was actually with the nightly builds (and future) in mind. For 60, it's probably best to just revert to the previous behaviour.

Comment 23

[Jorg K (CEST = GMT+2)]

OK, based on comment #22, can we change the patch and re-instate the previous behaviour. I know some UX purists won't like it.

Aceman, you're the assignee.

Comment 24

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #14)

Yes, I know that you dislike extra prefs, but in this case it's the only way to restore the old behaviour for some users (like we did for the mailing list munging). It would have to go into the release notes and be spread by word of mouth for those affected.

To get back to the body, hitting tab does the trick,

hitting ESC does the trick, too

it's more difficult for the subject

It's obvious that keyboard focus can only be in one place and moving it to another place needs some extra key presses. It's also obvious that within the tab sequence, some elements will require TAB to move forward, and others will require Shift+TAB to move backwards. Blind people probably know that best. I don't see any major difficulties here. My questions are:

• Why is Alt+S to go back to subject (current behaviour) more difficult than Alt+M for attachment list (legacy behaviour)?
• What would be difficult even about pressing Shift+(Tab,Tab) to get back to subject? (current behaviour)
• What if a blind user has already typed the subject, then adds an attachment, and wants to proceed to body? That forces him to press Tab twice to go to body (legacy behaviour). How is that better/harder then Alt+S or Shift+(Tab, Tab) to go back to subject? (current behaviour)

or other parts of the addressing widget.

Dito. Obviously remote elements in the tab sequence are always harder to reach. That's not an argument either way, for or against.

Shift-tab seems to select the subject, so quite fatal if you simply continue typing.

I don't understand. Why would you simply continue typing after your screen reader has told you that you are now in attachment list? And what fatal error would occur from that?

Similarly, I would like to know from commenters which "mistake" beginners are going to make? For beginners without previous habit formation, it will be very easy to understand that attachments can be conveniently acted upon right after adding them, and when you're done with attaching, renaming, reordering, or checking your attachments, you just move focus with TAB (or ESC) as usual whenever you need to shift focus in the tab sequence.

Bottom line: What people find "convenient" / "efficient" or not, very much depends on their personal workflows (and much less on visual abilities as suggested here), and on habit formation. What about the blind person who wants to double-check, rename, reorder his attachments immediately after adding them, so as to be done with that part and avoid the extra step of going back into the list?

What I am missing here is a serious appreciation of the advantages and workflow consistency/efficiency for an assumed majority of users (including visually impaired) of having focus on attachments right after adding them. And just to press TAB or ESC to get into body really isn't that hard, and you can't be lost because your screenreader (after fixing the de-XBL/de-XUL bugs) will tell you exactly where you are.

Another question: How does a blind person find the attachment list when focus remains in body? What is more difficult about finding body over finding attachment list? I still suspect it's much more about habit formation than we'd all like to admit. I've suggested a new habit which can be very convenient and efficient: deal with your attachments easily right after adding them, then when you're done, press TAB or ESC to continue on message body.

That said, I am not refusing that the legacy behaviour can be convenient, too, for adding just one or two attachments on-the-fly, as a peripheral action, where you don't care much about them. As for myself, adding attachments is rarely peripheral, it's a high-focus (sic!) action where I want to make sure that my attachments are in perfect shape and order. Surely I'm not the only one who wants that.
So a pref with UI might be worth considering. Otherwise, whatever you wish.

Comment 25

[Thomas D. (:thomas8)]

In a nutshell: There was nothing much bad or wrong about the legacy behaviour, and it makes for a convenient workflow for users who don't focus much (pun intended) on their attachments. Other users (possibly including visually impaired, especially beginnners) may appreciate the convenience of being able to act on their attachments right after adding them, and focus-follows-action is a standard UX principle, so no surprises here. I don't know if that's purism. Possible actions on added attachments are plenty.

Comment 26

[Jorg K (CEST = GMT+2)]

Well, my two cents worth from someone not vision-impaired. I never noticed where the focus was and I've never used Ctrl+Shift+A or clicking on the paper clip. I'm always attaching with drag and drop and clearly that loses the focus from the subject or body. If I were to work on the attachments (rename, remove, reorder), I'd be happy to click them first. So the legacy behaviour I never noticed wouldn't affect me, I think. But there there are people who manoeuvre everything via the keyboard, and they need some stability as to where the focus is. But Alt+M gets those people there, doesn't it?

Comment 27

[Thomas D. (:thomas8)]

Adding attachment moves the keyboard focus from the body to the attachment pane since version 60

Fwiw: Imho the current summary is biased. An alternative presentation is that it's in the legacy behaviour that we move focus back to where it was, without knowing how helpful that really is (what if recipients or subject are already done?). In the current behaviour, we just keep focus where the current user action has taken it, assuming that it'll be helpful there, and we do NOT move it around... Why should it NOT stay in attachments if that's what we're currently editing?

Comment 28

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #26)

Well, my two cents worth from someone not vision-impaired. I never noticed where the focus was and I've never used Ctrl+Shift+A or clicking on the paper clip. I'm always attaching with drag and drop and clearly that loses the focus from the subject or body.

With drag n drop I'd think it's even more expected that the focus will be on what you just dropped. That's what always happens to files when you drag them around on windows: focus follows action.

If I were to work on the attachments (rename, remove, reorder), I'd be happy to click them first.

That's where we differ. Wearing my UX hat, I can never be happy about extra clicks which are not needed. I'm not happy having to click-focus something which I've just added. Admittedly, the question remains which workflow is more likely and more worthy to support: peripheral attaching which does not require any further focus, or attachment-centric where the focus is on allowing users to sort them out after adding.

So the legacy behaviour I never noticed wouldn't affect me, I think. But there there are people who manoeuvre everything via the keyboard, and they need some stability as to where the focus is.

Both the legacy and the current behaviour have stability and predictability of focus; after fixing our XBL/XUL problems, focus location will be correctly announced by screenreaders, too. We might even consider adding extra information for screenreaders, e.g. "press ESC to focus message body", i.e. screenreader will say something like "Attachment pane, 4 attachments, 1 out of 4 selected, A.txt, press ESC to focus message body.". I'm a keyboard-centric user that's why I have proposed this change in the first place.

But Alt+M gets those people there, doesn't it?

Yes it does. As I said, it's not like the legacy behaviour is totally out of order, especially after I have improved the keyboard accessibility.

Comment 29

[:aceman]

So what was agreed here? Previous behaviour, a pref or what?

Comment 30

[Jorg K (CEST = GMT+2)]

Previous behaviour, no pref, see comment #22.

Comment 31

[Peter Vágner]

@Alex @Jean Philippe I love your work, I like when we can share some amazing news related to a11y however frankly this is not accessibility related as I'm seeing it. This is more about preference choices. You have both argued that focussing attachments list after adding an attachment is distraction however I can argue the same way that If I am adding attachment or more attachments I like to focus list of them to verify I did it right.
I know it's much more than personal preferences when teaching non tech savvy blind individuals however what I think you should try to be a bit stronger about when teaching is that you should emphasize on all the possible occassions to those learners that rule #1 for them is "do listen to your screen reader" and avoid performing automatic actions resulting from your habits.

I'm with Thomas D and Magnus Melin about this one.
Let's revert it for TB 60 if you like it that way however let's move forward for the future.

I really apologize to my fellow blind friends by saying this. However we can't abuse your gratitude towards us visually or otherwise impaired people by pushing for our preferences the same way as if these were real critical accessibility issues. @Jorg K I am looking at you right now. For sure you are an amazing person, however you don't have strong personal opinion on this and you were in a position to help @Alex and @Jeanphilippe with this to the best of your abilities.
Please keep such a helpfull attitude for real accessibility issues and reconsider this single one.
If you are still in doupd perhaps you can reach out to a11y guys at Mozilla for some quick respectable hints.

Comment 32

[Alex ARNAUD]

(In reply to Peter Vágner from comment #31)

I know it's much more than personal preferences when teaching non tech savvy
blind individuals however what I think you should try to be a bit stronger
about when teaching is that you should emphasize on all the possible
occassions to those learners that rule #1 for them is "do listen to your
screen reader" and avoid performing automatic actions resulting from your
habits.

If all people have your technical skills and brain ability I would agree with you but we're teaching blind, elderly, visual-impaired for 4 years and for some of them it's just not possible to teach them logically, we're forced to train them procedurally.

Also your message demonstrates difference of approach between us. We're not only focusing on accessibility as a technical point of view but also from a user point of view.

Best regards,
Alex.

Comment 33

[Alex ARNAUD]

(In reply to Jorg K (GMT+1) from comment #23)

OK, based on comment #22, can we change the patch and re-instate the
previous behaviour. I know some UX purists won't like it.

Aceman, you're the assignee.

@aceman, Do you still plan to work on this ? As I understand a decision has been taken in the beginning of this month on this and since that nothing happen.

Best regards,
Alex.

Comment 34

[:aceman]

Attachment: 1519328.patch

Try run:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=20cef34869ce861dc2deeac108ac0c56844f162e

Comment 35

[Jorg K (CEST = GMT+2)]

Comment on attachment 9053770 [details] [diff] [review]
1519328.patch

Hmm, perhaps this is overdoing it a bit. Now the focus stays where it was even if something is attached via drag and drop. Surely you've just moved the cursor there, so the thing might as well have the focus, no?

Comment 36

[:aceman]

Attachment: 1519328.patch v2

What about this?

Comment 37

[Jorg K (CEST = GMT+2)]

Comment on attachment 9055281 [details] [diff] [review]
1519328.patch v2

Review of attachment 9055281 [details] [diff] [review]:
-----------------------------------------------------------------

OK, but trying to test the focus using the arrow-keys, I get "JavaScript error: chrome://messenger/content/mailWidgets.xml, line 150: TypeError: box is null". That code above is `let box = this.scrollbox;`. I'll file a bug.

Comment 38

[Jorg K (CEST = GMT+2)]

Does Alt+M still focus the bucket? I can't try it due to bug 1526811 comment #6.

Comment 39

[:aceman]

That one is kinda strange now, I'll investigate it.

Comment 40

[Jorg K (CEST = GMT+2)]

Works fine with the patch from bug 1526811.

Comment 41

[:aceman]

Attachment: 1519328.patch v3

I think it didn't work as well. Try this one. Thanks for fixing the other bug, that helped.

Comment 42

[Jorg K (CEST = GMT+2)]

Comment on attachment 9055616 [details] [diff] [review]
1519328.patch v3

Review of attachment 9055616 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/components/compose/content/MsgComposeCommands.js
@@ +5914,5 @@
>      // Add attachments if any.
>      if (attachments.length > 0)
>        AddAttachments(attachments);
> +
> +    bucket.focus();

I guess you want to move this into the if-clause above, no? If the was nothing added, no need to focus.

Comment 43

[:aceman]

That's subjective. If you dragged something into the bucket and for some reason it didn't do anything (e.g. you do not have perms, or the file is already attached), should the focus be in the bucket or not?

Comment 44

[Jorg K (CEST = GMT+2)]

Comment on attachment 9055616 [details] [diff] [review]
1519328.patch v3

Excellent, I'm fully convinced :-)

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8a8f1584d1f4
Do not focus attachment pane if an attachment is added via the keyboard. r=jorgk

Comment 46

[Jorg K (CEST = GMT+2)]

TB 67 beta 2:
https://hg.mozilla.org/releases/comm-beta/rev/532adb62e1c9590ef039aba0ad3eceaf953aea33

Comment 47

[Jorg K (CEST = GMT+2)]

TB 60.7 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/70ce813285f678f675a7ef2d83af7c4c82c47640