Re: GitHub issue on checkbox and radio button labels

Andrew, IMO this would pass current criteria.

Jon

Sent from my iPhone

On Nov 20, 2015, at 9:52 AM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto: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<mailto: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-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 (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