1538497 - Consider making some tabstops point to fixed items to make tabbing more predictable

Status: NEW

(Firefox :: Keyboard Navigation, enhancement, P5)

Description

[:Gijs (he/him)]

In bug 1538405, Alice pointed out that tabbing can be a bit unpredictable right now depending on page state etc.

(In reply to Alice0775 White from bug 1538405 comment #1)

And sometimes [when pressing 'tab' from the URL bar] Toggle reader view button gets focus if the reader view is available....

We could consider trying to somehow give (some) keyboard stops a "fixed" target, instead of just focusing the left- (start, ie right in RTL) most item in their group of items, though we'd still need to ensure that item is focusable because it might be hidden (e.g. we don't show the page action button on about:newtab) or disabled (e.g. back/fwd) or removed (e.g. reload/home, for the items before the url bar).

Jamie, what do you think about this idea?

Comment 1

[:Gijs (he/him)]

+ni this time (for comment #0).

Comment 2

[James Teh [:Jamie]]

I'm not a fan of this for two reasons:

1. Tab/shift+tab move between "groups" of buttons. Changing the start point dynamically makes it unclear where the groups start and end. Right now, it's consistent and clear: they always land at the start of the group.
2. Closely related is the fact that screen reader users don't even have the benefit of visual separation to determine where groups start. If tab appears to frequently land on the first button in the group, a screen reader user won't necessarily know that there are buttons before in cases where a tab stop is pinned to some later button in the group.

One thing I did consider (and which I implemented in an earlier prototype of this functionality) was having tab/shift+tab "remember" the position in the group that the user last focused. While this too means the tab order changes, it only changes due to explicit user action. The benefit of this is that this makes it more efficient for the user to access frequently used buttons; e.g. if they frequently use a particular extension, that button will remain in the tab order without them having to arrow to it.

Gijs, thoughts?

Comment 3

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #2)

I'm not a fan of this for two reasons:

1. Tab/shift+tab move between "groups" of buttons. Changing the start point dynamically makes it unclear where the groups start and end. Right now, it's consistent and clear: they always land at the start of the group.
2. Closely related is the fact that screen reader users don't even have the benefit of visual separation to determine where groups start. If tab appears to frequently land on the first button in the group, a screen reader user won't necessarily know that there are buttons before in cases where a tab stop is pinned to some later button in the group.

One thing I did consider (and which I implemented in an earlier prototype of this functionality) was having tab/shift+tab "remember" the position in the group that the user last focused. While this too means the tab order changes, it only changes due to explicit user action. The benefit of this is that this makes it more efficient for the user to access frequently used buttons; e.g. if they frequently use a particular extension, that button will remain in the tab order without them having to arrow to it.

Gijs, thoughts?

Yeah, the memory thing might make sense... the problem we can't keep it in sync between windows (because windows can have different sizes so the tabstops will be different because some items might be in the overflow menu) and that will still add more inconsistencies / unexpected behaviors...