Closed Bug 580537 Opened 12 years ago Closed 1 year ago
Set useful initial focus in Add-ons Manager
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.
Is this related to, or a duplicate of, bug 563911?
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.
See bug 682514
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)?
Confirming, this is still happening, and is now also apparent when opening Tools/Options.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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.
> 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.
(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".
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.
Flags: needinfo?(bmcbride) → firefox-backlog+
Summary: Set useful initial focus in Add-ons Manager → Set useful initial focus in Add-ons Manager and Preferences
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?
(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.
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.
Summary: Set useful initial focus in Add-ons Manager and Preferences → Set useful initial focus in Add-ons Manager
Component: Keyboard Navigation → Add-ons Manager
Product: Firefox → Toolkit
Assignee: nobody → mstriemer
Priority: -- → P1
Whiteboard: [access-p3] → [access-s4]
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.