Re: GitHub issue on checkbox and radio button labels

correct
the requirement is not that it be programmatically connected — but that the relationship between the label and the control be programmatically determinable if it can be visually determinable (for example). 

g



> On Nov 19, 2015, at 1:36 PM, John Foliot <john.foliot@deque.com> wrote:
> 
> Paul Adam wrote:
> > 
> > 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
> > 
> > Is there a definition in WCAG for the term "or are available in text.” 
> > 
> > So a title attribute can create not just an accessible name 4.1.2 but also a relationship connection 1.3.1? I could see the argument for aria-labelledby as that’s an association but aria-label or title are not connecting anything programmatically to the input. 
>  
>  
> I think WCAG’s non-normative text is fairly clear here:
>  
> From Understanding SC 1.3.1 - Examples of Success Criterion 1.3.1 
> ( http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#content-structure-separation-programmatic-examples-head <http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#content-structure-separation-programmatic-examples-head>)   
>  
> A form where the labels for the checkboxes can be programmatically determined: 
>                In a form, the labels for each checkbox can be programmatically determined by assistive technology.
> [JF: AT no time does SC 1.3.1 speak to “association” nor “connection” – simply AND EXCLUSIVELY programmatic determination]
>  
> And then from Understanding SC 1.3.1 - Key Terms: 
> (http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#key-terms <http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#key-terms>) 
>  
> programmatically determined (programmatically determinable) 
>  
>     determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
>  
>     Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
>  
> [JF: <label> is an element, aria is a collection of attributes. My read here is that either is acceptable, as long as they are ”accessed directly by commonly available assistive technology”. This is achieved via the Accessibility APIs where the Accessible Name is programmatically associated to the form input, and can then subsequently be programmatically determined.]
>  
>  
> Next, go here: http://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-calculation <http://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-calculation> (Mapping form inputs)
> HTML Accessibility API Mappings 1.0
> 5.5 Other Form Elements
> Other Form Elements Accessible Name Calculation (This includes checkbox and radio button)
> 
> Use aria-labelledby
> Otherwise use aria-label
> Otherwise use label element
> Otherwise use title attribute
> If none of the above yield a usable text string there is no accessible name
>  
> [JF: Translation: The various Accessibility APIs will try to determine the “Accessible Name” of a form input using the above 5 listed solutions, IN THAT ORDER. Once the Accessible Name has been determined, the processing stops. This then establishes the ‘relationship’ to the Accessibility API, and binds it “programmatically” - and subsequently meeting the WCAG requirement. “
>  
> In practice, using the title attribute is not a great idea, as many AT’s have elected to ignore that under most circumstances – the exception being when used in Forms. Even then, the combined specs agree that @title is the last resort:
> “…with HTML title attribute having the lowest precedence…”
>  
>  
>  
> What Paul appears to be arguing for is better *usability*, and I think that none of us would disagree that improved usability is a worthwhile goal. But from my years of working with WCAG 2 I’ve never actually seen a Success Criteria mandate a specific behavior or even user pattern – in actual fact it seems that this was studiously avoided. This is also one of the reasons why many of the Success Criteria have multiple Techniques.
>  
> Based on this, I would suggest the following:
>  
> For best Usability, use the <label> element with your checkboxes, as it will make the associated (programmatically determinable) Accessible name also “interactive” (in that you can click on it with a mouse… if of course you are using a mouse). I’ll note here as well that all form inputs automatically are in the document’s tab-order, so *another* way of placing focus on a checkbox would be to tab to it (but again, WCAG doesn’t mandate that behavior either).
>  
> For determining conformance to WCAG however, any of the four options noted above - use aria-labelledby, otherwise use aria-label, otherwise use label element, or use title attribute - will meet the Success Criteria’s requirement for “…labels for each checkbox can be programmatically determined by assistive technology.”
>  
> JF