1767802 - A11y review for making the tabs toolbar a keyboard accessible toolbar

Status: VERIFIED FIXED

(Firefox :: Keyboard Navigation, task)

Description

[Dão Gottwald [:dao]]

Bug 1762903 adds the tabs toolbar to the toolbars that are keyboard accessible (see ToolbarKeyboardNavigator). This is currently behind the browser.tabs.firefox-view pref. I put this together rather quickly to ensure the Firefox View button can be reached with the keyboard, and we'll want to do an a11y review ensure this works well for the toolbar as a whole.

Comment 1

[James Teh [:Jamie]]

Thanks for working on this.

My only possible concern here is that this adds an extra tab stop. Every tab stop we add risks decreasing efficiency slightly for keyboard users. It's always a tradeoff: we want to ensure things are keyboard accessible, but we also want to keep it efficient.

That said, it only adds one extra tab stop (more on that below), which I think is acceptable given that we want these buttons to be keyboard accessible.

One idea I had a while back to avoid the extra tab stop is to somehow make it so that these buttons are reachable with the arrow keys in the tab bar. That is, you would focus the tab bar, then left arrow past the first tab to get to the Firefox View button, or right arrow past the last tab to get to the new tab button. However, thinking about this more, this would be bad because arrowing through the tab bar changes the active tab and we wouldn't want the user to have to switch through all their tabs just to get to these buttons. So, I think the extra tab stop is the best compromise.

One other thing to consider is that with the navigation toolbar, groups of controls are split into separate tab stops. Buttons to the left of the address bar have a tab stop, the site info buttons have a tab stop, the address bar has a tab stop, page actions have a tab stop and buttons to the right of the address bar have a tab stop. This isn't ideal for tab stop efficiency. It was implemented this way because we were concerned that sighted users might find it confusing if there were buttons to the right of the address bar, but you had to shift+tab and right arrow past the buttons on the left of the address bar to get to them.

As currently implemented, you get to the buttons on the right of the tab bar by shift+tabbing from the tab bar and using right arrow to move past the buttons on the left of the tab bar. On one hand, that means we don't consume two tab stops instead of one, which I like. On the other hand, it might be confusing for sighted users and it's inconsistent with the navigation toolbar.

Do we have a reason to think the tabs toolbar is different to the navigation toolbar such that it would justify this inconsistency?

If we want to be consistent, the question is: do we change the navigation bar to behave like the tabs toolbar (reducing tab stops) or do we change the tabs toolbar to behave like the navigation bar (increasing tab stops)?

Comment 2

[Dão Gottwald [:dao]]

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

Do we have a reason to think the tabs toolbar is different to the navigation toolbar such that it would justify this inconsistency?

No, that wasn't a specific reason for implementing it this way.

If we want to be consistent, the question is: do we change the navigation bar to behave like the tabs toolbar (reducing tab stops) or do we change the tabs toolbar to behave like the navigation bar (increasing tab stops)?

I generally like the nav bar behavior. After playing around with this more, I think adding another tabstop here would make the behavior more obvious and predictable.

Comment 4

[:Gijs (he/him)]

In bug 1772811 Shane raises some issues with the current system:

(In reply to Shane Hughes [:aminomancer] from comment #0)

With the Firefox View changes, the tabs toolbar is navigable with tab and arrow keys by the same means as other toolbars. This is a nice improvement, but because there can be buttons on either side of the tab strip, and the tab strip has its own internal focus behavior, the user can't tab through the elements on the tabs toolbar in an intuitive way.

(I'm gonna use the terms left/right to make this easier but I really mean start/end, as I believe all of this is reversed for RTL) I would expect there to be a tabstop for elements to the left of the tabstrip (like the Firefox View entry point), another tabstop for the tabstrip itself, and another tabstop for elements to the right of the tabstrip.

So, when an element to the left of the tabstrip is focused, arrow keys would only advance through those elements to the left of the tabstrip. When a tab is focused, arrow keys would only advance through tabs. And when an element to the right of the tabstrip is focused, arrow keys would only advance through those.

That would mean if we Shift+Tab backwards from the urlbar, we should hit the back button, then hit the "all tabs" button or the new tab button, then hit the tabstrip, then hit the Firefox View button. In other words, Tab should advance through at least 3 zones in the tabs toolbar.

Currently, there's only one tabstop in the tabs toolbar, so when we Shift+Tab backwards from the urlbar, we jump right to the tabstrip, then another Tab press focuses the Firefox View button.

That means the only way we can focus the buttons to the right of the tabstrip is to focus the Firefox View button (to the left of the tabstrip) and then use the right arrow key. This is pretty unintuitive behavior, jumping past the right side items with Tab, and jumping over the tabstrip with the arrow keys. (Keep in mind you can only test this if browser.tabs.firefox-view is enabled when the window opens.)

If we had additional tabstops we could keep the arrow keys confined to the left/right-of-tabstrip zones. That would be analogous to what happens with the urlbar when navigating buttons in the navbar. But I think we also need to change the focus behavior for the tabstrip to avoid some jank. I'll investigate that further later, unless someone else wants to work on this.

Jamie/Dão, wdyt?

Comment 5

[James Teh [:Jamie]]

Gijs, note that this is the crux of the discussion in comment 1 and comment 2. There are pros and cons to both approaches, but I think Dao and Ray are leaning towards having the extra tab stop.

Comment 6

[Dão Gottwald [:dao]]

Attachment: Bug 1767802 - Add another tab stop to the tabs toolbar. r=gijs

Comment 7

[James Teh [:Jamie]]

There's currently a bug where if the Firefox View button isn't showing (as is the case in a private browsing window), you'll get stuck in a loop between the tab control and the New Tab button when you shift+tab. I think adding this new toolbartabstop should fix this, but this needs to be verified.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b79ebf7f49d8
Add another tab stop to the tabs toolbar. r=Gijs

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/b79ebf7f49d8

Comment 10

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest versions of Firefox but for the ESR 102.3.0 the issue still occurs and it directly affects Bug 1784432. We cannot verify that Fix without this one.