[PATCH] konqueror keyboard link navigation

[Robert Ewald]

On Thursday 02 December 2004 15:06, Lubos Lunak wrote:
> On Thursday 02 of December 2004 12:08, Robert Ewald wrote:
> > After thinking a bit more, the seperate function is not such a good idea,
> > it should really be merged with accesskeys. It would confuse all users
> > that want to interact with a form and links via the keyboard. Also form
> > elements should be accessible, even if no accesskeys are defined. The
> > collision remains though. We could choose to ignore the accesskey
> > definition in the webpage altogether. Thats a quick and dirty sollution
> > to the problem, but I am not sure if it is a good idea.
>
>  Accesskeys are created manually, and as such should usually fit better.
> You probably can't write an algorithm that'd give better assignments than
> the one implemented in human brain. I think your code should be rather seen
> as a fallback when accesskeys are missing (either completely, or for some
> elements). Moreover I think pages with more than 26 links would be
> cumbersome with it anyway - search as you type for links would be probably
> better in such cases.

Let me respond to your second point first. I developed this patch especially 
for pages with more than 26 _visible_ links, esp. if the link caption is 
duplicated. On many blogs like slashdot, you have multiple "read more" on the 
same page. You would have to search multiple times with the type ahead method. 
Also images are hard to access. I wanted to change that and navigate to a 
link as quick as possible.

I have investigated access keys a little more. I think it is a pretty flawed 
concept. For example in firefox, you alt+access key. now alt+1 switches to the 
first tab as well, so every time you switch the tab you also call the access 
key on the current page, leading to strange effects. Since all browsers 
define their own set of hotkeys, the web author can only choose from a very 
small set of possible access keys. The access key approach taken by 
konqureror is much better, having it visible.

So since type ahead is sometimes cumbersome and my approach collides with 
accesskeys, but otherwise provides the same functionality, I would suggest to 
treat access keys in the webpage at most as hints if not abandon this concept 
altogether. If we would abandon it, only minor changes to the patch are 
needed. If we would treat the accesskeys as hint integration is much more 
difficult, so I'd like to avoid that.

Thanks for reading

Robert Ewald