Re[2]: 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.
This is interesting Paul, and could be something to bring up with the 
HTML5 working group and/or the ARIA group. As obviously use of @title 
like that does imply an explicit relationship that maybe needs a better 
markup pattern to imply author intent?

HTH

Josh

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