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.

We need a description of how you want to make navigation easier to do this.

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.

See also bug 20159.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Directional navigation is also important for embedded uses.

bug 67684 has been opened to split off directional navigation issues into their own bug.

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.

This one's mine.

Bug 67684 is for directional navigation. Renaming this bug to reflect incremental link searching only

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

In bug 105665, risto details some possible UI implementations for incremental searching of links.

Actually it's bug 105565. And had I found this bug, I had added my comments here...

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?

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.

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.

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

This might be a dup of or depend on bug 28605, "[rfe] list links on page".

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/

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.

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?

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

WONTFIX, the important functionality is covered by bug 30088.

removing topembed and vrfy'ing.

Bulk adding topembed keyword. Gecko/embedding needed.