Re[2]: CfC: Checkbox and Radio button labels and 1.3.1

>Hi Josh, I would definitely be happy to join a call if folks would like 
>to discuss the issue.

Great stuff Paul, I think that would be helpful :-)

Thanks

Josh

>
>>As to the first point, I don't understand how a user is supposed to 
>>click on a non-visible label in the first place? Could you comment 
>>further on what you are thinking? Do you mean that even if a label 
>>isn't visible the 'hit area' may still be active as if there was a 
>>visible label?
>
>The requirement is that if a label is visible it must have a 
>relationship association. I’m not talking about controls that don’t 
>have visible labels. For example this code: <p><input type=“checkbox”> 
>Please send me a ton of email</p> fails info and relationships because 
>the is no association from label to control.
>
>Thanks!
>
>Paul J. Adam
>Accessibility Evangelist
>www.deque.com
>
>>On Dec 5, 2015, at 4:07 AM, josh@interaccess.ie wrote:
>>
>>Paul,
>>
>>Just to be clear - the original thread brought up a couple of 
>>interesting issues.
>>
>>1)  There are no examples of radio button or checkbox without a 
>>visible label that is programmatically connected to the input so that 
>>you can click on the label to check the checkbox or radio button.
>>
>>2) You raised the issue that always having a clickable label is a 
>>desirable thing. In many cases the larger the better, as it makes 
>>these controls accessible to many users. All well and good, and no-one 
>>in the group would say this is a bad thing.
>>
>>However, to comment on the second item first, and on clickable labels 
>>in general -  it just may not be desirable in *all* cases to mandate 
>>that developers do this - it may not be a suitable pattern depending 
>>on the environment, the way a form is put together etc. This is one of 
>>the main blockers to your original suggestion/issue IMO. So we are 
>>hesitant in suggesting that the group takes this direction. Yes, we 
>>have spoken about this at length on the calls and are discussing it 
>>here and the consensus supports our decision to leave things as they 
>>are. Again, no one is saying that per say, clickable labels are bad 
>>but they may just not be appropriate in all situations and our spec 
>>needs to provide gestalt guidance, and then as you drill down into our 
>>resources - specific suitable techniques that support a wide range of 
>>use cases.
>>
>>As to the first point, I don't understand how a user is supposed to 
>>click on a non-visible label in the first place? Could you comment 
>>further on what you are thinking? Do you mean that even if a label 
>>isn't visible the 'hit area' may still be active as if there was a 
>>visible label?
>>
>>Finally, on the first point, as Andrew points out we have existing 
>>examples of there inputs can be connected to visible label via 
>>aria-labelledby by and for/id combinations and even when there are no 
>>labels you can use the well supported @title attribute on <input> 
>>elements. All good. So no-one is arguing against programmatically 
>>determined relationships, and we are aware that we need to keep our 
>>techniques up to date as development and design patterns change (and 
>>are actively working on this).
>>
>>So I look forward to more input from you on this, actually it would be 
>>great if you could attend a call to discuss - as this topic is 
>>interesting nuanced discussion - and may point the way to wider issues 
>>that the group need to deal with.
>>
>>Thanks
>>
>>Josh
>>
>>
>>
>>------ Original Message ------
>>From: "Paul Adam" <paul.adam@deque.com>
>>To: "Andrew Kirkpatrick" <akirkpat@adobe.com>
>>Cc: "josh@interaccess.ie" <josh@interaccess.ie>; "Detlev Fischer" 
>><detlev.fischer@testkreis.de>; "David MacDonald" 
>><david100@sympatico.ca>; "Makoto UEKI" <ueki@infoaxia.com>; "WCAG" 
>><w3c-wai-gl@w3.org>
>>Sent: 05/12/2015 00:45:59
>>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>>
>>>All modern screen readers determine aria-labelledby properly, if not 
>>>let’s file a bug report.
>>>
>>>aria-labelledby is an explicit association between an element and the 
>>>id of another element whereas a checkbox and a text string inside the 
>>>same paragraph have no explicit association and I don’t see how they 
>>>could have a relationship just because they’re in the same paragraph. 
>>>I understand that passes for link purpose in context but I didn’t 
>>>think for info and relationships?
>>>
>>>Does that mean that form inputs with error messages below the input 
>>>or input format instructions don’t really need to be associated with 
>>>the error and info strings? They can just be in the same paragraph? 
>>>Or in close proximity?
>>>
>>>I did not think that you could claim WCAG conformance based on how 
>>>good of a guesser a particular screen reader is. I know that JAWS 
>>>does lots of guessing and VoiceOver does some as well whereas NVDA 
>>>does not.
>>>
>>>I really hope we’re not promoting that these methods can pass WCAG!
>>>
>>>Thanks!
>>>
>>>Paul J. Adam
>>>Accessibility Evangelist
>>>http://www.deque.com/
>>>
>>>>On Dec 4, 2015, at 4:22 PM, Andrew Kirkpatrick <akirkpat@adobe.com> 
>>>>wrote:
>>>>
>>>>Paul,
>>>>When using aria-labelledby which screen readers can determine the 
>>>>label of the checkbox?  Which ones determine this properly?  Of 
>>>>course, not all do (yet) and the way that you determine is to test 
>>>>it.
>>>>
>>>>Does the less-than-ideal code I suggested pass with all user agents? 
>>>>  Undoubtedly not.  Does it pass with some?  Yes, and if those are 
>>>>the user agents that I use to base my accessibility support claim 
>>>>then that would be how I’d justify the pass.
>>>>
>>>>The relationship can be implicit as well as explicit and I believe 
>>>>that also includes the case where you have:
>>>>
>>>><input type=“checkbox” title=“Please send me a ton of email”> Please 
>>>>send me a ton of email
>>>>
>>>>I’ll re-emphasize that there is no doubt that using the explicit 
>>>>approaches are better, but the thinking expressed on the call I 
>>>>believe was that even though the other approaches are not as good 
>>>>that we can’t state that they fail.
>>>>
>>>>Thanks,
>>>>AWK
>>>>
>>>>Andrew Kirkpatrick
>>>>Group Product Manager, Accessibility
>>>>Adobe
>>>>
>>>>akirkpat@adobe.com
>>>>http://twitter.com/awkawk
>>>>http://blogs.adobe.com/accessibility
>>>>
>>>>From: "paul.adam@deque.com"
>>>>Date: Friday, December 4, 2015 at 16:55
>>>>To: Andrew Kirkpatrick
>>>>Cc: "josh@interaccess.ie", Detlev Fischer, David MacDonald, Makoto 
>>>>UEKI, WCAG
>>>>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>>>>
>>>>Hi Andrew, no this does not make sense to me.
>>>>
>>>><PastedGraphic-2.png>
>>>>
>>>><p><input type=“checkbox”> Please send me a ton of email</p>
>>>>
>>>>You’re saying that this passes info and relationships? Because 
>>>>they’re in the same paragraph? It passes in screen readers that can 
>>>>guess the label of the checkbox? Which ones guess properly?
>>>>
>>>>I’m not saying that WCAG requires the code to be written in a 
>>>>specific way, I’m saying that it requires the relationship 
>>>>association and I don’t see how a title attribute that duplicates 
>>>>the visible label text or a checkbox inside the same paragraph as 
>>>>the visible label text counts as a relationship association.
>>>>
>>>>Thank you all for discussing the issue!
>>>>
>>>>Paul J. Adam
>>>>Accessibility Evangelist
>>>>http://www.deque.com/
>>>>
>>>>
>>>>On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com> 
>>>>wrote:
>>>>
>>>>In the instance of a control that is implicitly associated with a 
>>>>label that may even meet 1.3.1 as well as 4.1.2 through the implicit 
>>>>means:
>>>><p><input type=“checkbox”> Please send me a ton of email</p>
>>>>
>>>>>On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com> 
>>>>>wrote:
>>>>>
>>>>>Does this make sense to you?  Others?
>>>>
>>>><PastedGraphic-2.png>
>>>
>>
>