#88558 - labels being focusable

[Tobias Anton]

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?

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

Besides, pressing Enter on a focused element is not too far-fetched from a 
usability point of view and i'm sure that the second keypress (after "tab") a 
user will try when a label is focused will be either space or enter.

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.

> > Maybe, however, only those labels need to be focusable that carry a
> > for-attribute which points to an element outside the label.
>
> ...and not straight after the label but only when some other visible
> text/data is in-between separating label and the linked-to element.

How exactly would you determine that? Please explain along with a piece of 
C++-code. Maybe you could put that code into 
htmllabelelementimpl::isSelectable and send a patch?

> This is the only case of labels where I can imagine labels being used
> as kind of anchor links when using keyboard navigation might actually
> be useful.

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

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.

Cheers
-- Tobias