#88558 - labels being focusable

[Lubos Lunak]

On Tuesday 19 of October 2004 20:01, Tobias Anton wrote:
> On Dienstag, 19. Oktober 2004 13:03, Lubos Lunak wrote:
> > > 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".
>
> In which spec did you read that?

 In the spec called "My user experience says it is that way everywhere". In 
which spec have you read that labels should be Tab focusable?

>
> >  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.
>
> "Usually" is different to "generally", however. Let's try to think of a
> general solution.
>
> > The potentional improvement for impaired users is so small compared to
> > the annoyance caused to other users.
>
> That's your opinion. I think differently. Mainly because I consider the
> annoyance for mouse-clickers less grave than you do.

 Ehm? There is no annoyance for mouse-clickers, they do click whatever they 
want, and generally don't use the keyboard for things like this. This is 
annoyance for keyboard users (and, if I understand this correctly, also 
includes most impaired users).

>
> > And so far you have provided only two
> > made-up examples,
>
> I just enumerated one counterexample for each example provided by you and
> "Datschge". We can continue with this as long as you like...

 You provided the <label> for <a> example, on which I already commented in my 
previous mail. I don't see any other reason from you for the change other 
than the generic 'better accessibility' kind of comments.

 Moreover, you commented on my reasoning with "That's your opinion. I think 
differently."

>
> > which I don't think can stand against the reasons for reverting.
>
> Whatever we decide on that, reverting the patch cannot be the solution.
> Please read the spec and fix it the right way instead of wasting time with
> long, redundant and destructive arguments.

 Oh please, you're getting silly.

> But be aware that the spec is not very precise on the focusability of
> labels. If there are doubts about how to read the spec, we can discuss it
> here. But please stop explaining the situation to me - it's understood.

1. the spec is not precise on the focusability of labels
2. labels are not focusable in others browsers
3. labels are not focusable in other forms of GUI (Qt,...)
4. labels in almost all cases directly precede their matching UI element in 
the tab order (and the rest can be probably considered broken UI)
5. all UI elements which can be activated should be focusable (this is kind of 
implied from your accessibility reasoning, if nothing else)

 conclusion =>

 Labels in the tab order only steal focusing from their matching UI element, 
for no benefit.

(Hmm, if I dropped that 'almost' which is probably something like 99,999%[*], 
I'd be probably even able to prove the validity of this mathematically, if I 
still remembered that from the uni).

Your accessibility reasoning is wrong, because if the user would be able to 
focus the label, they would be able as well to focus the UI element, and if 
that's not focusable, then that's not the label's problem.

 Reverting the patch is _the_ solution.

[*] Perhaps you know some URL where the label is far from the element and 
needs to be activated?

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