No keyboard access to link toolbar



UI Design
16 years ago
5 years ago


(Reporter: Hixie (not reading bugmail), Assigned: jag (Peter Annema))


(Depends on: 1 bug, {access, testcase})

access, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





16 years ago
   Disconnect your mouse.
   Open the link toolbar if required (Alt+V, W, down, down, enter).
   Go to a web page with link elements (Ctrl+L and type URI), e.g.:
   Use one of the links on the link toolbar.

   You can't.

   There should be a menu somewhere giving you access to the menu items 
   equivalent to a menu-ized link toolbar (this could go, e.g., in the Go menu).

cc'ing usual suspects as per bug 102832.

mpt: could you give us some UI advice here? Which menu is appropriate?

Comment 1

16 years ago
Sorry, the link in the initial description should be
Keywords: access, testcase


16 years ago
Summary: No keybaord access to link toolbar → No keyboard access to link toolbar
This is an RFE, even if it is an accessibility issue. The problem is that most
solutions would be fairly deeply nested. But I'd go for Go | Related Document or

Severity: normal → enhancement
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

16 years ago
See also bug 33684, which includes Alt+up for going up a direcotry, even if the 
page doesn't have a <link> element saying where "up" is.

Comment 4

16 years ago
As was mentioned in bug 2800 when the Link toolbar was under discussion, the
features of the Link toolbar should be placed in the Go Menu. There should be a
seperator and sub menus as appropriate. (From what I understand they will not
exceed 3 levels)

