580537 - Set useful initial focus in Add-ons Manager

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect, P1)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre

When the Add-ons Manager is activated, the focus is not set to a control inside the applet. While this is acceptable for normal documents, an application/applet should really focus something useful initially. This is particularly useful for screen reader users because at present, how to proceed after the Add-ons Manager appears isn't obvious.

Reproducible: Always

Steps to Reproduce:
1. Select Tools menu -> Add-ons.
Actual Results:  
The application element itself is focused instead of an element inside it.

Expected Results:  
An element inside the Add-ons Manager, such as the add-on type list, should be focused.

Note that the focused accessible state is not set on the Add-ons Manager application when it is focused, so at present, some screen reader users often literally have no idea when the Add-ons Manager appears. This is a separate issue, but it isn't really a problem if this bug is fixed, which would be more ideal.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Is this related to, or a duplicate of, bug 563911?

Comment 2

[James Teh [:Jamie]]

Related. Bug 563911 talks about the weird tab order, but doesn't mention that the initial focus should be set to something useful. These could be merged as long as bug 563911 is updated to cover this.

Comment 3

[Johannes Buchner]

See bug 682514

Comment 4

[Tony Mechelynck [:tonymec]]

If there is an initial focus in the add-ons manager, shouldn't it be set identically in Firefox, Thunderbird and SeaMonkey (which would mean that this bug would belong in Toolkit :: Add-ons Manager rather than in Firefox :: Keyboard Navigation)?

Comment 5

[Marco Zehe (:MarcoZ)]

Confirming, this is still happening, and is now also apparent when opening Tools/Options.

Comment 6

[Fabian]

Is there any reliable data about the initial interaction that users have upon opening about:addons? This page opens with the Get Add-ons tab by default, showing inline content. For me, the principle of lesat astonishment would be if the main content area is autofocused (as in web pages by default) so users can start scrolling the view with the arrow keys. In about: pages which mainly consist of (labeled) controls, having the first of those controls autofocused sounds most expected to me (like in most Prefs screens). In huge lists where the user is likely to interact primarily by searching/filtering, the search field might be a candidate.

Comment 7

[Marco Zehe (:MarcoZ)]

The initial focus should in all cases be an interactive control. Right now, focus lands in limbo-land with no control having focus. In Settings, for example, I would expect the focus to either go to the list of tabs (General, Privacy, etc.), or the first control on the currently open tab, e. g. the "When Firefox starts..." combobox. In add-ons Manager, the most logical place, in my opinion, would be the list of tabs like "Get Add-ons", since we never know what the user might want to do next.

Comment 8

[Fabian]

I agree that current initial focus is useless in all cases since no-one can do anything from there except getting focus to something first.
I'm not sure why you think initial focus should in all cases be on an interactive control. For views with a lot of non-interactive informative content, this is not standard. And landing initial focus on a tab list is something I've seldom seen and seems awkward to me, even if we'd fix the focus visibility in the tab list.

Comment 9

[Johannes Buchner]

> This page opens with the Get Add-ons tab by default, showing inline content.
The page opens on whatever was open last.

In my opinion, the focus should be on the search box when opening, because
 - That field is always there
 - It is on the top
 - It is useful for all possible add-on interactions, as the user will either modify a add-on, or install one, in either case she/he has to find it somehow.

Also, pressing tab reaches the list of tabs directly next.

Comment 10

[Marco Zehe (:MarcoZ)]

(In reply to Johannes Buchner from comment #9)
> In my opinion, the focus should be on the search box when opening, because
>  - That field is always there
>  - It is on the top
>  - It is useful for all possible add-on interactions, as the user will
> either modify a add-on, or install one, in either case she/he has to find it
> somehow.

Yep, that would be useful!

In the case of Settings, we could reintroduce the mechanism that was there when this was still a modal XUL dialog: Focus the first item on whichever tab was open last inside that dialog. Like I said above, on the General tab, this would be the combobox "When Firefox opens".

Comment 11

[Fabian]

I'm still sceptical on searching being the primary interaction here and love to see some harder data on it.

For the first tab (which opens by default the first time you open about:addons) searching isn't useful. It is an introductory text aimed at novice users to peruse, giving a few examples of useful add-ons. The user can't use the search field as he doesn't have a clear search term in mind that he knows should be on that page.

For tabs such as Extensions and themes, I doubt most users have a list that is so big that searching is a preferred way of reaching the desired item, rather than simply scrolling to it.

For reference: applications such as Windows Explorer, mail programs etc. autofocus the main content view, even when having much larger collections of files or mails displayed. Searching is almost invariably a secondary tool.

Comment 12

[Johannes Buchner]

In other news, Ctrl-K has surprising behaviour on this page: It changes the view to go to the default search engines website? Can we make Ctrl-K to jump to the search box?

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Johannes Buchner from comment #12)
> In other news, Ctrl-K has surprising behaviour on this page: It changes the
> view to go to the default search engines website? Can we make Ctrl-K to jump
> to the search box?

Please file a separate bug for this.

Comment 14

[James Teh [:Jamie]]

In Preferences, focus now lands in the search box, so this has been fixed there. There's still no useful initial focus in the Add-ons Manager, though.

Note that the search box in the Add-ons Manager doesn't exist in the "Get Add-ons" tab, so it's unfortunately not as simple as saying we should do what we did for Preferences and focus the search box.

Comment 15

[James Teh [:Jamie]]

Now that the rest of the Add-ons Manager is being converted to HTML (bug 1556776) and is more document-like, it seems reasonable to focus the HTML document initially. This way, screen reader users will end up in browse mode.

I think this will probably "just happen" when we move to using the HTML document at the root in bug 1525179.

Comment 16

[Deleted Account]

Maybe focus should be on the search box like the Options page?

Comment 17

[James Teh [:Jamie]]

I covered that in comment 14. Since then, it seems there is a search box on every tab of the Add-ons Manager now, so I guess that could work. I'm not convinced it makes sense, though. In Options, searching for an option is a very common primary task, given the size of the Options dialog. In the Add-ons Manager, the search box is used to find new add-ons. So, focusing the search box assumes that the primary reason a user opens the Add-ons Manager is to search for a new add-on. That's not true for me personally, but maybe it is for most users? Do we have telemetry on that?

Comment 18

[Asa Dotzler [:asa]]

Updating the Accessibility Team's impact assessment to conform with the new triage guidelines. See https://wiki.mozilla.org/Accessibility/Triage for descriptions of these whiteboard flags.

Comment 19

[Shane Caraveo (:mixedpuppy)]

Mark, you took this back in April, are you still planning to work on this?

Comment 20

[James Teh [:Jamie]]

As per comment 15, bug 1525179 took care of this.