Open Bug 1418973 Opened 2 years ago Updated 3 months ago

[meta] Improve keyboard accessibility of the toolbar and its buttons

Categories

(Firefox :: Toolbars and Customization, enhancement)

57 Branch
enhancement
Not set

Tracking

()

ASSIGNED

People

(Reporter: Gijs, Assigned: MarcoZ)

References

(Depends on 8 open bugs)

Details

(Keywords: meta)

Keyboard users do not have a way of interacting with toolbar items. This includes the main hamburger menu, the overflow menu, main toolbar buttons, and action items in the location bar. This is unfortunate, because it means all of those items need a keyboard-accessible alternative (and not all of them have one today). 

Previously, we struggled to make some of these items keyboard accessible in part because add-ons could put whatever they liked in the toolbar/menu. Now that we control all the widgets that go into these toolbars and the overflow/hamburger panel, it should be possible to do better in terms of keyboard a11y.

We've started doing some of this in bug 1354144 (arrow key navigation in panelmultiview subviews) which should work in the main hamburger panel, though there's no real reason (off-hand) it shouldn't also work in e.g. the overflow panel -- though we'll need to think a bit about what happens if the search box is in there I don't think that needs to block enabling it there.

For webextensions, we provide support for the add-on to define a keyboard shortcut, and they can programmatically invoke the same (browser/page) action that way.

All we really need is a plan for how this should work for the toolbar... I'm not convinced, for instance, that [tab] should tab through all the items, and trying to come up with individual shortcuts for each button also seems difficult given that we're already finding it difficult to come up with shortcuts anyway (though we should probably have a shortcut for the hamburger button, and maybe for the overflow one). Plus we'll need clear focus styling for buttons that is probably a bit less subtle than the hover styling.

dbolter, who could work on getting such a plan?
Flags: needinfo?(dbolter)
I think MarcoZ will drive this and will tap people for help.
Flags: needinfo?(dbolter) → needinfo?(mzehe)
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #1)
> I think MarcoZ will drive this and will tap people for help.

Correct.
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Flags: needinfo?(mzehe)
Depends on: 1425972
No longer depends on: 1425972
Over the past few weeks, I've come up with a keyboard proposal that should satisfy most requirements and be smarter than just tabbing through all the items. Gathered feedback from the team plus Gijs, and here's the plan, which will subsequently be divided into bugs blocking this one.

To accomplish this, the browser chrome needs to gain some more comprehensive tab navigation. The general idea is that tabbing goes from one general container to the next, and arrow keys left and right navigate through the buttons of such a container. Exceptions are, of course, the address bar and search box, which require the user to type something in and use left and right arrows to review/change the typed text.
Unlike Chrome and Edge, which both have each and every item in the tab order, we’ll cut down the tab stops to a logical and still manageable number, and the items within each are then navigated in a different way to reduce clutter. Since the customizer can add items to each of the following, we should ensure a very comprehensive set of navigation that allows for full keyboard access. The tab order is as follows:

1. Tab strip. This is the bar that contains the open and pinned tabs. This already has a proper tab stop and left and right arrow key navigation. Items to pin, close and move the selected tab are accessible through the context menu, so the Close Tab buttons don’t need to have an extra focus stop. Closing a tab can, in addition, be accomplished via CTRL+W as well.

2. The buttons to the left of the main toolbar. In my profile, and I believe by default, these are Back, Forward, Home and Reload, but due to customization, could be anything. Left and right arrows cycle through, Space activates. If either end is reached, focus wraps around to the other end.

3. The Page Actions and Site Info etc. buttons surrounding the actual input box of the address bar. Previously, the Site Info/Security Info button was only reachable via shift-tabbing from the address field itself. This decision was made ten years ago and should now be revisited. Forward tabbing should, for the sake of symmetry and because we’re enhancing this one, be stopping here now, too. Left and Right arrows will cycle through the buttons to the left and right of the actual input box. This includes the Page Actions menu, any buttons put here, and any alerts that may be needing attention. Right now, these are separate tab stops, but I believe these are part of the buttons to the left of the actual input box, so they should be integrated and those extra tab stops removed.

4. The actual address field. This is the same that would be reached via CTRL+L, Alt+D or such.

5. The search box, if it has been enabled by the user or is still enabled from legacy profiles.

6. The buttons to the right of the search box (if enabled) or address bar. This is where, at least in my current profile, the Firefox menu button is, add-ons put their buttons by default etc. Same model as above: Left and right arrows move between buttons, wrapping around at each end to the other side. Space activates.

7. Next toolbar, the bookmarks toolbar I believe. Since buttons now can go here, too, the decision to not make this keyboard accessible from 2008 needs to be revisited, even though bookmarks themselves have a mirroring in the Bookmarks main dropdown menu from the (by default invisible) legacy menu bar.

