Re: GitHub issue on checkbox and radio button labels

Yes I'd agree with a failure based on Sailesh's example:

Failure of 1.3.1 due to programmatic label not providing equivalent
information as the visible label.

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Nov 20, 2015 at 11:23 AM, Jonathan Avila <jon.avila@ssbbartgroup.com
> wrote:

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