Bugzilla

Also note that having an unpredictable number of tab stops makes it much harder to develop efficient use patterns ("muscle memory").
If I have a message with 2 To-recipients and 100 CC recipients as a keyboard-only user, and I want to add a BCC-recipient, I'm not sure if "tab, tab, tab, tab... ok, now in CC... tab, tab, tab, tab... oh, this doesn't work... let me use END... then TAB again for CC" is very memorable compared to "Tab -> To. Tab-> CC. Tab -> BCC" (always). Also depends where exactly we want to put the focus if we make each recipient field (To, CC, BCC) a single stop - first item focus (without selection) or cursor after last item. I think those Aria rules said first item somewhere. Then, pressing END when I really want to reach the END of that field makes more sense imo then just using END as a clumsy workaround to escape an unfinite tab sequence.

One aspect which I haven't fully considered is autocomplete. There's no problem to allow TAB to autocomplete the last item and remain in the field component. It might be trickier if we allow autocompletion for creating pills between existing pills. In general, my impression is that tab is much less used for autocomplete than it was in the past. Check FF location bar - you can only auto-complete with Enter, tab navigates (micro-navigation in this case because we're in location bar edit mode).

Also note that having an unpredictable number of tab stops makes it much harder to develop efficient use patterns ("muscle memory").
If I have a message with 2 To-recipients and 100 CC recipients as a keyboard-only user, and I want to add a BCC-recipient, I'm not sure if "tab, tab, tab, tab... ok, now in CC... tab, tab, tab, tab... oh, this doesn't work... let me use END... then TAB again for CC" is very memorable compared to "Tab -> To. Tab-> CC. Tab -> BCC" (always). Also depends where exactly we want to put the focus if we make each recipient field (To, CC, BCC) a single stop - first item focus (without selection) or cursor after last item. I think those Aria rules said first item somewhere. Then, pressing END when I really want to reach the END of that field makes more sense imo then just using END as a clumsy workaround to escape an indefinite tab sequence.

One aspect which I haven't fully considered is autocomplete. There's no problem to allow TAB to autocomplete the last item and remain in the field component. It might be trickier if we allow autocompletion for creating pills between existing pills. In general, my impression is that tab is much less used for autocomplete than it was in the past. Check FF location bar - you can only auto-complete with Enter, tab navigates (micro-navigation in this case because we're in location bar edit mode).

Also note that having an unpredictable number of tab stops makes it much harder to develop efficient use patterns ("muscle memory").
If I have a message with 2 To-recipients and 100 CC recipients as a keyboard-only user, and I want to add a BCC-recipient, I'm not sure if "tab, tab, tab, tab... ok, now in CC... tab, tab, tab, tab... oh, this doesn't work... let me use END... then TAB again for CC" is very memorable compared to "Tab -> To. Tab-> CC. Tab -> BCC" (always). Also depends where exactly we want to put the focus if we make each recipient field (To, CC, BCC) a single stop - first item focus (without selection) or cursor after last item. I think those Aria rules said first item somewhere. Then, pressing END when I really want to reach the END of that field makes more sense imo then just using END as a clumsy workaround to escape an indefinite tab sequence.

One aspect which I haven't fully considered is autocomplete. There's no problem to allow TAB to autocomplete the last item and remain with a concluding text cursor in the field component. It might be trickier if we allow tab for autocompletion to create pills between existing pills. But I think it would still feel OK if tab just autocompletes the current item and offers me a cursor insertion point after that item (or maybe exceptionally focuses only the next item as long as we don't have insertion points), but tab again gets me out to the next field (e.g. CC). In general, my impression is that tab is much less used for autocomplete than it was in the past. Check FF location bar - you can only auto-complete with Enter, tab navigates (micro-navigation in this case because we're in location bar edit mode).

Also note that having an unpredictable number of tab stops makes it much harder to develop efficient use patterns ("muscle memory").
If I have a message with 2 To-recipients and 100 CC recipients as a keyboard-only user, and I want to add a BCC-recipient, I'm not sure if
`"tab, tab, tab, tab... ok, now in CC... tab, tab, tab, tab... oh, this doesn't work... let me use END... then TAB again for BCC"`
is very memorable compared to
`"Tab -> To. Tab-> CC. Tab -> BCC" (always)`.
Also depends where exactly we want to put the focus if we make each recipient field (To, CC, BCC) a single stop - first item focus (without selection) or cursor after last item. I think those Aria rules said first item somewhere. Then, pressing END when I really want to reach the END of that field makes more sense imo then just using END as a clumsy workaround to escape an indefinite tab sequence.

One aspect which I haven't fully considered is autocomplete. There's no problem to allow TAB to autocomplete the last item and remain with a concluding text cursor in the field component. It might be trickier if we allow tab for autocompletion to create pills between existing pills. But I think it would still feel OK if tab just autocompletes the current item and offers me a cursor insertion point after that item (or maybe exceptionally focuses only the next item as long as we don't have insertion points), but tab again gets me out to the next field (e.g. CC). In general, my impression is that tab is much less used for autocomplete than it was in the past. Check FF location bar - you can only auto-complete with Enter, tab navigates (micro-navigation in this case because we're in location bar edit mode).