8. The main document as usual.

I realize that this increases the number of tab stops from a minimum of 4 to 8. But since the reverse tab order already had at least one more tab stop traditionally, and parity is better than inconsistency, it is better to do it this way. Also, it is still less than the 15 I counted with Edge and Chrome. And it is always consistent, regardless of how many items there are in the actual toolbars.
(In reply to Marco Zehe (:MarcoZ) from comment #3)
> 3. The Page Actions and Site Info etc. buttons surrounding the actual input
> box of the address bar. Previously, the Site Info/Security Info button was
> only reachable via shift-tabbing from the address field itself. This
> decision was made ten years ago and should now be revisited. Forward tabbing
> should, for the sake of symmetry and because we’re enhancing this one, be
> stopping here now, too. Left and Right arrows will cycle through the buttons
> to the left and right of the actual input box. This includes the Page
> Actions menu, any buttons put here, and any alerts that may be needing
> attention. Right now, these are separate tab stops, but I believe these are
> part of the buttons to the left of the actual input box, so they should be
> integrated and those extra tab stops removed.

Note that visually, it'd be confusing if the items on the left of the input (security, site info) and the right (page actions, reader mode, popup blocked item) are in the same group that is navigable by something other than tab, but the address field itself (which is in the middle!) is in a different group.

I'd sooner have an additional tab stop so that there's 1 for the start (left-hand in LTR languages) side of the address bar, and 1 for the end (right-hand in LTR languages).

> 4. The actual address field. This is the same that would be reached via
> CTRL+L, Alt+D or such.
> 
> 5. The search box, if it has been enabled by the user or is still enabled
> from legacy profiles.
> 
> 6. The buttons to the right of the search box (if enabled) or address bar.
> This is where, at least in my current profile, the Firefox menu button is,
> add-ons put their buttons by default etc. Same model as above: Left and
> right arrows move between buttons, wrapping around at each end to the other
> side. Space activates.

Note that there can be buttons between the address bar and search bar as well.
(In reply to :Gijs from comment #4)
> I'd sooner have an additional tab stop so that there's 1 for the start
> (left-hand in LTR languages) side of the address bar, and 1 for the end
> (right-hand in LTR languages).

OK, let's be consistent all the way through, then.

> Note that there can be buttons between the address bar and search bar as
> well.

Sigh... OK, *any* group of buttons will get its tab stop then regardless of where it is. I thought there were at least some limits of where these beasts can go. ;)
Depends on: 1436086
Depends on: 1436089
Depends on: 1436090
A nice follow-up bug could be filed to improve keyboard accessibility of the developer toolbox. Currently, it follows the document in tab order, but there are a lot of tab stops in there; and it does not participate in F6 order but probably should; and tab switching and control activation is inconsistent there.
(In reply to Yuri Khan from comment #6)
> A nice follow-up bug could be filed to improve keyboard accessibility of the
> developer toolbox. Currently, it follows the document in tab order, but
> there are a lot of tab stops in there; and it does not participate in F6
> order but probably should; and tab switching and control activation is
> inconsistent there.

I'm NI'ing Yzen for this, since he owns all things accessibility around the developer tools. I *think* we already have a bug on file for this. Yura?
Flags: needinfo?(yzenevich)
Yes we have bug 1242586, which is rather out of date. It was/is/and will be a major undertaking, and it is always on the radar.
Flags: needinfo?(yzenevich)
Component: Keyboard Navigation → Toolbars and Customization
(In reply to :Gijs (he/him; out 3-8 May) from comment #4)
> Note that visually, it'd be confusing if the items on the left of the input
> (security, site info) and the right (page actions, reader mode, popup
> blocked item) are in the same group that is navigable by something other
> than tab, but the address field itself (which is in the middle!) is in a
> different group.

This is going to be really tricky to deal with. The problem is that the actual <input> for the address field is part of an XBL binding, so it doesn't show up in the DOM from the toolbar's perspective.
Duplicate of this bug: 1132036
Depends on: 1482025
Depends on: 1506503
Depends on: 1506504
Depends on: 1509767
Depends on: 1515543
Depends on: 1531246
Depends on: 1537706
Depends on: 1538405
Depends on: 1538497
Depends on: 1538575
Depends on: 1538639
Depends on: 1536521
Depends on: 1539402
Depends on: 1539612
Depends on: 1539647
Depends on: 1539976
Depends on: 1539984
Depends on: 1540918
Depends on: 1541787
Depends on: 1542975
Depends on: 1544447
Depends on: 1545154
Depends on: 1444569
Depends on: 1554421
Depends on: 1575749
You need to log in before you can comment on or make changes to this bug.