#88558 - labels being focusable

Lubos Lunak l.lunak at suse.cz
Tue Oct 19 12:03:31 BST 2004


On Tuesday 19 of October 2004 02:08, Tobias Anton wrote:
> On Samstag, 16. Oktober 2004 19:59, Datschge wrote:
> > On Friday 15 October 2004 18:25, Tobias Anton wrote:
> > > My point is about accessibility. Everything that can be activated
> > > by mouse should be activatable via keyboard as well.
> >
> > Then please check out your code actual behavior. With KDE CVS visiting
> > http://www.gmx.net/de/ and playing with the 'GMX Login' box in the
> > middle right I can indeed click the 'e-mail' and 'Passwort' labels
> > with the mouse, in which cases the keyboard focus is forwarded to the
> > respective input fields. With tab-focussable labels many users will
> > feel like being stuck in the label, since having to press Enter to
> > move on to the respective input field with every other key press
> > sucked up is not increasing accessibility.
>
> But pressing tab again does move focus to the input field, no?

 Yes. Is that supposed to be an excuse for it?

>
> > They will enter the name,
> > tab once, start typing expecting it to go to the password field,
> > notice that the ****ing 'Passwort' label has the focus and all
> > inputted text is lost, tab again to get to the password fielöd not
> > aware that Enter would do that as well.
>
> I think that users will learn about this rather quickly.

 What makes you think so? It's inconsistent with everything else. It's 
annoying. It doesn't make any sense.

> Regardless of 
> that, I'd suggest to keep emotions out of the discussion. Your formulations
> are not constructive. Somehow I feel like canceling this discussion.
> Especially, you won't make me hack around in my code for your interest just
> because you state that you don't like my patch about six weeks after it was
> committed.
>
> > I would suggest either to
> > directly forward the label focus to the respective input field, or at
> > least redirect all the keyboard input to there instead just pretend
> > that no input to act on actually happened.
> >
> > As it behaves now the accessibility feature is more a regression than
> > a real help (I didn't know about Enter for moving to the linked
> > element, and I doubt anybody so far is aware of it, and as an
> > additional key press which is usually considered unnecessary I doubt
> > it's becoming popular).
>
> For disabled users or users with constrained input methods (no mouse), it
> _is_ a real help. Not in the cases you describe, but I can enumerate enough
> counterexamples.

 Such as? So far you have provided only one:

<label for="a_link"> activate me! </label>
blah lots of html with many line breaks blah
<a id="a_link"><img src="picture_link_for_mouse_users.gif"></a>

 It's true that in this case the <a> is really not usable from the keyboard, 
but the <a> is also useless in this case. After adding href to it, it is 
itself focusable, so there's no special need for the label.

> Additionally, as you correctly noticed above, users won't get around
> noticing the new behaviour when they tab through a document with labels for
> the first time. So, if we leave it as is, users would for sure accommodate
> to the change.

 You're kidding, right?

> Alright. I'm not willing to change the user interface behaviour each and
> every time someone finds something to rant about. Maybe you're just lacking
> ability of imagination.

 Sorry, but it is you who is getting emotial here.

> I admit that there's a considerable number of 
> real-world cases in which the new label support is confusing and i also
> recognize that the behaviour could (and maybe should) be changed. But we
> should discuss this thoroughly before rushing in another usability change
> that already has happened. In the discussion, we have to respect the issues
> of impaired users as well which is the reason why we should keep the code
> consistent across input methods.

 Very well.

>
> Imagine for example the case when the label is assigned an
> onactivate-handler on which some action depends. If you can explain how a
> keyboard-only user is supposed to trigger that action, I'll be the first
> one to help implementing a usability improvement for those users that are
> unable to accomodate to a slight change in khtml's tabbing behaviour.

 Oh, it's simple. Labels are not supposed to be activated (meaning _really_ 
activated). They don't work that way in Qt. They don't work that way in other 
browsers. They don't work that way anywhere. Users don't expect labels to be 
focusable, let alone activateable. The only things labels are good for are 
simply being there, showing some text, and moving focus to their real UI 
element after they're "activated".

 Since the label's element is usually right after it, and should be focusable 
if it makes sense, there's no point in labels being focusable. The 
potentional improvement for impaired users is so small compared to the 
annoyance caused to other users. And so far you have provided only two 
made-up examples, which I don't think can stand against the reasons for 
reverting.

-- 
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/




More information about the kfm-devel mailing list