Re: GitHub issue on checkbox and radio button labels

I’ve also seen examples where the input has title which does not fully match e.g. <input title=“First Name” aria-required=true> but the visible text label said <span>First Name*</span>. So the accessible name of the input does not have the “*” star/asterisks. 

It’s not a big negative impact to a user if they have ARIA support and hear the required attribute but they would not hear the * “star” so that seems like it could be fail. One reason it’s risky business not relating your labels to your inputs. 

Paul J. Adam
Accessibility Evangelist 
www.deque.com

> On Nov 20, 2015, at 9:42 AM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> 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 <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
>> 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><mailto: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><mailto: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><mailto:jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>
>> 
>> 703-637-8957 (o)
>> Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup <http://www.facebook.com/#%21/ssbbartgroup>> |
>> Twitter<http://twitter.com/#%21/SSBBARTGroup <http://twitter.com/#%21/SSBBARTGroup>> |
>> LinkedIn<http://www.linkedin.com/company/355266?trk=tyah <http://www.linkedin.com/company/355266?trk=tyah>> |
>> Blog<http://www.ssbbartgroup.com/blog <http://www.ssbbartgroup.com/blog>> | Newsletter<http://eepurl.com/O5DP <http://eepurl.com/O5DP>>
>> 
>> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org <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><mailto: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)
>> 
>>  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