Activation behavior of label elements pointing to form-associated custom elements

[annevk]

For existing controls the behavior of the label element depends on the platform. This is not an option for form-associated custom elements since the platform has no idea what kind of controls they represent.

So we need to decide what activating a label element means when it is associated with a form-associated custom element. Always forwarding a click event seems somewhat reasonable?

cc @whatwg/a11y @muan @rakina

[aardrian]

As opposed to focus?

[stevefaulkner]

Suggest as a start all elements with roles that match labelable element roles are treated the same as the native labelled elements in respect to how an associated label behaves.

[domenic]

I think the spec's current intent may still apply to FACEs. It kind of depends on what the actual variance in platform behavior is, but my read is that UAs would use the spec's flexibility to have no activation behavior at all, not to toggle it on a per-element-type basis.

Stated another way, I suspect that all UAs treat all labelable elements the same way, and so the behavior will fall out pretty naturally from the fact that FACEs are labelable elements.

[annevk]

That's somewhat fair, I guess I'd appreciate an explicit note about FACEs.

[domenic]

We could also do some testing to make sure my suspicions are correct, and if they are, perhaps tighten up the spec's requirements a bit, to make it fall out more obviously. But perhaps tightening up requirements is a bad idea here since the full range of ways that a UA might want to help users is probably best left up to the UA and the user's individual situation.

So for now I'll say that the way to resolve this is to add a note to https://html.spec.whatwg.org/multipage/forms.html#the-label-element after the current text of

The label element's exact default presentation and behavior, in particular what its activation behavior might be, if anything, should match the platform's label behavior. The activation behavior of a label element for events targeted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing.

which says something like

NOTE: form-associated custom elements are labelable elements, so for user agents where the label elements' activation behavior impacts the labeled control, both built-in and custom form-associated elements will be impacted.

and maybe expand the "For example, on platforms where clicking a checkbox label checks the checkbox" example with a custom element code snippet that exemplifies the parallel.

[annevk]

One other thing is that label can be activated and this causes the control it points towards to also match :active. Given how that's currently defined (one definition of active is mouse down) that should always work and would be testable.