1776657 - Inconsistent focus after activating the "Add <field>" buttons in the vcard contact form

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[Henry Wilkes (they/them) [:henry-x]]

When you activate the "Add <field>" buttons the focus often moves to an unexpected place.

Usually, we should focus the first form element that gets revealed. But often it will focus the first text input instead.

Add email address button

Actual focus: The email text input.
Expect: The email type selector.

Add website button

Actual focus: The website text input.
Expect: The website type selector.

Add address button

Actual focus: Focus does not move.
Expect: The address type selector.

Add phone number button

Actual focus: The number input.
Expect: The number type selector.

Add timezone button

Actual focus: Remains on the now-hidden button.
Expect: The timezone selector.

Add chat account button

This is fine.

Add special dates button

Actual focus: The year input.
Expect: The date type selector.

Add notes button

Actual focus: Remains on the now-hidden button.
Expect: The notes text input.

Add organizational properties button

This is fine.

Comment 1

[u695164]

(In reply to Henry Wilkes [:henry] from comment #0)

When you activate the "Add <field>" buttons the focus often moves to an unexpected place.

Usually, we should focus the first form element that gets revealed. But often it will focus the first text input instead.
[...]

For:

• Add email address button
• Add website button
• Add phone number button

I do think that it's more convenient for mouse users to focus the text input.
But you are right. We should focus the first form element. This is confusing for keyboard users.

Comment 2

[Thomas D. (:thomas8)]

Similar to what Nicolai has commented, I'm not sure if most of the expected results (focusing the type selector after clicking an add button) will be convenient for mouse users. We should reflect this very carefully - for users who are not interested in setting type fields, or who just want to quickly capture some data, first focusing the type selector instead of the actual input can create undesirable click feasts.
Even for keyboard users, the same might apply. Going back from the input to the type selector (if needed) with Shift+Tab isn't all that hard...
If we think this is required for keyboard users, I think we should seriously consider having a different and more convenient focus for mouse users.

Comment 3

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Thomas D. (:thomas8) from comment #2)

Similar to what Nicolai has commented, I'm not sure if most of the expected results (focusing the type selector after clicking an add button) will be convenient for mouse users. We should reflect this very carefully - for users who are not interested in setting type fields, or who just want to quickly capture some data, first focusing the type selector instead of the actual input can create undesirable click feasts.

The force-moving of focus is usually most disruptive to keyboard and non-visual users, and in this case moving focus to a middle entry is confusing and unexpected. So this has priority to me.

Even for keyboard users, the same might apply. Going back from the input to the type selector (if needed) with Shift+Tab isn't all that hard...

I think this statement is assuming a user has a visual reference to know:

1. Where their focus was moved to in relation to where they were.
2. All the form entries that were revealed.

If you are using a screen reader, it takes some work to establish both of these after a force focus. Because of this, the priority is to end up somewhere intuitive.

Going back from the input to the type selector (if needed) with Shift+Tab isn't all that hard...

Based on the mock ups and the fact that we placed the selector first, I think we expect it to be chosen first and used frequently. To illustrate, your suggestion is for users to do:

1. Enter on "Add website" button.
2. Shift+Tab.
3. Select the type.
4. Tab.
5. Enter the name.

This is not a good pattern. If we expected the type to be secondary, then it would make more sense to place the selector second rather than first.

Moreover, for a user who can use a keyboard and speed is a priority: changing the type is usually faster with a keyboard. And if the type is not important, the next input is just one unmodified Tab press away.

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1776657 - Focus first revealed form element when adding a contact field. r=aleca

Comment 5

[Alessandro Castellani [:aleca]]

I took a few days to test it and consider the implications of this change.
Indeed, I agree with Henry on this change for 2 main reasons:

• Blind users won't have any idea that a Type selector is before the currently focused input filed.
• Keyboard users or mouse users can easily change the focus (which is visible, so no confusion there) to the desired field with a click or tab. We're not adding 20 clicks, this is pretty straightforward.

Skipping the natural focus flow of form elements for mouse-centric convenience is not good.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3d4952f80e0d
Focus first revealed form element when adding a contact field. r=aleca

Comment 7

[Henry Wilkes (they/them) [:henry-x]]

Comment on attachment 9283420 [details]
Bug 1776657 - Focus first revealed form element when adding a contact field. r=aleca

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: No focus or misplaced focus when adding a new field. Especially impacts keyboard and screen reader users.
Testing completed (on c-c, etc.): Added mochitest and tested on Daily
Risk to taking this patch (and alternatives if risky): Low. This is a relatively small patch with mild changes.

Comment 8

[Wayne Mery (:wsmwk)]

Comment on attachment 9283420 [details]
Bug 1776657 - Focus first revealed form element when adding a contact field. r=aleca

[Triage Comment]
Approved for beta

Can you or thomas test this once the beta is built?

Comment 9

[Henry Wilkes (they/them) [:henry-x]]

Beta testing seems like thomas's domain.

Comment 10

[Rob Lemley [:rjl]]

Thunderbird 103.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/f1533166e4d6

Comment 11

[Rob Lemley [:rjl]]

Comment on attachment 9283420 [details]
Bug 1776657 - Focus first revealed form element when adding a contact field. r=aleca

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: No focus or misplaced focus when adding a new field. Especially impacts keyboard and screen reader users.
Testing completed (on c-c, etc.): Added mochitest and tested on Daily, 103.0b4
Risk to taking this patch (and alternatives if risky): Low. This is a relatively small patch with mild changes.

Comment 12

[Wayne Mery (:wsmwk)]

Comment on attachment 9283420 [details]
Bug 1776657 - Focus first revealed form element when adding a contact field. r=aleca

[Triage Comment]
Approved for esr102

Comment 13

[Rob Lemley [:rjl]]

Thunderbird 102.0.2:
https://hg.mozilla.org/releases/comm-esr102/rev/757812e177d8