#88558 - labels being focusable

Fri Oct 22 13:47:06 BST 2004

Selon Lubos Lunak <l.lunak at suse.cz>:

> On Friday 22 of October 2004 02:55, Tobias Anton wrote:
> > On Mittwoch, 20. Oktober 2004 14:41, Lubos Lunak wrote:
> > > > In which spec did you read that?
> > >
> > >  In the spec called "My user experience says it is that way everywhere".
> >
> > That's exactly what I did _not_ ask for.
>
>  Sorry, but that's the spec that usually counts the most.

I agree. But here the specs are stupid, ergonomicly talking :)
I'll explain just after.

> [...]
>  "When a LABEL element receives focus, it passes the focus on to its
> associated control."
>
>  That's the only thing said about focus, it doesn't say anything about ways
> of
> receiving it or similar. If this is not the right spec or it's stated
> elsewhere, then please be so kind and spend a couple of seconds on saving me
> a lot of searching.

Wrong !
The spec totally defines what is to "focus" :
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.11
Moreover the specs says "on to its associated control" :
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.2.1
Regarding this a link "A" is not a control and so authors won't use "id" of
links in the "for" attribute. So what will browers do if the id is not one of a
control ? That's the real question.

> > > 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)
> >
> > This is a false assumption and will remain so even if you repeat that a
> > million times.
>
>  While your opposite assumption is true, even though you haven't provided a
> single proof for it, although explicitly asked?
>
>  Ok, let's make this simple:
>
> a) the element is right after the label in focus tab - just not having the
> label in tab order will in practice be the same like the label receiving the
> focus and forwarding it to the element
>
> b) the label is not right before the matching element; for the lack of real
> world example let's consider this:
> <html>
> <body>
> <label for="zelva">label</label>
> <br>
> <a href="/">kuku</a>
> <br>
> <a href="/tmp/" id="zelva">zelva</a>
> <br>
> </body>
> </html>

Sorry but your example is bad :)
"label" is used for "control".
If you want an example see my blog :
http://infernal.quack.free.fr/index.php?2004/07/03/2-new-look#co

You can see a form using labels. All labels are before associated controls
except for "checkbox" where labels are currently after (See "Se souvenir de mes
informations" at the bottom of the page).

Now imagine that the focus goes to the checkbox then pressing Tab goes to the
label. Specs says that focus will come back to the "associated control" so the
checkbox. The user can't navigate with tab. The focus won't go after this label
:)

The problem is the same with Shift+Tab with other controls.
So the as you says after : this specs breaks the tab order.

Now imagine than you focus on the checkbox but the tab order is taken from the
label so you can continue your navigation with tab. So when a control is
focused, the browser has to remember from where it come from (direct focus or
indirect via label). It will be an implementation that can fit both "label" and
"tab order" specs.

The problem is that with this implementation you go throw the label and the
control and it is clearly bad ergonomicly talking : 2 focus for one control :(

That's why other browsers decided that "focus" is only for "mouse focus". It
doesn't respect specs but it is the better between don't disturbing user and
respecting specs.

So specs or ergonomy ? :)

And what about "for" attribute using id of non-control types ?

Franck