1476852 - [a11y] Support multiselect tab operations via the keyboard

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, enhancement, P1)

Description

[James Teh [:Jamie]]

Unless I'm missing something, it's only possible to select multiple tabs with the mouse. Pressing shift+rightArrow on a tab doesn't seem to multi select the next tab, for example. This means it's impossible for keyboard only users (including screen reader users) to use this functionality.

Non-contiguous selection of tabs presents a challenge, as control+left/right are currently used to move tabs (and normally you'd do non-contiguous selection with control+arrows and control+space). There are a few possible solutions:

1. Change control+arrows to do non-contiguous selection. That means we'd need to move the existing tab movement functionality to some other key combinations; e.g. alt+left/right. Not great from a user change perspective, but control+arrows is standard for non-contiguous selection, whereas there's no real standard for movement.
2. Do non-contiguous selection with control+shift+arrows. Not quite as standard, but not unreasonable.
3. Only implement contiguous selection with shift+arrows, but still implement control+space to toggle selection. So, to move to the next tab but exclude it from the selection, you would do shift+rightArrow, control+space. A bit odd, but users could get used to it.

Comment 1

[Marco Zehe (:MarcoZ)]

(In reply to James Teh [:Jamie] from comment #0)
> 1. Change control+arrows to do non-contiguous selection. That means we'd
> need to move the existing tab movement functionality to some other key
> combinations; e.g. alt+left/right. Not great from a user change perspective,
> but control+arrows is standard for non-contiguous selection, whereas there's
> no real standard for movement.

I'm all for this option. MS OneNote, for example, uses Alt+Shift+Arrows to move sheets around in a list.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: WIP Patch

this patch doesn't work but is a start towards fixing this bug.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1476852 - Implement keyboard selection for multiselect tabs. r?Gijs,Jamie

This does not properly move focus to the other tabs though because they have .MozUserFocus="ignore".

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Hi Jamie, the patch that I have attached should mostly work except that changing the focused tab doesn't work because the <tab> elements have MozUserFocus set to "ignore". I could set MozUserFocus to "normal" before changing focus, but that will cause other issues with the tab order as well as potentially change some mouse-related behaviors.

It would be nice if I could use something like aria-activedescendant but that would only work for nodes that are descendant of the focused node, which would need to be <tabs> but in this case the focused node is a <tab>.

Do you have any ideas for other ways I could accomplish this? We could keep our own state as to which tab is focused and style it accordingly, but I'm not sure how to let accessibility tools know which tab is pseudo-focused.

Comment 5

[James Teh [:Jamie]]

For Gecko, aria-activedescendant actually doesn't care whether it's a descendant or not; something like this works just fine:
data:text/html,<button aria-activedescendant="b">a</button><div id="b" role="button">b</div>
Strictly speaking, this isn't spec compliant, but this behaviour has existed for years and we have no plans to change it. If you do rely on this, I'd suggest you comment explaining this just to avoid any confusion in future.

Note that you may run into bug 1322621 if you remove aria-activedescendant from the focused element. If this turns out to be a problem, we can prioritise fixing that bug in the a11y module.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Thanks, that helps! I've updated the patch to use aria-activedescendant. Using this I can now select and unselect tabs but I haven't implemented any visual styling to show which tab is the active descendant. Do you think you could test this patch out and let me know if it works for you?

To change which tab is in the foreground, focus the current tab and use the Left and Right arrow keys.
To move a tab within the tabstrip, use Ctrl+Shift and the Left and Right arrow keys.
To move which tab is focused (the active descendant), use Ctrl and the Left and Right arrow keys.
To select or unselect a tab, use Ctrl+Space.

Comment 7

[James Teh [:Jamie]]

Thanks for working on this!

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> Do you think you
> could test this patch out and let me know if it works for you?

A few things:

1. Active descendant (fake) focus and real focus are very separate. That makes the UX a bit confusing:
a) If tab 1 is active and you press control+rightArrow, tab 2 gets fake focus.
b) If you now press right arrow, tab 2 is still focused. It has both real and fake focus. Ideally, pressing right arrow would take you to tab 3. Even though tab 1 was active, tab 2 had "focus" (fake or otherwise), so I'd expect right arrow to move to tab 3.
c) If you press left arrow, tab 1 becomes active (real focus), but tab 2 still has fake focus. I'd expect tab 1 to have both real and fake focus.
So, I'm saying the concepts of focus need to be linked. I guess b) might be tricky, but I think we definitely need c).

2. aria-activedescendant doesn't get set on the active tab when you change it; e.g. by pressing left/right arrow.

3. Rather than setting aria-activedescendant to a new id (e.g. each tab having its own id), you "move" the id to the new node. The former is how it's conventionally done; I've never seen the latter. Gecko a11y doesn't currently support the latter. It seems like we probably should, so I'm trying to patch this at the moment.

Comment 8

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #7)
> 3. Rather than setting aria-activedescendant to a new id (e.g. each tab
> having its own id), you "move" the id to the new node. The former is how
> it's conventionally done; I've never seen the latter. Gecko a11y doesn't
> currently support the latter.

Fix for this submitted for review in bug 1488109.

Comment 9

[James Teh [:Jamie]]

Comment on attachment 9005184 [details]
Bug 1476852 - Implement keyboard selection for multiselect tabs. r?Gijs,Jamie

James Teh [:Jamie] has approved the revision.

Comment 10

[:Gijs (he/him)]

Comment on attachment 9005184 [details]
Bug 1476852 - Implement keyboard selection for multiselect tabs. r?Gijs,Jamie

:Gijs (he/him) has approved the revision.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c5dc6b7928ad
Implement keyboard selection for multiselect tabs. r=Gijs,Jamie

Comment 12

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7724a00e9bd2
Backed out changeset c5dc6b7928ad for browser chrome failures on browser_bug563588. CLOSED TREE

Comment 13

[Cosmin Sabou [:CosminS]]

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=os,x,10.10,opt,mochitests,with,e10s,test-macosx64%2Fopt-mochitest-browser-chrome-e10s-7,m-e10s(bc7)&selectedJob=199145068&revision=c5dc6b7928ad6421f29c1357b33745346770e29c

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=199145068&repo=autoland&lineNumber=1251

11:38:17     INFO - TEST-PASS | browser/base/content/test/general/browser_bug563588.js | accel+right doesn't change which tab is selected - 
11:38:17     INFO - Buffered messages finished
11:38:17     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug563588.js | accel+right moves the tab to the expected position - Got 0, expected 1
11:38:17     INFO - Stack trace:
11:38:17     INFO - chrome://mochikit/content/browser-test.js:test_is:1304
11:38:17     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug563588.js:press:6
11:38:17     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug563588.js:test:21
11:38:17     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1133
11:38:17     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:995
11:38:17     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:795
11:38:17     INFO - TEST-PASS | browser/base/content/test/general/browser_bug563588.js | accel+right leaves the selected tab focused - 
11:38:17     INFO - TEST-PASS | browser/base/content/test/general/browser_bug563588.js | accel+down doesn't change which tab is selected - 
11:38:17     INFO - Not taking screenshot here: see the one that was previously logged

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/autoland/rev/110f70038099ac777b4c394b109c0100ac11e4b0

Comment 15

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/110f70038099