Closed
Bug 58852
Opened 24 years ago
Closed 22 years ago
Navigate to links by selecting from list
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
WONTFIX
Future
People
(Reporter: aaronlev, Assigned: aaronlev)
References
Details
(Keywords: access, helpwanted, topembed, Whiteboard: [p-ie/mac] [KEYBASE+])
Keyboard navigation through a web page via TAB is painfully slow and repetitive.
This is an issue for disabled and mainstream users both.
Here are some ideas people have had:
A key that jumps to the next form element.
Directional link navigation keys.
Incremental search navigation: i.e. as you start typing letters, each successive
letter narrows you down to the next link. Also, typing the same letter multiple
times moves you through the links starting with that letter. This would be
similar to keyboard navigation in a list in Windows. Also, typing backspace acts
like you didn't type the last letter.
Comment 1•24 years ago
|
||
We need a description of how you want to make navigation easier to do this.
Assignee | ||
Comment 2•24 years ago
|
||
More description:
Directional link navigation key. For example, control-left, control-down,
control-up, control-right could move to the next link in that direction.Or some
other keystroke combination.
Incremental search navigation: when you're not in a form control, but your focus
is in the browser window, typing a letter b would move you to the first link
starting with a b (from where you're current position is). Typing another b
would move you to the next link with starting with a b. Alternatively, typing
the combination "be" would move to the first link starting with be. Finally,
typing "be" followed by backspace would bring the user back to the first link
starting with a b. Here backspace would be contextual, because the user is using
the incremental link search feature.
Finally, we need some key that jumps to the next form element in a page. This
key could be alt Z - zip to next form element. Whatever. Half the time when
you're in a page that's where you want to hump to. For example, a login or text
field.
This would be nice. Not important, but would be great for so-called "power
users" who like to use the keyboard, as well as for accessability.
Comment 5•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy
Assignee: don → vishy
Comment 6•24 years ago
|
||
Directional navigation is also important for embedded uses.
Comment 7•24 years ago
|
||
bug 67684 has been opened to split off directional navigation issues into their
own bug.
Comment 8•23 years ago
|
||
In Internet Explorer, I can hit Ctrl+F, type a few letters from a link, and
press enter to select part of a link, and then tab to focus that link. If I do
the same in Mozilla, the first element on the page is focused instead of the
link I found. Bug 66597.
Summary: Alternative ways to navigate links → Alternative ways to navigate links with keyboard
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Assignee | ||
Comment 10•23 years ago
|
||
Bug 67684 is for directional navigation.
Renaming this bug to reflect incremental link searching only
Summary: Alternative ways to navigate links with keyboard → Navigate to links by selecting from list
Assignee | ||
Comment 11•23 years ago
|
||
Bug 66597 will be good to fix as well
This one is more specific to searching only for links.
I envision it thus:
Type Accel+J (Jump to Link)
The links panel popus open in the sidebar.
You navigate the list with arrow keys, or by typing the first few letters.
Type Enter to be zipped to the link. Ideally, he sidebar closes again if it was
not open before you typed AcceL+J.
Drbrain, do you think the link panel could be modified for this task?
I couldn't get it to work with NS 6.1
Assignee | ||
Comment 12•23 years ago
|
||
In bug 105665, risto details some possible UI implementations for incremental
searching of links.
Comment 13•23 years ago
|
||
Actually it's bug 105565. And had I found this bug, I had added my comments here...
Comment 14•23 years ago
|
||
OK, here are some comments:
> This would be similar to keyboard navigation in a list in Windows.
I hope not identical, though. There seems to be some kind of timeout that makes
Windows move from incremental search to first-letter searching. And the timeout
is quite short. All kinds of time-outs are usually bad. Let's not do it that way.
From bug 105565:
> I actually think both of your methods should work concurrently - that is
> sequential letters of the same kind and incremental searching of several
> different letters should both work. The only thing you'd lose is when something
> begins with two of the same letter, which doesn't happen all that often.
One note: long wovels are not rare in Finnish, many words start with two same
wovels. Other languages may have other implicatins...
My thinking is that one method might be enough, if it is easy and powerful
enough. If we can combine both, all the better. If not, the search type could be
a preference. Or you could automatically open help the first time this feature
is used (like emacs does for many commands), if we decide to do something different.
In any case, I think there needs to be a key for going to the next match of the
entered characters. E.g. you have 5 links named "Go!" on the page. Once you have
typed "Go!", you are still on the first one and need a way to go to the others.
Once we have that go-to-the-next-match key, do we still badly need the first
letter searching? If you want to search links starting with "b", press "b" and
then go-to-the-next-match key repeatedly.
> perhaps the list or sidebar panel would be easier to do, while this one might
> cause some problems with the page jumping around a lot as you type.
The jumping might be a problem, but I definitely want to see the selected link
in context. Especially when the page has a number of identically named links,
like "Go!". Using the sidebar shouldn't be necessary to incrementally search for
links, but if there is a link sidebar, it would be nice if the same search
features worked there, too. And I guess there are also other places in Mozilla
where you could use this (e.g. the "normal" search by control-f).
Summary of incremental mode keys:
A letter starts incremental search and moves to the incremental mode,
with the following key commands:
1. a letter: adds more characters to the search string and moves to a matching
link
2. TAB: moves to the next matching link
3. Back Space: moves to previous matching link, deleting a character from
the search string IF NECESSARY
4. ESC: aborts incremental mode, focus leaves where it is
5. any other key command aborts incremental mode and carries out its action
Need to define what is "a letter", how to deal with "special characters" in
links (e.g. an (accidental) initial space in link name), what to do when a
non-matching character is entered (ignored, ignored with beeb, "remembered",
...). The keys I mentioned are just examples. What visual cues could be used to
show the matching part of search in links, what should status bar contain while
in incremental mode?
Comment 15•23 years ago
|
||
Couldn't we just do this similar to the browser autocomplete?
An entry field called the links bar.
As you start to type in the name of a link, it autocompletes based on linknames
on the page.
Updated•23 years ago
|
Keywords: helpwanted
Comment 16•23 years ago
|
||
Such an entry field would be extra UI for something which is rarely used. Just
focusing (and scrolling to) the link which is alphabetically closest to the
series of characters typed since the last 1-second delay -- as already happens
in native listboxes (bug 104503) -- would be more convenient and efficient,
since (1) you wouldn't have to type any special keys (e.g. accel+J) beforehand,
(2) you wouldn't have to wait for the sidebar to open and close, (3) you
wouldn't be disoriented by the page changing shape when the sidebar opened, (4)
you could immediately see whether you had the right link because it was
highlighted in the page itself, (5) it would work in HTML sidebar panels
themselves without the sidebar having to have its own mini-sidebar, and (6) it
would work in embedding clients which are too sophisticated to have sidebars.
Whiteboard: [p-ie/mac]
Comment 17•23 years ago
|
||
I find the 1-second reset in Windows Explorer frustrating even when I know
exactly what I'm going to type beforehand. Either increase it to 5 seconds or
make it infinite, with backspace to shorten the selection and tab or esc to
start over.
By the way, what you're asking for is also described by bug 105565, "RFE:
Mnemonic keyboard navigation of links".
Comment 18•23 years ago
|
||
This might be a dup of or depend on bug 28605, "[rfe] list links on page".
Comment 19•23 years ago
|
||
I have limited use of my arms due to RSI, so I am attempting to use a
computer with voice recognition. One of the biggest problems is trying
to navigate Web pages. ( I am using ViaVoice and Xvoice on Linux.)
<p>
The best interface for this by far is in either Links or the Lynx
browsers, which have an option
to turn on Link numbering. To navigate to a link, input field, submit button,
etc. you simply enter it's number and hit return.
<p>
I have setup XVoice so that I can just say "link 45" and have the
browser load that link's url immediately.
<p>
The advantage of this method is that it is deterministic. there isn't
extra keying or speaking in order to get to the fifth of 20 "edit"
links. A disadvantage is that it requires modifying page display in some
way, but it would still beat a text based browser for those with good
eyesight (like me). Plus, text browsers don't work with some sites very well.
<p>
The voice recognition of numbers is more reliable than that of arbitrary
link words, for obvious reasons. Individual letters could reach the
same level of recognition,
but you really have to use a phonetic alphabet (golf, victor, tango, etc.) for
accuracy.
<p>
I also want to mention one small detail that could cause problems. I
don't know about other voice input systems, but X voice doesn't handle a
pop-up window for entering something like a link name or number in a
command macro, although at worst that this would mean saying something
like "link 14 return" instead of just "link 14". (Maybe this could be
considered a bug in xvoice.) Could these link navigation methods
keep focus in the browser window rather than in a popup?
<p>
Please let me know if you have any questions or if I can help in any
way.
<p>
xvoice home page: http://xvoice.sourceforge.net/
Comment 20•23 years ago
|
||
This may be a dup of bug 103704, which includes making it possible to navigate
to a link shown in the Links tab of Page Info.
Assignee | ||
Updated•22 years ago
|
Whiteboard: [p-ie/mac] → [p-ie/mac] [KEYBASE+]
Assignee | ||
Comment 21•22 years ago
|
||
I don't think this will be necessary after bug 30088 is checked in, which allows
you type part of a links name to bring focus there. Anyone disagree with WONTFIX?
Comment 22•22 years ago
|
||
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Assignee | ||
Comment 23•22 years ago
|
||
WONTFIX, the important functionality is covered by bug 30088.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Comment 24•22 years ago
|
||
removing topembed and vrfy'ing.
Status: RESOLVED → VERIFIED
Keywords: topembed
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•