Re: CfC: Checkbox and Radio button labels and 1.3.1

> 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? 
> 
> AWK: We would need to look at that separately.


<p><input type=“checkbox”> Please send me a ton of email</p> 

If the above code with a checkbox with no accessible name inside the same paragraph as a text string passes info and relationships then that would also allow any form error messages and instructions to pass just by being placed inside the same paragraph as well. So there would be no need for aria-describedby to connect input instructions and error messages to their inputs. 

Form control associations are required in my book and I don’t see how putting labels and instructions in the same paragraph could count as an association to the input. 

Thanks!

Paul J. Adam
Accessibility Evangelist 
www.deque.com

> On Dec 5, 2015, at 7:27 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 
> 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? 
> 
> AWK: Based on the call and the 15 attendees there, I believe that people would prefer that the explicit association was required, but agree that WCAG 2.0 doesn’t currently require it.
> 
> 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? 
> 
> AWK: We would need to look at that separately.
> 
> 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’m sure that screen readers would say that they aren’t guessing but that they have algorithms that make a determination that may not account for some cases, and if you test and verify that a particular page works correctly that is due to their algorithm working correctly.  
> 
> I really hope we’re not promoting that these methods can pass WCAG!
> 
> “Promoting" is not what we are doing. The reason that the explicit approaches are in the techniques is because that is what we want to promote.  However, that doesn’t mean that other approaches cannot pass (or avoid failing, take your pick).
> 
> AWK
> 
>> On Dec 4, 2015, at 4:22 PM, Andrew Kirkpatrick <akirkpat@adobe.com <mailto: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 <mailto:akirkpat@adobe.com>
>> http://twitter.com/awkawk <http://twitter.com/awkawk>
>> http://blogs.adobe.com/accessibility <http://blogs.adobe.com/accessibility>
>> 
>> From: "paul.adam@deque.com <mailto:paul.adam@deque.com>"
>> Date: Friday, December 4, 2015 at 16:55
>> To: Andrew Kirkpatrick
>> Cc: "josh@interaccess.ie <mailto: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 
>> www.deque.com <http://www.deque.com/>
>> 
>> 
>> On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com <mailto: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 <mailto:akirkpat@adobe.com>> wrote:
>>> 
>>> Does this make sense to you?  Others?
>> 
>> <PastedGraphic-2.png>
>