RE: GitHub issue on checkbox and radio button labels

+1 to Jon. 

 

It's ugly, but it works. If I was doing an evaluation, I would have to Pass
it (as opposed to Fail it). In a teachable moment scenario I'd certainly
seize the opportunity to advocate for something better, but I could not use
"compliance to WCAG" as a justification for the better code pattern. I'd
instead focus on why the better code pattern is better from the usability
perspective.

 

Be the fireman, not the cop.

 

JF

 

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
Sent: Friday, November 20, 2015 9:06 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>; John Foliot
<john.foliot@deque.com>; Paul Adam <paul.adam@deque.com>; GLWAI Guidelines
WG org <w3c-wai-gl@w3.org>
Subject: 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 
 <mailto:jon.avila@ssbbartgroup.com> jon.avila@ssbbartgroup.com

 

703-637-8957 (o) 
Follow us:  <http://www.facebook.com/#%21/ssbbartgroup> Facebook |
<http://twitter.com/#%21/SSBBARTGroup> Twitter |
<http://www.linkedin.com/company/355266?trk=tyah> LinkedIn |
<http://www.ssbbartgroup.com/blog> Blog |  <http://eepurl.com/O5DP>
Newsletter

 

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 < <mailto:john.foliot@deque.com>
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-prog
rammatic.html#content-structure-separation-programmatic-examples-head>
http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-progr
ammatic.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-prog
rammatic.html#key-terms>
http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-progr
ammatic.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-calculat
ion>
http://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-calculati
on (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