Re: GitHub issue on checkbox and radio button labels

Sorry to be cryptic

by  “relationship between the label and the control…”  I just meant that this label went with that control. 

and yes - accessible names (if they are different than the visible names) should have the same meaning. 

Gregg


> 
> On Nov 19, 2015, at 3:30 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> 
> Ø  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). 
>  
> Gregg, I agree with you on the programmatically connected statement, however, I would very much like to get more information from you on what “relationship between the label and the control...” means.  Does this mean the programmatic name must match – what criteria can we use to be sure the relationship is there other than the label text and the accessible name are similar or mean the same thing, and include all relevant details such as required state, etc.
>  
> Thank you.
>  
> Jonathan
>  
> -- 
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
>  
> 703-637-8957 (o) 
> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>  
> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
> Sent: Thursday, November 19, 2015 1:49 PM
> To: John Foliot
> Cc: Paul Adam; Jonathan Avila; Andrew Kirkpatrick; GLWAI Guidelines WG org
> Subject: 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 <mailto: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