684457 - Need keyboard access to 'Tools for all add-ons' button in Addons Manager: Extensions list

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Rick]

This button is just to the left of the Search box and is currently only accessible by mouse (left-click). Everything else on the page is accessible by keyboard, and the tools found there cannot be reached by keyboard in another way.

Preferably, if in the Search box, you should be able to Shift+Tab leftwards onto the Tools button, with a clear visual indicator that it is focused, and then be able to use a key to open up its menu, like the Context-Menu key on Windows keyboards which is already useful in opening up the per-extension Tools menu.

Comment 1

[Benedikt Pfeifer]

This affects us in Instantbird as well. Our add-on manager opens in a new window and this menu is the only way to install extensions without drag and drop to the window. We have had complaints about this from a user with screenreader software who couldn't install extensions because of it.

I lack the necessary rights to set this bug blocking the Instantbird tracking bug (bug 596002), maybe someone could do this for me?

Comment 2

[Benedikt Pfeifer]

The following rule does the trick, e.g. as workaround in userChrome.css:

#header-utils-btn {
  -moz-user-focus: normal;
}

Comment 3

[Benedikt Pfeifer]

Attachment: Make toolbar button focusable

I've spent over an hour guiding a blind user of Instantbird through editing her userChrome.css file last friday because of this bug. Time to fix it!

Is the product and component of this bug set correctly by the way? I would rather have expected something like Toolkit:Add-ons Manager. I'll request review from the appropriate reviewer as soon as I have found out.

Comment 5

[Benedikt Pfeifer]

Attachment: Make toolbar button focusable (for checkin)

Added reviewer information to the commit message, carrying forward the r+.

Comment 6

[Benedikt Pfeifer]

Attachment: Make toolbar button focusable (for checkin)

There was a mistake in the user-line of my patch. Carrying on the r+ again.

My apologies for the bugspam.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/6198c2c064ba

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6198c2c064ba

Comment 9

[Francesca Ciceri [:madamezou]]

Hi,

I was able to reproduce it on Nightly 30.0a1 2014-03-03 on Linux x86_64 and I can confirm that in latest beta (30 20140603140158) hitting Shift+Tab you can reach the Tools button and there's a visual indicator that it's on focus. I wasn't able, though, to press the Tools button so to open its submenu: is there a special key to open it while focused? On my installation, neither Enter, nor the arrow down, or the "windows" key did the trick, but I'm not an expert on keyboard shortcut/accessibility.

Benedikt: what key do I need to press when the Tools button is focused in order to open its menu? At this point I'd like to test it, so that I can understand if it's a Linux-specific problem (and file a new bug in that case). Thanks!

Cheers,
Francesca

Comment 10

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Francesca, I think you could also try the Space key... at least on Windows that usually works.

Comment 11

[Francesca Ciceri [:madamezou]]

Hi Florin, 

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #10)
> Francesca, I think you could also try the Space key... at least on Windows
> that usually works.

Space key also seems not working.

Thanks for the suggestion anyway,
Francesca

Comment 12

[Florian Quèze [:florian]]

I just tried on Mac and I could open the menu with either the "Down arrow" or the "Space" key. The enter key didn't do anything; but that behavior may be platform-dependent.

Comment 13

[Benedikt Pfeifer]

On Windows you can use Alt+"Down arrow" to open the menu.

Comment 14

[Francesca Ciceri [:madamezou]]

(In reply to Benedikt Pfeifer [:Mic] from comment #13)
> On Windows you can use Alt+"Down arrow" to open the menu.

Ah! That did the trick on Linux also :). Thanks for the hint!

So, I can confirm this bug is fixed on Linux x86_64 on latest Beta (30.0 2014-06-05), Aurora (31.0a2 2014-06-09) and Nightly (32.0a1 2014-06-09); as well as on Windows 7 x86_64 on the same versions.
I'm marking it as verified, as I tested it on two platforms out of three (and I'd say it's working on Mac as well, per comment 12).