RE: GitHub issue on checkbox and radio button labels

> Maybe a failure technique needs to be added to demonstrate  such situations?

I agree.  Having a failure for such a situation would allow us to provide guidance on the subject and set some expectation of what an implied relationship must be and is not.

Jonathan

-- 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com

703-637-8957 (o) 
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: Sailesh Panchang [mailto:sailesh.panchang@deque.com] 
Sent: Friday, November 20, 2015 10:42 AM
To: Andrew Kirkpatrick
Cc: Gregg Vanderheiden RTF; Jonathan Avila; John Foliot; Paul Adam; GLWAI Guidelines WG org
Subject: Re: GitHub issue on checkbox and radio button labels

Andrew,
Your example  is a certain "pass" but the one below may not  be so clear:
If non-PD visible label is "Phone number (10 digits)" but title / aria-label is "Phone number", or non-PD visible label is "First name" and title or aria-label is "Name"

Maybe a failure technique needs to be added to demonstrate  such situations?
Best regards,
Sailesh Panchang


On 11/20/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> So, just as an actual example, here’s one possible bit of code that 
> one might encounter:
>
> <p>What is your favorite color?</p>
> <input type="radio” name=“aa” value=“a1” title="What is your favorite
> color?: Red"> Red<br>
> <input type="radio” name=“aa” value=“a2” title="What is your favorite
> color?: Blue"> Blue<br>
> …
>
> And yes, one would be better off doing this, but we aren’t talking 
> about what is better, we are talking about what is sufficient to meet 
> the standard we have today, whether we like the standard or don't:
> <fieldset><legend>What is your favorite color?</legend> <label><input 
> type="radio" value="a1"> Red</label> <label><input type="radio" 
> value="a2"> Blue</label> ...
> </fieldset>
>
> What do people think, does the first, less-well coded example pass 1.3.1?
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk

> http://blogs.adobe.com/accessibility

>
> From: CAE-Vanderhe
> Date: Thursday, November 19, 2015 at 20:21
> To: Jonathan Avila
> Cc: John Foliot, "paul.adam@deque.com<mailto:paul.adam@deque.com>", 
> Andrew Kirkpatrick, WCAG
> Subject: 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<mailto: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)
>
> 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-separatio

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

> culation
> (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)
>
>   1.  Use aria-labelledby
>   2.  Otherwise use aria-label
>   3.  Otherwise use label element
>   4.  Otherwise use title attribute
>   5.  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
>
>

Received on Friday, 20 November 2015 16:24:27 UTC