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

>Ø  I agree with Andrew here that 4.1.2 includes HTML element and 
>controls – not just custom scripted controls, which is why I generally 
>place requirements and failures for FRAMES under 4.1.2, as one instance 
>of binding HTML elements (and controls), for name and role, in a 
>programmatically determinable way, to AAPIs.
>
>
>
>I actual do agree – [...]  So I would suggest we update it to say 
>something like
>
>
>
>Note: When web authors develop or script their own user interface 
>components the name, role, and value properties may not be implicitly 
>available without being programmatically exposed by the author.
>

I like that suggestion Jonathan, thanks.

Josh
>
>
>
>Jonathan
>
>
>
>Jonathan Avila
>
>Chief Accessibility Officer
>SSB BART Group
>jon.avila@ssbbartgroup.com
>
>703.637.8957 (o)
>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
>From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
>Sent: Tuesday, December 08, 2015 10:13 AM
>To: 'Andrew Kirkpatrick'; Jonathan Avila
>Cc: 'Steve Faulkner'; 'Paul Adam'; josh@interaccess.ie; 'Detlev 
>Fischer'; 'David MacDonald'; 'Makoto UEKI'; 'WCAG'
>Subject: RE: CfC: Checkbox and Radio button labels and 1.3.1
>
>
>
>I agree with Andrew here that 4.1.2 includes HTML element and controls 
>– not just custom scripted controls, which is why I generally place 
>requirements and failures for FRAMES under 4.1.2, as one instance of 
>binding HTML elements (and controls), for name and role, in a 
>programmatically determinable way, to AAPIs.
>
>
>
>​​​​​
>
>
>
>
>
>* katie *
>
>
>
>Katie Haritos-Shea
>Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
>
>
>
>Cell: 703-371-5545 |ryladog@gmail.com|Oakton, VA |LinkedIn 
>Profile|Office: 703-371-5545
>
>
>
>From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
>Sent: Monday, December 7, 2015 10:28 PM
>To:jon.avila@ssbbartgroup.com
>Cc: Steve Faulkner <faulkner.steve@gmail.com>; Paul Adam 
><paul.adam@deque.com>; 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>
>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>
>
>
>Jonathan,
>
>My reading of that is just that the WG felt that 4.1.2 was expected to 
>be handled by the native system for those controls. There is also this 
>note in understanding which confirms to me that 4.1.2 applies for 
>control labeling:
>
>
>
>Note: Success Criterion 4.1.2 requires a programmatically determinable 
>name for all user interface components. Names may be visible or 
>invisible. Occasionally, the name must be visible, in which case it is 
>identified as a label. Refer to the definition of name and label in the 
>glossary for more information.
>
>I too generally agree that 1.1.1 refers to 4.1.2 for controls.
>
>
>
>AWK
>
>Sent from my iPad
>
>
>On Dec 7, 2015, at 7:34 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> 
>wrote:
>
>>As a general FYI – I don’t consider that SC 1.1.1 applies to controls 
>>because of the following passage from the understanding document:
>>
>>
>>
>>Except for the situations listed below... Controls, Input: If non-text 
>>content is a control or accepts user input, then it has a name that 
>>describes its purpose. (Refer to Guideline 4.1 for additional 
>>requirements for controls and content that accepts user input.) 
>>(Understanding SC 1.1.1)
>>
>>
>>
>>Furthermore, I read that standard controls are not covered under SC 
>>4.1.2 as indicated by this note from understanding SC 4.1.2
>>
>>
>>
>>Note: This success criterion is primarily for Web authors who develop 
>>or script their own user interface components. (Understanding SC 
>>4.1.2)
>>
>>
>>
>>So, IMO this is really a SC 3.3.2 and SC 1.3.1 topic and not SC 1.1.1 
>>and not SC 4.1.2 – unless the understanding documents are out of sync 
>>with the groups understanding.
>>
>>
>>
>>Jonathan
>>
>>
>>
>>--
>>Jonathan Avila
>>Chief Accessibility Officer
>>SSB BART Group
>>jon.avila@ssbbartgroup.com
>>
>>
>>
>>703-637-8957 (o)
>>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>>
>>From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
>>Sent: Monday, December 07, 2015 6:35 PM
>>To: Steve Faulkner; Paul Adam
>>Cc:josh@interaccess.ie; Detlev Fischer; David MacDonald; Makoto UEKI; 
>>WCAG
>>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>>
>>
>>
>>><p><input type=“checkbox”> Please send me a ton of email</p>
>>>
>>
>>Apologies, but I am getting confused here.
>>
>>
>>
>>The code example passes 1.3.1 Info and Relationships because the 
>>content is grouped by the <p> element and passes 3.3.2 Labels or 
>>Instructions as the control has a visible prompt, but fails 1.1.1 
>>Non-text Content and 4.1.2 Name, Role, Value as the control does not 
>>have a name.
>>
>>
>>
>>This may or may not pass 1.3.1 and 4.1.2/1.1.1 as a result of the 
>>implied relationship and the assistive technology support for that 
>>relationship.  It is impossible to say that it passes or fails without 
>>that additional information.  If I pick assistive technologies and 
>>browsers that read the accessibility name correctly from that 
>>undesirable markup then I would pass 4.1.2/1.1.1 as it has a 
>>programmatically determinable name and for the same reason I’d pass 
>>1.3.1.  If the name doesn’t get read, then it not only doesn’t have a 
>>programmatically determinable name but since the text that is used for 
>>the 3.3.2 label is right there the fact that it wasn’t recognized is a 
>>sign that the relationship isn’t programmatically determinable either.
>>
>>
>>
>>As a developer, this is just how you don’t want to do this.  You want 
>>to pick a technique that provides greater rigor and predictability, 
>>but for WCAG 2.0 this will not always fail.
>>
>>
>>
>>There are a number of possible methods to resolve the failure state 
>>including:
>>
>>
>>
>>via label
>>
>><p><label><input type=“checkbox”> Please send me a ton of 
>>email</label></p>
>>
>>
>>
>>AWK: This (or with the for/id attributes) is what WCAG techniques 
>>promote in the examples.  Clearly the best, most native way.
>>
>>
>>
>>via aria-label or title attribute
>>
>><p><input type=“checkbox” aria-label="Please send me a ton of email"> 
>>Please send me a ton of email</p>
>>
>>
>>
>>AWK: This also works.  Some people on the list have disagreed saying 
>>that this fails 1.3.1.
>>
>>
>>
>>or via aria-labelledby
>>
>>
>>
>><p id="label"><input type=“checkbox” aria-labelledby="label"> Please 
>>send me a ton of email</p>
>>
>>
>>
>>AWK: yep, also good.
>>
>>
>>
>>Does that help clarify at all Steve, or just mess it up further?
>>
>>
>>
>>AWK
>>