The Up choice in that menu will be filled with a truncated URL if no "Up" Link
is specified. (That's what bug 33684 is for.)
Blocks: 103053

Comment 5

16 years ago
> mpt: could you give us some UI advice here?

The links in the Links Bar should be part of the Tab/Shift+Tab cycle, just like
the rest of the links in the page or frame.

> Which menu is appropriate?

None. We don't list A HREF links in a separate menu, either.

> (From what I understand they will not exceed 3 levels)

Submenus should never exceed one level.

Comment 6

16 years ago
The link toolbar being part of tab/shift+tab would work for me.

Comment 7

16 years ago
bug 104586 would provide an alternate way to satisfy this bug by making all the
LINKs available in the toolbar also accessible from the main menu system.  This
is consistent with how functionality in all other toolbars is given keyboard
access.  I prefer it to making a toolbar part of the TAB cycle.

Comment 8

16 years ago
> The links in the Links Bar should be part of the Tab/Shift+Tab cycle, just like
> the rest of the links in the page or frame.

I disagree. This cycle is unsably long enough already, no need to entend it further.
IMO, the link toolbar is UI, not part of the page.

I vote for a common modifier key plus
cursor left:   Next
cursor right:  Prev
cursor up:     Up
cursor down:   first child (chapter, section, subsection or rev-parent)
home:          either Top or First
end:           Last, if home = First

Comment 9

16 years ago
Certainly, if Beonex could follow Microsoft's lead and convince the world's 
keyboard manufacturers to add a new modifier key to their keyboards, and then 
persuade everyone to upgrade to such keyboards just for use with Mozilla, 
direct keyboard shortcuts would be an option. However, that might take a while.

Comment 10

16 years ago
Changing summary to reflect the only workable proposed solution.
Summary: No keyboard access to link toolbar → Link Toolbar should be in tab cycle (No keyboard access to link toolbar)

Comment 11

16 years ago
I disagree. There would be no point in doing that.

Since not all browser support link toolbars, we can assume that the pages will
have the same functionality accessible via normal links. These links are in the
tab-cycle of the page anyways, so the functionality is already available via
this means. The only thing you would achieve is that you have Next *twice* in
the tab-cycle - once as normal link and once as link toolbar button.

The main advantage of the link toolbar is that it offers a well-known location,
which I can hit without looking at the page (so I can e.g. hit Next 3 times in a
row). The keyboard equivalent of this would be to have fixed hotkeys for the
link toobar buttons.

I don't know by what all my proposed keys are already occupied, but we should be
able to find *some* free hotkeys which we can use for this. Say, Ctrl-D for
Previous, Ctrl-G for Next, Ctrl-R for Up, Ctrl-E for Top. This was only an
example - well possible that some of these are already taken, but again, there
should be *any* set of hotkeys which is still free. If not, maybe make room by
removing some obsure ones.
Summary: Link Toolbar should be in tab cycle (No keyboard access to link toolbar) → No keyboard access to link toolbar

Comment 12

16 years ago
I forgot: For the less used options on the Link toobar, esp. those in the menus,
we could use a method similar to the main menu: Have a hotkey which focuses the
link toolbar and thus allows the user to navigate in it and activate options
there this way (via Tab, normal cursor keys, return etc.).
*** Bug 123353 has been marked as a duplicate of this bug. ***

Comment 14

16 years ago
I would argue that at least 'previous' and 'next' are assigned some _very_ easy
to find keys. 

I use mozilla for classroom presentations (instead of powerpoint), so going to
the next and previous slide should be as simple as possible. 'Backspace' (for
back) is still available as far as I can see. 'Space' is already used, but maybe
if the page has already scrolled to the bottom (or the whole page is displayed),
'space' could trigger the next page ? This is what some newsreaders do... 


Comment 15

16 years ago
t.schnier, that's bug 59118.

I find it slightly amusing that *every one* of Ben Bucksch's proposed keyboard 
shortcuts is already taken by a more common function. We just don't have spare 
keys. Putting REL/REV links in the Tab cycle is still the only viable option.

Comment 16

16 years ago
*** Bug 132607 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
Suggestions from bug 33684 (infer up from URL) and bug 32627 (infer next/prev) :
Alt+-        Prev (since Prev usually goes to the previous /numbered/ something)
Alt++        Next 
Alt+Shift+-  First
Alt+Shift++  Last
Alt+Up       Up
Alt+/        Top (not alt+shift+up to avoid conflicts with directional navigation)

I agree with BenB that it doesn't make sense to include these links in the tab

Comment 18

16 years ago
directional navigation?

Comment 19

16 years ago
*** Bug 141989 has been marked as a duplicate of this bug. ***

Comment 20

16 years ago
Directional navigation is like tabbing but depends on where focusable objects
appear on the screen rather than their order in the HTML.  The Windows desktop
uses directional navigation instead of tab navigation.  It would probably be
alt+shift+arrow or ctrl+arrow if Mozilla had it (bug 67684).

Comment 21

15 years ago
*** Bug 150629 has been marked as a duplicate of this bug. ***

Comment 22

15 years ago
*** Bug 160217 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
Since the bug 134823: Toolbars don't honour accesskeys
has been fixed, we can implement this by adding accesskeys to the links in
linktoolbar,such as:

Comment 24

15 years ago
*** Bug 183182 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
While Modifier + Character shortcuts are fine as a fallback, I'd very much
prefer Modifier + Special Key. The downside of N for Next is that in localised
versions it either becomes illogical, or a completely different shortcut. If my
muscle memory still largly works on a French Mozilla, that's a good thing.

My humble suggestions (all keys seem to do nothing in my copy):
Mod-PgUp        Previous
Mod-PgDn        Next
Mod-Home        First
Mod-End         Last
Mod-Shift-PgUp  Up
Mod-Shift-Home  Top

Comment 26

15 years ago
Ctrl+PgUp/PgDn = navigating tabs
Alt+PgUp/PGDn = navigating sidebars
Ctrl+Home = Go to top of document in caret mode
Alt+Home = Go to home page
Ctrl+End = Go to bottom of document in caret mode

Look on the keyboard binding chart, though, there might be some free keys about
if we use the Mod+Shift combinations.

Comment 27

15 years ago
shift+mod is often used by the os, window managers and third party macros.
when it isn't, it's used for selection.

While it wouldn't be as convenient i'd prefer to be able to walk the toolbar.

If you don't care about caret browsing and if you don't care about selection
browsing (which i had never met until today) then we could just use:
shift-arrows and ctrl-shift-arrows, which only runs into problems w/ windowmanagers.

why not do what everyone else does and abuse the context menu ;-).

but seriously why not put this stuff into the go menu?

  {global list of recent pages}
 lOcation [hypothetical movement from file>open location, or a way to get to the
location bar]

Comment 28

15 years ago
Even if you cannot come up with keys that are free to be used for the link
toolbar, please consider letting me choose keys for myself.

I don't know if there already is a way to configure these keys though.

If there isn't, my suggestion would be <accel>+, and <accel>+. (as these are the
< and > keys.) One could also consider [ and ] but ctrl-[ typically is escape.
Keywords: qawanted
QA Contact: sairuh → nobody


14 years ago
Depends on: 241105

Comment 29

13 years ago
*** Bug 240707 has been marked as a duplicate of this bug. ***
I agree with tinus_mozilla.

One possibility until hotkeys are configurable is to make it the numpad keys -
the keys actually lend themselves well to the common link types:

Up key - Up
Left key - Prev
Right key - Next
Product: Core → Mozilla Application Suite


13 years ago
Keywords: qawanted


9 years ago
Component: XP Apps: GUI Features → UI Design
Assignee: drbrain-bugzilla → jag
QA Contact: nobody

Comment 31

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 32

8 years ago
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.