[PATCH] Automatic assignment of accesskeys

[Lubos Lunak]

On Monday 11 of April 2005 00:29, Robert Ewald wrote:
> On Friday 08 April 2005 15:09, Lubos Lunak wrote:
> >  What do you think of it?
>
> Hello,
>
> I am the guy, who tried to implement a similar feature before. I did not

 Hmm, I remember that patch.

> have time to make the patch good, so I am happy to see someone to work on
> such a feature. In this post I would like to give some input regarding the
> high level approach. When I was working on this kind of feature I had the
> following in mind:
>
> * Only currently (without scrolling) visible elements are assigned a
> fallback access key. That is because no attempt is made to assign the same
> access key to the same element.

 Well, there's indeed a conflict between trying to assign always the same 
accesskey (which is what I want) and having an accesskey for every element, 
at least visible. For reasons listed below I believe my way is a better 
choice.

>
> I imagne a use like a ping-pong: Request accesskeys - see all available
> elements assigned an access key (or sequence see below) - enter a key( or
> sequence) and have the respective element focused or (in case of an URL
> selected).
>
> * accesskeys may not be only a single key, but also a unique key sequnce.
> That ensures, that there are always enough accesskeys available.

 We already have that: Just press / or ' and start typing. That doesn't work 
with some elements like buttons, but that's exactly why my patch gives those 
higher priority.

> * During building of the fallback access keys the already by the web
> designer assigned keys would be omitted. Also for sequence building. That
> would mean, if all possible access keys are taken by design, there would be
> no keys left to start a sequence for the fallback.
>
> One could argue, that this approach does not have much in common with the
> original idea of access keys. That is true, but an approach like this would
> ensure that each element of a webpage is quickly accessible without using
> the mouse or using ' and having to hit F3 a number of times because of
> equally captioned links (like blogs with "Read more").

 I consider that to be a problem of the type ahead find implementation. It 
should first search visible elements, like it does e.g. in Mozilla. Since 
after the Find Previous fixes now I'm almost an expert on KHTML's find 
implementation ;) , I hope I'll be able to do something with this soon.

 And having too many accesskeys looks really weird with pages with many links, 
e.g. http://seznam.cz looked awfully when I had higher limit in my patch. Not 
to mention that'd need revamping the accesskeys implementation because it now 
supports only one key, not a sequence of them.

> If you like, I can resubmit the work I have done so far, the patch is not
> as functional as I would like it. Namly it does not work yet properly with
> frames and the positioning of tooltips is also far from perfect.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/