CfC: Checkbox and Radio button labels and 1.3.1

In order to bring this issue in, I suggest a couple of things.

Regarding the original CFC; while it was withdrawn the consensus of the 
group was stated here and I feel this majority view still stands unless 
we have some new information or a proposal is brought to the group. [1]

The decision goes along the line of "WCAG 2.0's success criteria 1.3.1 
does not require that the relationship between the label text and the 
checkbox or radio button be determined only using the explicit 
mechanisms where the label element contains the input element or where 
the label and the input are associated using the 'for' and 'id' 
attributes."

My feeling here is that there are other issues that may not be covered 
by the original CFC that we can discuss. It is our intent to work out if 
there are any gaps in our SCs and this discussion needs to be re-framed 
in order to do this successfully.

There seems to be several layers to this thread (doing my best to unpick 
them as themes, they are in no particular order):

1) Machine readable associations.
2) Clickable labels (in terms of user interaction).
3) Labels may not always need to be explicitly programatically 
associated with their inputs if they can have appropriate title or other 
ARIA semantics applied.
4) Does the use of title and/or ARIA semantics represent sufficient 
identity and relationship data to the user agent/end user and should we 
look at new ways of making these methods satisfy 1.3.1?
5) Implicit vs Explicit programmatic association/determination. We know 
enough about the later, but what can we do to support the former? This 
seems to be a core issue in this thread.

If these don't capture some of the themes let me know. I'm inclined to 
think this thread should be split into sub threads, so feel free to do 
so if you wish to take the discussion is a particular direction. FWIW, 
I'm not convinced that we need to mint an extension as there are enough 
techniques for authors to create accessible forms and they are widely 
available.

I'm also cautious about coming up with new failures, even for edge cases 
or to try to enforce 'best practice'. Andrew phrased it rather well in a 
previous mail when he said:

"Requiring that the code be written in a specific way is also saying 
that it must fail if it isn’t written that way, and to have a failure 
for WCAG (To write a failure technique) requires that the code or markup 
would always fail.

That means, _always_. So unless there is a hard anti pattern that we 
want to mint failures for, it's just best not to.

Currently, I'm not convinced of the need for change. The remit of WCAG 
is 'content'. I don't think anyone here is arguing for looser 
relationships but from a WCAG perspective that may be needed for the 
moment as the environment is diverse explicit relationships in all 
situations may just not work in the long run. There are potentially 
issues here for WCAG.next for sure - and that means bringing in the User 
Agent side.

Thanks

Josh

[1] https://github.com/w3c/wcag/issues/122#issuecomment-158676010