Open Bug 102909 Opened 23 years ago Updated 3 years ago

No keyboard access to link toolbar

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: ian, Assigned: jag+mozilla)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: access, testcase) 

STEPS TO REPRODUCE
   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.:
      http://www.bath.ac.uk/~py8ieh/internet/eviltests/link6.html
   Use one of the links on the link toolbar.

ACTUAL RESULTS
   You can't.

EXPECTED RESULTS
   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?
Sorry, the link in the initial description should be
   http://www.bath.ac.uk/~py8ieh/internet/eviltests/link2.html
Keywords: access, testcase
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
something.

Gerv
Severity: normal → enhancement
OS: Windows 2000 → All
Hardware: PC → All
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.
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
> 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.
The link toolbar being part of tab/shift+tab would work for me.
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.
> 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

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.
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)
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
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. ***
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... 

  
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.
*** Bug 132607 has been marked as a duplicate of this bug. ***
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
cycle.
directional navigation?
*** Bug 141989 has been marked as a duplicate of this bug. ***
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).
*** Bug 150629 has been marked as a duplicate of this bug. ***
*** Bug 160217 has been marked as a duplicate of this bug. ***
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:
_T_op,
_U_p,
F_i_rst,
_P_revious,
_N_ext
_L_ast
*** Bug 183182 has been marked as a duplicate of this bug. ***
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

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.
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?

Go>
 hIstory>
  Back>
   previouspage
   pagebeforethat
   ...
  Forward>
   forwardpage
   pageafterthat
   ...
  Manager
  -
  {global list of recent pages}
 Back
 Forward
 Home
 lOcation [hypothetical movement from file>open location, or a way to get to the
location bar]
 -
 Top
 fiRst
 Prev
 Next
 Last
 Document>
 More>
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
Depends on: 241105
*** 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
Keywords: qawanted
Component: XP Apps: GUI Features → UI Design
Assignee: drbrain-bugzilla → jag
QA Contact: nobody
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
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true

          You need to log in
          before you can comment on or make changes to this bug.